From: Christian Couder <firstname.lastname@example.org> To: Johannes Schindelin <Johannes.Schindelin@gmx.de> Cc: "Junio C Hamano" <email@example.com>, "Elijah Newren" <firstname.lastname@example.org>, "Phillip Wood" <email@example.com>, "Elijah Newren via GitGitGadget" <firstname.lastname@example.org>, "Git Mailing List" <email@example.com>, "Philip Oakley" <firstname.lastname@example.org>, "Ævar Arnfjörð Bjarmason" <email@example.com> Subject: Re: unifying sequencer's options persisting, was Re: [PATCH v2] sequencer: fix edit handling for cherry-pick and revert messages Date: Thu, 8 Apr 2021 21:58:40 +0200 [thread overview] Message-ID: <CAP8UFD1WsjB_shHnRUcH3rnQjwh0yodrETq6zh39vnZnHQpVyw@mail.gmail.com> (raw) In-Reply-To: <nycvar.QRO.firstname.lastname@example.org> Hi, On Thu, Apr 8, 2021 at 2:22 PM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > On Fri, 2 Apr 2021, Junio C Hamano wrote: > > > Elijah Newren <email@example.com> writes: > > > > > Even if others now disagree with the above, I know I can get a huge > > > speedup by changing sequencer to stop per-commit wasteful work (stop > > > forking processes like "git commit", don't write control structures if > > > the rebase hasn't ended or hit a conflict, don't update the working > > > copy or index or reflog). It would be interesting to know which of these updates (working copy, index or reflog) is the most costly. Of course the best would be to compare the costs when updates are done at each step vs only at the end. Some years ago I worked on the split index as some tests showed that, for really big repos with a big index, it could significantly speed up rebases. So I have the, perhaps wrong, impression that most of the gain would be related to the index. > > > It's enough of a speedup that if backward > > > compatibility won't allow such a method to be used by default, I'd > > > still make yet another backend that could be optionally used. And I'd > > > have the default rebase and cherry-pick start printing annoying > > > deprecation notices so that users become aware of a faster option. > > > > A faster and less powerful interface is good; I doubt deprecation > > would work well. If a workflow depends on things like post-commit > > hook, the affected users deserve some way to migrate to --exec or > > whatever method to compensate the loss of functionality. > > I could imagine that there is opportunity to "persist on disk only when > needed". For example, if no `pre-commit` hook is installed that needs to > be run, there is no need to update the worktree nor HEAD until the rebase > is done. > > And this type of `only write to disk when needed` functionality could > probably be abstracted away so much as to make the rest of the code > look elegant again. Yeah, I agree with this approach too. If the split index could also become the default one day, I guess we could be doing pretty well even when some hooks are installed.
next prev parent reply other threads:[~2021-04-08 19:59 UTC|newest] Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-26 7:16 [PATCH] " Elijah Newren via GitGitGadget 2021-03-26 12:27 ` Philip Oakley 2021-03-26 15:12 ` Elijah Newren 2021-03-28 1:30 ` Junio C Hamano 2021-03-29 9:23 ` Phillip Wood 2021-03-29 20:52 ` Junio C Hamano 2021-03-29 21:25 ` Elijah Newren 2021-03-30 2:09 ` [PATCH v2] " Elijah Newren via GitGitGadget 2021-03-30 10:13 ` Johannes Schindelin 2021-03-30 18:47 ` Junio C Hamano 2021-03-30 20:16 ` Elijah Newren 2021-03-31 17:36 ` Ævar Arnfjörð Bjarmason 2021-03-31 17:52 ` Elijah Newren 2021-03-31 18:01 ` Junio C Hamano 2021-04-01 16:31 ` Elijah Newren 2021-03-30 19:37 ` Elijah Newren 2021-03-31 13:48 ` unifying sequencer's options persisting, was " Johannes Schindelin 2021-04-02 11:28 ` Phillip Wood 2021-04-02 13:10 ` Phillip Wood 2021-04-02 21:01 ` Junio C Hamano 2021-04-02 22:18 ` Elijah Newren 2021-04-02 22:27 ` Junio C Hamano 2021-04-08 2:40 ` Johannes Schindelin 2021-04-08 17:45 ` Junio C Hamano 2021-04-08 19:58 ` Christian Couder [this message] 2021-04-09 13:53 ` Johannes Schindelin 2021-03-31 6:52 ` [PATCH v3] " Elijah Newren via GitGitGadget 2021-03-31 14:38 ` Johannes Schindelin 2021-04-02 11:40 unifying sequencer's options persisting, was Re: [PATCH v2] " Gabriel Young
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 List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAP8UFD1WsjB_shHnRUcH3rnQjwh0yodrETq6zh39vnZnHQpVyw@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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: unifying sequencer'\''s options persisting, was Re: [PATCH v2] sequencer: fix edit handling for cherry-pick and revert messages' \ /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
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).