Recently we fixed 'git-apply --stat' not to barf on a binary
differences. But it accidentally broke the error detection when
we actually attempt to apply them.
This commit fixes the problem and adds test cases.
For some reason I've done a "git grep" twice with no pattern, which is
really irritating, since it just grep everything. If I actually wanted
that, I could do "git grep ^" or something.
So add a "usage" message if the pattern is empty.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
python 2.2.1 is perfectly capable of executing git-merge-recursive,
provided that it finds heapq and sets. All you have to do is to steal
heapq.py and sets.py from python 2.3 or newer, and drop them in your
GIT_PYTHON_PATH.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch provides a C implementation of the 'git' program and
introduces support for putting the git-* commands in a directory
of their own. It also saves some time on executing those commands
in a tight loop and it prints the currently available git commands
in a nicely formatted list.
The location of the GIT_EXEC_PATH (name discussion's closed, thank gods)
can be obtained by running
git --exec-path
which will hopefully give porcelainistas ample time to adapt their
heavy-duty loops to call the core programs directly and thus save
the extra fork() / execve() overhead, although that's not really
necessary any more.
The --exec-path value is prepended to $PATH, so the git-* programs
should Just Work without ever requiring any changes to how they call
other programs in the suite.
Some timing values for 10000 invocations of git-var >&/dev/null:
git.sh: 24.194s
git.c: 9.044s
git-var: 7.377s
The git-<tab><tab> behaviour can, along with the someday-to-be-deprecated
git-<command> form of invocation, be indefinitely retained by adding
the following line to one's .bash_profile or equivalent:
PATH=$PATH:$(git --exec-path)
Experimental libraries can be used by either setting the environment variable
GIT_EXEC_PATH, or by using
git --exec-path=/some/experimental/exec-path
Relative paths are properly grok'ed as exec-path values.
Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
where gitweb was found to be using a lot of time and memory to
detect renames on huge commits. git-diff family takes -l<num>
flag, and if the number of paths that are rename destination
candidates (i.e. new paths with -M, or modified paths with -C)
are larger than that number, skips rename/copy detection even
when -M or -C is specified on the command line.
This commit makes the rename detection limit easier to use. You
can have:
[diff]
renamelimit = 30
in your .git/config file to specify the default rename detection
limit. You can override this from the command line; giving 0
means 'unlimited':
git diff -M -l0
We might want to change the default behaviour, when you do not
have the configuration, to limit it to say 20 paths or so. This
would also help the diffstat generation after a big 'git pull'.
Rework object refs tracking to reduce memory usage
Store pointers to referenced objects in a variable sized array instead
of linked list. This cuts down memory usage of utilities which use
object references; e.g., git-fsck-objects --full on the git.git
repository consumes about 2 MB of memory tracked by Massif instead of
7 MB before the change. Object refs are still the biggest consumer of
memory (57%), but the malloc overhead for a single block instead of a
linked list is substantially smaller.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Junio C Hamano <junkio@cox.net>
The Massif tool of Valgrind revealed that parsed tree entries occupy
more than 60% of memory allocated by git-fsck-objects. These entries
can be freed immediately after use, which significantly decreases
memory consumption.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation: do not blindly run 'cat' .git/HEAD, or echo into it.
Many places in the documentation we still talked about reading
what commit is recorded in .git/HEAD or writing the new head
information into it, both assuming .git/HEAD is a symlink. That
is not necessarily so.
The current http-fetch is rather careless about fd leakage, causing
problems while fetching large repositories. This patch does not reserve
exhaustiveness, but I covered everything I spotted. I also left some
safeguards in place in case I missed something, so that we get to know,
sooner or later.
Reported by Becky Bruce <becky.bruce@freescale.com>.
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch renames the tarball "git" rather than "git-core", and changes
the names of various packages from git-core-foo to git-foo. git-core is
still the true core package; an empty RPM package named "git" pulls in
ALL the git packages -- this makes updates work correctly, and allows
"yum install git" to do the obvious thing.
It also renames the git-(core-)tk package to gitk.
Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes git-rev-list so that when there are multiple branches, we still
sort the heads in proper approximate date order even when sorting the
output topologically.
This makes things like
gitk --all -d
work sanely and show the branches in date order (where "date order" is
obviously modified by the paren-child dependency requirements of the
topological sort).
The trivial fix is to just build the "work" list in date order rather than
inserting the new work entries at the beginning.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Because we use "lost-found" as the directory name to hold
dangling object names, it is confusing to call the command
git-lost+found, although it makes sense and is even cute ;-).
Fix for multiple alternates requests in http-fetch
Stop additional alternates requests from starting if one is already in
progress. This adds an optional callback which is processed after a slot
has finished running.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Just to avoid confusion that scripts poorly written by somebody
else ;-) might mistake this as a mount point, or backup tools
ignoring the directory. The latter is probably not a big loss,
however, considering that this directory's contents are to be
used while fresh anyway.
This patch renames git-pack-intersect to git-pack-redundant
as suggested by Petr Baudis. The new name reflects what the
program does, rather than how it does it.
Also fix a small argument parsing bug.
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
merge-one-file: use empty- or common-base condintionally in two-stage merge.
If two sides added the same path completely different thing, it is
easier to see the merge pivoting on /dev/null. So check the size of
the common section we have found, and empty it if it is too small.
merge-one-file: use common as base, instead of emptiness.
Unlike the previous round that merged the path added differently
in each branches using emptiness as the base, compute a common
version and use it as input to 'merge' program.
This would show the resulting (still conflicting) file left in
the working tree as:
common file contents...
<<<<<< FILENAME
version from our branch...
======
version from their branch...
>>>>>> .merge_file_XXXXXX
more common file contents...
Merge ... /dev/null as base, instead of punting O==empty case
Instead of leaving the path unmerged in a case where each side
adds different version of the same path, attempt to merge it
with empty base and leave "our" version in the index file, just
like we do for the case in conflicting merge.
t1200: use --topo-order to keep the show-branch output stable.
Because a batch-oriented script creates many commits within a second
on a fast machine, show-branch output of the test results are unstable
without topo-order.
With the change in the previous round, we are guaranteed to come up
with the list of all relevant merge bases, but sometimes we do not
fully mark unintersting ones due to a horizon effect. Add a phase to
postprocess, so that we mark all ancestor of "interesting" commit.
This also changes the default ordering of shown commits back to
chronological order, and adds --topo-order flag to show them in
topological order.
This makes the merge-base computation resistant to the pathological
case discussed on the list earlier, by doing the same logic as
git-merge-base. As a side effect, it breaks the command's primary
function to list non-merge commit sequences, which needs to be fixed
separately.
Although it was shown that the "full contamination" was not really full
during the list discussion, the series improves things without incurring
extra parsing cost, and here is a test to check that.
When we have only one merge-base candidates in the result list,
there is no point going back to mark the reachable commits
again. And that is the most common case, so try not to waste
time on it. Suggested by Linus.
The discussion on the list demonstrated a pathological case where
an ancestor of a merge-base can be left interesting. This commit
introduces a postprocessing phase to fix it.
Some specfile cleanups after the split.
- zlib dependency fix, current method is inconsistent, you can
potentially build a package that you can't install on machine you
built it on
- Add proper defattr
- Remove trailing '.' in summary
- Add docs to split up packages
- Add git-core dependency for each subpackage
- Move arch import to separate package as well
Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Arch uses pika escaping in some places (but not all!). Specifically, commits of
the type 'patch' use pika escaping in the log entries, which we parse to know
what to add/delete and what to commit.
This patch checks for hints of pika escaping and asks tla to unescape for us.
Originally implemented by Penny Leach <penny@catalyst.net.nz>
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-clone doesn't quote the full path to the destination directory,
which causes it to fail if the path contains spaces or other characters
interpreted by the shell.
[jc: obviously I was not careful enough. Pavel, thanks for catching.]
Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
When doing an octopus, we incorrectly used the previous merge
base as the reference to compute next merge base. This was
unnecessary, because that can never be better than using the
original HEAD. And that is far simpler as well ;-).
git log without --pretty showed author and author-date, while
with --pretty=full showed author and committer but no dates.
The new formatting option, --pretty=fuller, shows both name and
timestamp for author and committer.
Do not lose author name information to locale gotchas.
I noticed format-patch loses authorship information of Lukas' patch
when I run git tools with LC_LANG set to ja_JP. It turns out that
the sed script to set environment variables were not working on his
name (encoded in UTF-8), which is unfortunate but technically correct.
Force sed invocation under C locale because we always want literal byte
semantics.
Documentation: "host:path/to/repo" is git native over ssh.
You could also spell it ssh://host:/path/to/repo (or git+ssh,
ssh+git), but without method:// is shorter to type, so mention
only that one in the short and sweet list.
When git-update-ref has hit the "Ref %s changed to %s" error, I just stare
at it, left puzzled. This patch attempts to reword that to a more useful
and less confusing error message.
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
Make git-recursive the default strategy for git-pull.
This does two things:
- It changes the hardcoded default merge strategy for two-head
git-pull from resolve to recursive.
- .git/config file acquires two configuration items.
pull.twohead names the strategy for two-head case, and
pull.octopus names the strategy for octopus merge.
IOW you are paranoid, you can have the following lines in your
.git/config file and keep using git-merge-resolve when pulling
one remote:
[pull]
twohead = resolve
OTOH, you can say this:
[pull]
twohead = resolve
twohead = recursive
to try quicker resolve first, and when it fails, fall back to
recursive.
git-apply: do not fail on binary diff when not applying nor checking.
We run git-apply with --stat and --summary at the end of the pull
by default, which causes it to barf when the pull brought in changes
to binary files. Just mark them as binary patch and proceed when
not applying nor checking.
[jc: I almost missed --check until I saw Linus did something similar.]