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
next prev parent 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
List information: http://vger.kernel.org/majordomo-info.html
* 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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).