Re: [RFD] remembering hand resolve...

Junio C Hamano wrote:
> 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?


> 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.

> 
> 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.
> 

> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html