Add paragraph for the -A option, and describe the new behaviour
that makes unreachable objects loose.
Signed-off-by: Chris Frey <cdfrey@foursquare.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit ccc1297226b184c40459e9d373cc9eebfb7bd898 changed the behavior
of 'git repack -A' so unreachable objects are stored as loose objects.
However it did so in a naive and inn efficient way by making packs
about to be deleted inaccessible and feeding their content through
'git unpack-objects'. While this works, there are major flaws with
this approach:
- It is unacceptably sloooooooooooooow.
In the Linux kernel repository with no actual unreachable objects,
doing 'git repack -A -d' before:
real 2m33.220s
user 2m21.675s
sys 0m3.510s
And with this change:
real 0m36.849s
user 0m24.365s
sys 0m1.950s
For reference, here's the timing for 'git repack -a -d':
real 0m35.816s
user 0m22.571s
sys 0m2.011s
This is explained by the fact that 'git unpack-objects' was used to
unpack _every_ objects even if (almost) 100% of them were thrown away.
- There is a black out period.
Between the removal of the .idx file for the redundant pack and the
completion of its unpacking, the unreachable objects become completely
unaccessible. This is not a big issue as we're talking about unreachable
objects, but some consistency is always good.
- There is no way to easily set a sensible mtime for the newly created
unreachable loose objects.
So, while having a command called "pack-objects" to perform object
unpacking looks really odd, this is probably the best compromize to be
able to solve the above issues in an efficient way.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is meant to force the creation of a loose object even if it
already exists packed. Needed for the next commit.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that repack -A will leave unreferenced objects unpacked, there is
no reason to use the -a option to repack (which will discard unreferenced
objects). The unpacked unreferenced objects will not be repacked by a
subsequent repack, and will eventually be pruned by git-gc based on the
gc.pruneExpire config option.
The previous behavior of the -A option was to retain any previously
packed objects which had become unreferenced, and place them into the newly
created pack file. Since git-gc, when run automatically with the --auto
option, calls repack with the -A option, this had the effect of retaining
unreferenced packed objects indefinitely. To avoid this scenario, the
user was required to run git-gc with the little known --prune option or
to manually run repack with the -a option.
This patch changes the behavior of the -A option so that unreferenced
objects that exist in any pack file being replaced, will be unpacked into
the repository. The unreferenced loose objects can then be garbage collected
by git-gc (i.e. git-prune) based on the gc.pruneExpire setting.
Also add new tests for checking whether unreferenced objects which were
previously packed are properly left in the repository unpacked after
repacking.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cc/help:
documentation: web--browse: add a note about konqueror
documentation: help: add info about "man.<tool>.cmd" config var
help: use "man.<tool>.cmd" as custom man viewer command
documentation: help: add "man.<tool>.path" config variable
help: use man viewer path from "man.<tool>.path" config var
Some systems define fopen as a macro based on compiler settings.
The previous technique for reverting to the system fopen function
by merely undefining fopen is inadequate in this case. Instead,
avoid defining fopen entirely when compiling this source file.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Tested-by: Mike Ralphson <mike@abacus.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "-u" option is described only in terms of "updating"
files, which in turn is described only as "similar to what
git commit -a does". Let's be a little more specific about
what updating entails.
Suggested by Geoffrey Irving.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before this patch, there were no "git bisect run" example.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'git gui' has a number of options that can be specified using the
options dialog. Sometimes it is convenient to be able to specify these
from the command line, therefor document these options.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
Acked-by: Shawn O. Pearce <speace@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before this patch in "git-add.txt" and "git-format-patch.txt", the
commands used in the examples were "git-CMD" instead of "git CMD".
This patch fixes that.
In "git-pull.txt" only the last example had the code sample in an
asciidoc "Listing Block", and in the other two files, none.
This patch fixes that by putting all code samples in listing
blocks.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Honour the setgid and umask when re-creating the objects directory
at the destination.
cpio in copy-pass mode aims to copy file permissions which causes this
problem and cannot be disabled. Be explicit by copying the directory
structure first, honouring the permissions at the destination, then copy
the files with 0444 permissions. This also avoids bugs in some versions
of cpio.
Signed-off-by: Mark Hills <mark@pogo.org.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/lstat:
diff-files: mark an index entry we know is up-to-date as such
write_index(): optimize ce_smudge_racily_clean_entry() calls with CE_UPTODATE
* lh/git-file:
Teach GIT-VERSION-GEN about the .git file
Teach git-submodule.sh about the .git file
Teach resolve_gitlink_ref() about the .git file
Add platform-independent .git "symlink"
* lh/branch-merged:
Add tests for `branch --[no-]merged`
git-branch.txt: compare --contains, --merged and --no-merged
git-branch: add support for --merged and --no-merged
When having a svn:ignore that ignores the .gitignore file the -f
option to git add must be used to avoid git complaining about adding
an ignored file and hence stop the process of creating .gitignores.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In recent versions GNU's git has been renamed to gnuit, document this
while talking about how to resolve the conflict.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When calling pretty_print_commit, there is an implicit
assumption that passing in a non-NULL "subject" variable
for oneline or email formats means that the output is part
of a subject and therefore "subject" to rfc2047 encoding.
This is not the desired effect when reporting the movement
of detached HEAD.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This eliminates a special case in the show_log() function, to help
simplify the terminator semantics. Now show_log() always prints a
newline after the log entry when use_terminator is set, even if the log
message is empty.
This change should only affect the --pretty=tformat output, since that
was the only way to trigger this special case.
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These variables were made unnecessary by commit
3969cf7db1a13a78f3b7a36d8c1084bbe0a53459.
Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using git-cvsimport, the author is inferred from the cvs commit,
e.g. cvs commit logname is foobaruser, then the author field in git
results in:
Author: foobaruser <foobaruser>
Which is not perfect, but perfectly acceptable given the circumstances.
The default git-svn import however, results in:
Author: foobaruser <foobaruser@acf43c95-373e-0410-b603-e72c3f656dc1>
When using mixes of imports, from CVS and SVN into the same git
repository, you'd like to harmonise the imports to the format cvsimport
uses.
git-svn supports an experimental option --use-log-author which currently
results in the same logentry as without that option when no From: or
Signed-off-by: is found in the logentry ($email currently ends up empty,
and hence is generated again).
This patches harmonises the result with cvsimport, and makes
git-svn --use-log-author produce:
Author: foobaruser <foobaruser>
Signed-off-by: Stephen R. van den Berg <srb@cuci.nl>
Acked-by: Eric Wong <normalperson@yhbt.net>
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>
