archive mirror
 help / color / mirror / Atom feed
From: Sergey Organov <>
To: "Ævar Arnfjörð Bjarmason" <>
Cc: Junio C Hamano <>,
Subject: Re: Rebase options via git pull
Date: Sat, 15 May 2021 10:39:43 +0300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (=?utf-8?B?IsOGdmFyIEFy?= =?utf-8?B?bmZqw7Zyw7A=?= Bjarmason"'s message of "Fri, 14 May 2021 11:14:53 +0200")

Ævar Arnfjörð Bjarmason <> writes:

> On Fri, May 14 2021, Junio C Hamano wrote:
>> Sergey Organov <> writes:
>>> Is there a way to specify additional options for "git rebase" when it's
>>> invoked via:
>>>   git pull --rebase
>>> ? What if rebase is used implicitly due to "pull.rebase" being set
>>> accordingly?
>>> In particular, I'd like to be able to:
>>>   git pull --rebase --no-fork-point
>>> but it doesn't work.
>>> From documentation is looks like "git pull --rebase" is still a
>>> second-class citizen. There is whole section about merge options in the
>>> manual, and none about rebase options.
>> Yeah, it does feel like so.
>> Just like we can pass merge-strategy specific options via -X<opt>=<val>,
>> e.g.
>>     $ git pull -Xsubtree=gitk git://
>> to ask the command to invoke "git merge -Xsubtree=gitk" after
>> fetching from the remote repository, we should allow rebase specific
>> options via a similar mechanism, e.g. -Yno-fork-point=yes (or
>> something along that line---exact syntax does not matter).
>> But I do not think there currently is anything like that.
> It seems much cleaner to do a bit of refactoring of their respective
> parse options specs to have "pull" understand the relevant subset of
> rebase or merge options depending on its mode, we do something similar
> in "rebase" depending on the "rebase stage" you're in.
> That has the added benefit over your suggestion of us catching any error
> in the passed option right away, as opposed to finding you typo'd
> -Xno-spork-point when we get to running "rebase".
> We also probably want to lib-ify the rebase logic enough that "pull" can
> run it directly without spawning another process eventually, at that
> point borrowing this "pass arg as-is to the driver program" syntax would
> become even weirder.

This sounds much better indeed!

To add to the issue, there has always been confusion that in case of
conflicts one should either do:

   git merge --continue


  git rebase --continue

depending on current configuration. So

  git pull --continue

would be much appreciated, I think.

Sergey Organov

  reply	other threads:[~2021-05-15  7:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-13 13:19 Rebase options via git pull Sergey Organov
2021-05-13 20:18 ` Junio C Hamano
2021-05-14  9:14   ` Ævar Arnfjörð Bjarmason
2021-05-15  7:39     ` Sergey Organov [this message]
2021-05-14  0:49 ` Alex Henrie
2021-05-14  0:58   ` Đoàn Trần Công Danh
2021-05-14  1:01     ` Alex Henrie
2021-05-14  6:37     ` Sergey Organov
2021-05-17 10:11       ` Ævar Arnfjörð Bjarmason
2021-05-17 12:33         ` Sergey Organov
2021-05-17 12:42           ` Đoàn Trần Công Danh
2021-05-17 12:59             ` Sergey Organov
2021-05-17 14:48               ` Đoàn Trần Công Danh

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* 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).