On 7/11/2011 6:21 PM, Junio C Hamano wrote: > Jeff King<peff@xxxxxxxx> writes: > >> ... But with a commit no top, you get: >> >> <<<<<<< HEAD >> two >> ======= >> one >> >>>>>>> one >> >> which looks like you are reverting, because of course you are building >> on top of the finished series. > Exactly. > >> $ git rebase master topic >> Applying: one >> Using index info to reconstruct a base tree... >> Falling back to patching base and 3-way merge... >> Auto-merging file >> CONFLICT (content): Merge conflict in file >> Failed to merge in the changes. >> Patch failed at 0001 one >> >> hint: this commit may already be in upstream as 1234abcd; >> hint: the differences between that commit and this one are: >> >> diff --git a/file b/file >> --- a/file >> +++ b/file >> @@ -1 +1 @@ >> -modified one >> +one >> >> When you have resolved this problem run "git rebase --continue". >> If you would prefer to skip this patch, instead run "git rebase --skip". >> To restore the original branch and stop rebasing run "git rebase --abort". > Actually I do not think identifying the ones that can safely skipped is > such a big issue. The case I am most concerned about is when you see that > "two reverted back to one" (which you obviously want to avoid, to keep the > effect of the commit the upstream has to have "two" on that line), but at > the same time when you do not agree with the change that the upstream took > for the _current commit_ you are replaying (i.e. you want the final result > to have "one", not "modified one" which the upstream has applied). > > The conflict resolution to come up with such an incremental change is very > painful. You have to avoid the "s/two/one/" revert, and you have to keep > the "s/modified one/one" revert, and you need to know which hunks are > conflicting due to what (i.e. the former is because a patch similar to the > one you haven't replayed in this rebase session is already in upstream, > the latter is the upstream tweaked the current patch you are looking at in > a way you do not agree with). > > I do not have a good idea to solve this in mind yet. I am not 100% sure that my solution is exactly about this problem, but it seems to be quite relevant. I think that if you rebase "step-by-step" by doing, for this particular example, something like $ git rebase master^ topic $ git rebase master topic You will first see the /modified one/one/ conflict that you will resolve your "two" against and then your second rebase will apply with no conflicts. I have a set of scripts that help me do this kind of rebases by essentially rebasing the topic branch against every single commit on the upstream. This way I can clearly see every conflict as at appears and can fix it even in cases when a rebase against the final state would give an absolutely unbearable diff. It definitely is much slower but in my case I find this to be the only possible solution. rerere helps enormously here. At the same time the less changes are in topic...master the faster it would be and the more changes are there the more you benefit from a gradual rebase. Here is the actual use case in case I was not very clear above or in case someone is interested. I have a very longed lived branch that I have to rebase against an actively developed master. Besides been longed live the branch contains a lot of absolutely unrelated changes. The branch is a "next version branch" and contains a result of a two year work done by two people who though that their version of the application will become master "tomorrow", so they where not too shy to change things. The upstream is developed by another 6 - 8 people over 3 years and they have no knowledge of the changes done in the "next version branch". Here is were I step in and am told to get the changes from the next version branch onto the master. And I am not part of either of these two groups of people. In addition to that one of the guys who developed the next version has left the company before I joined and the other one is also gone by now. While it seems pretty crazy to me, thanks to git rebase, git rerere and the "step-by-step" rebase I am at my 9th rebase of this topic branch through last year and had only minor problems so far. Essentially now we have 6 people developing the application "in the middle" of its history with one person trying to hold the rest of the history on top. I imagine this as a kind of an acrobatic trick worth showing in a circus :) Ilya Bobyr-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html