From: Junio C Hamano <gitster@pobox•com>
To: Stefan Haller <lists@haller-berlin•de>
Cc: Phillip Wood <phillip.wood123@gmail•com>, Git <git@vger•kernel.org>
Subject: Re: Thoughts about the -m option of cherry-pick and revert
Date: Mon, 24 Jun 2024 11:43:46 -0700 [thread overview]
Message-ID: <xmqqmsnab2ql.fsf@gitster.g> (raw)
In-Reply-To: <0a948acf-ebe9-407e-8899-d714b6fcb528@haller-berlin.de> (Stefan Haller's message of "Mon, 24 Jun 2024 09:33:24 +0200")
Stefan Haller <lists@haller-berlin•de> writes:
> And we prefer single-commit cherry-picks of the merge commits because it
> makes the history of the release branches easier to read.
I would have expected that "git log --first-parent" would give you
the same "easy-to-read" history as a run of squached cherry-picks.
It of course takes some discipline to ensure that the first-parent
chain is kept meaningful, but "never merge, always cherry-pick the
merges of topics" also already takes some discipline, so I do not
see either workflow has much upside with respect to this point.
> I'm not saying I'm very happy with this workflow, it wasn't my decision.
> And in particular I'm not trying to argue which workflow is better than
> the other; all I'm saying is that there are teams who decide they want
> to cherry-pick merge commits, so git should continue to allow it. This
> is only in response to your earlier "If I were simplifying this, I would
> probably [...] disallow cherry-picking a merge".
Sure. I thought it was fairly obvious to everybody that I was not
"simplifying this", at least unilaterally, so raising a concern like
you did was the right thing ;-).
> (Side note: my main gripe about cherry-picking in general is, of course,
> that it makes it impossible to use "git branch --contains" or "git tag
> --contains" to find out which releases contain a given bug fix; but
> that's a problem no matter whether you cherry-pick the merge commit, or
> replay the branch on maint and merge it there again.)
Correct for the "cherry-picking", but not necessarily for a "rebase
and merge".
You can have (1) a "fix" based on the "main", and (2) the backport
of the same "fix" rebased on the "maint", the latter of which has
likely been spawned after the former was merged to "main". You can
merge the "rebased fix" to the "maint" *as well as* to the "main".
If we think about it, that is a natural thing to do. By rebasing
"fix" to "maint" to create "rebased fix", we are "correcting" an
earlier mistake of basing the fix on a wrong (iow, too recent)
point, so after such a rebase, we treat the rebased result as the
primary thing.
After that, "contains" will do the right thing for the "rebased
fix", which is now the primary fix, and shows both "main" and
"maint" has it.
Of course, a project can choose to adopt a workflow that refuses to
obtain such a benefit (presumably for other reasons that gives
benefits that outweigh the "sigh, we cannot merge but have to
cherry-pick, with all the inconveniences").
next prev parent reply other threads:[~2024-06-24 18:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-20 10:05 Thoughts about the -m option of cherry-pick and revert Stefan Haller
2024-06-21 2:03 ` Junio C Hamano
2024-06-21 6:33 ` Stefan Haller
2024-06-21 10:19 ` Phillip Wood
2024-06-21 11:48 ` Stefan Haller
2024-06-21 16:34 ` Junio C Hamano
2024-06-24 7:33 ` Stefan Haller
2024-06-24 18:43 ` Junio C Hamano [this message]
2024-06-21 10:12 ` Phillip Wood
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=xmqqmsnab2ql.fsf@gitster.g \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=lists@haller-berlin$(echo .)de \
--cc=phillip.wood123@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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