New `--reapply-cherry-picks` warning

Hello there,

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

I am currently using the `[pull] rebase = true` option; and basically that warning is also coming every time I am pulling. 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.

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

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.

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)

Would you consider adding a configuration option for the `--reapply-cherry-picks`?

With regards, Ntentos Stavros

Hi Ntentos,

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

Hi !

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

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?

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

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

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

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

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

On Wed, 2 Feb 2022 at 21:03, Philippe Blain <levraiphilippeblain@gmail.com> wrote:

No idea 😅 I do a metric ton of pulls. "For fun", I also do --set-upstream=master on branches I am working on; pulling master (and all of the branches) puts me at the latest point in time. It could very well have been the former, since "at some point", I did lose some changes.

However, it was "do" time; the debugging (and digging) came a little later.

Fingers crossed? :-D

So ... the workaround is not a workaround :-(

True. OOOOR somehow things that affect such behaviors are also given an option counterpart?

I am not talking about `fetch.all = true`; however, if an option warrants a warning, I'd say it deserves an option?

With regards, Ntentos Stavros