From: Junio C Hamano <gitster@pobox.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: Ruslan Yakauleu via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Ruslan Yakauleu <ruslan.yakauleu@gmail.com>
Subject: Re: [PATCH] merge: --ff-one-only to apply FF if commit is one
Date: Tue, 31 Oct 2023 09:19:11 +0900 [thread overview]
Message-ID: <xmqq1qdb8wzk.fsf@gitster.g> (raw)
In-Reply-To: <ZUALkdSJZ70+KBYq@nand.local> (Taylor Blau's message of "Mon, 30 Oct 2023 16:01:21 -0400")
Taylor Blau <me@ttaylorr.com> writes:
> This seems like a pretty niche feature to want to introduce a new option
> for. I would imagine the alternative is something like:
>
> ff="--no-ff"
> if test 1 -eq $(git rev-list @{u}..)
> then
> ff="--ff"
> fi
>
> [on upstream @{u}]
> git merge "$ff" "$branch"
>
> I don't have a great sense of how many users might want or benefit from
> something like this. My sense is that there aren't many, but I could
> very easily be wrong here.
Another more fundamental objection is "Why do we special case only a
singleton commit?"
Why isn't a trivial two-patch series also OK to fast-forward?
Three? There is no inherent reason to draw a line on one commit
topic---given that a single commit could be a large and involved one
that could have been a multi commmit series.
And you cannot decide if the "topic" is large enough to deserve a
binding merge commit even if it is a single commit topic, or if is
small enough and you want to allow fast-forward, without looking at
it first. So from that point of view, too, I do not think this new
option is a good idea. Let's not add an option to encourage a bad
discipline.
Thanks.
next prev parent reply other threads:[~2023-10-31 0:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-25 8:58 [PATCH] merge: --ff-one-only to apply FF if commit is one Ruslan Yakauleu via GitGitGadget
2023-10-25 16:27 ` Kristoffer Haugsbakk
2023-10-25 18:31 ` Ruslan Yakauleu
2023-10-25 19:04 ` Kristoffer Haugsbakk
[not found] ` <c37ba153-7239-49ff-b40f-370bc695986e@gmail.com>
2023-10-26 13:40 ` Ruslan Yakauleu
2023-10-30 20:01 ` Taylor Blau
2023-10-31 0:19 ` Junio C Hamano [this message]
2023-10-31 5:48 ` Ruslan Yakauleu
2023-10-31 6:07 ` Junio C Hamano
2023-10-31 8:32 ` Kristoffer Haugsbakk
2023-11-01 1:42 ` Junio C Hamano
2023-11-01 6:34 ` Ruslan Yakauleu
2023-11-01 10:09 ` Kristoffer Haugsbakk
2023-11-01 23:05 ` Junio C Hamano
2023-10-31 6:01 ` Ruslan Yakauleu
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=xmqq1qdb8wzk.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=me@ttaylorr.com \
--cc=ruslan.yakauleu@gmail.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.