All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Ericsson <ae@op5.se>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [RFD] remembering hand resolve...
Date: Wed, 25 Jan 2006 14:45:49 +0100	[thread overview]
Message-ID: <43D7810D.9010508@op5.se> (raw)
In-Reply-To: <7v4q3ssbr6.fsf@assigned-by-dhcp.cox.net>

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

  reply	other threads:[~2006-01-25 13:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-25 13:00 [RFD] remembering hand resolve Junio C Hamano
2006-01-25 13:45 ` Andreas Ericsson [this message]
2006-01-25 23:56   ` Junio C Hamano
2006-01-26 11:12     ` How to create and keep up to date a naked/bare repository? Mathieu Chouquet-Stringer
2006-01-26 12:22       ` Junio C Hamano
2006-01-26 15:11         ` Mathieu Chouquet-Stringer
2006-01-26 18:27         ` Mathieu Chouquet-Stringer
2006-01-27  3:36           ` Junio C Hamano
2006-01-27 10:30             ` Refs naming after clone (was: Re: How to create and keep up to date a naked/bare repository?) Josef Weidendorfer
2006-01-27 13:34             ` How to create and keep up to date a naked/bare repository? Mathieu Chouquet-Stringer
2006-01-27 18:41               ` Junio C Hamano
2006-01-27 19:01                 ` J. Bruce Fields
2006-01-27 21:00                   ` Junio C Hamano
2006-01-29  9:10 ` [PATCH/RFC] git-rerere: reuse recorded resolve Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43D7810D.9010508@op5.se \
    --to=ae@op5.se \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.