git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Abhijit Menon-Sen <ams@toroid.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: [PATCH v2] Make cherry-pick use rerere for conflict resolution.
Date: Mon, 11 Aug 2008 11:47:01 -0700	[thread overview]
Message-ID: <7vmyjjxuca.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: 20080811023053.GA9144@toroid.org

Abhijit Menon-Sen <ams@toroid.org> writes:

> It was a dark and stormy night. Sam struggled to keep his eyelids open
> as he integrated yet another gigantic patch series. Ever the optimist,
> he'd pulled in the changes, only to discover several merge conflicts.
> But the night was young then, and he'd fixed them all by hand.
>
> It was only later that he noticed many lousy, one-line commit messages.
> Undaunted, he reset his branch and began to cherry-pick patches, giving
> them a once-over, writing a comment here, squashing the odd grotesque
> hack there, and writing sensible commit messages more often than not.
>
> But even that was hours ago, and each new but oh-so-familiar conflict
> ate into his determination like maggots through decaying meat; and Sam
> was beginning to question the wisdom of staying in this fruit business.
> His whiskey was running low, and time was running out.
>
> "If only", thought Sam, "If only cherry-pick would..."

That's cute, but I do not think that story is a good example.

By "pulled in the changes" do you mean "he merged somebody else's work"?
If so, the cherry-pick would be doing rebase of the series manually, and
as you already may know, you are not supposed to be rebasing other
people's work.  And if you are indeed rebasing, that would not be a good
example of cherry-pick, either.

Do you mean instead "he applied many patches, but there were conflicts and
he wiggled them in?"  If so, at the resolution time rerere() wouldn't have
recorded them in the first place, and more importantly, what you would be
cherry-picking won't have conflicts.  What the second paragraph describes
is what he would do with "git rebase -i" on top of the same base, so there
won't be merge conflicts, and even if there were, the use case is again
about rebase and not cherry-pick.

A better example would be if you have two (or more) maintenance tracks
from similarly old vintage and a far more advanced development track, and
cherry-picking from that development track to backport a fix down to one
of the maintenance track would have conflicts you need to fix.  Then you
would face the same conflict while propagating the same fix to another
maintenance track.  But even then, you would most likely cherry-pick the
cherry-picked fix from the maintenance track, which would be conflict
free, instead of cherry-picking it from the development track.

  parent reply	other threads:[~2008-08-11 18:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-10 11:48 [PATCH] Make cherry-pick use rerere for conflict resolution Abhijit Menon-Sen
2008-08-10 23:12 ` Johannes Schindelin
2008-08-11  2:30   ` [PATCH v2] " Abhijit Menon-Sen
2008-08-11 10:19     ` Johannes Schindelin
2008-08-11 10:40       ` Petr Baudis
2008-08-11 11:32         ` Johannes Schindelin
2008-08-11 11:49           ` Johannes Sixt
2008-08-11 15:54             ` Johannes Schindelin
2008-08-12  7:02               ` Johannes Sixt
2008-08-11 18:47     ` Junio C Hamano [this message]
2008-08-12  2:34       ` Abhijit Menon-Sen
2008-08-12  6:59         ` 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=7vmyjjxuca.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=ams@toroid.org \
    --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.
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 NNTP newsgroup(s).