git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Rebase options via git pull
@ 2021-05-13 13:19 Sergey Organov
  2021-05-13 20:18 ` Junio C Hamano
  2021-05-14  0:49 ` Alex Henrie
  0 siblings, 2 replies; 13+ messages in thread
From: Sergey Organov @ 2021-05-13 13:19 UTC (permalink / raw)
  To: git

Hello,

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.

Thanks,
-- Sergey Organov

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Rebase options via git pull
  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-14  0:49 ` Alex Henrie
  1 sibling, 1 reply; 13+ messages in thread
From: Junio C Hamano @ 2021-05-13 20:18 UTC (permalink / raw)
  To: Sergey Organov; +Cc: git

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.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Rebase options via git pull
  2021-05-13 13:19 Rebase options via git pull Sergey Organov
  2021-05-13 20:18 ` Junio C Hamano
@ 2021-05-14  0:49 ` Alex Henrie
  2021-05-14  0:58   ` Đoàn Trần Công Danh
  1 sibling, 1 reply; 13+ messages in thread
From: Alex Henrie @ 2021-05-14  0:49 UTC (permalink / raw)
  To: Sergey Organov; +Cc: Git mailing list

On Thu, May 13, 2021 at 7:23 AM Sergey Organov <sorganov@gmail.com> wrote:
>
> Hello,
>
> 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.

It would be cumbersome, but you could run `git config rebase.forkPoint
false` before pulling and `git config rebase.forkPoint true` after.

-Alex

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Rebase options via git pull
  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
  0 siblings, 2 replies; 13+ messages in thread
From: Đoàn Trần Công Danh @ 2021-05-14  0:58 UTC (permalink / raw)
  To: Alex Henrie; +Cc: Sergey Organov, Git mailing list

On 2021-05-13 18:49:03-0600, Alex Henrie <alexhenrie24@gmail.com> wrote:
> On Thu, May 13, 2021 at 7:23 AM Sergey Organov <sorganov@gmail.com> wrote:
> >
> > Hello,
> >
> > 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.
> 
> It would be cumbersome, but you could run `git config rebase.forkPoint
> false` before pulling and `git config rebase.forkPoint true` after.

Or, for this *specific* case:

	git -c rebase.forkpoint=false pull --rebase

-- 
Danh

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Rebase options via git pull
  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
  1 sibling, 0 replies; 13+ messages in thread
From: Alex Henrie @ 2021-05-14  1:01 UTC (permalink / raw)
  To: Đoàn Trần Công Danh; +Cc: Sergey Organov, Git mailing list

On Thu, May 13, 2021 at 6:58 PM Đoàn Trần Công Danh
<congdanhqx@gmail.com> wrote:
>
> On 2021-05-13 18:49:03-0600, Alex Henrie <alexhenrie24@gmail.com> wrote:
> > On Thu, May 13, 2021 at 7:23 AM Sergey Organov <sorganov@gmail.com> wrote:
> > >
> > > Hello,
> > >
> > > 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.
> >
> > It would be cumbersome, but you could run `git config rebase.forkPoint
> > false` before pulling and `git config rebase.forkPoint true` after.
>
> Or, for this *specific* case:
>
>         git -c rebase.forkpoint=false pull --rebase

I forgot that you can do that. Thanks for the better answer!

-Alex

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Rebase options via git pull
  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
  1 sibling, 1 reply; 13+ messages in thread
From: Sergey Organov @ 2021-05-14  6:37 UTC (permalink / raw)
  To: Đoàn Trần Công Danh; +Cc: Alex Henrie, Git mailing list

Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:

> On 2021-05-13 18:49:03-0600, Alex Henrie <alexhenrie24@gmail.com> wrote:
>> On Thu, May 13, 2021 at 7:23 AM Sergey Organov <sorganov@gmail.com> wrote:
>> >
>> > Hello,
>> >
>> > 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.
>> 
>> It would be cumbersome, but you could run `git config rebase.forkPoint
>> false` before pulling and `git config rebase.forkPoint true` after.
>
> Or, for this *specific* case:
>
> 	git -c rebase.forkpoint=false pull --rebase

