git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Sergey Organov <sorganov@gmail.com>, git@vger.kernel.org
Subject: Re: Rebase options via git pull
Date: Fri, 14 May 2021 11:14:53 +0200	[thread overview]
Message-ID: <8735upsmg9.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <xmqq1raabd5d.fsf@gitster.g>


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.

  reply	other threads:[~2021-05-14  9:18 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 [this message]
2021-05-15  7:39     ` Sergey Organov
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=8735upsmg9.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sorganov@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 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).