On Wed, 2 Feb 2022 at 21:03, Philippe Blain <levraiphilippeblain@xxxxxxxxx> 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
