{"thread":{"id":"57355","subject":"New `--reapply-cherry-picks` warning","startedAt":"2022-02-02T08:57:10Z","lastAt":"2022-02-02T22:13:27Z","messageCount":3,"participants":["Σταύρος Ντέντος","Philippe Blain"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"447524","messageId":"CAHMHMxUZpR8MBj+9mSb1Cr3PBCsAx=6zLo9mKpeD_ehqDP4nvQ@mail.gmail.com","threadId":"57355","inReplyTo":null,"subject":"New `--reapply-cherry-picks` warning","fromName":"Σταύρος Ντέντος","fromEmail":"stdedos@gmail.com","sentAt":"2022-02-02T08:56:31Z","receivedAt":"2022-02-02T08:57:10Z","isPatch":false,"sender":{"key":"stdedos@gmail.com","avatar":null},"body":"Hello there,\n\nI have noticed the new warning that's coming in the\nhttps://github.com/git/git/commit/767a4ca648f8791c1fb623bd9f79fd8d7f026499\n\nI am currently using the `[pull] rebase = true` option; and basically\nthat warning is also coming every time I am pulling.\nI have tried doing `git pull --reapply-cherry-picks`; however, it\nseems that the `git pull` cannot pass options to the underlying `git\nrebase` invocation.\n\nI noticed that there is no way to \"set\" the `--reapply-cherry-picks`\nin the gitconfig options.\n\nI prefer the rebase backend for the `git pull`; however, I see no way\nof doing \"what I want\", with the exception of:\ngit fetch --all ; git rebase --reapply-cherry-picks\n\nWhich is two steps, technically.\n\nAlso with every rebase I am doing, I'd have to remember that.\nAnd it is probably not possible (by design) to do `alias.rebase =\nrebase --reapply-cherry-picks` - which I understand.\n(however, allowing aliases like `alias.x = x --cmd-opts` does not\nsound \"so bad\" with me)\n\nWould you consider adding a configuration option for the\n`--reapply-cherry-picks`?\n\nWith regards,\nNtentos Stavros\n"},{"id":"447553","messageId":"31e822be-b7c1-acb2-20d5-6db2200c3383@gmail.com","threadId":"57355","inReplyTo":"CAHMHMxUZpR8MBj+9mSb1Cr3PBCsAx=6zLo9mKpeD_ehqDP4nvQ@mail.gmail.com","subject":"Re: New `--reapply-cherry-picks` warning","fromName":"Philippe Blain","fromEmail":"levraiphilippeblain@gmail.com","sentAt":"2022-02-02T19:03:39Z","receivedAt":"2022-02-02T19:03:43Z","isPatch":false,"sender":{"key":"levraiphilippeblain@gmail.com","avatar":"https://avatars.githubusercontent.com/u/44212482?v=4"},"body":"Hi Ntentos,\n\nLe 2022-02-02 à 03:56, Σταύρος Ντέντος a écrit :\n> Hello there,\n> \n\nHi !\n\n> I have noticed the new warning that's coming in the\n> https://github.com/git/git/commit/767a4ca648f8791c1fb623bd9f79fd8d7f026499\n\nNice archeology work. It's always a good idea when mentioning specific \ncommits to CC the commit author (which I've done here).\n\n> I am currently using the `[pull] rebase = true` option; and basically\n> that warning is also coming every time I am pulling.\n\nOK, that would mean either:\n\n1- each time you are pulling, the upstream branch *did* get some of your\nlocal commits somehow, so the warning is justified\n\nor \n\n2- the upstream branch *did not* get some of your local commits, so the warning\nis shown but shouldn't be, and that's a bug.\n\nWhich one is it?\n\n> I have tried doing `git pull --reapply-cherry-picks`; however, it\n> seems that the `git pull` cannot pass options to the underlying `git\n> rebase` invocation.\n\nIndeed, it can't. I agree it would be nice to be able to do that, and the \nsame for 'merge', I would say. Right now a lot of 'merge' options are \nduplicated in 'git pull'.\n\n> \n> I noticed that there is no way to \"set\" the `--reapply-cherry-picks`\n> in the gitconfig options.\n\nYes, that would be a nice option to have indeed.\n\n> \n> I prefer the rebase backend for the `git pull`; however, I see no way\n> of doing \"what I want\", with the exception of:\n> git fetch --all ; git rebase --reapply-cherry-picks\n> \n> Which is two steps, technically.\n\nCareful, as this is not the exact equivalent of 'git pull --rebase', as\nthe documentation for that option states [1]:\n\n    If there is a remote-tracking branch corresponding\n    to the upstream branch and the upstream branch was rebased \n    since last fetched, the rebase uses that information to \n    avoid rebasing non-local changes.\n\n(see also paragraphs 2-3 of [2], [3] [4] and [5]).\n\n> \n> Also with every rebase I am doing, I'd have to remember that.\n> And it is probably not possible (by design) to do `alias.rebase =\n> rebase --reapply-cherry-picks` - which I understand.\n> (however, allowing aliases like `alias.x = x --cmd-opts` does not\n> sound \"so bad\" with me)\n\nYes, that's considered \"by design\" that you can't alias an existing\ncommand using the exact command name. That is to make sure that scripts\nhave consistent behaviour across users (other config options can still\naffect behaviour, but anyway that's the justification I've read before\non the list). What I can suggest is using 're = rebase --reapply-cherry-picks'\nand then retrain your finger ;)\n\n> \n> Would you consider adding a configuration option for the\n> `--reapply-cherry-picks`?\n> \n> With regards,\n> Ntentos Stavros\n> \n> \n\nCheers,\nPhilippe.\n\n[1] https://git-scm.com/docs/git-pull#Documentation/git-pull.txt--r\n[2] https://git-scm.com/docs/git-rebase#_description\n[3] https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---fork-point\t\n[4] https://git-scm.com/docs/git-merge-base#Documentation/git-merge-base.txt---fork-point\n[5] https://git-scm.com/docs/git-merge-base#_discussion_on_fork_point_mode\n"},{"id":"447577","messageId":"CAHMHMxWGqPT50Xsj4kcigoKJy7h0dM3J4UHBeGPMrUA9cs=C-w@mail.gmail.com","threadId":"57355","inReplyTo":"31e822be-b7c1-acb2-20d5-6db2200c3383@gmail.com","subject":"Re: New `--reapply-cherry-picks` warning","fromName":"Σταύρος Ντέντος","fromEmail":"stdedos@gmail.com","sentAt":"2022-02-02T22:11:48Z","receivedAt":"2022-02-02T22:13:27Z","isPatch":false,"sender":{"key":"stdedos@gmail.com","avatar":null},"body":"On Wed, 2 Feb 2022 at 21:03, Philippe Blain\n<levraiphilippeblain@gmail.com> wrote:\n>\n> ...\n>\n> > I am currently using the `[pull] rebase = true` option; and basically\n> > that warning is also coming every time I am pulling.\n>\n> OK, that would mean either:\n>\n> 1- each time you are pulling, the upstream branch *did* get some of your\n> local commits somehow, so the warning is justified\n>\n> or\n>\n> 2- the upstream branch *did not* get some of your local commits, so the warning\n> is shown but shouldn't be, and that's a bug.\n>\n> Which one is it?\n\nNo idea 😅 I do a metric ton of pulls. \"For fun\", I also do\n--set-upstream=master on branches I am working on; pulling master (and\nall of the branches) puts me at the latest point in time.\nIt could very well have been the former, since \"at some point\", I did\nlose some changes.\n\nHowever, it was \"do\" time; the debugging (and digging) came a little later.\n\n> > I noticed that there is no way to \"set\" the `--reapply-cherry-picks`\n> > in the gitconfig options.\n>\n> Yes, that would be a nice option to have indeed.\n\nFingers crossed? :-D\n\n> > I prefer the rebase backend for the `git pull`; however, I see no way\n> > of doing \"what I want\", with the exception of:\n> > git fetch --all ; git rebase --reapply-cherry-picks\n> >\n> > Which is two steps, technically.\n>\n> Careful, as this is not the exact equivalent of 'git pull --rebase', as\n> the documentation for that option states [1]:\n>\n>     If there is a remote-tracking branch corresponding\n>     to the upstream branch and the upstream branch was rebased\n>     since last fetched, the rebase uses that information to\n>     avoid rebasing non-local changes.\n>\n> (see also paragraphs 2-3 of [2], [3] [4] and [5]).\n\nSo ... the workaround is not a workaround :-(\n\n> > Also with every rebase I am doing, I'd have to remember that.\n> > And it is probably not possible (by design) to do `alias.rebase =\n> > rebase --reapply-cherry-picks` - which I understand.\n> > (however, allowing aliases like `alias.x = x --cmd-opts` does not\n> > sound \"so bad\" with me)\n>\n> Yes, that's considered \"by design\" that you can't alias an existing\n> command using the exact command name. That is to make sure that scripts\n> have consistent behaviour across users (other config options can still\n> affect behaviour, but anyway that's the justification I've read before\n> on the list). What I can suggest is using 're = rebase --reapply-cherry-picks'\n> and then retrain your finger ;)\n\nTrue. OOOOR somehow things that affect such behaviors are also given\nan option counterpart?\n\nI am not talking about `fetch.all = true`; however, if an option\nwarrants a warning, I'd say it deserves an option?\n> ....\n> >\n> > With regards,\n> > Ntentos Stavros\n> >\n> >\n>\n> Cheers,\n> Philippe.\n>\n> [1] https://git-scm.com/docs/git-pull#Documentation/git-pull.txt--r\n> [2] https://git-scm.com/docs/git-rebase#_description\n> [3] https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---fork-point\n> [4] https://git-scm.com/docs/git-merge-base#Documentation/git-merge-base.txt---fork-point\n> [5] https://git-scm.com/docs/git-merge-base#_discussion_on_fork_point_mode\n\nWith regards,\nNtentos Stavros\n"}]}