From: Elijah Newren <firstname.lastname@example.org> To: Eugeniu Rosca <email@example.com> Cc: "SZEDER Gábor" <firstname.lastname@example.org>, "Junio C Hamano" <email@example.com>, "Jeff King" <firstname.lastname@example.org>, "Ævar Arnfjörð" <email@example.com>, "Git Mailing List" <firstname.lastname@example.org>, "Eugeniu Rosca" <email@example.com> Subject: Re: Unreliable 'git rebase --onto' Date: Thu, 9 Jan 2020 10:05:52 -0800 Message-ID: <CABPp-BFiDNb18m8geTCxKLXg0fOd0DS1dWRVWCfnTG0suwGRHg@mail.gmail.com> (raw) In-Reply-To: <20200109105307.GA1349@lxhi-065.adit-jv.com> On Thu, Jan 9, 2020 at 2:53 AM Eugeniu Rosca <firstname.lastname@example.org> wrote: > > Hi Elijah, hi Szeder, > > On Wed, Jan 08, 2020 at 02:06:22PM -0800, Elijah Newren wrote: > > This looks like a known bug in rebase, in particular in the am-backend that > > rebase uses by default. If I'm correct that it's just a context region > > issue, then this is the same bug that was recently discussed at > > https://lore.kernel.org/git/CAN_72e2h2avv-U9BVBYqXVKiC+5kHy-pjejyMSD3X22uRXE39g@mail.gmail.com/. > > The current plan is to switch the default over to the merge backend (the > > same machinery that cherry-pick uses), which doesn't suffer from the same > > shortcomings (you can see the current work being done in this area at > > https://email@example.com/ > > ). > > Thank you for your feedback and references, here and in [*]. > > Once hit by this or similar issues, I think there is high chance for > people to go through the same feelings as described by Pavel in [**]: > > --- > That's so scary that I'm going to stop using "git rebase" for now. > --- Yep, I understand; that kind of feeling is why I wanted to jump in and try to help fix it. I want merge/rebase/cherry-pick to be reliable. > Some years ago I was hit by 'git merge' producing slightly different > results compared to 'git rebase --onto' and 'git cherry-pick A..B' > (maybe I can come up with a reproduction scenario for that too). If you can, I'd be interested to see it and take a look. I'd normally assume it was just some case where A..B included "evil" merge commits (merge commits that made additional changes not part of the actual merging) since rebasing or cherry-picking such a range would exclude the merge commits and thus drop those changes -- but you identified a real bug with the default rebase backend so I'm interested to see if you happen to have more bugs I should know about. > > Since then, I usually contrast the outcomes of merging, cherry-picking > and rebasing, to make sure they match, but that's painful and > time-consuming. > > > In the mean time, you can pass the -m flag to rebase to avoid these types > > of problems. In fact, if you could retry with -m you may be able to > > confirm whether it's the same issue. > > Indeed, neither `git rebase -m` nor `git rebase -i` exhibit the problem. That's good news. Unfortunately, you should note that git-2.25 is going to have the same bug you reported; there are still some loose ends with my series to make -m the default, and the 2.25 release is expected within a few days, so my change of default won't happen until 2.26. (That series would have needed to be completed several weeks ago for it to go into 2.25).
next prev parent reply index Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-08 21:43 Eugeniu Rosca 2020-01-08 22:35 ` SZEDER Gábor 2020-01-09 0:55 ` Elijah Newren 2020-01-09 15:03 ` SZEDER Gábor 2020-01-09 17:53 ` Elijah Newren 2020-01-21 19:18 ` [PATCH v1] rebase -i: stop checking out the tip of the branch to rebase Alban Gruin 2020-01-21 20:07 ` Elijah Newren 2020-01-22 20:24 ` Junio C Hamano 2020-01-22 20:47 ` Junio C Hamano 2020-01-24 14:45 ` Alban Gruin 2020-01-24 14:45 ` [PATCH v2] " Alban Gruin 2020-01-24 14:55 ` Alban Gruin 2020-01-24 18:12 ` Junio C Hamano 2020-01-24 15:05 ` [PATCH v3] " Alban Gruin 2020-01-24 18:30 ` Junio C Hamano 2020-02-05 14:31 ` Johannes Schindelin 2020-01-24 17:11 ` [PATCH v2] " Andrei Rybak 2020-01-09 11:13 ` Unreliable 'git rebase --onto' Eugeniu Rosca [not found] ` <CABPp-BHsyMOz+hi7EYoAnAWfzms7FRfwqCoarnu8H+vyDoN6SQ@mail.gmail.com> 2020-01-09 10:53 ` Eugeniu Rosca 2020-01-09 18:05 ` Elijah Newren [this message] 2020-01-10 0:06 ` Eugeniu Rosca 2020-01-10 2:35 ` Elijah Newren
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CABPp-BFiDNb18m8geTCxKLXg0fOd0DS1dWRVWCfnTG0suwGRHg@mail.gmail.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Mailing List Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/git/0 git/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 git git/ https://lore.kernel.org/git \ firstname.lastname@example.org public-inbox-index git Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.git AGPL code for this site: git clone https://public-inbox.org/public-inbox.git