Re: New `--reapply-cherry-picks` warning
- From
- Σταύρος Ντέντος <stdedos@gmail.com>
- Date
- Feb 2, 2022, 22:11 UTC
- Message-ID
- <CAHMHMxWGqPT50Xsj4kcigoKJy7h0dM3J4UHBeGPMrUA9cs=C-w@mail.gmail.com>
- In-Reply-To
- <31e822be-b7c1-acb2-20d5-6db2200c3383@gmail.com>
On Wed, 2 Feb 2022 at 21:03, Philippe Blain <levraiphilippeblain@gmail.com> wrote:
Show 17 quoted lines
> > ... > > > 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
Show 15 quoted lines
> > 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 :-(
Show 12 quoted lines
> > 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?
Show 15 quoted lines
> .... > > > > 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