1. 09 Nov, 2006 1 commit
  2. 04 Oct, 2006 2 commits
  3. 25 Sep, 2006 1 commit
    • Junio C Hamano's avatar
      Deprecate merge-recursive.py · a06f678e
      Junio C Hamano authored
      This renames merge-recursive written in Python to merge-recursive-old,
      and makes merge-recur as a synonym to merge-recursive.  We do not remove
      merge-recur yet, but we will remove merge-recur and merge-recursive-old
      in a few releases down the road.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      a06f678e
  4. 31 Jul, 2006 2 commits
  5. 14 Jul, 2006 3 commits
    • Junio C Hamano's avatar
      recur vs recursive: help testing without touching too many stuff. · 06d30f4f
      Junio C Hamano authored
      During git-merge-recur development, you could set an environment
      variable GIT_USE_RECUR_FOR_RECURSIVE to use WIP recur in place
      of the recursive strategy.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      06d30f4f
    • Johannes Schindelin's avatar
      Status update on merge-recursive in C · 6d297f81
      Johannes Schindelin authored
      This is just an update for people being interested. Alex and me were
      busy with that project for a few days now. While it has progressed nicely,
      there are quite a couple TODOs in merge-recursive.c, just search for "TODO".
      
      For impatient people: yes, it passes all the tests, and yes, according
      to the evil test Alex did, it is faster than the Python script.
      
      But no, it is not yet finished. Biggest points are:
      
      - there are still three external calls
      - in the end, it should not be necessary to write the index more than once
        (just before exiting)
      - a lot of things can be refactored to make the code easier and shorter
      
      BTW we cannot just plug in git-merge-tree yet, because git-merge-tree
      does not handle renames at all.
      
      This patch is meant for testing, and as such,
      
      - it compile the program to git-merge-recur
      - it adjusts the scripts and tests to use git-merge-recur instead of
        git-merge-recursive
      - it provides "TEST", a script to execute the tests regarding -recursive
      - it inlines the changes to read-cache.c (read_cache_from(), discard_cache()
        and refresh_cache_entry())
      
      Brought to you by Alex Riesen and Dscho
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      6d297f81
    • Shawn Pearce's avatar
      8ef1c7c7
  6. 08 Jul, 2006 1 commit
  7. 28 Jun, 2006 2 commits
  8. 27 Jun, 2006 1 commit
  9. 25 Jun, 2006 3 commits
  10. 22 Jun, 2006 1 commit
    • Junio C Hamano's avatar
      rebase --merge: fix for rebasing more than 7 commits. · 5887ac82
      Junio C Hamano authored
      Instead of using 4-digit numbers to name commits being rebased,
      just use "cmt.$msgnum" string, with $msgnum as a decimal number
      without leading zero padding.  This makes it possible to rebase
      more than 9999 commits, but of more practical importance is that
      the earlier code used "printf" to format already formatted
      $msgnum and barfed when it counted up to 0008.  In other words,
      the old code was incapable of rebasing more than 7 commits, and
      this fixes that problem.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      5887ac82
  11. 21 Jun, 2006 2 commits
  12. 21 May, 2006 1 commit
  13. 14 May, 2006 1 commit
  14. 27 Apr, 2006 1 commit
    • sean's avatar
      Add --continue and --abort options to git-rebase. · 031321c6
      sean authored
        git rebase [--onto <newbase>] <upstream> [<branch>]
        git rebase --continue
        git rebase --abort
      
      Add "--continue" to restart the rebase process after
      manually resolving conflicts.  The user is warned if
      there are still differences between the index and the
      working files.
      
      Add "--abort" to restore the original branch, and
      remove the .dotest working files.
      
      Some minor additions to the git-rebase documentation.
      
      [jc: fix that applies to the maintenance track has been dealt
       with separately.]
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      031321c6
  15. 26 Apr, 2006 1 commit
  16. 13 Apr, 2006 1 commit
  17. 22 Feb, 2006 2 commits
  18. 15 Feb, 2006 1 commit
    • Junio C Hamano's avatar
      rebase: allow rebasing onto different base. · e646c9c8
      Junio C Hamano authored
      This allows you to rewrite history a bit more flexibly, by
      separating the other branch name and new branch point.  By
      default, the new branch point is the same as the tip of the
      other branch as before, but you can specify where you graft the
      rebased branch onto.
      
      When you have this ancestry graph:
      
                A---B---C topic
               /
          D---E---F---G master
      
      	$ git rebase --onto master~1 master topic
      
      would rewrite the history to look like this:
      
      	      A'\''--B'\''--C'\'' topic
      	     /
          D---E---F---G master
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      e646c9c8
  19. 13 Feb, 2006 1 commit
  20. 15 Dec, 2005 1 commit
  21. 14 Dec, 2005 2 commits
  22. 28 Nov, 2005 1 commit
    • Junio C Hamano's avatar
      rebase: one safety net, one bugfix and one optimization. · 7f4bd5d8
      Junio C Hamano authored
      When a .dotest from a previously failed rebase or patch
      application exists, rebase got confused and tried to apply
      mixture of what was already there and what is being rebased.
      Check the existence of the directory and barf.
      
      It failed with an mysterious "fatal: cannot read mbox" message
      if the branch being rebased is fully in sync with the base.
      Also if the branch is a proper descendant of the base, there is
      no need to run rebase logic.  Prevent these from happening by
      checking where the merge-base is.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      7f4bd5d8
  23. 25 Nov, 2005 1 commit
  24. 18 Nov, 2005 1 commit
    • 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]>
      7f59dbbb
  25. 28 Sep, 2005 1 commit
  26. 08 Sep, 2005 1 commit
    • Junio C Hamano's avatar
      Big tool rename. · 215a7ad1
      Junio C Hamano authored
      As promised, this is the "big tool rename" patch.  The primary differences
      since 0.99.6 are:
      
        (1) git-*-script are no more.  The commands installed do not
            have any such suffix so users do not have to remember if
            something is implemented as a shell script or not.
      
        (2) Many command names with 'cache' in them are renamed with
            'index' if that is what they mean.
      
      There are backward compatibility symblic links so that you and
      Porcelains can keep using the old names, but the backward
      compatibility support  is expected to be removed in the near
      future.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      215a7ad1
  27. 29 Aug, 2005 1 commit
    • Junio C Hamano's avatar
      Redo "revert" using three-way merge machinery. · 48313592
      Junio C Hamano authored
      The reverse patch application using "git apply" sometimes is too
      rigid.  Since the user would get used to resolving conflicting merges
      by hand during the normal merge experience, using the same machinery
      would be more helpful rather than just giving up.
      
      Cherry-picking and reverting are essentially the same operation.
      You pick one commit, and apply the difference that commit introduces
      to its own commit ancestry chain to the current tree.  Revert applies
      the diff in reverse while cherry-pick applies it forward.  They share
      the same logic, just different messages and merge direction.
      
      Rewrite "git rebase" using "git cherry-pick".
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      48313592
  28. 18 Aug, 2005 2 commits
  29. 17 Aug, 2005 1 commit