From: Elijah Newren <email@example.com> To: Pavel Roskin <firstname.lastname@example.org> Cc: Git Mailing List <email@example.com>, Phillip Wood <firstname.lastname@example.org>, Johannes Schindelin <Johannes.Schindelin@gmx.de>, Junio C Hamano <email@example.com> Subject: Re: git-rebase produces incorrect output Date: Sat, 30 Nov 2019 08:37:54 -0800 Message-ID: <CABPp-BHPkwnbLR0xNaY3SphCpmR6QRA1j953c2hU7ZFpL38Nig@mail.gmail.com> (raw) In-Reply-To: <CABPp-BGiu2nVMQY_t-rnFR5GQUz_ipyEE8oDocKeO+h+t4Mn4A@mail.gmail.com> On Fri, Nov 29, 2019 at 8:22 PM Elijah Newren <firstname.lastname@example.org> wrote: > On Fri, Nov 29, 2019 at 12:24 AM Pavel Roskin <email@example.com> wrote: > So, to summarize here: > * you have a case where the default 3 lines of context mess stuff > up; but rebase --merge works great > * am doesn't have a -U option, and ignores the diff.context setting, > making it impossible to force the am backend to work on your case > * rebase doesn't have an option to use the merge/interactive backend > by default (nor an --am option to override it) > > Also: > * The performance of the merge/interactive backend is slightly > better than the am-backend > (https://public-inbox.org/git/CABPp-BF=ev03WgODk6TMQmuNoatg2kiEe5DR__gJ0OTVqHSnfQ@mail.gmail.com/) > and will continue to get better > * The merge/interactive backend supports many more options than the > am-backend, though the am one still has a few the merge backend > doesn't. Once the ra/rebase-i-more-options topic merges, --whitespace > will be the only consequential option that the am-backend supports > that the merge/interactive-backend doesn't. (There's also -C, but as > noted above, the merge/interactive backend already have access to the > full file). In case it wasn't clear above, the merge/interactive backend could just accept the -C option and ignore it and do nothing, since it already has access to the full file (thus why I consider the -C option to not be consequential). Also, I remembered and dug out a few more items about the default rebase backend that might be worth including in this summary: * The am backend operates with incomplete tree information as well, limiting what the merge/resolve/whatever can do and what information can be provided to the user (see https://firstname.lastname@example.org/) * The interactive backend, although slightly faster than the am-backend (on p3400 at least), is slightly slower with split-index which hasn't yet been investigated (see https://public-inbox.org/git/nycvar.QRO.email@example.com/) > Maybe we should just switch the default, for everyone? (And provide > an --am option to override it and a config setting to get the old > default?) CC'ing a few folks for opinions on switching the default backend of rebase from --am to --merge. Johannes already agreed it was the right path eventually, and Junio suggested the am backend should be deprecated and eventually replaced, so I was going to push on this after some merge performance work but perhaps it's a good time to query if it's time to switch the default sooner.  See the end of https://public-inbox.org/git/nycvar.QRO.firstname.lastname@example.org/, also linked above.  https://email@example.com/, also linked above.
next prev parent reply index Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-29 8:21 Pavel Roskin 2019-11-29 13:31 ` Philip Oakley 2019-11-29 21:28 ` Pavel Roskin 2019-11-30 4:22 ` Elijah Newren 2019-11-30 16:37 ` Elijah Newren [this message] 2019-11-30 17:58 ` Junio C Hamano
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-BHPkwnbLR0xNaY3SphCpmR6QRA1j953c2hU7ZFpL38Nig@mail.gmail.com \ --firstname.lastname@example.org \ --cc=Johannes.Schindelin@gmx.de \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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 \ email@example.com 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