git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sergey Organov <sorganov@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: Rebase options via git pull
Date: Sat, 15 May 2021 10:39:43 +0300	[thread overview]
Message-ID: <87r1i8fnsw.fsf@osv.gnss.ru> (raw)
In-Reply-To: <8735upsmg9.fsf@evledraar.gmail.com> (=?utf-8?B?IsOGdmFyIEFy?= =?utf-8?B?bmZqw7Zyw7A=?= Bjarmason"'s message of "Fri, 14 May 2021 11:14:53 +0200")

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Fri, May 14 2021, Junio C Hamano wrote:
>
>> Sergey Organov <sorganov@gmail.com> 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://ozlabs.org/~paulus/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

or:

  git rebase --continue

depending on current configuration. So

  git pull --continue

would be much appreciated, I think.

Thanks,
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:
  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=87r1i8fnsw.fsf@osv.gnss.ru \
    --to=sorganov@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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 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).