Hi Rohit, On Fri, Apr 5, 2019 at 11:32 PM Rohit Ashiwal <rohit.ashiwal265@xxxxxxxxx> 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 mistakes. 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. Nice! > #### 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 \<s-beyer@xxxxxxx> 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 > \<chriscool@xxxxxxxxxxxxx> and then mentor Daniel Barkalow > \<barkalow@xxxxxxxxxxxx>. > > The project was continued by Ramkumar Ramachandra \<artagnon@xxxxxxxxx> 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 \<chriscool@xxxxxxxxxxxxx> 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 ago. > 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.