Skip to content
Commits on Feb 23, 2006
  1. git-fetch: follow tag only when tracking remote branch.

    Junio C Hamano committed
    Unless --no-tags flag was given, git-fetch tried to always
    follow remote tags that point at the commits we picked up.
    
    It is not very useful to pick up tags from remote unless storing
    the fetched branch head in a local tracking branch.  This is
    especially true if the fetch is done to merge the remote branch
    into our current branch as one-shot basis (i.e. "please pull"),
    and is even harmful if the remote repository has many irrelevant
    tags.
    
    This proposed update disables the automated tag following unless
    we are storing the a fetched branch head in a local tracking
    branch.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  2. pack-objects eye-candy: finishing touches.

    Junio C Hamano committed
    This updates the progress output to match "every one second or
    every percent whichever comes early" used by unpack-objects, as
    discussed on the list.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Feb 22, 2006
  1. also adds progress when actually writing a pack

    Nicolas Pitre committed with Junio C Hamano
    If that pack is big, it takes significant time to write and might
    benefit from some more eye candies as well.  This is however disabled
    when the pack is written to stdout since in that case the output is
    usually piped into unpack_objects which already does its own progress
    reporting.
    
    Signed-off-by: Nicolas Pitre <nico@cam.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  2. nicer eye candies for pack-objects

    Nicolas Pitre committed with Junio C Hamano
    This provides a stable and simpler progress reporting mechanism that
    updates progress as often as possible but accurately not updating more
    than once a second.  The deltification phase is also made more
    interesting to watch (since repacking a big repository and only seeing a
    dot appear once every many seconds is rather boring and doesn't provide
    much food for anticipation).
    
    Signed-off-by: Nicolas Pitre <nico@cam.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  3. Keep Porcelainish from failing by broken ident after making changes.

    Junio C Hamano committed
    "empty ident not allowed" error makes commit-tree fail, so we
    are already safer in that we would not end up with commit
    objects that have bogus names on the author or committer fields.
    However, before commit-tree is called there are already changes
    made to the index file and the working tree.  The operation can
    be resumed after fixing the environment problem, but when this
    triggers to a newcomer with unusable gecos, the first question
    becomes "what did I lose and how would I recover".
    
    This patch modifies some Porcelainish commands to verify
    GIT_COMMITTER_IDENT as soon as we know we are going to make some
    commits before doing much damage to prevent confusion.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  4. Delay "empty ident" errors until they really matter.

    Junio C Hamano committed
    Previous one warned people upfront to encourage fixing their
    environment early, but some people just use repositories and git
    tools read-only without making any changes, and in such a case
    there is not much point insisting on them having a usable ident.
    
    This round attempts to move the error until either "git-var"
    asks for the ident explicitly or "commit-tree" wants to use it.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  5. Make "empty ident" error message a bit more helpful.

    Junio C Hamano committed
    It appears that some people who did not care about having bogus
    names in their own commit messages are bitten by the recent
    change to require a sane environment [*1*].
    
    While it was a good idea to prevent people from using bogus
    names to create commits and doing sign-offs, the error message
    is not very informative.  This patch attempts to warn things
    upfront and hint people how to fix their environments.
    
    [Footnote]
    
    *1* The thread is this one.
    
        http://marc.theaimsgroup.com/?t=113868084800004
    
        Especially this message.
    
        http://marc.theaimsgroup.com/?m=113932830015032
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  6. pack-objects: avoid delta chains that are too long.

    Junio C Hamano committed
    This tries to rework the solution for the excess delta chain
    problem. An earlier commit worked it around ``cheaply'', but
    repeated repacking risks unbound growth of delta chains.
    
    This version counts the length of delta chain we are reusing
    from the existing pack, and makes sure a base object that has
    sufficiently long delta chain does not get deltified.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  7. git-repack: allow passing a couple of flags to pack-objects.

    Junio C Hamano committed
    A new flag -q makes underlying pack-objects less chatty.
    A new flag -f forces delta to be recomputed from scratch.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  8. pack-objects: finishing touches.

    Junio C Hamano committed
    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>
  9. pack-objects: reuse data from existing packs.

    Junio C Hamano committed
    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>
  10. detect broken alternates.

    Junio C Hamano committed
    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>
  11. @cworth-gh

    git-push: Update documentation to describe the no-refspec behavior.

    cworth-gh committed with Junio C Hamano
    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>
  12. format-patch: pretty-print timestamp correctly.

    Junio C Hamano committed
    Perl is not C and does not truncate the division result.  Arghh!
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  13. @cworth-gh

    git-add: Add support for --, documentation, and test.

    cworth-gh committed with Junio C Hamano
    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>