That's nice, thanks! Doesn't solve entire issue, but definitely better
than nothing.

Probably add generic cmd.<cmd>.opts config support, so that I can say:

  git -c cmd.rebase.opts="--no-fork-point --empty=keep" pull --rebase

Thoughts?

Thanks,
-- Sergey Organov

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Rebase options via git pull
  2021-05-13 20:18 ` Junio C Hamano
@ 2021-05-14  9:14   ` Ævar Arnfjörð Bjarmason
  2021-05-15  7:39     ` Sergey Organov
  0 siblings, 1 reply; 13+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2021-05-14  9:14 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Sergey Organov, git


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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Rebase options via git pull
  2021-05-14  9:14   ` Ævar Arnfjörð Bjarmason
@ 2021-05-15  7:39     ` Sergey Organov
  0 siblings, 0 replies; 13+ messages in thread
From: Sergey Organov @ 2021-05-15  7:39 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason; +Cc: Junio C Hamano, git

Æ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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Rebase options via git pull
  2021-05-14  6:37     ` Sergey Organov
@ 2021-05-17 10:11       ` Ævar Arnfjörð Bjarmason
  2021-05-17 12:33         ` Sergey Organov
  0 siblings, 1 reply; 13+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2021-05-17 10:11 UTC (permalink / raw)
  To: Sergey Organov
  Cc: Đoàn Trần Công Danh, Alex Henrie, Git mailing list


On Fri, May 14 2021, Sergey Organov wrote:

> Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:
>
>> On 2021-05-13 18:49:03-0600, Alex Henrie <alexhenrie24@gmail.com> wrote:
>>> On Thu, May 13, 2021 at 7:23 AM Sergey Organov <sorganov@gmail.com> wrote:
>>> >
>>> > Hello,
>>> >
>>> > 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.
>>> 
>>> It would be cumbersome, but you could run `git config rebase.forkPoint
>>> false` before pulling and `git config rebase.forkPoint true` after.
>>
>> Or, for this *specific* case:
>>
>> 	git -c rebase.forkpoint=false pull --rebase
>
> That's nice, thanks! Doesn't solve entire issue, but definitely better
> than nothing.
>
> Probably add generic cmd.<cmd>.opts config support, so that I can say:
>
>   git -c cmd.rebase.opts="--no-fork-point --empty=keep" pull --rebase
>
> Thoughts?

It's been discussed before (but I did not dig up the discussions,
sorry). It's been considered a bad idea, because our commands are a
mixture of plumbing/porcelain commands and switches, so we want to be
able to reliably invoke say ls-tree with some switches internally,
without config tripping us up.

Of course we could make this sort of thing work by selectively ignoring
the config, but such a thing would be equal in complexity to the effort
of assering that it's safe to introduce new rebase.* config in the
codebase for every switch it has now, but with a less friendly interface
both for git itself and users.

I.e. instead of rebase.noForkPoint=<bool> we'd need to to getopt parsing
on some cmd.rebase.opts string.

I don't see why in this case what I suggested elsewhere in the thread
wouldn't be viable, i.e. you specify --rebase or --merge to "pull", and
that affects how we interpret the rest of the options. I haven't tried
it though, so there may be hidden gotchas there I haven't thought of.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Rebase options via git pull
  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
  0 siblings, 1 reply; 13+ messages in thread
From: Sergey Organov @ 2021-05-17 12:33 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: Đoàn Trần Công Danh, Alex Henrie, Git mailing list

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

