Re: [RFD] remembering hand resolve...

From: Andreas Ericsson <ae@op5.se>
Date: Jan 25, 2006, 13:45 UTC
Message-ID: <43D7810D.9010508@op5.se>
In-Reply-To: <7v4q3ssbr6.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:

Show 8 quoted lines

> As people on the list may know, I keep many mini topic-branches
> and keep combining them on top of then-current master to publish
> "pu".  This involves resolving merge conflicts by hand, when the
> areas topic-branches touch overlap.
> 
> The thing is, I find myself resolving the same conflicts over
> and over.  This is because the master branch tends to advance
> faster than topic branches that touch an overlapping area.

How can that be possible? If the area of code in master is modified beyond simple merging from the topic-branches, the resulting diff (which has to be against master's HEAD) should apply cleanly so long as there aren't *new* changes to master, in which case the pu commit needs adaptation again, so it wouldn't really be the same conflict (or even necessarily a similar one), would it?

Show 7 quoted lines

> If I linearize topic-branches that conflict with each other in
> some way, say base topic B on top of topic A, I would not have
> problem merging them into "pu" as long as I do not change my
> mind later and try to merge only topic B without topic A.  But
> that defeats the whole point of having independent topic
> branches.
>

Wouldn't cherry-pick be useful here? If it isn't, I fail to understand how a merge can solve it for you. Admittedly, I know little of the inner workings of git.

Show 8 quoted lines

> 
> A trivial solution would be to save the diff between conflicted
> automerge result before hand resolving, and the result of my
> hand resolve, and apply with "patch" when I see a conflicted
> automerge the next time.  I've tried this by hand and it worked
> quite well tonight, but I felt it was somewhat kludgy.  We
> should be able to do better than that, with some tool support.
>

Show 6 quoted lines

> Another obvious way is to avoid rebuilding "pu"; instead I could
> pull "master" into "pu" every time I have added something new to
> "master".  That would work most of the time, until I decide to
> change the order the topic branches are merged into "pu" (or
> drop one of them).
>

Couldn't you do something like this:

for t in $topic_branches; do
	checkout $t
	git rebase master
done
git checkout master
git branch -D pu
git checkout -b pu
git pull . $topic_branches

That's what I thought you were doing right now, but I can't imagine that flow leading to the same conflicts over and over, so I must be mistaken somehow.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231