git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: git@vger.kernel.org
Subject: [RFD] remembering hand resolve...
Date: Wed, 25 Jan 2006 05:00:45 -0800	[thread overview]
Message-ID: <7v4q3ssbr6.fsf@assigned-by-dhcp.cox.net> (raw)

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.  I'd
take more time than I usually do to decide what to do with them;
as a result, overlapping topic branches tend to stay unmerged
into "master" longer than other topic branches.

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.

I would imagine that people who use StGIT or quilt would have
similar issues.  If they are in the same series, then inside of
that queue the patches are already ordered to be in some way,
probably conflict is resolved once when the patch is refreshed
and they stay applicable as long as the base part cleanly
applies to the updated base version, but patches in the queue
then depend on the earlier ones in the same series, and
extracting and applying only the later parts of the queue would
need you to manually un-resolve the conflict you earlier
resolved.  If you keep different topics in separate queues, on
the other hand, I would imagine you would have exactly the same
"oh, I know this and that patch conflict with each other and I
recall I resolved that last time I merged everything up" issue.

How do people on patch-queue based systems like StGIT and quilt
deal with this?  I am wondering if somebody have a clever idea
to record and reuse an earlier conflict resolution.

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

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

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-25 13:00 Junio C Hamano [this message]
2006-01-25 13:45 ` [RFD] remembering hand resolve Andreas Ericsson
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=7v4q3ssbr6.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    /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).