All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Josh Steadmon <steadmon@google.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH] sequencer: warn on skipping previously seen commit
Date: Wed, 04 Aug 2021 14:28:22 -0700	[thread overview]
Message-ID: <xmqqsfzonbm1.fsf@gitster.g> (raw)
In-Reply-To: <4d83766ab3425a5f4b361df2ac505d07fefd7899.1628109852.git.steadmon@google.com> (Josh Steadmon's message of "Wed, 4 Aug 2021 13:53:45 -0700")

Josh Steadmon <steadmon@google.com> writes:

> Silently skipping commits when rebasing with --no-reapply-cherry-picks
> (currently the default behavior) can cause user confusion. Issue a
> warning in this case so that users are aware of what's happening.
>
> Signed-off-by: Josh Steadmon <steadmon@google.com>
> ---
>
> We've had some complaints at $JOB where users were confused when
> rebasing branches that contained commits that were previously
> cherry-picked into their master branch. How do folks feel about adding a
> warning in this case?

I'd unconditionally in support if this were done under --verbose
option, but it becomes iffy if this is done unconditionally.

This is because I do not expect everybody will stay to be ignorant
of the behaviour of the tool they use every day, and I'd fear that
we'd start hearing "yeah, I know the command would skip to avoid
duplicated changes, why waste lines to tell me that?" complaints.

Having said that, I _hope_ that in a project with good hygiene, such
a multiple cherry-picking would not be so common and an exception,
and if my _hope_ proves to be true, then I am OK with giving this
warning unconditionally.  The user may know what the command does
when it sees a duplicated change, but the warning becomes about the
presence of such duplicated changes, which would be a rare event
that is worth notifying about.

>  		is_empty = is_original_commit_empty(commit);
> -		if (!is_empty && (commit->object.flags & PATCHSAME))
> +		if (!is_empty && (commit->object.flags & PATCHSAME)) {
> +			warning(_("skipped previously seen commit %s"),

I am debating myself if s/seen/applied/ should be suggested here.

The existing text in the manual page says "a patch already accepted
upstream with a different commit message or timestamp will be
skipped", and "accepted" is a verb that would apply only in a
certain workflow, which is OK in the manual page that give more
context, but not here.  But 'seen' feels a bit too weak to me.

> +	if (skipped_commit)
> +		warning(_("use --reapply-cherry-picks to include skipped commits"));

I'd be hesitant to endorse doing this kind of "here is how to use
this command" unconditionally.  Perhaps under --verbose, or hide it
under "advise.*".

Thanks.

  reply	other threads:[~2021-08-04 21:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-04 20:53 [RFC PATCH] sequencer: warn on skipping previously seen commit Josh Steadmon
2021-08-04 21:28 ` Junio C Hamano [this message]
2021-08-05 10:13   ` Phillip Wood
2021-08-05 16:30     ` Junio C Hamano
2021-08-10 19:20 ` [PATCH v2] sequencer: advise if skipping cherry-picked commit Josh Steadmon
2021-08-10 22:33   ` Junio C Hamano
2021-08-18 10:08     ` Phillip Wood
2021-08-30 21:19     ` Josh Steadmon
2021-08-12 17:45   ` Philippe Blain
2021-08-12 19:13     ` Junio C Hamano
2021-08-18 10:02     ` Phillip Wood
2021-08-18 22:45       ` Philippe Blain
2021-08-19 10:04         ` Phillip Wood
2021-08-30 21:21     ` Josh Steadmon
2021-08-25 19:40   ` Junio C Hamano
2021-08-30 21:46 ` [PATCH v3] " Josh Steadmon
2021-08-30 22:21   ` Junio C Hamano
2021-08-30 23:40     ` 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=xmqqsfzonbm1.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=steadmon@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.