git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v7 0/5] making pull advice not to trigger when unneeded
Date: Tue, 15 Dec 2020 02:58:05 -0800	[thread overview]
Message-ID: <xmqqmtyf8hfm.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: 5fd85811c3a6_d7c48208aa@natae.notmuch

Felipe Contreras <felipe.contreras@gmail.com> writes:

>> To avoid the ugly-looking "strcmp()" in the above, we may need to
>> adjust "--ff" (fast-forward without creating an extra merge commit)
>> and "--no-ff" (create an extra merge commit when the history could
>> be fast-forwarded) to imply "merge", though.
>> ...
>
> Or do you mean --ff doesn't override --rebase? Therefore it's more of an
> internal conceptual change.

I meant "--ff/--no-ff" without saying anything between merge and
rebase would make merge implied.  It was merely for the purpose of
getting rid of !opt_ff in the condition there and such an implied
merge would be one way to ensure that rebase_unspecified becomes
false.

"--no-ff --rebase" (in any order) would be a nonsense combination,
as it asks "please create an extra merge commit even when the
history fast-forwards, but by the way I do not want merge I want
rebase" [*1*].  It should error out when the history fast-forwards,
I think, and it probably should also error out when the history does
not fast-forward, instead of rebasing.

"--ff --rebase" (in any order), on the other hand, would be "if the
history fast-forwards, just do so without creating an extra merge
commit, by the way, I prefer rebase and not merge".  If the history
fast-forwards, it is OK to just fast-forward (using the merge
backend if needed), as rebasing against the history that is ahead of
us would mean all our unique development since we diverged from them,
which is nothing, will be replayed on top of their history.  If the
history does not fast-forward, then the precondition of "--ff" part
does not hold, so just rebasing as if "--ff" does not exist would
probably be OK, too.

In any case, I haven't thought the opt_ff part of the expression
through.  During the review of v5 3/3 (and doing v7 5/5), what I was
more interested in was to ensure the verbosity option, which would
control how verbose a message we should be giving, can stay
independent of other conditionals, which would control if we even
need to error out and/or give hints.

Thanks.


[Footnote]

*1* Even though the current code may simply ignore --no-ff after the
control is given to the rebase codepath,

  reply	other threads:[~2020-12-15 11:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-14 20:26 [PATCH v7 0/5] making pull advice not to trigger when unneeded Junio C Hamano
2020-12-14 20:26 ` [PATCH v7 1/5] pull: refactor fast-forward check Junio C Hamano
2020-12-14 20:26 ` [PATCH v7 2/5] pull: give the advice for choosing rebase/merge much later Junio C Hamano
2020-12-14 20:26 ` [PATCH v7 3/5] pull: get rid of unnecessary global variable Junio C Hamano
2020-12-14 20:59   ` Felipe Contreras
2020-12-14 23:16     ` Junio C Hamano
2020-12-15  2:55       ` Felipe Contreras
2020-12-14 20:26 ` [PATCH v7 4/5] pull: correct condition to trigger non-ff advice Junio C Hamano
2020-12-14 21:17   ` Felipe Contreras
2020-12-14 23:19     ` Junio C Hamano
2020-12-15  6:35       ` Felipe Contreras
2020-12-14 20:26 ` [PATCH v7 5/5] pull: display default warning only when non-ff Junio C Hamano
2020-12-14 21:24   ` Felipe Contreras
2020-12-14 23:20     ` Junio C Hamano
2020-12-15  2:57       ` Felipe Contreras
2020-12-15  6:30 ` [PATCH v7 0/5] making pull advice not to trigger when unneeded Felipe Contreras
2020-12-15 10:58   ` Junio C Hamano [this message]
2020-12-15 12:22     ` Felipe Contreras
2020-12-18 20:46       ` Felipe Contreras
2020-12-23 10:04         ` Junio C Hamano
2020-12-23 14:10           ` Felipe Contreras

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=xmqqmtyf8hfm.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=felipe.contreras@gmail.com \
    --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).