The 'depth' variable doesn't reflect the actual maximum depth used
when other objects already depend on the current one.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the delta data is cached in memory until it is written to a pack
file on disk, it is best to compress it right away in find_deltas() for
the following reasons:
- we have to compress that data anyway;
- this allows for caching more deltas with the same cache size limit;
- compression is potentially threaded.
This last point is especially relevant for SMP run time. For example,
repacking the Linux repo on a quad core processor using 4 threads with
all default settings produce the following results before this change:
real 2m27.929s
user 4m36.492s
sys 0m3.091s
And with this change applied:
real 2m13.787s
user 4m37.486s
sys 0m3.159s
So the actual execution time stayed more or less the same but the
wall clock time is shorter.
This is however not a good thing to do when generating a pack for
network transmission. In that case, the network is most likely to
throttle the data throughput, so it is best to make find_deltas()
faster in order to start writing data ASAP since we can afford
spending more time between writes to compress the data
at that point.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Parsing !no_reuse_delta everywhere makes my brain spend extra
cycles wondering each time.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When I applied Linus's patch from the list by hand somehow I ended
up reversing the logic by mistake. This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most users should be using git-gc instead of directly
calling prune. For those who really do want more information
on pruning, let's point them at git-fsck, which goes into
slightly more detail on reachability.
And since we're pointing users there, let's make sure
reflogs are mentioned in git-fsck(1).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
xread() and xwrite() return ssize_t values as their native POSIX
counterparts read(2) and write(2).
To be consistent, read_in_full() and write_in_full() should also return
ssize_t values.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As a nice side effect it also fixes t2002-checkout-cache-u.sh on FreeBSD 4,
/bin/sh of which has problems interpreting "! command" construction.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The command
git svn clone (URL of an empty SVN repo here)
works, creates an empty git repository. I can perform the initial
commit there, but then, "git svn dcommit" says :
Use of uninitialized value in concatenation (.) or string at .../git-svn line 414.
Committing to ...
Unable to determine upstream SVN information from HEAD history
I guess a correct management of the initial commit in git-svn would be
hard to implement, but at least, the error message can be improved.
First step is something like the patch below, and better would be for
"git svn clone" to warn that it won't be able to do much with the
cloned repo.
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
make git status act similar to git log and git diff by presenting long
output in a pager.
Signed-off-by: Bart Trojanowski <bart@jukie.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
cvsimport: always pass user data to "system" as a list
fix reflog approxidate parsing bug
Fix use after free() in builtin-fetch
fetch-pack: do not stop traversing an already parsed commit
Use "=" instead of "==" in condition as it is more portable
This avoids invoking the shell. Not only is it faster, but
it prevents the possibility of interpreting our arguments in
the shell.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In get_sha1_basic, we parse a string like
HEAD@{10 seconds ago}:path/to/file
into its constituent ref, reflog date, and path components.
We never actually munge the string itself, but instead keep
offsets into the string with their associated lengths.
When we call approxidate on the contents inside braces,
however, we pass just a string without a length. This means
that approxidate could sometimes look past the closing brace
and (erroneously) interpret the rest of the string as part
of the date.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As reported by Dave Jones:
Since master.kernel.org updated to latest, I noticed that I could crash
git-fetch by doing this..
export KERNEL=/pub/scm/linux/kernel/git/
git fetch $KERNEL/torvalds/linux-2.6 master:linus
(gdb) bt
0 0x000000349fd6d44b in free () from /lib64/libc.so.6
1 0x000000000048f4eb in transport_unlock_pack (transport=0x7ce530) at transport.c:811
2 0x000000349fd31b25 in exit () from /lib64/libc.so.6
3 0x00000000004043d8 in handle_internal_command (argc=3, argv=0x7fffea4449f0) at git.c:379
4 0x0000000000404547 in main (argc=3, argv=0x7fffea4449f0) at git.c:443
5 0x000000349fd1c784 in __libc_start_main () from /lib64/libc.so.6
6 0x0000000000403ef9 in ?? ()
7 0x00007fffea4449d8 in ?? ()
8 0x0000000000000000 in ?? ()
I then remembered, my .bashrc has this..
export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))
which is handy for showing up such bugs.
More info on this glibc feature is at http://udrepper.livejournal.com/11429.html
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
f3ec549 (fetch-pack: check parse_commit/object results, 2008-03-03)
broke common ancestor computation by stopping traversal when it sees
an already parsed commit. This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
At least the dash from Ubuntu's /bin/sh says:
test: 233: ==: unexpected operator
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The resulting data is zero terminated after the read loop, but
the subsequent loop that scans for '\n' will overrun the buffer.
Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git clone [options] $src $dst excess-garbage" simply ignored
excess-garbage without giving any diagnostic message. Fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Option is only completed when .git/MERGE_HEAD is present.
Signed-off-by: Richard Quirk <richard.quirk@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before this patch something like:
$ git rev-parse --verify <good-rev> <junk>
worked whatever junk was as long as <good-rev> could be parsed
correctly.
This patch makes "git rev-parse --verify" error out when passed
any junk after a good rev.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently "git rev-parse --verify <something>" is often used with
its error output redirected to /dev/null. This patch makes it
easier to do that.
The -q|--quiet option is designed to work the same way as it does
for "git symbolic-ref".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
remote: create fetch config lines with '+'
push: allow unqualified dest refspecs to DWIM
doc/git-gc: add a note about what is collected
t5516: remove ambiguity test (1)
Linked glossary from cvs-migration page
write-tree: properly detect failure to write tree objects
Since git-remote always uses remote tracking branches, it
should be safe to always force updates of those branches.
I.e., we should generate
fetch = +refs/heads/*:refs/remotes/$remote/*
instead of
fetch = refs/heads/*:refs/remotes/$remote/*
This was the behavior of the perl version, which seems to
have been lost in the C rewrite.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, a push like:
git push remote src:dst
would go through the following steps:
1. check for an unambiguous 'dst' on the remote; if it
exists, then push to that ref
2. otherwise, check if 'dst' begins with 'refs/'; if it
does, create a new ref
3. otherwise, complain because we don't know where in the
refs hierarchy to put 'dst'
However, in some cases, we can guess about the ref type of
'dst' based on the ref type of 'src'. Specifically, before
complaining we now check:
2.5. if 'src' resolves to a ref starting with refs/heads
or refs/tags, then prepend that to 'dst'
So now this creates a new branch on the remote, whereas it
previously failed with an error message:
git push master:newbranch
Note that, by design, we limit this DWIM behavior only to
source refs which resolve exactly (including symrefs which
resolve to existing refs). We still complain on a partial
destination refspec if the source is a raw sha1, or a ref
expression such as 'master~10'.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It seems to be a FAQ that people try running git-gc, and
then get puzzled about why the size of their .git directory
didn't change. This note mentions the reasons why things
might unexpectedly get kept.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This test tried to push into a remote with ambiguous refs in
remotes/$x/master and remotes/$y/master. However, the remote
never actually tells us about the refs/remotes hierarchy, so
we don't even see this ambiguity.
The test happened to pass because we were simply looking for
failure, and the test fails for another reason: the dst
refspec does not exist and does not begin with refs/, making
it invalid.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Coming from CVS, I found the git glossary vital to learning git and learning
how terms in git correlate to the cvs terminology with which I am familiar.
This patch links the glossary from the cvs-migration page so cvs users will
be able to fine the glossary as soon as they start looking at git documents.
Signed-off-by: Matt Graham <mdg149@gmail.com>
Acked-by: J. Bruce Fields <bfields@fieldses.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tomasz Fortuna reported that "git commit" does not error out properly when
it cannot write tree objects out. "git write-tree" shares the same issue,
as the failure to notice the error is deep in the logic to write tree
objects out recursively.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Amend git-push refspec documentation
git-gc --prune is deprecated
svn-git: Use binmode for reading/writing binary rev maps
diff options documentation: refer to --diff-filter in --name-status
Don't force imap.host to be set when imap.tunnel is set
git-clone.txt: Adjust note to --shared for new pruning behavior of git-gc
git-svn bug with blank commits and author file
archive.c: format_subst - fixed bogus argument to memchr
copy.c: copy_fd - correctly report write errors
gitattributes: Fix subdirectory attributes specified from root directory
These paragraphs are a little confusing. Also, make it clearer when
you have to specify the full name for <dst>
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
25ee9731c1 made the '--prune' option
deprecated and removed its description from the git-gc man page. This
patch removes all references to this option from the rest of the Git
documentation.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Otherwise, there is a possible interaction with UTF-8 locales in
combination with PERL_UNICODE, resulting in "inconsistent size: 40" or
"read:"-type errors.
See also:
perldoc -f binmode
<http://perldoc.perl.org/perl581delta.html#UTF-8-no-longer-default-under-UTF-8-locales>
Signed-off-by: Michael Weber <michaelw@foldr.org>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git diff --name-status outputs letters, but the meaning of those letters
is documented elsewhere. Add a note to make the manpage more intuitive.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation for git-imap-send suggests a tunnel setting such as
Tunnel = "ssh -q user@server.com /usr/bin/imapd ./Maildir 2> /dev/null"
which works wonderfully and doesn't require a username, password or port
setting.
However, git-imap-send currently requires that the imap.host variable be
set in the config even when it was unused. This patch changes imap-send
to only require that the imap.host setting is set if imap.tunnel is not
set. Otherwise, server.host is set to "tunnel" for reporting purposes.
Acked-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
