list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Christian Couder <>
To: Rohit Ashiwal <>
Cc: Elijah Newren <>,
	Johannes Schindelin <>,
	Alban Gruin <>,
	Ramkumar Ramachandra <>,
	git <>,, Stephan Beyer <>,
	Thomas Gummerer <>
Subject: Re: [GSoC][RFC v3] Proposal: Improve consistency of sequencer commands
Date: Sun, 7 Apr 2019 09:15:30 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Rohit,

On Fri, Apr 5, 2019 at 11:32 PM Rohit Ashiwal
<> wrote:
> Here is one more iteration of my draft proposal[1]. RFC.

Nice, thanks for iterating on this!

As we are close to the deadline (April 9th) for proposal submissions,
I think it's a good idea to already upload your draft proposal on the
GSoC site. I think you will be able to upload newer versions until the
deadline, but uploading soon avoid possible last minute issues and

In the version you upload, please add one or more links to the
discussion of your proposal on the mailing list.

> ### List of Contributions at Git:
> Repo                              |Status                      |Title
> ----------------------------------|----------------------------|-----------------------------------------------------------------------
> [git/git][8]                      | [Will merge in master][13] | [Micro][3]**:** Use helper functions in test script
> [git-for-windows/git][9]          | Merged and released        | [#2077][4]**:** [FIX] git-archive error, gzip -cn : command not found.
> [git-for-windows/build-extra][10] | Merged and released        | [#235][5]**:** installer: Fix version of installer and installed file.


> #### Overview
> Since when it was created in 2005, the `git rebase` command has been
> implemented using shell scripts that are calling other git commands. Commands
> like `git format-patch` to create a patch series for some commits, and then
> `git am` to apply the patch series on top of a different commit in case of
> regular rebase and the interactive rebase calls `git cherry-pick` repeatedly
> for the same.
> Neither of these approaches has been very efficient though, and the main reason
> behind that is that repeatedly calling a git command has a significant
> overhead. Even the regular git rebase would do that as `git am` had been
> implemented by launching `git apply` on each of the patches.
> The overhead is especially big on Windows where creating a new process is quite
> slow, but even on other Operating Systems it requires setting up everything
> from scratch, then reading the index from disk, and then, after performing some
> changes, writing the index back to the disk.
> Stephan Beyer \<> tried to introduce git-sequencer as his GSoC
> 2008 [project][6] which executed a sequence of git instructions to  \<HEAD> or
> \<branch> and the sequence was given by a \<file> or through `stdin`. The
> git-sequencer wants to become the common backend for git-am, git-rebase and
> other git commands, so as to improve performance, since then it eliminated the
> need to spawn a new process.
> Unfortunately, most of the code did not get merged during the SoC period but he
> continued his contributions to the project along with Christian Couder
> \<> and then mentor Daniel Barkalow
> \<>.
> The project was continued by Ramkumar Ramachandra \<> in
> [2011][7], extending its domain to git-cherry-pick. The sequencer code got
> merged and it was now possible to "continue" and "abort" when cherry-picking or
> reverting many commits.
> A patch series by Christian Couder \<> was merged in
> [2016][16] to the `master` branch that makes `git am` call `git apply`’s
> internal functions without spawning the latter as a separate process. So the
> regular rebase will be significantly faster especially on Windows and for big
> repositories in the next Git feature release.

It looks like you copy pasted the Git Rev News article without
updating the content. The improvement has been released a long time

> Despite the success (of GSoC '11), Dscho had to improve a lot of things to make
> it possible to reuse the sequencer in the interactive rebases making it faster.

Maybe s/rebases/rebase/

> His work can be found [here][15].

It seems to me that there has been more recent work than this and also
perhaps interesting suggestions and discussions about possible
sequencer related  improvements on the mailing list.

> The learnings from all those works will serve as a huge headstart this year for
> me.
> As of now, there are still some inconsistencies among these commands, e.g.,
> there is no `--skip` flag in `git-cherry-pick` while one exists for
> `git-rebase`. This project aims to remove inconsistencies in how the command
> line options are handled.

  reply	other threads:[~2019-04-07  7:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-24 10:05 [GSoC] Introduction Rohit Ashiwal
2019-02-24 14:47 ` Johannes Schindelin
2019-02-25  6:50 ` Christian Couder
2019-02-25 11:35   ` Rohit Ashiwal
2019-02-25 20:21     ` Christian Couder
2019-02-25 21:09       ` Eric Sunshine
2019-03-22 15:11 ` [GSoC][RFC] Proposal: Improve consistency of sequencer commands Rohit Ashiwal
2019-03-23 22:17   ` Christian Couder
2019-03-24  1:21     ` Rohit Ashiwal
2019-03-24  1:07   ` Elijah Newren
2019-03-24  1:45     ` Rohit Ashiwal
2019-03-29 22:32 ` [GSoC][RFC v2] " Rohit Ashiwal
2019-03-29 23:25   ` Elijah Newren
2019-03-29 23:34     ` Rohit Ashiwal
2019-03-30  0:38       ` Elijah Newren
2019-03-30  8:48         ` Rohit Ashiwal
2019-03-30 17:13           ` Elijah Newren
2019-03-30  7:16   ` Christian Couder
2019-03-30 17:12     ` Elijah Newren
2019-04-05 21:31 ` [GSoC][RFC v3] Proposal: " Rohit Ashiwal
2019-04-07  7:15   ` Christian Couder [this message]
2019-04-07 12:16     ` Rohit Ashiwal
2019-04-07 23:07       ` Christian Couder

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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).