This project is mirrored from Pull mirroring updated .
  1. 20 Nov, 2005 22 commits
  2. 19 Nov, 2005 3 commits
  3. 18 Nov, 2005 15 commits
    • Junio C Hamano's avatar
    • Junio C Hamano's avatar
      Rewrite rebase to use git-format-patch piped to git-am. · 7f59dbbb
      Junio C Hamano authored
      The current rebase implementation finds commits in our tree but
      not in the upstream tree using git-cherry, and tries to apply
      them using git-cherry-pick (i.e. always use 3-way) one by one.
      Which is fine, but when some of the changes do not apply
      cleanly, it punts, and punts badly.
      Suppose you have commits A-B-C-D-E since you forked from the
      upstream and submitted the changes for inclusion.  You fetch
      from upstream head U and find that B has been picked up.  You
      run git-rebase to update your branch, which tries to apply
      changes contained in A-C-D-E, in this order, but replaying of C
      fails, because the upstream got changes that touch the same area
      from elsewhere.
      Now what?
      It notes that fact, and goes ahead to apply D and E, and at the
      very end tells you to deal with C by hand.  Even if you somehow
      managed to replay C on top of the result, you would now end up
      with ...-B-...-U-A-D-E-C.
      Breaking the order between B and others was the conscious
      decision made by the upstream, so we would not worry about it,
      and even if it were worrisome, it is too late for us to fix now.
      What D and E do may well depend on having C applied before them,
      which is a problem for us.
      This rewrites rebase to use git-format-patch piped to git-am,
      and when the patch does not apply, have git-am fall back on
      3-way merge.  The updated diff/patch pair knows how to apply
      trivial binary patches as long as the pre- and post-images are
      locally available, so this should work on a repository with
      binary files as well.
      The primary benefit of this change is that it makes rebase
      easier to use when some of the changes do not replay cleanly.
      In the "unapplicable patch in the middle" case, this "rebase"
      works like this:
       - A series of patches in e-mail form is created that records
         what A-C-D-E do, and is fed to git-am.  This is stored in
         .dotest/ directory, just like the case you tried to apply
         them from your mailbox.  Your branch is rewound to the tip of
         upstream U, and the original head is kept in .git/ORIG_HEAD,
         so you could "git reset --hard ORIG_HEAD" in case the end
         result is really messy.
       - Patch A applies cleanly.  This could either be a clean patch
         application on top of rewound head (i.e. same as upstream
         head), or git-am might have internally fell back on 3-way
         (i.e.  it would have done the same thing as git-cherry-pick).
         In either case, a rebased commit A is made on top of U.
       - Patch C does not apply.  git-am stops here, with conflicts to
         be resolved in the working tree.  Yet-to-be-applied D and E
         are still kept in .dotest/ directory at this point.  What the
         user does is exactly the same as fixing up unapplicable patch
         when running git-am:
         - Resolve conflict just like any merge conflicts.
         - "git am --resolved --3way" to continue applying the patches.
       - This applies the fixed-up patch so by definition it had
         better apply.  "git am" knows the patch after the fixed-up
         one is D and then E; it applies them, and you will get the
         changes from A-C-D-E commits on top of U, in this order.
      I've been using this without noticing any problem, and as people
      may know I do a lot of rebases.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Junio C Hamano's avatar
      git-branch: -f to forcibly reset branch head. · eb777612
      Junio C Hamano authored
      A new usage, 'git-branch -f branch [start]', resets the branch head at
      start (or current head).  Should be considered a dangerous operation,
      but if you are like me to keep rewinding branches it is handy.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Junio C Hamano's avatar
      Do not show .exe in git command list. · f9039f30
      Junio C Hamano authored
      Truncate the result from readdir() in the exec-path if they end
      with .exe, to make it a bit more readable on Cygwin.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Lukas Sandström's avatar
    • Lukas Sandström's avatar
    • Lukas Sandström's avatar
      Remove all old packfiles when doing "git repack -a -d" · 62af0b53
      Lukas Sandström authored
      No point in running git-pack-redundant if we already know
      which packs are redundant.
      Signed-off-by: default avatarLukas Sandström <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Luck, Tony's avatar
      Update pull/fetch --tags documentation · 4d16f8de
      Luck, Tony authored
      When fetching/pulling from a remote repository the "--tags" option
      can be used to pull tags too.  Document that it will limit the pull
      to only commits reachable from the tags.
      Signed-off-by: default avatarTony Luck <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Lukas Sandström's avatar
      Fix a bug in get_all_permutations. · 0cb022e0
      Lukas Sandström authored
      This line was missing in the previous patch for some reason.
      Signed-off-by: default avatarLukas Sandström <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Junio C Hamano's avatar
      Cygwin *might* be helped with NO_MMAP · 2e67a5f4
      Junio C Hamano authored
      When HPA added Cygwin target, it ran just fine without NO_MMAP for him,
      but recently we are getting reports that for some people things break
      without it.  For now, just suggest it in the Makefile without actually
      updating the default.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Linus Torvalds's avatar
      Teach "approxidate" about weekday syntax · a8aca418
      Linus Torvalds authored
      On Fri, 18 Nov 2005, David Roundy wrote:
      > Don't forget "high noon"!  (and perhaps "tea time"?)  :)
          [[email protected] git]$ ./test-date "now" "midnight" "high noon" "tea-time"
          now -> bad -> Wed Dec 31 16:00:00 1969
          now -> Fri Nov 18 08:50:54 2005
          midnight -> bad -> Wed Dec 31 16:00:00 1969
          midnight -> Fri Nov 18 00:00:00 2005
          high noon -> bad -> Wed Dec 31 16:00:00 1969
          high noon -> Thu Nov 17 12:00:00 2005
          tea-time -> bad -> Wed Dec 31 16:00:00 1969
          tea-time -> Thu Nov 17 17:00:00 2005
      Thanks for pointing out tea-time.
      This is also written to easily extended to allow people to add their own
      important dates like Christmas and their own birthdays.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Linus Torvalds's avatar
      Make "git fetch" less verbose by default · 583122cd
      Linus Torvalds authored
      When doing something like
      	git fetch --tags origin
      the excessively verbose output of git fetch makes the result totally
      unreadable. It's impossible to tell if it actually fetched anything new or
      not, since the screen will fill up with an endless supply of
         * committish: 9165ec17fde255a1770886189359897dbb541012
           tag 'v0.99.7c' of
         * refs/tags/v0.99.7c: same as tag 'v0.99.7c' of
      and any new tags that got fetched will be totally hidden.
      So add a new "--verbose" flag to "git fetch" to enable this verbose mode,
      but make the default be quiet.
      NOTE! The quiet mode will still report about new or changed heads, so if
      you are really fetching a new head, you'll see something like this:
         [[email protected] git]$ git fetch --tags parent
         Packing 6 objects
         Unpacking 6 objects
          100% (6/6) done
         * refs/tags/v1.0rc2: storing tag 'v1.0rc2' of
         * refs/tags/v1.0rc3: storing tag 'v1.0rc3' of
         * refs/tags/v1.0rc1: storing tag 'v1.0rc1' of
      which actually tells you something useful that isn't hidden by all the
      useless crud that you already had.
      Extensively tested (hey, for me, this _is_ extensive) by doing a
         rm .git/refs/tags/v1.0rc*
      and re-fetching with both --verbose and without.
      NOTE! This means that if the fetch didn't actually fetch anything at all,
      git fetch will be totally quiet. I think that's much better than being so
      verbose that you can't even tell whether something was fetched or not, but
      some people might prefer to get a "nothing to fetch" message in that case.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Lukas Sandström's avatar
      Fix bug introduced by the latest changes to git-pack-redundant · 3afd1694
      Lukas Sandström authored
      I forgot to initialize part of the pll struct when copying it.
      Found by valgrind.
      Signed-off-by: default avatarLukas Sandström <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Junio C Hamano's avatar
    • Junio C Hamano's avatar
      git-am: --binary; document --resume and --binary. · 087b6742
      Junio C Hamano authored
      Now git-apply can grok binary replacement patches, give --binary
      flag to git-am.  As a safety measure, this is not by default
      enabled, so that you do not let malicious e-mailed patch to
      replace an arbitrary path with just a couple of lines (diff
      index lines, the filename and string "Binary files "...) by
      Signed-off-by: default avatarJunio C Hamano <[email protected]>