git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / 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

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