Commits on Feb 19, 2006
  1. @gollux

    Fix retries in git-cvsimport

    gollux committed with Junio C Hamano
    Fixed a couple of bugs in recovering from broken connections:
    
    The _line() method now returns undef correctly when the connection
    is broken instead of falling off the function and returning garbage.
    
    Retries are now reported to stderr and the eventual partially
    downloaded file is discarded instead of being appended to.
    
    The "Server gone away" test has been removed, because it was
    reachable only if the garbage return bug bit.
    
    Signed-off-by: Martin Mares <mj@ucw.cz>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Feb 18, 2006
  1. archimport: remove files from the index before adding/updating

    Eric Wong committed with Junio C Hamano
    This fixes a bug when importing where a directory gets removed/renamed
    but is immediately replaced by a file of the same name in the same
    changeset.
    
    This fix only applies to the accurate (default) strategy the moment.
    
    This patch should also fix the fast strategy if/when it is updated
    to handle the cases that would've triggered this bug.
    
    This bug was originally found in git-svn, but I remembered I did the
    same thing with archimport as well.
    
    Signed-off-by: Eric Wong <normalperson@yhbt.net>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  2. @spearce

    Make git-reset delete empty directories

    spearce committed with Junio C Hamano
    When git-reset --hard is used and a subdirectory becomes
    empty (as it contains no tracked files in the target tree)
    the empty subdirectory should be removed.  This matches
    the behavior of git-checkout-index and git-read-tree -m
    which would not have created the subdirectory or would
    have deleted it when updating the working directory.
    
    Subdirectories which are not empty will be left behind.
    This may happen if the subdirectory still contains object
    files from the user's build process (for example).
    
    [jc: simplified the logic a bit, while keeping the test script.]
  3. @jonas

    Document --short and --git-dir in git-rev-parse(1)

    jonas committed with Junio C Hamano
    Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
  4. @jonas

    git-rev-parse: Fix --short= option parsing

    jonas committed with Junio C Hamano
    Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
  5. @cworth-gh

    Prevent git-upload-pack segfault if object cannot be found

    cworth-gh committed with Junio C Hamano
    Signed-off-by: Carl Worth <cworth@cworth.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  6. @cworth-gh

    Abstract test_create_repo out for use in tests.

    cworth-gh committed with Junio C Hamano
    Signed-off-by: Carl Worth <cworth@cworth.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  7. @cworth-gh

    Trap exit to clean up created directory if clone fails.

    cworth-gh committed with Junio C Hamano
    Signed-off-by: Carl Worth <cworth@cworth.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Feb 16, 2006
  1. @weidendo

    More useful/hinting error messages in git-checkout

    weidendo committed with Junio C Hamano
    Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  2. Print an error if cloning a http repo and NO_CURL is set

    Fernando J. Pereda committed with Junio C Hamano
    If Git is compiled with NO_CURL=YesPlease and one tries to
    clone a http repository, git-clone tries to call the curl
    binary. This trivial patch prints an error instead in such
    situation.
    
    Signed-off-by: Fernando J. Pereda <ferdy@gentoo.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Feb 15, 2006
  1. checkout: fix dirty-file display.

    Junio C Hamano committed
    When we refused to switch branches, we incorrectly showed
    differences from the branch we would have switched to.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Feb 14, 2006
  1. combine-diff: diff-files fix (#2)

    Junio C Hamano committed
    The raw format "git-diff-files -c" to show unmerged state forgot
    to initialize the status fields from parents, causing NUL
    characters to be emitted.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  2. combine-diff: diff-files fix.

    Junio C Hamano committed
    When showing a conflicted merge from index stages and working
    tree file, we did not fetch the mode from the working tree,
    and mistook that as a deleted file.  Also if the manual
    resolution (or automated resolution by git rerere) ended up
    taking either parent's version, we did not show _anything_ for
    that path.  Either was quite bad and confusing.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  3. s/SHELL/SHELL_PATH/ in Makefile

    Fredrik Kuivinen committed with Junio C Hamano
    With the current Makefile we don't use the shell chosen by the
    platform specific defines when we invoke GIT-VERSION-GEN.
    
    Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  4. bisect: remove BISECT_NAMES after done.

    Junio C Hamano committed
    I noticed that we forgot to clean this file and kept it that
    way, while trying to help with Andrew's bisect problem.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  5. Documentation: git-ls-files asciidocco.

    Junio C Hamano committed
    Noticed by Jon Nelson.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Feb 13, 2006
  1. Documentation: git-commit in 1.2.X series defaults to --include.

    Junio C Hamano committed
    The documentation was mistakenly describing the --only semantics to
    be default.  The 1.2.0 release and its maintenance series 1.2.X will
    keep the traditional --include semantics as the default.  Clarify the
    situation.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Commits on Feb 12, 2006
  1. GIT 1.2.0

    Junio C Hamano committed
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  2. Fix "test: unexpected operator" on bsd

    Junio C Hamano committed
    This fixes the same issue as a previous fix by Alex Riesen does.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
  3. git-commit: show dirtiness including index.

    Junio C Hamano committed
    Earlier, when we switched a branch we used diff-files to show
    paths that are dirty in the working tree.  But we allow switching
    branches with updated index ("read-tree -m -u $old $new" works that
    way), and only showing paths that have differences in the working
    tree but not paths that are different in index was confusing.
    
    This shows both as modified from the top commit of the branch we
    just have switched to.
    
    Signed-off-by: Junio C Hamano <junkio@cox.net>
Something went wrong with that request. Please try again.