> On Fri, May 14 2021, Sergey Organov wrote:
>
>> Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:
>>
>>> On 2021-05-13 18:49:03-0600, Alex Henrie <alexhenrie24@gmail.com> wrote:
>>>> On Thu, May 13, 2021 at 7:23 AM Sergey Organov <sorganov@gmail.com> wrote:
>>>> >
>>>> > Hello,
>>>> >
>>>> > 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.
>>>> 
>>>> It would be cumbersome, but you could run `git config rebase.forkPoint
>>>> false` before pulling and `git config rebase.forkPoint true` after.
>>>
>>> Or, for this *specific* case:
>>>
>>> 	git -c rebase.forkpoint=false pull --rebase
>>
>> That's nice, thanks! Doesn't solve entire issue, but definitely better
>> than nothing.
>>
>> Probably add generic cmd.<cmd>.opts config support, so that I can say:
>>
>>   git -c cmd.rebase.opts="--no-fork-point --empty=keep" pull --rebase
>>
>> Thoughts?
>
> It's been discussed before (but I did not dig up the discussions,
> sorry). It's been considered a bad idea, because our commands are a
> mixture of plumbing/porcelain commands and switches, so we want to be
> able to reliably invoke say ls-tree with some switches internally,
> without config tripping us up.
>
> Of course we could make this sort of thing work by selectively ignoring
> the config, but such a thing would be equal in complexity to the effort
> of assering that it's safe to introduce new rebase.* config in the
> codebase for every switch it has now, but with a less friendly interface
> both for git itself and users.

I don't see much complexity here. We'd then just need to effectively
invoke ls-tree internally like this:

   git -c 'cmd.ls-tree.opts=' ls-tree

Not a big deal.

>
> I.e. instead of rebase.noForkPoint=<bool> we'd need to to getopt parsing
> on some cmd.rebase.opts string.

As this is meant to be generic, then yes, every command will first parse
corresponding config option, then command-line options, rebase not being
any different.

>
> I don't see why in this case what I suggested elsewhere in the thread
> wouldn't be viable, i.e. you specify --rebase or --merge to "pull", and
> that affects how we interpret the rest of the options. I haven't tried
> it though, so there may be hidden gotchas there I haven't thought of.

This is the best solution for "git pull" indeed, but the above is a
generic feature that could provide solution in cases like this, where
immediate specific solution is not (yet) available.

Thanks,
-- Sergey Organov

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Rebase options via git pull
  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
  0 siblings, 1 reply; 13+ messages in thread
From: Đoàn Trần Công Danh @ 2021-05-17 12:42 UTC (permalink / raw)
  To: Sergey Organov
  Cc: Ævar Arnfjörð Bjarmason, Alex Henrie, Git mailing list

On 2021-05-17 15:33:18+0300, Sergey Organov <sorganov@gmail.com> wrote:
> >> Probably add generic cmd.<cmd>.opts config support, so that I can say:
> >>
> >>   git -c cmd.rebase.opts="--no-fork-point --empty=keep" pull --rebase
> >>
> >> Thoughts?
> >
> > It's been discussed before (but I did not dig up the discussions,
> > sorry). It's been considered a bad idea, because our commands are a
> > mixture of plumbing/porcelain commands and switches, so we want to be
> > able to reliably invoke say ls-tree with some switches internally,
> > without config tripping us up.
> >
> > Of course we could make this sort of thing work by selectively ignoring
> > the config, but such a thing would be equal in complexity to the effort
> > of assering that it's safe to introduce new rebase.* config in the
> > codebase for every switch it has now, but with a less friendly interface
> > both for git itself and users.
> 
> I don't see much complexity here. We'd then just need to effectively
> invoke ls-tree internally like this:
> 
>    git -c 'cmd.ls-tree.opts=' ls-tree
> 
> Not a big deal.

It's a big deal.

Scripts was written with plumbing command and expect stable output.
If such change can be accepted, a lot of scripts will begin to fail.

> > I.e. instead of rebase.noForkPoint=<bool> we'd need to to getopt parsing
> > on some cmd.rebase.opts string.
> 
> As this is meant to be generic, then yes, every command will first parse
> corresponding config option, then command-line options, rebase not being
> any different.
> 
> >
> > I don't see why in this case what I suggested elsewhere in the thread
> > wouldn't be viable, i.e. you specify --rebase or --merge to "pull", and
> > that affects how we interpret the rest of the options. I haven't tried
> > it though, so there may be hidden gotchas there I haven't thought of.

I didn't follow that sub-thread. However, I think we can extend
git-pull with a dedicated option prefix for options that would be
passed down to git-merge or git-rebase.
Sililar to -W of CCLD (as in gcc -W,--as-needed)

-- 
Danh

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Rebase options via git pull
  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
  0 siblings, 1 reply; 13+ messages in thread
