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

["Σταύρος Ντέντος" <stdedos@gmail.com>]

On Wed, 2 Feb 2022 at 21:03, Philippe Blain
<levraiphilippeblain@gmail.com> wrote:
>
> ...
>
> > 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?

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.

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

Fingers crossed? :-D

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

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

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

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

With regards,
Ntentos Stavros