Re: New `--reapply-cherry-picks` warning

[Philippe Blain <levraiphilippeblain@gmail.com>]

Hi Ntentos,

Le 2022-02-02 à 03:56, Σταύρος Ντέντος a écrit :
> Hello there,
> 

Hi !

> I have noticed the new warning that's coming in the
> https://github.com/git/git/commit/767a4ca648f8791c1fb623bd9f79fd8d7f026499

Nice archeology work. It's always a good idea when mentioning specific 
commits to CC the commit author (which I've done here).

> I am currently using the `[pull] rebase = true` option; and basically
> that warning is also coming every time I am pulling.

OK, that would mean either:

1- each time you are pulling, the upstream branch *did* get some of your
local commits somehow, so the warning is justified

or 

2- the upstream branch *did not* get some of your local commits, so the warning
is shown but shouldn't be, and that's a bug.

Which one is it?

> I have tried doing `git pull --reapply-cherry-picks`; however, it
> seems that the `git pull` cannot pass options to the underlying `git
> rebase` invocation.

Indeed, it can't. I agree it would be nice to be able to do that, and the 
same for 'merge', I would say. Right now a lot of 'merge' options are 
duplicated in 'git pull'.

> 
> I noticed that there is no way to "set" the `--reapply-cherry-picks`
> in the gitconfig options.

Yes, that would be a nice option to have indeed.

> 
> I prefer the rebase backend for the `git pull`; however, I see no way
> of doing "what I want", with the exception of:
> git fetch --all ; git rebase --reapply-cherry-picks
> 
> Which is two steps, technically.

Careful, as this is not the exact equivalent of 'git pull --rebase', as
the documentation for that option states [1]:

    If there is a remote-tracking branch corresponding
    to the upstream branch and the upstream branch was rebased 
    since last fetched, the rebase uses that information to 
    avoid rebasing non-local changes.

(see also paragraphs 2-3 of [2], [3] [4] and [5]).

> 
> Also with every rebase I am doing, I'd have to remember that.
> And it is probably not possible (by design) to do `alias.rebase =
> rebase --reapply-cherry-picks` - which I understand.
> (however, allowing aliases like `alias.x = x --cmd-opts` does not
> sound "so bad" with me)

Yes, that's considered "by design" that you can't alias an existing
command using the exact command name. That is to make sure that scripts
have consistent behaviour across users (other config options can still
affect behaviour, but anyway that's the justification I've read before
on the list). What I can suggest is using 're = rebase --reapply-cherry-picks'
and then retrain your finger ;)

> 
> Would you consider adding a configuration option for the
> `--reapply-cherry-picks`?
> 
> With regards,
> Ntentos Stavros
> 
> 

Cheers,
Philippe.

[1] https://git-scm.com/docs/git-pull#Documentation/git-pull.txt--r
[2] https://git-scm.com/docs/git-rebase#_description
[3] https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---fork-point	
[4] https://git-scm.com/docs/git-merge-base#Documentation/git-merge-base.txt---fork-point
[5] https://git-scm.com/docs/git-merge-base#_discussion_on_fork_point_mode