From: Sergey Organov @ 2021-05-17 12:59 UTC (permalink / raw)
  To: Đoàn Trần Công Danh
  Cc: Ævar Arnfjörð Bjarmason, Alex Henrie, Git mailing list

Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:

> On 2021-05-17 15:33:18+0300, Sergey Organov <sorganov@gmail.com> wrote:
>> >> Probably add generic cmd.<cmd>.opts config support, so that I can say:
>> >>
>> >>   git -c cmd.rebase.opts="--no-fork-point --empty=keep" pull --rebase
>> >>
>> >> Thoughts?
>> >
>> > It's been discussed before (but I did not dig up the discussions,
>> > sorry). It's been considered a bad idea, because our commands are a
>> > mixture of plumbing/porcelain commands and switches, so we want to be
>> > able to reliably invoke say ls-tree with some switches internally,
>> > without config tripping us up.
>> >
>> > Of course we could make this sort of thing work by selectively ignoring
>> > the config, but such a thing would be equal in complexity to the effort
>> > of assering that it's safe to introduce new rebase.* config in the
>> > codebase for every switch it has now, but with a less friendly interface
>> > both for git itself and users.
>> 
>> I don't see much complexity here. We'd then just need to effectively
>> invoke ls-tree internally like this:
>> 
>>    git -c 'cmd.ls-tree.opts=' ls-tree
>> 
>> Not a big deal.
>
> It's a big deal.
>
> Scripts was written with plumbing command and expect stable output.
> If such change can be accepted, a lot of scripts will begin to fail.

Makes sense. Then simply don't do it for plumbing?

Thanks,
-- Sergey Organov

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Rebase options via git pull
  2021-05-17 12:59             ` Sergey Organov
@ 2021-05-17 14:48               ` Đoàn Trần Công Danh
  0 siblings, 0 replies; 13+ messages in thread
From: Đoàn Trần Công Danh @ 2021-05-17 14:48 UTC (permalink / raw)
  To: Sergey Organov
  Cc: Ævar Arnfjörð Bjarmason, Alex Henrie, Git mailing list

On 2021-05-17 15:59:49+0300, Sergey Organov <sorganov@gmail.com> wrote:
> Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:
> 
>> On 2021-05-17 15:33:18+0300, Sergey Organov <sorganov@gmail.com> wrote:
>>> >> Probably add generic cmd.<cmd>.opts config support, so that I can say:
>>> >>
>>> >>   git -c cmd.rebase.opts="--no-fork-point --empty=keep" pull --rebase
>>> >>
>>> >> Thoughts?
>>> >
>>> > It's been discussed before (but I did not dig up the discussions,
>>> > sorry). It's been considered a bad idea, because our commands are a
>>> > mixture of plumbing/porcelain commands and switches, so we want to be
>>> > able to reliably invoke say ls-tree with some switches internally,
>>> > without config tripping us up.
>>> >
>>> > Of course we could make this sort of thing work by selectively ignoring
>>> > the config, but such a thing would be equal in complexity to the effort
>>> > of assering that it's safe to introduce new rebase.* config in the
>>> > codebase for every switch it has now, but with a less friendly interface
>>> > both for git itself and users.
>>> 
>>> I don't see much complexity here. We'd then just need to effectively
>>> invoke ls-tree internally like this:
>>> 
>>>    git -c 'cmd.ls-tree.opts=' ls-tree
>>> 
>>> Not a big deal.
>>
>> It's a big deal.
>>
>> Scripts was written with plumbing command and expect stable output.
>> If such change can be accepted, a lot of scripts will begin to fail.
> 
> Makes sense. Then simply don't do it for plumbing?

Then, we will get back to the state Ævar pointed out.

Quoted again:

>>> > Of course we could make this sort of thing work by selectively ignoring
>>> > the config, but such a thing would be equal in complexity to the effort
>>> > of assering that it's safe to introduce new rebase.* config in the
>>> > codebase for every switch it has now, but with a less friendly interface
>>> > both for git itself and users.

Anyway, it's not only plumbing command, it's also semi-plumbing
commands (the ones accept --porcelain option) like:

	git status --porcelain[=<version>]

-- 
Danh

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2021-05-17 16:15 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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