Add a test script for all archive attributes and their handling in
normal and bare repositories. export-ignore and export-subst are
tested, as well as the effect of the option --worktree-attributes.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This instructs attr mechanism, not to look into working .gitattributes
at all. Needed by tools that does not handle working directory, such
as "git archive".
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When interpreting a config value, the config parser reads in 1+ space
character(s) and puts -one- space character in the buffer as soon as
the first non-space character is encountered (if not inside quotes).
Unfortunately the buffer size check lacks the extra space character
which gets inserted at the next non-space character, resulting in
a crash with a specially crafted config entry.
The unit test now uses Java to compile a platform independent
.NET framework to output the test string in C# :o)
Read: Thanks to Johannes Sixt for the correct printf call
which replaces the perl invocation.
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitk: Avoid crash if closed while reading references
As recorded in msysGit issue 125, if the user closes gitk while it
reports itself as still reading references then Tk will crash in the
geometry management code. This has been fixed for Tk 8.5.7 and above.
This patch avoids the problem by flushing outstanding geometry events
before calling the readrefs procedure.
See also http://code.google.com/p/msysgit/issues/detail?id=125
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Handle external diff tool with spaces in the path
This fixes the launching of external diff to handle a diff tool
that has spaces in the path. This ensures a correctly formed
tcl list is passed to the open command with a single pipe character
prefixing the list (as per the tcl manual page for open).
The specific fault observed was that selecting WinMerge as the diff
tool from the default installed location in Program Files failed to
be launched from the context menu.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
The original implementation considered the mode separately
from the rest of the hunks, asking about it outside the main
hunk-selection loop. This patch instead places a mode change
as the first hunk in the loop. This has two advantages:
1. less duplicated code (since we use the main selection
loop). This also cleans up an inconsistency, which is
that the main selection loop separates options with a
comma, whereas the mode prompt used slashes.
2. users can now skip the mode change and come back to it,
search for it (via "/mode"), etc, as they can with other
hunks.
To facilitate this, each hunk is now marked with a "type".
Mode hunks are not considered for splitting (which would
make no sense, and also confuses the split_hunk function),
nor are they editable. In theory, one could edit the mode
lines and change to a new mode. In practice, there are only
two modes that git cares about (0644 and 0755), so either
you want to move from one to the other or not (and you can
do that by staging or not staging).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
There's already 'd' to stop staging hunks in a file, but no explicit
command to stop the interactive staging (for the current files and the
remaining ones). Of course you can do 'd' and then ^C, but it would be
more intuitive to allow 'quit' action.
builtin-apply: keep information about files to be deleted
Example correct diff generated by `diff -M -B' might look like this:
diff --git a/file1 b/file2
similarity index 100%
rename from file1
rename to file2
diff --git a/file2 b/file1
similarity index 100%
rename from file2
rename to file1
Information about removing `file2' comes after information about creation
of new `file2' (renamed from `file1'). Existing implementation isn't able to
apply such patch, because it has to know in advance which files will be
removed.
This patch populates fn_table with information about removal of files
before calling check_patch() for each patch to be applied.
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
rev-parse: --abbrev-ref option to shorten ref name
This applies the shorten_unambiguous_ref function to the object name.
Default mode is controlled by core.warnAmbiguousRefs. Else it is given as
optional argument to --abbrev-ref={strict|loose}.
This should be faster than 'git for-each-ref --format="%(refname:short)" <ref>'
for single refs.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
doc/checkout: split checkout and branch creation in synopsis
These can really be thought of as two different modes, since
the "<branch>" parameter is treated differently in the two
(in one it is the branch to be checked out, but in the other
it is really a start-point for branch creation).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
doc/checkout: refer to git-branch(1) as appropriate
Most of description for the branch creation options is
simply cut and paste from git-branch. There are two reasons
to fix this:
1. It can grow stale with respect to what's in "git
branch" (which it is now is).
2. It is not just an implementation detail, but rather the
desired mental model for the command that we are using
"git branch" here. Being explicit about that can help
the user understand what is going on.
It also makes sense to strip the branch creation options
from the synopsis, as they are making it a long,
hard-to-read line. They are still easily discovered by
reading the options list, and --track is explicitly
referenced when branch creation is described.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
doc: refer to tracking configuration as "upstream"
The term "tracking" often creates confusion between remote
tracking branches and local branches which track a remote
branch. The term "upstream" captures more clearly the idea
of "branch A is based on branch B in some way", so it makes
sense to mention it.
At the same time, upstream branches are used for more
than just git-pull these days; let's mention that here.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In particular, pushing the "path_name()" call _into_ the show() function
would seem to allow
- more clarity into who "owns" the name (ie now when we free the name in
the show_object callback, it's because we generated it ourselves by
calling path_name())
- not calling path_name() at all, either because we don't care about the
name in the first place, or because we are actually happy walking the
linked list of "struct name_path *" and the last component.
Now, I didn't do that latter optimization, because it would require some
more coding, but especially looking at "builtin-pack-objects.c", we really
don't even want the whole pathname, we really would be better off with the
list of path components.
Why? We use that name for two things:
- add_preferred_base_object(), which actually _wants_ to traverse the
path, and now does it by looking for '/' characters!
- for 'name_hash()', which only cares about the last 16 characters of a
name, so again, generating the full name seems to be just unnecessary
work.
Anyway, so I didn't look any closer at those things, but it did convince
me that the "show_object()" calling convention was crazy, and we're
actually better off doing _less_ in list-objects.c, and giving people
access to the internal data structures so that they can decide whether
they want to generate a path-name or not.
This patch does that, and then for people who did use the name (even if
they might do something more clever in the future), it just does the
straightforward "name = path_name(path, component); .. free(name);" thing.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
process_{tree,blob}: show objects without buffering
Here's a less trivial thing, and slightly more dubious one.
I was looking at that "struct object_array objects", and wondering why we
do that. I have honestly totally forgotten. Why not just call the "show()"
function as we encounter the objects? Rather than add the objects to the
object_array, and then at the very end going through the array and doing a
'show' on all, just do things more incrementally.
Now, there are possible downsides to this:
- the "buffer using object_array" _can_ in theory result in at least
better I-cache usage (two tight loops rather than one more spread out
one). I don't think this is a real issue, but in theory..
- this _does_ change the order of the objects printed. Instead of doing a
"process_tree(revs, commit->tree, &objects, NULL, "");" in the loop
over the commits (which puts all the root trees _first_ in the object
list, this patch just adds them to the list of pending objects, and
then we'll traverse them in that order (and thus show each root tree
object together with the objects we discover under it)
I _think_ the new ordering actually makes more sense, but the object
ordering is actually a subtle thing when it comes to packing
efficiency, so any change in order is going to have implications for
packing. Good or bad, I dunno.
- There may be some reason why we did it that odd way with the object
array, that I have simply forgotten.
Anyway, now that we don't buffer up the objects before showing them
that may actually result in lower memory usage during that whole
traverse_commit_list() phase.
This is seriously not very deeply tested. It makes sense to me, it seems
to pass all the tests, it looks ok, but...
Does anybody remember why we did that "object_array" thing? It used to be
an "object_list" a long long time ago, but got changed into the array due
to better memory usage patterns (those linked lists of obejcts are
horrible from a memory allocation standpoint). But I wonder why we didn't
do this back then. Maybe there's a reason for it.
Or maybe there _used_ to be a reason, and no longer is.
* jk/show-upstream:
branch: show upstream branch when double verbose
make get_short_ref a public function
for-each-ref: add "upstream" format field
for-each-ref: refactor refname handling
for-each-ref: refactor get_short_ref function
* fg/remote-prune:
add tests for remote groups
git remote update: Fallback to remote if group does not exist
remote: New function remote_is_configured()
git remote update: Report error for non-existing groups
git remote update: New option --prune
builtin-remote.c: Split out prune_remote as a separate function.
* cc/bisect-filter: (21 commits)
rev-list: add "int bisect_show_flags" in "struct rev_list_info"
rev-list: remove last static vars used in "show_commit"
list-objects: add "void *data" parameter to show functions
bisect--helper: string output variables together with "&&"
rev-list: pass "int flags" as last argument of "show_bisect_vars"
t6030: test bisecting with paths
bisect: use "bisect--helper" and remove "filter_skipped" function
bisect: implement "read_bisect_paths" to read paths in "$GIT_DIR/BISECT_NAMES"
bisect--helper: implement "git bisect--helper"
bisect: use the new generic "sha1_pos" function to lookup sha1
rev-list: call new "filter_skip" function
patch-ids: use the new generic "sha1_pos" function to lookup sha1
sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
rev-list: pass "revs" to "show_bisect_vars"
rev-list: make "show_bisect_vars" non static
rev-list: move code to show bisect vars into its own function
rev-list: move bisect related code into its own file
rev-list: make "bisect_list" variable local to "cmd_rev_list"
refs: add "for_each_ref_in" function to refactor "for_each_*_ref" functions
quote: add "sq_dequote_to_argv" to put unwrapped args in an argv array
...
mergetool--lib: simplify API usage by removing more global variables
The mergetool--lib scriplet was tricky to use because it relied upon
the existance of several global shell variables. This removes more
global variables so that things are simpler for callers.
A side effect is that some variables are recomputed each time
run_merge_tool() is called, but the overhead for recomputing
them is justified by the simpler implementation.
Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Wed, 8 Apr 2009, Björn Steinbrink wrote:
>
> The name of the processed object was duplicated for passing it to
> add_object(), but that already calls path_name, which allocates a new
> string anyway. So the memory allocated by the xstrdup calls just went
> nowhere, leaking memory.
Ack, ack.
There's another easy 5% or so for the built-in object walker: once we've
created the hash from the name, the name isn't interesting any more, and
so something trivial like this can help a bit.
Does it matter? Probably not on its own. But a few more memory saving
tricks and it might all make a difference.
This test was added recently (5a688fe, "core.sharedrepository = 0mode"
should set, not loosen; 2009-03-28). It checked the result of a sed
invocation for emptyness, but in some cases it forgot to print anything
at all, so that those checks would never be false.
Due to this mistake, it went unnoticed that the files in objects/info are
not necessarily 0440, but can also be 0660. Because the 0mode setting
tries to guarantee that the files are accessible only to the people they
are meant to be used by, we should only make sure that they are readable
by the user and the group when the configuration is set to 0660. It is a
separate matter from the core.shredrepository settings that w-bit from
immutable object files under objects/[0-9a-f][0-9a-f] directories should
be dropped.
COMMIT_EDITMSG is still world-readable, but it (and any transient files
that are meant for repositories with a work tree) does not matter. If you
are working on a shared machine and on a sekrit stuff, the root of the
work tree would be with mode 0700 (or 0750 to allow peeking by other
people in the group), and that would mean that .git/COMMIT_EDITMSG in such
a repository would not be readable by the strangers anyway.
Also, in the real-world use case, .git/COMMIT_EDITMSG will be given to an
arbitrary editor the user happens to use, and we have no guarantee what it
does (e.g. it may create a new file with umask and replace, it may rewrite
in place, it may leave an editor backup file but use umask to create it,
etc.), and the protection of the file lies majorly on the protection of
the root of the work tree.
This test cannot be run on Windows; it requires POSIXPERM when merged to
'master'.
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
documentation: Makefile accounts for SHELL_PATH setting
Ensure that the Makefile that generates and installs the Documentation is
aware of any SHELL_PATH setting. Use this value if found or the current
setting for SHELL if not. This is an accommodation for systems where sh
is not POSIX enough.
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca> Signed-off-by: Junio C Hamano <gitster@pobox.com>
I told people on the kernel mailing list to please use "-M" when sending
me rename patches, so that I can see what they do while reading email
rather than having to apply the patch and then look at the end result.
I also told them that if they want to make it the default, they can just
add
[diff]
renames
to their ~/.gitconfig file. And while I was thinking about that, I wanted
to also check whether you can then mark individual projects to _not_ have
that default in the per-repository .git/config file.
And you can't. Currently you cannot have a global "enable renames by
default" and then a local ".. but not for _this_ project". Why? Because if
somebody writes
[diff]
renames = no
we simply ignore it, rather than resetting "diff_detect_rename_default"
back to zero.
Fixed thusly.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace ",<,>,& with their respective XML entities in DAV requests
If the repo url or the user email contain XML special characters, the
remote DAV server is likely to reject the LOCK requests because the XML
is then malformed.
Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: always initialize with core.autocrlf=false
It has been reported time and time again in relation to msysGit that
git-svn does not work well when core.autocrlf has any value other than
'false'. So let's make it so by default.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update delta compression message to be less misleading
In the case of a small repository, pack-objects is smart enough to not
start more threads than necessary. However, the output to the user always
reports the value of the pack.threads configuration and not the real
number of threads to be used.
Signed-off-by: Dan McGee <dpmcgee@gmail.com> Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --ignore-paths option to fetch is very useful for working on a subset
of a SVN repository. For proper operation, every command that causes a
fetch (explicit or implied) must include a matching --ignore-paths option.
This patch adds a persistent svn-remote.$repo_id.ignore-paths config by
promoting Fetcher::is_path_ignored to a member function and initializing
$self->{ignore_regex} in Fetcher::new. Command line --ignore-paths is
still recognized and acts in addition to the config value.
Signed-off-by: Ben Jackson <ben@ben.com> Acked-by: Eric Wong <normalperson@yhbt.net>
'git svn blame' now uses the 'git cat-file --batch' command to
speed up resolving SVN revision number out of commit SHA by
removing fork+exec overhead.
[ew: enforced 80-column line wrap]
Signed-off-by: Boris Byk <boris.byk@gmail.com> Acked-by: Eric Wong <normalperson@yhbt.net>
On Thu, 9 Apr 2009, Linus Torvalds wrote:
>
> [diff]
> renames = no
Btw, while doing this, I also though that "renames = on/off" made more
sense, but while we allow yes/no and true/false for booleans, we don't
allow on/off.
gitk: Add a command to compare two strings of commits
This adds a row context menu command to compare this commit and its
descendants with the marked commit and its descendants. The results
are shown in the bottom-left pane. Commits are compared by checking
whether their headlines are the same and their patches have the same
patch ID as generated by git patch-id.
Merges are ignored and skipped over (as long as they have one
descendant). If two commits have the same patch ID then the process
will continue and compare their descendants, as long as they both have
exactly one descendant. If either commit has 0 or 2 or more descendants,
the comparison stops there. There is currently a limit of 100
comparisons.
This can be useful for checking whether one string of commits is just
a rebased version of another string of commits. Mark the end of one
string (i.e. the oldest commit in the string) and invoke "Compare with
marked commit" on the end of the other string.
As this is implemented, the UI will be unresponsive while the results
are being generated. This should be fixed.
* jc/shared-literally:
t1301: loosen test for forced modes
set_shared_perm(): sometimes we know what the final mode bits should look like
move_temp_to_file(): do not forget to chmod() in "Coda hack" codepath
Move chmod(foo, 0444) into move_temp_to_file()
"core.sharedrepository = 0mode" should set, not loosen
Merge branch 'jc/maint-1.6.0-keep-pack' into maint
* jc/maint-1.6.0-keep-pack:
pack-objects: don't loosen objects available in alternate or kept packs
t7700: demonstrate repack flaw which may loosen objects unnecessarily
Remove --kept-pack-only option and associated infrastructure
pack-objects: only repack or loosen objects residing in "local" packs
git-repack.sh: don't use --kept-pack-only option to pack-objects
t7700-repack: add two new tests demonstrating repacking flaws
is_kept_pack(): final clean-up
Simplify is_kept_pack()
Consolidate ignore_packed logic more
has_sha1_kept_pack(): take "struct rev_info"
has_sha1_pack(): refactor "pretend these packs do not exist" interface
git-repack: resist stray environment variable
The name of the processed object was duplicated for passing it to
add_object(), but that already calls path_name, which allocates a new
string anyway. So the memory allocated by the xstrdup calls just went
nowhere, leaking memory.
This reduces the RSS usage for a "rev-list --all --objects" by about 10% on
the gentoo repo (fully packed) as well as linux-2.6.git:
gentoo:
| old | new
----------------|-------------------------------
RSS | 1537284 | 1388408
VSZ | 1816852 | 1667952
time elapsed | 1:49.62 | 1:48.99
min. page faults| 417178 | 379919
linux-2.6.git:
| old | new
----------------|-------------------------------
RSS | 324452 | 292996
VSZ | 491792 | 460376
time elapsed | 0:14.53 | 0:14.28
min. page faults| 89360 | 81613
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
These scripts all test git programs that are written in
perl, and thus obviously won't work if NO_PERL is defined.
We pass NO_PERL to the scripts from the building Makefile
via the GIT-BUILD-OPTIONS file.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
For systems with a missing or broken perl, it is nicer to
explicitly say "we don't want perl" because:
1. The Makefile knows not to bother with Perl-ish things
like Git.pm.
2. We can print a more user-friendly error message
than "foo is not a git command" or whatever the broken
perl might barf
3. Test scripts that require perl can mark themselves and
such and be skipped
This patch implements parts (1) and (2). The perl/
subdirectory is skipped entirely, gitweb is not built, and
any git commands which rely on perl will print a
human-readable message and exit with an error code.
This patch is based on one from Robin H. Johnson.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitk: Add a way to mark a commit, plus a "find descendant" command
This adds a context-menu command to put a mark on this commit. There
is at most one marked commit at any time, and it is indicated by a box
drawn around the headline. Once a commit is marked, two other
context-menu commands become available: one to select the marked commit,
and another to find the closest common descendant of this commit and
the marked commit.
The "find common descendant" command uses the displayed parent/child
relationships (i.e. the rewritten parent pointers produced by git log),
not the real parent/child relationships. Currently the UI will be
unresponsive while gitk is working out the nearest common descendant;
this should be improved in future.
git-gui is using "git-read-tree -u" when cloning which doesn't
invoke the post-checkout hook as a plain git-clone would.
So git-gui must call the hook itself.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: fix use of undeclared variable diff_empty_count
Commit 584fa9cc introduced the global variable diff_empty_count, which
is used in diff.tcl. This variable wasn't declared anywhere which
resulted in an ugly error message box instead of the intended
informative message.
Signed-off-by: Joerg Bornemann <joerg.bornemann@web.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-pull.sh: better warning message for "git pull" on detached head.
Otherwise, git complains about not finding a branch to pull from in
'branch..merge', which is hardly understandable. While we're there,
reword the sentences slightly.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This information is easily accessible when we are
calculating the relationship. The only reason not to print
it all the time is that it consumes a fair bit of screen
space, and may not be of interest to the user.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Often we want to shorten a full ref name to something "prettier"
to show a user. For example, "refs/heads/master" is often shown
simply as "master", or "refs/remotes/origin/master" is shown as
"origin/master".
Many places in the code use a very simple formula: skip common
prefixes like refs/heads, refs/remotes, etc. This is codified in
the prettify_ref function.
for-each-ref has a more correct (but more expensive) approach:
consider the ref lookup rules, and try shortening as much as
possible while remaining unambiguous.
This patch makes the latter strategy globally available as
shorten_unambiguous_ref.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The logic for determining the upstream ref of a branch is
somewhat complex to perform in a shell script. This patch
provides a plumbing mechanism for scripts to access the C
logic used internally by git-status, git-branch, etc.
This code handles some special magic like *-deref and the
:short formatting specifier. The next patch will add another
field which outputs a ref and wants to use the same code.
This patch splits the "which ref are we outputting" from the
actual formatting. There should be no behavioral change.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Change double quotes to single quotes in message
Documentation: clarify .gitattributes search
git-checkout.txt: clarify that <branch> applies when no path is given.
git-checkout.txt: fix incorrect statement about HEAD and index
* maint-1.6.1:
Documentation: clarify .gitattributes search
git-checkout.txt: clarify that <branch> applies when no path is given.
git-checkout.txt: fix incorrect statement about HEAD and index
Most of the time when we give branch name in the message, we quote it
inside a pair of single-quotes. git-checkout uses double-quotes; this
patch corrects the inconsistency.
Signed-off-by: Jari Aalto <jari.aalto@cante.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.6.0:
Documentation: clarify .gitattributes search
git-checkout.txt: clarify that <branch> applies when no path is given.
git-checkout.txt: fix incorrect statement about HEAD and index
* bs/maint-1.6.0-tree-walk-prefix:
match_tree_entry(): a pathspec only matches at directory boundaries
tree_entry_interesting: a pathspec only matches at directory boundary