Git - reorder commit on branch as early as possible without conflict

Question

How can I move the commit of a branch as early as possible without any conflicts (without a lot of manual work, for example, rebase -i)?

For instance,

A-B-C-DX

should become

A-B-X-C-D

if replacing X with C and D has no conflicts, but replacing X with B will lead to a conflict.

Thanks.

Answer 1

Well, this pretty much works, but does require some cleaning.

After working with him for a while, I ran into another problem that I posted here .

  #! / bin / sh -e

 # todo: integrate with git
 GIT_DIR =. /. Git /

 commitid = $ 1

 if ["$ 1" = ""];  then
    echo usage: $ 0 commitid
    exit 1
 fi

 tmpdir = "$ GIT_DIR / bubble-work"
 / bin / rm -rf "$ tmpdir"
 mkdir "$ tmpdir"

 # checkout commit with detached head
 git checkout -q $ commitid ^ 0 ||  die "could not detach HEAD"

 while [1 = 1];  do

 # todo pipe output to avoid temp files
 # see git-rebase.sh

 patchfile = `git format-patch -k --full-index --src-prefix = a / --dst-prefix = b / --no-renames -o" $ tmpdir "HEAD ~ 1`
 echo patch = $ patchfile

 git checkout -q HEAD ~ 2
 git am --rebasing "$ patchfile" ||  die "git am failed"
 / bin / rm -f "$ patchfile"

 echo looping
 done



 / bin / rm -rf "$ tmpdir"

Answer 2

Use git rebase -i X~ , where X~ is the version prior to X

Then change the order of the lines in the reinstallation log to the desired order.

Learn more about interactive rebooting .

Answer 3

Here is a demonstration of what I came up with after 15 minutes of hacking. This is not a complete solution to the problem, but it should reduce the work.

The goal is to use git bisect to find the earliest merge point without conflict for future commit. The solution takes advantage of the binary search inherent in git bisect to shorten the steps.

Unfortunately, this does not prevent an exception due to conflict, so interactive redirection is required to check the results (but this is the point).

One of the drawbacks / caveats is that you have to change the meaning of good and bad in your head when you instruct git about whether this step was unsuccessful or succeeded when testing the patch.

If any of the steps below is unclear, let me know and I will try to clarify.

First create the next file in a series of commits. Each commit should add a series of four identical lines (a, then b, then c, and then ds).

 a a a a b b b b c c c c d d d d 

At this point, git log should display something like:

 commit 6f2b809863632a86cc0523df3a4bcca22cf5ab17 Author: Todd Sundsted <...> Date: Tue Dec 20 22:45:44 2011 -0500 Added d. commit 91ba7e6f19db74adb6ce79e7b85ea965788f6b88 Author: Todd Sundsted <...> Date: Tue Dec 20 22:44:26 2011 -0500 Added c. commit f83beee55d6e060536584852ebb55c5ac3b850b2 Author: Todd Sundsted <...> Date: Tue Dec 20 22:44:00 2011 -0500 Added b. commit d6d924b0a30a9720f6e01dcc79dc49097832a587 Author: Todd Sundsted <...> Date: Tue Dec 20 22:43:38 2011 -0500 Added a. commit 74d41121470108642b1a5df087bc837fdf77d31c Author: Todd Sundsted <...> Date: Tue Dec 20 22:43:11 2011 -0500 Initial commit. 

Now edit the file to contain the following and commit it:

 a a a a b x x b c x x c d d d d 

Now the log should include another commit:

 commit 09f247902a9939cb228b580d39ed2622c3211ca6 Author: Todd Sundsted <...> Date: Tue Dec 20 22:46:36 2011 -0500 Replaced a few lines with x. 

Now create a patch to fix X

 git diff -p master~ > x.patch 

Finish bisect - remember to use git bisect good if the fix is ​​not completed, and git bisect bad when the patch succeeds:

 $ git bisect start $ git bisect good 74d41121470108642b1a5df087bc837fdf77d31c $ git bisect bad master Bisecting: 2 revisions left to test after this (roughly 1 step) [f83beee55d6e060536584852ebb55c5ac3b850b2] Added b. $ patch --dry-run -p1 < x.patch patching file file.txt Hunk #1 FAILED at 3. 1 out of 1 hunk FAILED -- saving rejects to file file.txt.rej $ git bisect good Bisecting: 0 revisions left to test after this (roughly 1 step) [6f2b809863632a86cc0523df3a4bcca22cf5ab17] Added d. $ patch --dry-run -p1 < x.patch patching file file.txt $ git bisect bad Bisecting: 0 revisions left to test after this (roughly 0 steps) [91ba7e6f19db74adb6ce79e7b85ea965788f6b88] Added c. $ patch --dry-run -p1 < x.patch patching file file.txt Hunk #1 succeeded at 3 with fuzz 2. $ git bisect bad 91ba7e6f19db74adb6ce79e7b85ea965788f6b88 is the first bad commit commit 91ba7e6f19db74adb6ce79e7b85ea965788f6b88 Author: Todd Sundsted <...> Date: Tue Dec 20 22:44:26 2011 -0500 Added c. $ git bisect reset 

As expected, changes to commit X can be rolled over immediately after commit C Interactive permutation confirms this:

 91e92489 * Added d. 6c082b1f * Replaced a few lines with x. a60ae2a9 * Added c. 4d5e78f2 * Added b. 7d2ff759 * Added a. 74d41121 * Initial commit.