This introduces --no-reuse-delta option to disable reusing of
existing delta, which is a large part of the optimization
introduced by this series. This may become necessary if
repeated repacking makes delta chain too long. With this, the
output of the command becomes identical to that of the older
implementation. But the performance suffers greatly.
It still allows reusing non-deltified representations; there is
no point uncompressing and recompressing the whole text.
It also adds a couple more statistics output, while squelching
it under -q flag, which the last round forgot to do.
$ time old-git-pack-objects --stdout >/dev/null <RL
Generating pack...
Done counting 184141 objects.
Packing 184141 objects....................
real 12m8.530s user 11m1.450s sys 0m57.920s
$ time git-pack-objects --stdout >/dev/null <RL
Generating pack...
Done counting 184141 objects.
Packing 184141 objects.....................
Total 184141, written 184141 (delta 138297), reused 178833 (delta 134081)
real 0m59.549s user 0m56.670s sys 0m2.400s
$ time git-pack-objects --stdout --no-reuse-delta >/dev/null <RL
Generating pack...
Done counting 184141 objects.
Packing 184141 objects.....................
Total 184141, written 184141 (delta 134833), reused 47904 (delta 0)
real 11m13.830s user 9m45.240s sys 0m44.330s
There is one remaining issue when --no-reuse-delta option is not
used. It can create delta chains that are deeper than specified.
A<--B<--C<--D E F G
Suppose we have a delta chain A to D (A is stored in full either
in a pack or as a loose object. B is depth1 delta relative to A,
C is depth2 delta relative to B...) with loose objects E, F, G.
And we are going to pack all of them.
B, C and D are left as delta against A, B and C respectively.
So A, E, F, and G are examined for deltification, and let's say
we decided to keep E expanded, and store the rest as deltas like
this:
E<--F<--G<--A
Oops. We ended up making D a bit too deep, didn't we? B, C and
D form a chain on top of A!
This is because we did not know what the final depth of A would
be, when we checked objects and decided to keep the existing
delta. Unfortunately, deferring the decision until just before
the deltification is not an option. To be able to make B, C,
and D candidates for deltification with the rest, we need to
know the type and final unexpanded size of them, but the major
part of the optimization comes from the fact that we do not read
the delta data to do so -- getting the final size is quite an
expensive operation.
To prevent this from happening, we should keep A from being
deltified. But how would we tell that, cheaply?
To do this most precisely, after check_object() runs, each
object that is used as the base object of some existing delta
needs to be marked with the maximum depth of the objects we
decided to keep deltified (in this case, D is depth 3 relative
to A, so if no other delta chain that is longer than 3 based on
A exists, mark A with 3). Then when attempting to deltify A, we
would take that number into account to see if the final delta
chain that leads to D becomes too deep.
However, this is a bit cumbersome to compute, so we would cheat
and reduce the maximum depth for A arbitrarily to depth/4 in
this implementation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When generating a new pack, notice if we have already needed
objects in existing packs. If an object is stored deltified,
and its base object is also what we are going to pack, then
reuse the existing deltified representation unconditionally,
bypassing all the expensive find_deltas() and try_deltas()
calls.
Also, notice if what we are going to write out exactly match
what is already in an existing pack (either deltified or just
compressed). In such a case, we can just copy it instead of
going through the usual uncompressing & recompressing cycle.
Without this patch, in linux-2.6 repository with about 1500
loose objects and a single mega pack:
$ git-rev-list --objects v2.6.16-rc3 >RL
$ wc -l RL
184141 RL
$ time git-pack-objects p <RL
Generating pack...
Done counting 184141 objects.
Packing 184141 objects....................
a1fc7b3e537fcb9b3c46b7505df859f0a11e79d2
real 12m4.323s
user 11m2.560s
sys 0m55.950s
With this patch, the same input:
$ time ../git.junio/git-pack-objects q <RL
Generating pack...
Done counting 184141 objects.
Packing 184141 objects.....................
a1fc7b3e537fcb9b3c46b7505df859f0a11e79d2
Total 184141, written 184141, reused 182441
real 1m2.608s
user 0m55.090s
sys 0m1.830s
Signed-off-by: Junio C Hamano <junkio@cox.net>
The real problem triggered an earlier fix was that an alternate
entry was pointing at a removed directory. Complaining on
object/pack directory that cannot be opendir-ed produces noise
in an ancient repository that does not have object/pack
directory and has never been packed.
Detect the real user error and report it. Also if opendir
failed for other reasons (e.g. no read permissions), report that
as well.
Spotted by Andrew Vasquez <andrew.vasquez@qlogic.com>.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-cvsserver is highly functional. However, not all methods are implemented,
and for those methods that are implemented, not all switches are implemented.
All the common read operations are implemented, and add/remove/commit are
supported.
Testing has been done using both the CLI CVS client, and the Eclipse CVS
plugin. Most functionality works fine with both of these clients.
Currently git-cvsserver only works over SSH connections, see the
Documentation for more details on how to configure your client. It
does not support pserver for anonymous access but it should not be
hard to implement. Anonymous access will need tighter input validation.
In our very informal tests, it seems to be significantly faster than a real
CVS server.
This utility depends on a version of git-cvsannotate that supports -S and on
DBD::SQLite.
Licensed under GPLv2. Copyright The Open University UK.
Authors: Martyn Smith <martyn@catalyst.net.nz>
Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since Ryan's git-annotate is much faster, and has support for renames,
it is likely it goes into the mainstream git soon. Adapt it a little to
work with gitcvs, and actually use it.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Stephen C. Tweedie noticed that we give up running rev-list when
we see too many refs on the remote side. Limit the number of
negative references we give to rev-list and continue.
Not sending any negative references to rev-list is very bad --
we may be pushing a ref that is new to the other end.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* fix:
git-push: Update documentation to describe the no-refspec behavior.
format-patch: pretty-print timestamp correctly.
git-add: Add support for --, documentation, and test.
* jc/perl:
cvsimport: avoid open "-|" list form for Perl 5.6
svnimport: avoid open "-|" list form for Perl 5.6
send-email: avoid open "-|" list form for Perl 5.6
rerere: avoid open "-|" list form for Perl 5.6
fmt-merge-msg: avoid open "-|" list form for Perl 5.6
* jc/pack-reuse:
pack-objects: avoid delta chains that are too long.
git-repack: allow passing a couple of flags to pack-objects.
pack-objects: finishing touches.
pack-objects: reuse data from existing packs.
* jc/nostat:
cache_name_compare() compares name and stage, nothing else.
"assume unchanged" git: documentation.
ls-files: split "show-valid-bit" into a different option.
"Assume unchanged" git: --really-refresh fix.
ls-files: debugging aid for CE_VALID changes.
"Assume unchanged" git: do not set CE_VALID with --refresh
"Assume unchanged" git
It turns out that the git-push documentation didn't describe what it
would do when not given a refspec, (not on the command line, nor in a
remotes file). This is fairly important for the user who is trying to
understand operations such as:
git clone git://something/some/where
# hack, hack, hack
git push origin
I tracked the mystery behavior down to git-send-pack and lifted the
relevant portion of its documentation up to git-push, (namely that all
refs existing both locally and remotely are updated).
Signed-off-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch address the below:
Use monospace font to draw branch and tag name
set the font size to 13.
Make the graph column resizable. This helps to accommodate large tag names
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fix the below bug
Junio C Hamano <junkio@cox.net> writes:
>
> It does not work in my repository, since you do not seem to
> handle branch and tag names with slashes in them. All of my
> topic branches live in directories with two-letter names
> (e.g. ak/gitview).
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I found a paper thin man page for git-rebase, but was quite happy to
see something much more useful in the usage statement of the script
when I went there to find out how this thing worked. Here it is
cleaned up slightly and expanded a bit into the actual documentation.
Signed-off-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds support to git-add to allow the common -- to separate
command-line options and file names. It adds documentation and a new
git-add test case as well.
[jc: this should apply to 1.2.X maintenance series, so I reworked
git-ls-files --error-unmatch test. ]
Signed-off-by: Junio C Hamano <junkio@cox.net>
In my attempt to port git to IRIX, I broke it. Sorry.
Signed-off-by: Johannes E. Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
- Solaris 9 and up do not need -liconv, so NEEDS_LIBICONV should be set
only for S8.
- Move the declaration of the uname variables to early in the Makefile
so they can be referenced by prefix and gitexecdir variables.
- gitexecdir defaults to being same as bindir, it might as well reference
that variable.
[jc: corrupt patch, sneakily tried to remove inclusion of GIT-VERSION-FILE
I do not know why I am applying this...]
Signed-off-by: Paul Jakma <paul@quagga.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This reads data in the format a (non recursive) ls-tree outputs
and writes a tree object to the object database. The created
tree object name is output to the standard output.
For convenience, the input data does not need to be sorted; the
command sorts the input lines internally.
By request from Tommi Virtanen.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/ident:
Keep Porcelainish from failing by broken ident after making changes.
Delay "empty ident" errors until they really matter.
Make "empty ident" error message a bit more helpful.
It said "after fixing up, commit the result using -F .msg", but
it was not clear for new people how "fix up" should be done.
Hint "git-update-index <path>".
We could recommend "git commit -a -F .msg" instead, but I am
hesitant to give that suggestion in the blind -- you could do a
cherry-pick, revert or a merge in general in a dirty working
tree as long as local modifications do not overlap with the
merge, but using "commit -a" would include them in the result.
Signed-off-by: Junio C Hamano <junkio@cox.net>
None of these were really show-stoppers (or even triggered)
on most of the trees I've tracked.
* Node change prevention for identically named nodes. This is
a limitation of SVN, but we find the error and exit before
it's passed to SVN so we don't dirty our working tree when our
commit fails. git-svn will exit with an error code 1 if any
of the following conditions are found:
1. a directory is removed and a file of the same name of the
removed directory is created
1a. a file has its parent directory removed and the file is
takes the name of the removed parent directory::
baz/zzz => baz
2. a file is removed and a directory of the same name of the
removed file is created.
2a. a file is moved into a deeper directory that shares the
previous name of the file::
dir/$file => dir/file/$file
Since SVN cannot handle these cases, the user will have to
manually split the commit into several parts.
* --rmdir now handles nested/deep removals. If dir/a/b/c/d/e/file
is removed, and everything else is in the dir/ hierarchy is
otherwise empty, then dir/ will be deleted when file is deleted
from svn and --rmdir specified.
* Always assert that we have written the tree we want to write
on commits. This helped me find several bugs in the symlink
handling code (which as been fixed).
* Several symlink handling fixes. We now refuse to set
permissions on symlinks. We also always unlink a file
if we're going to overwrite it.
* Apply changes in a pre-determined order, so we always have
rename from locations handy before we delete them.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
XML::Simple was originally required back when I made svn-arch-mirror
because I needed to explictly track renames with Arch. Then I carried
it over to git-svn because I was afraid somebody could commit an svn
log message that could throw off a non-XML log parser. Then I noticed
the <n> lines column in the header. So, no more XML :)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow 'from..to' notation from the command line.
More liberal sha1 parsing when reading from stdin no longer requires the
sha1 to be the first character, so a leading 'commit ' string is OK.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Both of these options are passed directly to git-diff-tree when
committing to a SVN repository.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Just a typo, I doubt anybody would use (and I highly recommend not
using) this option anyways. But you never know...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Maybe we would want to make this default before it graduates to
the master branch, but in the meantime to help testing things,
this allows you to say "git push --thin destination".
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new flag loosens the usual "self containedness" requirment
of packfiles, and sends deltified representation of objects when
we know the other side has the base objects needed to unpack
them. This would help reducing the transfer size.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano
Martin Langhoff
Johannes Schindelin
Carl Worth
aneesh.kumar@gmail.com
Jason Riedy
Paul Jakma
Ryan Anderson
Eric Wong