{"thread":{"id":"50576","subject":"[GSoC] Introduction","startedAt":"2019-02-24T10:06:02Z","lastAt":"2019-04-07T23:08:33Z","messageCount":23,"participants":["Rohit Ashiwal","Johannes Schindelin","Christian Couder","Eric Sunshine","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"370057","messageId":"CAL7ArXqkVfrnQWYFDYdwMGkZjHCwzyQX4pbKCo=KCzy-zJiRBw@mail.gmail.com","threadId":"50576","inReplyTo":null,"subject":"[GSoC] Introduction","fromName":"Rohit Ashiwal","fromEmail":"rohit.ashiwal265@gmail.com","sentAt":"2019-02-24T10:05:01Z","receivedAt":"2019-02-24T10:06:02Z","isPatch":false,"sender":{"key":"rohit.ashiwal265@gmail.com","avatar":"https://avatars.githubusercontent.com/u/31043830?v=4"},"body":"Hello\nI am Rohit Ashiwal, a computer science and engineering student from\nIIT Roorkee. I am a git user for 2 years now and want to contribute\ntowards its development.\nI have read the microproject list available [here](1) and project\ntitled `Use test_path_is_* functions in test scripts` caught my eye.\nI want to work on this one if anyone is not working on it (I was not\nable to find related threads on public-inbox).\nI am somewhat familiar with git's code as I was previously working on\ngit-for-windows and I have solved 1 [issue](2), which is a reason for\nmy concern. Should this count as a microproject? As the webpage\ninstructs us to work only on 1 microproject.\nIf you disregard that contribution, here is my approach to solving\nthis microproject: search for `test -f` in `t/**` and replace all\noccurrences with `test_path_is_file` and similarly for other mentioned\ncommands. Is it correct?\n\nRegards\nRohit Ashiwal\n\n[1]: https://git.github.io/SoC-2019-Microprojects/\n[2]: https://github.com/git-for-windows/git/issues/1970\n"},{"id":"370089","messageId":"nycvar.QRO.7.76.6.1902241537370.45@tvgsbejvaqbjf.bet","threadId":"50576","inReplyTo":"CAL7ArXqkVfrnQWYFDYdwMGkZjHCwzyQX4pbKCo=KCzy-zJiRBw@mail.gmail.com","subject":"Re: [GSoC] Introduction","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-02-24T14:47:08Z","receivedAt":"2019-02-24T14:47:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Rohit,\n\nOn Sun, 24 Feb 2019, Rohit Ashiwal wrote:\n\n> Hello\n\nHi there!\n\n> I am Rohit Ashiwal, a computer science and engineering student from\n> IIT Roorkee. I am a git user for 2 years now and want to contribute\n> towards its development.\n\nGreat!\n\n> I have read the microproject list available [here](1) and project\n> titled `Use test_path_is_* functions in test scripts` caught my eye.\n> I want to work on this one if anyone is not working on it (I was not\n> able to find related threads on public-inbox).\n\nGo for it ;-) The microprojects are basically a straight-forward way to\nintroduce prospective GSoC students to Git's code contribution process.\n\nIn that sense, while it would be better for students not to have\noverlapping microprojects, it is not the end of the world, either.\n\nIn your case, it is relatively easy to figure out that no other student\nmentioned this project on the Git mailing list:\nhttps://public-inbox.org/git/?q=test_path_is_file\n\n> I am somewhat familiar with git's code as I was previously working on\n> git-for-windows and I have solved 1 [issue](2), which is a reason for\n> my concern. Should this count as a microproject? As the webpage\n> instructs us to work only on 1 microproject.\n\nTrue. You could brush up that pair of patches to teach `git archive` to\navoid spawning `gzip` when generating `.tar.gz` archives, and submit them\nusing the process suggested in https://git-scm.com/docs/SubmittingPatches.\n\n(You might want to make it easier on yourself and use GitGitGadget, which\ntakes out the challenge of sending patches in the required format via\nemail, see https://gitgitgadget.github.io/ for details.)\n\nOn the other hand, it might make more sense to start afresh with the\ntest_path_is_* microproject, as I already took custody of your patches and\nplanned on submitting them (via GitGitGadget) right after v2.21.0 comes\nout.\n\n> If you disregard that contribution, here is my approach to solving\n> this microproject: search for `test -f` in `t/**` and replace all\n> occurrences with `test_path_is_file` and similarly for other mentioned\n> commands. Is it correct?\n\nThis is a good first step, indeed. You may want to be careful about it,\nthough, as there *might* be instances where replacing the `test -f` would\nnot make sense (such as instances where scripts are written via\n`write_script`, and those scripts would not have access to the\n`test_path_is_file` function).\n\nYou probably also want to inspect instances of `test -e` (which\ntechnically only ask whether a path exists, whether it is a file, a\ndirectory, or a symbolic link), as it might be possible that some tests\nuse that invocation when they really want to ask whether a file exists.\n\nThen, you want to also look for `test -d` for the `test_path_is_dir`\nconversion.\n\nGood luck,\nJohannes\n"},{"id":"370105","messageId":"CAP8UFD1U+4ww8rC=TSjjH+Rt77P9w4YWA9s5yspVZ7GgPpx0pw@mail.gmail.com","threadId":"50576","inReplyTo":"CAL7ArXqkVfrnQWYFDYdwMGkZjHCwzyQX4pbKCo=KCzy-zJiRBw@mail.gmail.com","subject":"Re: [GSoC] Introduction","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-02-25T06:50:26Z","receivedAt":"2019-02-25T06:50:41Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi Rohit,\n\nOn Sun, Feb 24, 2019 at 11:08 AM Rohit Ashiwal\n wrote:\n\n> If you disregard that contribution, here is my approach to solving\n> this microproject: search for `test -f` in `t/**` and replace all\n> occurrences with `test_path_is_file` and similarly for other mentioned\n> commands. Is it correct?\n\nIn addition to what Dscho (alias Johannes Schindelin) wrote, please\njust send one patch that replaces `test -d`, `test -d` and similar\ncode in only one t/tXXXX-*.sh file. No need to do more than that.\n\nThanks,\nChristian.\n"},{"id":"370111","messageId":"CAL7ArXqrV7qb29i6JvQdeUtLNX9A7WC0-deKMx-_6pQUpaqSJA@mail.gmail.com","threadId":"50576","inReplyTo":"CAP8UFD1U+4ww8rC=TSjjH+Rt77P9w4YWA9s5yspVZ7GgPpx0pw@mail.gmail.com","subject":"Re: [GSoC] Introduction","fromName":"Rohit Ashiwal","fromEmail":"rohit.ashiwal265@gmail.com","sentAt":"2019-02-25T11:35:06Z","receivedAt":"2019-02-25T11:36:07Z","isPatch":false,"sender":{"key":"rohit.ashiwal265@gmail.com","avatar":"https://avatars.githubusercontent.com/u/31043830?v=4"},"body":"Hey Christian\n\nOn Mon, Feb 25, 2019 at 12:20 PM Christian Couder\n wrote:\n\n> In addition to what Dscho (alias Johannes Schindelin) wrote, please\n> just send one patch that replaces `test -d`, `test -d` and similar\n> code in only one t/tXXXX-*.sh file. No need to do more than that.\n\nI don't think I quite understood this. Were you asking for replacing\nall `test -X` calls with `test_path_is_*` calls in only one tXXXX-*.sh\nfile or `test -d` calls with `test_path_is_dir` in all tXXXX-*.sh? As\nof now, I've changed almost all `test -d` in all relevant tXXXX-*.sh\nfiles.\n\nThanks\nRohit\n"},{"id":"370134","messageId":"CAP8UFD1wK+goi1rKGjABcs01VwYw2kEma95n08H1EWVT4vh6ng@mail.gmail.com","threadId":"50576","inReplyTo":"CAL7ArXqrV7qb29i6JvQdeUtLNX9A7WC0-deKMx-_6pQUpaqSJA@mail.gmail.com","subject":"Re: [GSoC] Introduction","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-02-25T20:21:52Z","receivedAt":"2019-02-25T20:22:08Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi Rohit,\n\nOn Mon, Feb 25, 2019 at 12:36 PM Rohit Ashiwal\n wrote:\n>\n> Hey Christian\n>\n> On Mon, Feb 25, 2019 at 12:20 PM Christian Couder\n> wrote:\n>\n> > In addition to what Dscho (alias Johannes Schindelin) wrote, please\n> > just send one patch that replaces `test -d`, `test -d` and similar\n> > code in only one t/tXXXX-*.sh file. No need to do more than that.\n>\n> I don't think I quite understood this. Were you asking for replacing\n> all `test -X` calls with `test_path_is_*` calls in only one tXXXX-*.sh\n> file or `test -d` calls with `test_path_is_dir` in all tXXXX-*.sh? As\n> of now, I've changed almost all `test -d` in all relevant tXXXX-*.sh\n> files.\n\nFirst on the micro-project page\n(https://git.github.io/SoC-2019-Microprojects/) there is \"Please\nattempt only ONE microproject. We want quality, not quantity!\"\n\nAnd the description of the micro-project you selected is:\n\n\"Find a test script that verifies the presence/absence of\nfiles/directories with ‘test -(e|f|d|…)’ and replace them with the\nappropriate test_path_is_file, test_path_is_dir, etc. helper\nfunctions.\"\n\nThis asks you to change only 1 test script, that is one t/tXXXX-*.sh file only.\n\nSo yes I am asking for replacing all `test -X` calls with\n`test_path_is_*` calls in only one tXXXX-*.sh file.\n\nThanks,\nChristian.\n"},{"id":"370142","messageId":"CAPig+cSZZaCT0G3hysmjn_tNvZmYGp=5cXpZHkdphbWXnONSVQ@mail.gmail.com","threadId":"50576","inReplyTo":"CAP8UFD1wK+goi1rKGjABcs01VwYw2kEma95n08H1EWVT4vh6ng@mail.gmail.com","subject":"Re: [GSoC] Introduction","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2019-02-25T21:09:18Z","receivedAt":"2019-02-25T21:09:31Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, Feb 25, 2019 at 3:22 PM Christian Couder\n wrote:\n> On Mon, Feb 25, 2019 at 12:36 PM Rohit Ashiwal\n> wrote:\n> > I don't think I quite understood this. Were you asking for replacing\n> > all `test -X` calls with `test_path_is_*` calls in only one tXXXX-*.sh\n> > file or `test -d` calls with `test_path_is_dir` in all tXXXX-*.sh? As\n> > of now, I've changed almost all `test -d` in all relevant tXXXX-*.sh\n> > files.\n>\n> So yes I am asking for replacing all `test -X` calls with\n> `test_path_is_*` calls in only one tXXXX-*.sh file.\n\nNot stated outright, but an important reason for limiting the scope of\nthis change (and, indeed, the scope of any patch series) is to ease\nthe burden on people who review your submission. Large patch series\ntend to tax reviewers heavily, even (and often) when repetitive and\nsimple, like replacing `test -d` with `test_path_is_dir()`. The\nshorter and more concise a patch series is, the more likely that it\nwill receive quality reviews.\n\nAnother reason for keeping the scope of changes limited is to ease the\nburden of the project maintainer. Patch series which touch a lot of\nareas tend to conflict with in-flight topics from other people, and\nthe project maintainer has to juggle and resolve these problems.\nConcise patch series, on the other hand, are less likely to conflict\nwith changes elsewhere.\n"},{"id":"372252","messageId":"20190322151157.9550-1-rohit.ashiwal265@gmail.com","threadId":"50576","inReplyTo":"CAL7ArXqkVfrnQWYFDYdwMGkZjHCwzyQX4pbKCo=KCzy-zJiRBw@mail.gmail.com","subject":"[GSoC][RFC] Proposal: Improve consistency of sequencer commands","fromName":"Rohit Ashiwal","fromEmail":"rohit.ashiwal265@gmail.com","sentAt":"2019-03-22T15:11:57Z","receivedAt":"2019-03-22T15:12:52Z","isPatch":false,"sender":{"key":"rohit.ashiwal265@gmail.com","avatar":"https://avatars.githubusercontent.com/u/31043830?v=4"},"body":"Hey People\n\nI am Rohit Ashiwal and here my first draft of the proposal for the project\ntitled: `Improve consistency of sequencer commands' this summer. I need your\nfeedback and more than that I need help to improve the timeline of this\nproposal since it looks very weak. Basically, it lacks the \"how\" component\nas I don't know much about the codebase in detail.\n\nThanks\nRohit\n\nPS: Point one is missing in the timeline from the ideas page[0], can someone\n explain what exactly it wants?\n\n\n######################################################################################\n Improve consistency of sequencer commands\n######################################################################################\n\n\nAbout Me\n========\n\nPersonal Information\n---------------+-----------------------------------------------------------------------\nName | Rohit Ashiwal\nMajor | Computer Science and Engineering\nE-mail | rohit.ashiwal265@gmail.com\nIRC | __rohit\nSkype | rashiwal\nPh no | [ ph_no ]\nGithub | r1walz\nLinkedin | rohit-ashiwal\nAddress | [ Address ]\nPostal Code | [ postal_code ]\nTime Zone | IST (UTC +0530)\n---------------+-----------------------------------------------------------------------\n\n\nBackground\n----------\nI am a sophomore at the Indian Institute of Technology Roorkee[1], pursuing\nmy bachelor's degree in Computer Science and Engineering. I was introduced\nto programming at a very early stage of my life. Since then, Ive been trying\nout new technologies by taking up various projects and participating in contests.\nI am passionate about system software development and competitive programming,\nand I also actively contribute to open-source projects. At college, I joined\nthe Mobile Development Group [MDG](2), IIT Roorkee - a student group that fosters\nmobile development within the campus. I have been an active part of the Git\ncommunity since February of this year, contributing to git-for-windows.\n\n\nDev-Env\n-------\nI am fluent in C/C++, Java and Shell Scripting, otherwise, I can also program\nin Python, JavaScript. I use both Ubuntu 18.04 and Windows 10 x64 on my laptop.\nI prefer Linux for development unless the work is specific to Windows.\nVCS: \tgit\nEditor: VS Code with gdb integrated\n\n\nContributions to Open Source\n============================\nMy contributions to open source have helped me gain experience in understanding\nthe flow of any pre-written code at a rapid pace and enabled me to edit/add new\nfeatures.\n\nList of Contributions at Git:\n-----------------------------\nStatus: Merge in next revision\ngit/git:\n[Micro](3): Use helper functions in test script.\n\nStatus: Merged\ngit-for-windows/git:\n[#2077](4): [FIX] git-archive error, gzip -cn : command not found.\n\nStatus: Merged\ngit-for-windows/build-extra:\n[#235](5): installer: Fix version of installer and installed file.\n\n\nThe Project: `Improve consistency of sequencer commands'\n========================================================\n\nOverview\n--------\ngit-sequencer was introduced by Stephan Beyer as his\nGSoC 2008 project[6]. It executed a sequence of git instructions to \nor and the sequence was given by a or through stdin. The\ngit-sequencer wants to become the common backend for git-am, git-rebase\nand other git commands. The project was continued by Ramkumar \nin 2011[7], converting it to a builtin and extending its domain to git-cherry-pick.\nAs of now, there are still some inconsistencies among these commands, e.g.,\nthere is no `--skip` flag in `git-cherry-pick` while one exists for `git-rebase`.\nThis project aims to remove inconsistencies in how the command line options are\nhandled.\n\n\nPoints to work on:\n------------------\n - Add `git cherry-pick --skip` \n - Implement flags that am-based rebases support, but not interactive\n\t or merge based, in interactive/merge based rebases\n - [Bonus] Deprecate am-based rebases\n - [Bonus] Make a flag to allow rebase to rewrite commit messages that\n\t refer to older commits that were also rebased\n\n\nProposed Timeline\n-----------------\n + Community Bonding (May 6th - May 26th):\n - Introduction to community\n - Get familiar with the workflow\n - Study and understand the workflow and implementation of the project in detail\n\n + Phase 1 (May 27th - June 23rd):\n - Start with implementing `git cherry-pick --skip`\n - Write new tests for the just introduced flag(s)\n - Analyse the requirements and differences of am-based and other rebases flags\n\n + Phase 2 (June 24th - July 21st):\n - Introduce flags of am-based rebases to other kinds.\n - Add tests for the same.\n\n + Phase 3 (July 22th - August 19th):\n - Act on [Bonus] features\n - Documentation\n - Clean up tasks\n\n\nRelevant Work\n=============\nDscho and I had a talk on how a non-am backend should implement `git rebase\n--whitespace=fix`, which he warned may become a large project (as it turns\nout it is a sub-task in one of the proposed ideas[0]), we were trying to\nintegrate this on git-for-windows first.\nKeeping warning in mind, I discussed this project with Rafael and he suggested\n(with a little bit uncertainty in mind) that I should work on implementing\na git-diff flag that generates a patch that when applied, will remove whitespace\nerrors which I am currently working on.\n\n\nAvailability\n============\nMy vacations start on 7 May and end on 15 July. The official GSoC period\nis from 6 May to 19 August. I can easily devote 40-45 hours a week until\nmy college reopens and 35-40 hours per week after that. Im also free on\nthe weekends and I intend to complete most of the work before my college\nreopens.\n\nOther than this project, I have no commitments/vacations planned for the\nsummer. I shall keep my status posted to all the community members on a\nweekly basis and maintain transparency in the project.\n\n\nAfter GSoC\n==========\nEven after the Google Summer of Code, I plan on continuing my contributions\nto this organization, by adding to my project and working on open issues\nor feature requests. With the community growing continuously, I feel\nresponsible for all the projects Im a part of. Having picked up a lot of\ndeveloping skills, my major focus would be to develop mentorship skills so\nthat I can give back to this community by helping other people navigate\naround and reviewing their contributions.\n\n\n[0]: https://git.github.io/SoC-2019-Ideas/\n[1]: https://www.iitr.ac.in/\n[2]: http://mdg.iitr.ac.in/\n[3]: https://public-inbox.org/git/20190303122842.30380-1-rohit.ashiwal265@gmail.com/\n[4]: https://github.com/git-for-windows/git/pull/2077\n[5]: https://github.com/git-for-windows/build-extra/pull/235\n[6]: https://public-inbox.org/git/20080607220101.GM31040@leksak.fem-net/\n[7]: https://public-inbox.org/git/20110403172054.GA10220@kytes/\n"},{"id":"372315","messageId":"CAP8UFD22PMjQBsAf1GYphmtmt8x+sO=q=c_4bHDsS8L31Y_3AA@mail.gmail.com","threadId":"50576","inReplyTo":"20190322151157.9550-1-rohit.ashiwal265@gmail.com","subject":"Re: [GSoC][RFC] Proposal: Improve consistency of sequencer commands","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-03-23T22:17:54Z","receivedAt":"2019-03-23T22:18:09Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi Rohit,\n\nOn Fri, Mar 22, 2019 at 4:12 PM Rohit Ashiwal\n wrote:\n>\n> Hey People\n>\n> I am Rohit Ashiwal and here my first draft of the proposal for the project\n> titled: `Improve consistency of sequencer commands' this summer. I need your\n> feedback and more than that I need help to improve the timeline of this\n> proposal since it looks very weak. Basically, it lacks the \"how\" component\n> as I don't know much about the codebase in detail.\n>\n> Thanks\n> Rohit\n>\n> PS: Point one is missing in the timeline from the ideas page[0], can someone\n> explain what exactly it wants?\n\nYou mean this point from the idea page:\n\n\"The suggestion to fix an interrupted rebase-i or cherry-pick due to a\ncommit that became empty via git reset HEAD (in builtin/commit.c)\ninstead of git rebase --skip or git cherry-pick --skip ranges from\nannoying to confusing. (Especially since other interrupted am’s and\nrebases both point to am/rebase –skip.). Note that git cherry-pick\n--skip is not yet implemented, so that would have to be added first.\"\n\nor something else?\n\nBy the way it is not very clear if the proposal uses markdown or\nanother related format and if it is also possible (and perhaps even\nbetter visually) to see it somewhere else (maybe on GitHub). If that's\nindeed possible, please provide a link. It is a good thing though to\nstill also send it attached to an email, so that it can be easily\nreviewed and commented on by people who prefer email discussions.\n\n> List of Contributions at Git:\n> -----------------------------\n> Status: Merge in next revision\n\nMaybe \"Merged into the 'next' branch\"\n\n> git/git:\n> [Micro](3): Use helper functions in test script.\n\nPlease give more information than that, for example you could point to\nthe commit in the next branch on GitHub and perhaps to the what's\ncooking email from Junio where it can be seen that the patch has been\nmerged into next and what's its current status.\n\n> Status: Merged\n> git-for-windows/git:\n> [#2077](4): [FIX] git-archive error, gzip -cn : command not found.\n>\n> Status: Merged\n> git-for-windows/build-extra:\n> [#235](5): installer: Fix version of installer and installed file.\n\nFor Git for Windows contributions I think a link to the pull request\nis enough. It could be nice to know though if the commits are part of\na released version.\n\n> The Project: `Improve consistency of sequencer commands'\n> ========================================================\n>\n> Overview\n> --------\n> git-sequencer was introduced by Stephan Beyer as his\n> GSoC 2008 project[6]. It executed a sequence of git instructions to \n> or and the sequence was given by a or through stdin. The\n> git-sequencer wants to become the common backend for git-am, git-rebase\n> and other git commands. The project was continued by Ramkumar \n> in 2011[7], converting it to a builtin and extending its domain to git-cherry-pick.\n\nYeah, you can say that it was another GSoC project and maybe give his\nfull name (Ramkumar Ramachandra).\n\nThere have been more related work to extend usage of the sequencer\nafter these GSoC projects, at least from Dscho and maybe from Alban\nGruin and Elijah too. I would be nice if you could document that a\nbit.\n\n> As of now, there are still some inconsistencies among these commands, e.g.,\n> there is no `--skip` flag in `git-cherry-pick` while one exists for `git-rebase`.\n> This project aims to remove inconsistencies in how the command line options are\n> handled.\n\n\n> Points to work on:\n> ------------------\n> - Add `git cherry-pick --skip`\n> - Implement flags that am-based rebases support, but not interactive\n> or merge based, in interactive/merge based rebases\n\nMaybe the flags could be listed.\n\n> - [Bonus] Deprecate am-based rebases\n> - [Bonus] Make a flag to allow rebase to rewrite commit messages that\n> refer to older commits that were also rebased\n\nThis part of your proposal (\"Points to work on\") looks weak to me.\n\nPlease try to add more details about what you plan to do, how you\nwould describe the new flags in the documentation, which *.c *.h and\ntest files might be changed, etc.\n\n> Proposed Timeline\n> -----------------\n> + Community Bonding (May 6th - May 26th):\n> - Introduction to community\n> - Get familiar with the workflow\n> - Study and understand the workflow and implementation of the project in detail\n>\n> + Phase 1 (May 27th - June 23rd):\n> - Start with implementing `git cherry-pick --skip`\n> - Write new tests for the just introduced flag(s)\n> - Analyse the requirements and differences of am-based and other rebases flags\n>\n> + Phase 2 (June 24th - July 21st):\n> - Introduce flags of am-based rebases to other kinds.\n> - Add tests for the same.\n>\n> + Phase 3 (July 22th - August 19th):\n> - Act on [Bonus] features\n> - Documentation\n> - Clean up tasks\n>\n>\n> Relevant Work\n> =============\n> Dscho and I had a talk on how a non-am backend should implement `git rebase\n> --whitespace=fix`, which he warned may become a large project (as it turns\n> out it is a sub-task in one of the proposed ideas[0]), we were trying to\n> integrate this on git-for-windows first.\n> Keeping warning in mind, I discussed this project with Rafael and he suggested\n> (with a little bit uncertainty in mind) that I should work on implementing\n> a git-diff flag that generates a patch that when applied, will remove whitespace\n> errors which I am currently working on.\n\nYou mean Rafael Ascensão? Please CC him if he is involved in this.\n\nThanks,\nChristian.\n"},{"id":"372317","messageId":"CABPp-BEdgSHGTkUcg_UDRu50Ag+cCqigmvU4_JaRZRnDpgWcdA@mail.gmail.com","threadId":"50576","inReplyTo":"20190322151157.9550-1-rohit.ashiwal265@gmail.com","subject":"Re: [GSoC][RFC] Proposal: Improve consistency of sequencer commands","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-03-24T01:07:17Z","receivedAt":"2019-03-24T01:07:31Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi Rohit!\n\nOn Fri, Mar 22, 2019 at 8:12 AM Rohit Ashiwal\n wrote:\n>\n> Hey People\n>\n> I am Rohit Ashiwal and here my first draft of the proposal for the project\n> titled: `Improve consistency of sequencer commands' this summer. I need your\n> feedback and more than that I need help to improve the timeline of this\n> proposal since it looks very weak. Basically, it lacks the \"how\" component\n> as I don't know much about the codebase in detail.\n>\n> Thanks\n> Rohit\n>\n> PS: Point one is missing in the timeline from the ideas page[0], can someone\n> explain what exactly it wants?\n\nI don't understand the question; could you restate it?\n\n> Points to work on:\n> ------------------\n> - Add `git cherry-pick --skip`\n\nI'd reword this section as 'Consistently suggest --skip for operations\nthat have such a concept'.[1]\n\nAdding a --skip flag to cherry-pick is useful, but was only meant as a\nstep. Let me explain in more detail and use another comparison point.\nEach of the git commands cherry-pick, merge, rebase take the flags\n\"--continue\" and \"--abort\"; but they didn't always do so and so\ncontinuing or aborting an operation often used special case-specific\ncommands for each (e.g. git reset --hard (or later --merge) to abort a\nmerge, git commit to continue it, etc.) Those commands don't\nnecessarily make sense to users, whereas ' --continue' and\n' --abort' do make intuitive sense and is thus memorable.\nWe want the same for --skip.\n\nBoth am-based rebases and am itself will give advice to the user to\nuse 'git rebase --skip' or 'git am --skip' when a patch isn't needed.\nThat's good. In contrast, interactive-based rebases and cherry-pick\nwill suggest that the user run 'git reset' (with no arguments). The\nplace that suggests that command should instead suggest either 'git\nrebase --skip' or 'git cherry-pick --skip', depending on which\noperation is in progress. The first step for doing that, is making\nsure that cherry-pick actually has a '--skip' option.\n\n> - Implement flags that am-based rebases support, but not interactive\n> or merge based, in interactive/merge based rebases\n\nThe \"merge-based\" rebase backend was deleted in 2.21.0, with all its\nspecial flags reimplemented on the top of the interactive backend. So\nwe can omit the deleted backend from the descriptions (instead just\ntalk about the am-based and interactive backends).\n\n> - [Bonus] Deprecate am-based rebases\n> - [Bonus] Make a flag to allow rebase to rewrite commit messages that\n> refer to older commits that were also rebased\n\nI'd reorder these two. I suspect the second won't be too hard and\nwill provide a new user-visible feature, while the former will\nhopefully not be visible to users; if the former has more than\ncosmetic differences visible to user, it might transform the problem\ninto more of a social problem than a technical one or just make into\nsomething we can't do.\n\n> Proposed Timeline\n> -----------------\n> + Community Bonding (May 6th - May 26th):\n> - Introduction to community\n> - Get familiar with the workflow\n> - Study and understand the workflow and implementation of the project in detail\n>\n> + Phase 1 (May 27th - June 23rd):\n> - Start with implementing `git cherry-pick --skip`\n> - Write new tests for the just introduced flag(s)\n> - Analyse the requirements and differences of am-based and other rebases flags\n\nWriting or finding tests to trigger all the --skip codepaths might be\nthe biggest part of this phase. Implementing `git cherry-pick --skip`\njust involves making it run the code that `git reset` invokes. The\nyou change the error message to reference ` --skip` instead\nof `git reset`. What you're calling phase 1 here isn't quite\nmicroproject sized, but it should be relatively quick and easy; I'd\nplan to spend much more of your time on phase 2.\n\n> + Phase 2 (June 24th - July 21st):\n> - Introduce flags of am-based rebases to other kinds.\n> - Add tests for the same.\n\nYou should probably mention the individual cases from \"INCOMPATIBLE\nFLAGS\" of the git rebase manpage. Also, some advice for order of\ntackling these: I think you should probably do --ignore-whitespace\nfirst; my guess is that one is the easiest. Close up would be\n--committer-date-is-author-date and --ignore-date. Re-reading, I'm\nnot sure -C even makes sense at all; it might be that the solution is\njust accepting the flag and ignoring it, or perhaps it remains the one\nflag the interactive backend won't support, or maybe there is\nsomething that makes sense to be done. There'd need to be a little\ninvestigation for that one, but it might turn out simple too. The\n--whitespace={nowarn|warn|fix|error|error-all} flag will be the\nkicker. I don't know how long that one will take, but I'm certain\nit's harder than the other flags and it might conceivably take up most\nthe summer or even extend beyond.\n\n> + Phase 3 (July 22th - August 19th):\n> - Act on [Bonus] features\n> - Documentation\n> - Clean up tasks\n\nI'd prefer that Documentation updates were made as you went; you'll\nparticularly need to look at Documentation/git-cherry-pick.txt and\nDocumentation/rebase.txt, especially the \"INCOMPATIBLE OPTIONS\" and\n\"BEHAVIORAL DIFFERENCES\" sections of the latter.\n\nAlso, as far as timing goes, the rewriting of commit messages seems\nrelatively straightforward; you may want to consider doing it before\nthe --whitespace flag (despite the fact that I originally suggested it\nas a bonus item). Deprecating am-based rebases, on the other hand, is\na bit of a wildcard. It depends on Phase 2 being completed so it\ndefinitely makes sense to be last. If phase 2 is complete, it's\nconceivable that deprecating am-based rebases only takes a little more\nwork, but it might expand to use up a lot of time.\n\n> Relevant Work\n> =============\n> Dscho and I had a talk on how a non-am backend should implement `git rebase\n> --whitespace=fix`, which he warned may become a large project (as it turns\n> out it is a sub-task in one of the proposed ideas[0]), we were trying to\n> integrate this on git-for-windows first.\n> Keeping warning in mind, I discussed this project with Rafael and he suggested\n> (with a little bit uncertainty in mind) that I should work on implementing\n> a git-diff flag that generates a patch that when applied, will remove whitespace\n> errors which I am currently working on.\n\nIt's awesome that you're looking in to this, but it may make more\nsense to knock out the easy parts of this project first. That way the\nproject gets some value out of your work for sure, you gain confidence\nand familiarity with the codebase, and then you can tackle the more\ndifficult items. Of course, if you're just exploring to learn what's\npossible in order to write the proposal, that's fine, I just think\nonce you start on this project, it'd make more sense to do the easier\nones first.\n\n\nHope that helps,\nElijah\n"},{"id":"372318","messageId":"20190324012130.6762-1-rohit.ashiwal265@gmail.com","threadId":"50576","inReplyTo":"CAP8UFD22PMjQBsAf1GYphmtmt8x+sO=q=c_4bHDsS8L31Y_3AA@mail.gmail.com","subject":"Re: [GSoC][RFC] Proposal: Improve consistency of sequencer commands","fromName":"Rohit Ashiwal","fromEmail":"rohit.ashiwal265@gmail.com","sentAt":"2019-03-24T01:21:30Z","receivedAt":"2019-03-24T01:22:24Z","isPatch":false,"sender":{"key":"rohit.ashiwal265@gmail.com","avatar":"https://avatars.githubusercontent.com/u/31043830?v=4"},"body":"Hi Christian\n\nOn 2019-03-23 22:17 UTC Christian Couder <> wrote:\n> On Fri, Mar 22, 2019 at 4:12 PM Rohit Ashiwal\n> wrote:\n> >\n> > Hey People\n> >\n> > I am Rohit Ashiwal and here my first draft of the proposal for the project\n> > titled: `Improve consistency of sequencer commands' this summer. I need your\n> > feedback and more than that I need help to improve the timeline of this\n> > proposal since it looks very weak. Basically, it lacks the \"how\" component\n> > as I don't know much about the codebase in detail.\n> >\n> > Thanks\n> > Rohit\n> >\n> > PS: Point one is missing in the timeline from the ideas page[0], can someone\n> > explain what exactly it wants?\n> \n> You mean this point from the idea page:\n> \n> \"The suggestion to fix an interrupted rebase-i or cherry-pick due to a\n> commit that became empty via git reset HEAD (in builtin/commit.c)\n> instead of git rebase --skip or git cherry-pick --skip ranges from\n> annoying to confusing. (Especially since other interrupted am’s and\n> rebases both point to am/rebase –skip.). Note that git cherry-pick\n> --skip is not yet implemented, so that would have to be added first.\"\n\nYes.\n\n> or something else?\n> \n> By the way it is not very clear if the proposal uses markdown or\n> another related format and if it is also possible (and perhaps even\n> better visually) to see it somewhere else (maybe on GitHub). If that's\n> indeed possible, please provide a link. It is a good thing though to\n> still also send it attached to an email, so that it can be easily\n> reviewed and commented on by people who prefer email discussions.\n\nThis was intentional. Here is the link of the proposal hosted at gist.github.com[1],\nthose who prefer text only version here[2] is mailing list link.\n\n> > List of Contributions at Git:\n> > -----------------------------\n> > Status: Merge in next revision\n> \n> Maybe \"Merged into the 'next' branch\"\n> \n> > git/git:\n> > [Micro](3): Use helper functions in test script.\n> \n> Please give more information than that, for example you could point to\n> the commit in the next branch on GitHub and perhaps to the what's\n> cooking email from Junio where it can be seen that the patch has been\n> merged into next and what's its current status.\n\nCurrent proposal has added links to those commits.\n\n> > Status: Merged\n> > git-for-windows/git:\n> > [#2077](4): [FIX] git-archive error, gzip -cn : command not found.\n\nThis was released in v2.21.0 [3]\n\n> > Status: Merged\n> > git-for-windows/build-extra:\n> > [#235](5): installer: Fix version of installer and installed file.\n> \n> For Git for Windows contributions I think a link to the pull request\n> is enough. It could be nice to know though if the commits are part of\n> a released version.\n\n> > The Project: `Improve consistency of sequencer commands'\n> > ========================================================\n> >\n> > Overview\n> > --------\n> > git-sequencer was introduced by Stephan Beyer as his\n> > GSoC 2008 project[6]. It executed a sequence of git instructions to \n> > or and the sequence was given by a or through stdin. The\n> > git-sequencer wants to become the common backend for git-am, git-rebase\n> > and other git commands. The project was continued by Ramkumar \n> > in 2011[7], converting it to a builtin and extending its domain to git-cherry-pick.\n> \n> Yeah, you can say that it was another GSoC project and maybe give his\n> full name (Ramkumar Ramachandra).\n> \n> There have been more related work to extend usage of the sequencer\n> after these GSoC projects, at least from Dscho and maybe from Alban\n> Gruin and Elijah too. I would be nice if you could document that a\n> bit.\n> \n> > As of now, there are still some inconsistencies among these commands, e.g.,\n> > there is no `--skip` flag in `git-cherry-pick` while one exists for `git-rebase`.\n> > This project aims to remove inconsistencies in how the command line options are\n> > handled.\n> \n> \n> > Points to work on:\n> > ------------------\n> > - Add `git cherry-pick --skip`\n> > - Implement flags that am-based rebases support, but not interactive\n> > or merge based, in interactive/merge based rebases\n> \n> Maybe the flags could be listed.\n> \n> > - [Bonus] Deprecate am-based rebases\n> > - [Bonus] Make a flag to allow rebase to rewrite commit messages that\n> > refer to older commits that were also rebased\n> \n> This part of your proposal (\"Points to work on\") looks weak to me.\n> \n> Please try to add more details about what you plan to do, how you\n> would describe the new flags in the documentation, which *.c *.h and\n> test files might be changed, etc.\n\nI'll soon add details to the proposal, currently digging deep into the mailing list.\n\n> > Proposed Timeline\n> > -----------------\n> > + Community Bonding (May 6th - May 26th):\n> > - Introduction to community\n> > - Get familiar with the workflow\n> > - Study and understand the workflow and implementation of the project in detail\n> >\n> > + Phase 1 (May 27th - June 23rd):\n> > - Start with implementing `git cherry-pick --skip`\n> > - Write new tests for the just introduced flag(s)\n> > - Analyse the requirements and differences of am-based and other rebases flags\n> >\n> > + Phase 2 (June 24th - July 21st):\n> > - Introduce flags of am-based rebases to other kinds.\n> > - Add tests for the same.\n> >\n> > + Phase 3 (July 22th - August 19th):\n> > - Act on [Bonus] features\n> > - Documentation\n> > - Clean up tasks\n> >\n> >\n> > Relevant Work\n> > =============\n> > Dscho and I had a talk on how a non-am backend should implement `git rebase\n> > --whitespace=fix`, which he warned may become a large project (as it turns\n> > out it is a sub-task in one of the proposed ideas[0]), we were trying to\n> > integrate this on git-for-windows first.\n> > Keeping warning in mind, I discussed this project with Rafael and he suggested\n> > (with a little bit uncertainty in mind) that I should work on implementing\n> > a git-diff flag that generates a patch that when applied, will remove whitespace\n> > errors which I am currently working on.\n> \n> You mean Rafael Ascensão? Please CC him if he is involved in this.\n\nYes, I'll CC him.\n\nThanks\nRohit\n\n[1]: https://gist.github.com/r1walz/5588d11065d5231ee451c0136400610e\n[2]: https://public-inbox.org/git/20190322151157.9550-1-rohit.ashiwal265@gmail.com/\n[3]: https://github.com/git-for-windows/git/releases/tag/v2.21.0.windows.1\n"},{"id":"372319","messageId":"20190324014530.8218-1-rohit.ashiwal265@gmail.com","threadId":"50576","inReplyTo":"CABPp-BEdgSHGTkUcg_UDRu50Ag+cCqigmvU4_JaRZRnDpgWcdA@mail.gmail.com","subject":"Re: [GSoC][RFC] Proposal: Improve consistency of sequencer commands","fromName":"Rohit Ashiwal","fromEmail":"rohit.ashiwal265@gmail.com","sentAt":"2019-03-24T01:45:30Z","receivedAt":"2019-03-24T01:46:24Z","isPatch":false,"sender":{"key":"rohit.ashiwal265@gmail.com","avatar":"https://avatars.githubusercontent.com/u/31043830?v=4"},"body":"Hi Elijah!\n\nOn Sat, 23 Mar 2019 18:07:17 -0700 Elijah Newren wrote:\n> Hi Rohit!\n> \n> On Fri, Mar 22, 2019 at 8:12 AM Rohit Ashiwal\n> wrote:\n> > PS: Point one is missing in the timeline from the ideas page[0], can someone\n> > explain what exactly it wants?\n> \n> I don't understand the question; could you restate it?\n\nI was talking about this point: \" The suggestion to fix an interrupted rebase-i\nor cherry-pick due to a commit that became empty via git reset HEAD (in builtin/commit.c)\ninstead of git rebase --skip or git cherry-pick --skip ranges from annoying to confusing.\".\n\n> > Points to work on:\n> > ------------------\n> > - Add `git cherry-pick --skip`\n> \n> I'd reword this section as 'Consistently suggest --skip for operations\n> that have such a concept'.[1]\n\nAlright! I'll correct this in comming revisions.\n\n> > - [Bonus] Deprecate am-based rebases\n> > - [Bonus] Make a flag to allow rebase to rewrite commit messages that\n> > refer to older commits that were also rebased\n> \n> I'd reorder these two. I suspect the second won't be too hard and\n> will provide a new user-visible feature, while the former will\n> hopefully not be visible to users; if the former has more than\n> cosmetic differences visible to user, it might transform the problem\n> into more of a social problem than a technical one or just make into\n> something we can't do.\n\nThere is no \"order\" in these points, just a rough TODO list, but I get your point here.\n \n> > Proposed Timeline\n> > -----------------\n> > + Community Bonding (May 6th - May 26th):\n> > - Introduction to community\n> > - Get familiar with the workflow\n> > - Study and understand the workflow and implementation of the project in detail\n> >\n> > + Phase 1 (May 27th - June 23rd):\n> > - Start with implementing `git cherry-pick --skip`\n> > - Write new tests for the just introduced flag(s)\n> > - Analyse the requirements and differences of am-based and other rebases flags\n> \n> Writing or finding tests to trigger all the --skip codepaths might be\n> the biggest part of this phase. Implementing `git cherry-pick --skip`\n> just involves making it run the code that `git reset` invokes. The\n> you change the error message to reference ` --skip` instead\n> of `git reset`. What you're calling phase 1 here isn't quite\n> microproject sized, but it should be relatively quick and easy; I'd\n> plan to spend much more of your time on phase 2.\n> \n> > + Phase 2 (June 24th - July 21st):\n> > - Introduce flags of am-based rebases to other kinds.\n> > - Add tests for the same.\n> \n> You should probably mention the individual cases from \"INCOMPATIBLE\n> FLAGS\" of the git rebase manpage. Also, some advice for order of\n> tackling these: I think you should probably do --ignore-whitespace\n> first; my guess is that one is the easiest. Close up would be\n> --committer-date-is-author-date and --ignore-date. Re-reading, I'm\n> not sure -C even makes sense at all; it might be that the solution is\n> just accepting the flag and ignoring it, or perhaps it remains the one\n> flag the interactive backend won't support, or maybe there is\n> something that makes sense to be done. There'd need to be a little\n> investigation for that one, but it might turn out simple too. The\n> --whitespace={nowarn|warn|fix|error|error-all} flag will be the\n> kicker. I don't know how long that one will take, but I'm certain\n> it's harder than the other flags and it might conceivably take up most\n> the summer or even extend beyond.\n> \n> > + Phase 3 (July 22th - August 19th):\n> > - Act on [Bonus] features\n> > - Documentation\n> > - Clean up tasks\n> \n> I'd prefer that Documentation updates were made as you went; you'll\n> particularly need to look at Documentation/git-cherry-pick.txt and\n> Documentation/rebase.txt, especially the \"INCOMPATIBLE OPTIONS\" and\n> \"BEHAVIORAL DIFFERENCES\" sections of the latter.\n\nThanks for advice, yes, of course, the documentation and implementation will go\nhand in hand.\n \n> Also, as far as timing goes, the rewriting of commit messages seems\n> relatively straightforward; you may want to consider doing it before\n> the --whitespace flag (despite the fact that I originally suggested it\n> as a bonus item). Deprecating am-based rebases, on the other hand, is\n> a bit of a wildcard. It depends on Phase 2 being completed so it\n> definitely makes sense to be last. If phase 2 is complete, it's\n> conceivable that deprecating am-based rebases only takes a little more\n> work, but it might expand to use up a lot of time.\n> \n> > Relevant Work\n> > =============\n> > Dscho and I had a talk on how a non-am backend should implement `git rebase\n> > --whitespace=fix`, which he warned may become a large project (as it turns\n> > out it is a sub-task in one of the proposed ideas[0]), we were trying to\n> > integrate this on git-for-windows first.\n> > Keeping warning in mind, I discussed this project with Rafael and he suggested\n> > (with a little bit uncertainty in mind) that I should work on implementing\n> > a git-diff flag that generates a patch that when applied, will remove whitespace\n> > errors which I am currently working on.\n> \n> It's awesome that you're looking in to this, but it may make more\n> sense to knock out the easy parts of this project first. That way the\n> project gets some value out of your work for sure, you gain confidence\n> and familiarity with the codebase, and then you can tackle the more\n> difficult items. Of course, if you're just exploring to learn what's\n> possible in order to write the proposal, that's fine, I just think\n> once you start on this project, it'd make more sense to do the easier\n> ones first.\n\nYes, I'm looking into the code to get some clear vision.\n\n> Hope that helps,\nYes! The vision in now clearer. Thanks Elijah. :)\n> Elijah\n\nThanks for the review\nRohit\n"},{"id":"372737","messageId":"20190329223228.4924-1-rohit.ashiwal265@gmail.com","threadId":"50576","inReplyTo":"CAL7ArXqkVfrnQWYFDYdwMGkZjHCwzyQX4pbKCo=KCzy-zJiRBw@mail.gmail.com","subject":"[GSoC][RFC v2] Improve consistency of sequencer commands","fromName":"Rohit Ashiwal","fromEmail":"rohit.ashiwal265@gmail.com","sentAt":"2019-03-29T22:32:28Z","receivedAt":"2019-03-29T22:33:28Z","isPatch":false,"sender":{"key":"rohit.ashiwal265@gmail.com","avatar":"https://avatars.githubusercontent.com/u/31043830?v=4"},"body":"Hiya\n\nThis is the v2 of the draft proposal[1]. I've added some details to the proposal,\nit talks more about what to implement instead of how. It is still incomplete.\n\nI'm currently adding more to the overview section, where I'll document the work\ndone by Dscho and Alban. After that I'll find files that will be changed while\nimplementing rest of the flags, finally add the basic control and/or data flow\nof the 'how' part.\n\nThanks\nRohit\n\n[1]: https://gist.github.com/r1walz/5588d11065d5231ee451c0136400610e\nhttps://public-inbox.org/git/20190322151157.9550-1-rohit.ashiwal265@gmail.com/\n\n------------------------------- >8 -------------------------------------\n\n# Improve consistency of sequencer commands\n\n## About Me\n\n### Personal Information\n\nName | Rohit Ashiwal\n---------------|----------------------------------------------------------------\nMajor | Computer Science and Engineering\nE-mail | \\\nIRC | __rohit\nSkype | rashiwal\nPh no | [ ph_no ]\nGithub | [r1walz](https://github.com/r1walz/)\nLinkedin | [rohit-ashiwal](https://linkedin.com/in/rohit-ashiwal/)\nAddress | [ Address ]\nPostal Code | [ postal_code ]\nTime Zone | IST (UTC +0530)\n\n\n### Background\n\nI am a sophomore at the [Indian Institute of Technology Roorkee][1], pursuing my\nbachelor's degree in Computer Science and Engineering. I was introduced to\nprogramming at a very early stage of my life. Since then, I've been trying out\nnew technologies by taking up various projects and participating in contests. I\nam passionate about system software development and competitive programming, and\nI also actively contribute to open-source projects. At college, I joined the\nMobile Development Group ([MDG][2]), IIT Roorkee - a student group that fosters\nmobile development within the campus. I have been an active part of the Git\ncommunity since February of this year, contributing to git-for-windows.\n\n\n### Dev-Env\n\nI am fluent in C/C++, Java and Shell Scripting, otherwise, I can also program in\nPython, JavaScript. I use both Ubuntu 18.04 and Windows 10 x64 on my laptop. I\nprefer Linux for development unless the work is specific to Windows. \\\nVCS **:** git \\\nEditor **:** VS Code with gdb integrated\n\n\n## Contributions to Open Source\n\nMy contributions to open source have helped me gain experience in understanding\nthe flow of any pre-written code at a rapid pace and enabled me to edit/add new\nfeatures.\n\n### List of Contributions at Git:\n\nRepo | Status | Title\n-|-|-\n[git/git][8] | Merged in 'next' branch | [Micro][3]**:** Use helper functions in test script\n[git-for-windows/git][9] | Merged and released | [#2077][4]**:** [FIX] git-archive error, gzip -cn : command not found.\n[git-for-windows/build-extra][10] | Merged | [#235][5]**:** installer: Fix version of installer and installed file.\n\n\n## The Project\n\n### _Improve consistency of sequencer commands_\n\n#### Overview\n\nStephan Beyer \\ tried to introduce git-sequencer as his GSoC\n2008 [project][6] which executed a sequence of git instructions to \\ or\n\\ and the sequence was given by a \\ or through `stdin`. The\ngit-sequencer wants to become the common backend for git-am, git-rebase and\nother git commands. Unfortunately, most of the code did not get merged during\nthe SoC period but he continued his contributions to the project along with\nChristian Couder \\ and then mentor Daniel Barkalow\n\\.\n\nThe project was continued by Ramkumar Ramachandra \\ in\n[2011][7], converting it to a builtin and extending its domain to\ngit-cherry-pick.\n\nThe learnings from all those works will serve as a huge headstart this year for\nme.\n\nAs of now, there are still some inconsistencies among these commands, e.g.,\nthere is no `--skip` flag in `git-cherry-pick` while one exists for\n`git-rebase`. This project aims to remove inconsistencies in how the command\nline options are handled.\n\n\n#### Points to work on:\n\n1. Suggest relevant flags for operations that have such a concept like\n `git cherry-pick --skip`\n2. Unify the suggestive messages of `git (cherry-pick|rebase-i)` with\n `git (am|rebase)`\n3. Implement flags that am-based rebases support, but not interactive,\n in interactive rebases, e.g.:\n```\n * --ignore-whitespace\n * --committer-date-is-author-date or --ignore-date\n * --signoff\n * --whitespace=...\n * -C\n```\n4. Test and Documentation\n5. `[Bonus]` Make a flag to allow rebase to rewrite commit messages that\n refer to older commits that were also rebased\n6. `[Bonus]` Deprecate am-based rebases\n\n\n#### \"The Plan\"\n\n1. Start by introducing `git cherry-pick --skip`, this will help in step 2 of\n\"the plan\", since we are required to unify the advice messages that show during\nan interrupt of `git (cherry-pick|rebase -i)` when the incoming commit has\nbecome \"empty\" (no change between commits).\n\n **_Files changed_ :**\n - revert.c: Introduce option `--skip` under `run_sequencer()`\n\n2. There are two backends available for rebasing/cherry-picking, _viz_, the `am`\nand the `interactive`. Naturally, there shall be some features that are\nimplemented in one but not in the other. One such quality is suggestive\nmessages. The am-based rebases (and am itself) will give advice to the user to\nuse `git rebase --skip` (or `git am --skip`) when a patch isn't needed. In\ncontrast, interactive-based and cherry-pick will suggest the user `git reset`.\nChange this to match the message of `am` backend, so that everything appears\nsymmetric.\n\n **_Files changed_ :**\n - rebase.c: change flow so that `--skip` calls `git reset` while interactive\n rebasing\n - commit.c: change messages\n - sequencer.c: change suggestive message under `create_seq_dir()`\n\n3. Now that I'm familiar with the code, I'll start picking the pace now. And\nstart implementing the meat of the project. The flags. I'll start implementing\nthe flags in the following order as [Elijah suggested][12]:\n 1. --ignore-whitespace\n 2. --committer-date-is-author-date\n 3. --ignore-date\n 4. --whitespace=...\n 5. `[Bonus]` --signoff\n\n **_Files changed_ :** [currently searching for files to be changed]\n\n4. Testing and Documentation will go in sync with implementation. I intend to\nfollow `Test Driven Development` but let's see how it turns out.\n\n5. `[Bonus]` As familiarity with the code increases, I might be able to implement\nthe feature of rewriting commits in time.\n\n6. `[Bonus]` If everything goes well and time permits, discuss with the mentor(s)\nthe possibility of deprecating the am backend of rebase. This point is last to\nwork on as it provides no \"cosmetic\" difference on the user side. Elijah\n[mentioned][12] the possibility of a \"social\" problem that might occur which shall\nbe discussed then.\n\n\n#### Proposed Timeline\n\n+ Community Bonding (May 6th - May 26th):\n - Introduction to community\n - Get familiar with the dataflow\n - Study and understand the workflow and implementation of the project in\n detail\n\n+ Phase 1 (May 27th - June 23rd):\n - Start with implementing `git cherry-pick --skip`\n - Write new tests for the just introduced flag(s)\n - Analyse the requirements and differences of am-based and other rebases\n flags\n\n+ Phase 2 (June 24th - July 21st):\n - Introduce flags of am-based rebases to other kinds.\n - Add tests for the same.\n\n+ Phase 3 (July 22th - August 19th):\n - Act on [Bonus] features\n - Documentation\n - Clean up tasks\n\n\n#### Relevant Work\n\nDscho and I had a talk on how a non-am backend should implement `git rebase\n--whitespace=fix`, which he warned may become a large project (as it turns out\nit is a sub-task in one of the [proposed ideas][11]), we were trying to\nintegrate this on git-for-windows first.\n\nKeeping warning in mind, I discussed this project with Rafael and he suggested\n(with a little bit uncertainty in mind) that I should work on implementing a\ngit-diff flag that generates a patch that when applied, will remove whitespace\nerrors which I am currently working on.\n\n\n## Availability\n\nMy vacations start on 7 May and end on 15 July. The official GSoC period is from\n6 May to 19 August. I can easily devote 40-45 hours a week until my college\nreopens and 35-40 hours per week after that. I'm also free on the weekends and I\nintend to complete most of the work before my college reopens.\n\nOther than this project, I have no commitments/vacations planned for the summer.\nI shall keep my status posted to all the community members on a weekly basis and\nmaintain transparency in the project.\n\n## After GSoC\n\nEven after the Google Summer of Code, I plan on continuing my contributions to\nthis organization, by adding to my project and working on open issues or\nfeature requests. With the community growing continuously, I feel responsible\nfor all the projects I'm a part of. Having picked up a lot of developing skills,\nmy major focus would be to develop mentorship skills so that I can give back\nthis community by helping other people navigate around and reviewing\ncontributions.\n\n\n[0]: https://git.github.io/SoC-2019-Ideas/\n[1]: https://www.iitr.ac.in/\n[2]: http://mdg.iitr.ac.in/\n[3]: https://public-inbox.org/git/20190303122842.30380-1-rohit.ashiwal265@gmail.com/\n[4]: https://github.com/git-for-windows/git/pull/2077\n[5]: https://github.com/git-for-windows/build-extra/pull/235\n[6]: https://public-inbox.org/git/20080607220101.GM31040@leksak.fem-net/\n[7]: https://public-inbox.org/git/20110403172054.GA10220@kytes/\n[8]: https://github.com/git/git/commit/404110d2910aa617c7fb7e326694f8e085c5b2a0\n[9]: https://github.com/git-for-windows/git/commit/ed2b22adeb760d967c567c5664d33d5d641db10e\n[10]: https://github.com/git-for-windows/build-extra/commit/2e879f7fa5808f5f9cbfdd08ca456209f9ac5f1b\n[11]: https://git.github.io/SoC-2019-Ideas/#improve-consistency-of-sequencer-commands\n[12]: https://public-inbox.org/git/CABPp-BEdgSHGTkUcg_UDRu50Ag+cCqigmvU4_JaRZRnDpgWcdA@mail.gmail.com/\n"},{"id":"372739","messageId":"CABPp-BETuwt96jeBMMhzT84-=-MqEA3D7uhLb2uxW3fijx7p7Q@mail.gmail.com","threadId":"50576","inReplyTo":"20190329223228.4924-1-rohit.ashiwal265@gmail.com","subject":"Re: [GSoC][RFC v2] Improve consistency of sequencer commands","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-03-29T23:25:49Z","receivedAt":"2019-03-29T23:26:03Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi Rohit,\n\nOn Fri, Mar 29, 2019 at 3:33 PM Rohit Ashiwal\n wrote:\n>\n> Hiya\n>\n> This is the v2 of the draft proposal[1]. I've added some details to the proposal,\n> it talks more about what to implement instead of how. It is still incomplete.\n>\n> I'm currently adding more to the overview section, where I'll document the work\n> done by Dscho and Alban. After that I'll find files that will be changed while\n> implementing rest of the flags, finally add the basic control and/or data flow\n> of the 'how' part.\n\nOverall this looks pretty good to me, just one question...\n\n> 3. Now that I'm familiar with the code, I'll start picking the pace now. And\n> start implementing the meat of the project. The flags. I'll start implementing\n> the flags in the following order as [Elijah suggested][12]:\n> 1. --ignore-whitespace\n> 2. --committer-date-is-author-date\n> 3. --ignore-date\n> 4. --whitespace=...\n> 5. `[Bonus]` --signoff\n\n--signoff is new and surprises me. What's the plan with that one?\n"},{"id":"372740","messageId":"20190329233407.13049-1-rohit.ashiwal265@gmail.com","threadId":"50576","inReplyTo":"CABPp-BETuwt96jeBMMhzT84-=-MqEA3D7uhLb2uxW3fijx7p7Q@mail.gmail.com","subject":"Re: [GSoC][RFC v2] Improve consistency of sequencer commands","fromName":"Rohit Ashiwal","fromEmail":"rohit.ashiwal265@gmail.com","sentAt":"2019-03-29T23:34:07Z","receivedAt":"2019-03-29T23:35:03Z","isPatch":false,"sender":{"key":"rohit.ashiwal265@gmail.com","avatar":"https://avatars.githubusercontent.com/u/31043830?v=4"},"body":"Hi Elijah\n\nOn Sat, Mar 30, 2019 at 4:56 AM Elijah Newren wrote:\n>\n> Overall this looks pretty good to me, just one question...\n>\n\n:)\n\n> > 5. `[Bonus]` --signoff\n>\n> --signoff is new and surprises me. What's the plan with that one?\n>\n\nI was reading the documentation of git-rebase[1], where I found that\n`--signoff` flag is not available for interactive backend, i.e., it is not\npossible to convert a commit into `Signed-off-by` commit while interactive\nrebasing.\n\nI though it might be a nice bonus to add, hence I listed it in \"the plan\".\n\nThanks\nRohit\n\n[1]: https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---signoff\n\n"},{"id":"372758","messageId":"CABPp-BEsqW61f4SWehTpFzMF97AzTUB_StOS83GAmZOC7QohSg@mail.gmail.com","threadId":"50576","inReplyTo":"20190329233407.13049-1-rohit.ashiwal265@gmail.com","subject":"Re: [GSoC][RFC v2] Improve consistency of sequencer commands","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-03-30T00:38:33Z","receivedAt":"2019-03-30T00:38:46Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Mar 29, 2019 at 4:35 PM Rohit Ashiwal\n wrote:\n>\n> Hi Elijah\n>\n> On Sat, Mar 30, 2019 at 4:56 AM Elijah Newren wrote:\n> >\n> > Overall this looks pretty good to me, just one question...\n> >\n>\n> :)\n>\n> > > 5. `[Bonus]` --signoff\n> >\n> > --signoff is new and surprises me. What's the plan with that one?\n> >\n>\n> I was reading the documentation of git-rebase[1], where I found that\n> `--signoff` flag is not available for interactive backend, i.e., it is not\n> possible to convert a commit into `Signed-off-by` commit while interactive\n> rebasing.\n\nI'm curious if you're looking at an old version of the documentation\n(...or maybe the documentation just isn't that clear?). Interactive\nrebases have supported --signoff since commit a852ec7f273c (\"rebase:\nextend --signoff support\", 2018-03-20)\n"},{"id":"372761","messageId":"CAP8UFD3b8wxj=T+HpeFAQNGLghs8fpEvQusP7Wq-BRZb3c50dg@mail.gmail.com","threadId":"50576","inReplyTo":"20190329223228.4924-1-rohit.ashiwal265@gmail.com","subject":"Re: [GSoC][RFC v2] Improve consistency of sequencer commands","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-03-30T07:16:10Z","receivedAt":"2019-03-30T07:16:27Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi Rohit,\n\nOn Fri, Mar 29, 2019 at 11:33 PM Rohit Ashiwal\n wrote:\n>\n> This is the v2 of the draft proposal[1]. I've added some details to the proposal,\n> it talks more about what to implement instead of how. It is still incomplete.\n>\n> I'm currently adding more to the overview section, where I'll document the work\n> done by Dscho and Alban. After that I'll find files that will be changed while\n> implementing rest of the flags, finally add the basic control and/or data flow\n> of the 'how' part.\n\nThe plan to improve it looks good to me.\n\n> ### List of Contributions at Git:\n>\n> Repo | Status | Title\n> -|-|-\n> [git/git][8] | Merged in 'next' branch | [Micro][3]**:** Use helper functions in test script\n\nIt would be nice to have a link to the last \"What's cooking in\ngit.git\" email from Junio so we can easily see the current status of\nyour patch/patch series.\n\n> [git-for-windows/git][9] | Merged and released | [#2077][4]**:** [FIX] git-archive error, gzip -cn : command not found.\n> [git-for-windows/build-extra][10] | Merged | [#235][5]**:** installer: Fix version of installer and installed file.\n>\n>\n> ## The Project\n>\n> ### _Improve consistency of sequencer commands_\n>\n> #### Overview\n>\n> Stephan Beyer \\ tried to introduce git-sequencer as his GSoC\n> 2008 [project][6] which executed a sequence of git instructions to \\ or\n> \\ and the sequence was given by a \\ or through `stdin`. The\n> git-sequencer wants to become the common backend for git-am, git-rebase and\n> other git commands. Unfortunately, most of the code did not get merged during\n> the SoC period but he continued his contributions to the project along with\n> Christian Couder \\ and then mentor Daniel Barkalow\n> \\.\n>\n> The project was continued by Ramkumar Ramachandra \\ in\n> [2011][7], converting it to a builtin and extending its domain to\n> git-cherry-pick.\n\nI don't think the sequencer has been converted into a builtin. I am\nnot sure why Ram wrote that he would do that in his proposal as I\ndon't think it was really a goal we had.\n\nBy the way, you might want to read the sequencer related article in\nhttps://git.github.io/rev_news/2016/10/19/edition-20/ for things that\nDscho did.\n\n> The learnings from all those works will serve as a huge headstart this year for\n> me.\n>\n> As of now, there are still some inconsistencies among these commands, e.g.,\n> there is no `--skip` flag in `git-cherry-pick` while one exists for\n> `git-rebase`. This project aims to remove inconsistencies in how the command\n> line options are handled.\n\n[...]\n\n> 5. `[Bonus]` As familiarity with the code increases, I might be able to implement\n> the feature of rewriting commits in time.\n\nI had to go back to the \"Points to work on\" section to understand what\nthis was about. Please describe what this is about in a clearer way.\n\n> 6. `[Bonus]` If everything goes well and time permits, discuss with the mentor(s)\n> the possibility of deprecating the am backend of rebase. This point is last to\n> work on as it provides no \"cosmetic\" difference on the user side. Elijah\n> [mentioned][12] the possibility of a \"social\" problem that might occur which shall\n> be discussed then.\n\nMaybe it would be interesting to see if there is a performance\ndifference between the 2 backends.\n\n[...]\n\n> #### Relevant Work\n>\n> Dscho and I had a talk on how a non-am backend should implement `git rebase\n> --whitespace=fix`, which he warned may become a large project (as it turns out\n> it is a sub-task in one of the [proposed ideas][11]), we were trying to\n> integrate this on git-for-windows first.\n>\n> Keeping warning in mind, I discussed this project with Rafael and he suggested\n> (with a little bit uncertainty in mind) that I should work on implementing a\n> git-diff flag that generates a patch that when applied, will remove whitespace\n> errors which I am currently working on.\n\nNice!\n"},{"id":"372763","messageId":"20190330084822.11285-1-rohit.ashiwal265@gmail.com","threadId":"50576","inReplyTo":"CABPp-BEsqW61f4SWehTpFzMF97AzTUB_StOS83GAmZOC7QohSg@mail.gmail.com","subject":"Re: [GSoC][RFC v2] Improve consistency of sequencer commands","fromName":"Rohit Ashiwal","fromEmail":"rohit.ashiwal265@gmail.com","sentAt":"2019-03-30T08:48:22Z","receivedAt":"2019-03-30T08:49:45Z","isPatch":false,"sender":{"key":"rohit.ashiwal265@gmail.com","avatar":"https://avatars.githubusercontent.com/u/31043830?v=4"},"body":"Hi Elijah\n\nOn 2019-03-30 0:38 UTC Elijah Newren wrote:\n\n> I'm curious if you're looking at an old version of the documentation\n> (...or maybe the documentation just isn't that clear?). Interactive\n> rebases have supported --signoff since commit a852ec7f273c (\"rebase:\n> extend --signoff support\", 2018-03-20)\n\nOh~ after having a quick look at my currently installed version of git,\nit was 2.17.1, which has outdated man pages :sweat_smile:. Yes, you are\ncorrect, I'm sorry.\n\nFeeling dumb\nRohit\n\n"},{"id":"372805","messageId":"CABPp-BFknrV8ALFTifcZ4-nzqy_yWO=7zdkemzcA2kfrZ+4_9A@mail.gmail.com","threadId":"50576","inReplyTo":"CAP8UFD3b8wxj=T+HpeFAQNGLghs8fpEvQusP7Wq-BRZb3c50dg@mail.gmail.com","subject":"Re: [GSoC][RFC v2] Improve consistency of sequencer commands","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-03-30T17:12:26Z","receivedAt":"2019-03-30T17:16:32Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Sat, Mar 30, 2019 at 12:16 AM Christian Couder\n wrote:\n\n> > 6. `[Bonus]` If everything goes well and time permits, discuss with the mentor(s)\n> > the possibility of deprecating the am backend of rebase. This point is last to\n> > work on as it provides no \"cosmetic\" difference on the user side. Elijah\n> > [mentioned][12] the possibility of a \"social\" problem that might occur which shall\n> > be discussed then.\n>\n> Maybe it would be interesting to see if there is a performance\n> difference between the 2 backends.\n\nYes, it may make sense to repeat\nhttps://public-inbox.org/git/nycvar.QRO.7.76.6.1901312310280.41@tvgsbejvaqbjf.bet/\nto verify we're still in a good state, and maybe even try to figure\nout why split-index is weird. However, more important is the handling\nof empty commits (both start-empty and become-empty) and trying to\nbring some consistency there or at least implementing more options for\nthe interactive backend and figuring out which empty-handling options\nshould be the default for which sets of flags. It's kind of a mess.\n"},{"id":"372807","messageId":"CABPp-BFdg8M17YuhKOrtTS3Xeyf2TQB1+vBzDVTo5EzMebyLEA@mail.gmail.com","threadId":"50576","inReplyTo":"20190330084822.11285-1-rohit.ashiwal265@gmail.com","subject":"Re: [GSoC][RFC v2] Improve consistency of sequencer commands","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-03-30T17:13:56Z","receivedAt":"2019-03-30T17:18:02Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Sat, Mar 30, 2019 at 1:49 AM Rohit Ashiwal\n wrote:\n>\n> Hi Elijah\n>\n> On 2019-03-30 0:38 UTC Elijah Newren wrote:\n>\n> > I'm curious if you're looking at an old version of the documentation\n> > (...or maybe the documentation just isn't that clear?). Interactive\n> > rebases have supported --signoff since commit a852ec7f273c (\"rebase:\n> > extend --signoff support\", 2018-03-20)\n>\n> Oh~ after having a quick look at my currently installed version of git,\n> it was 2.17.1, which has outdated man pages :sweat_smile:. Yes, you are\n> correct, I'm sorry.\n>\n> Feeling dumb\n> Rohit\n\nDon't feel dumb. I like the initiative. Also, since you highlighted\nit, there might be an issue with picking merge commits; either they\naren't affected by --signoff and should be, or the documentation\nshould be updated to mention they are handled too. So there is\nactually something here, I think.\n"},{"id":"373262","messageId":"20190405213100.9577-1-rohit.ashiwal265@gmail.com","threadId":"50576","inReplyTo":"CAL7ArXqkVfrnQWYFDYdwMGkZjHCwzyQX4pbKCo=KCzy-zJiRBw@mail.gmail.com","subject":"[GSoC][RFC v3] Proposal: Improve consistency of sequencer commands","fromName":"Rohit Ashiwal","fromEmail":"rohit.ashiwal265@gmail.com","sentAt":"2019-04-05T21:31:00Z","receivedAt":"2019-04-05T21:32:11Z","isPatch":false,"sender":{"key":"rohit.ashiwal265@gmail.com","avatar":"https://avatars.githubusercontent.com/u/31043830?v=4"},"body":"Hiya\n\nHere is one more iteration of my draft proposal[1]. RFC.\n\nThanks\nRohit\n\n[1]: https://gist.github.com/r1walz/5588d11065d5231ee451c0136400610e\n\n---------------------------------- >8 ------------------------------------------\n\n\n# Improve consistency of sequencer commands\n\n## About Me\n\n### Personal Information\n\nName | Rohit Ashiwal\n---------------|----------------------------------------------------------------\nMajor | Computer Science and Engineering\nE-mail | \\\nIRC | __rohit\nSkype | rashiwal\nPh no | [ ph_no ]\nGithub | [r1walz](https://github.com/r1walz/)\nLinkedin | [rohit-ashiwal](https://linkedin.com/in/rohit-ashiwal/)\nAddress | [ Address ]\nPostal Code | [ postal_code ]\nTime Zone | IST (UTC +0530)\n\n\n### Background\n\nI am a sophomore at the [Indian Institute of Technology Roorkee][1], pursuing my\nbachelor's degree in Computer Science and Engineering. I was introduced to\nprogramming at a very early stage of my life. Since then, I've been trying out\nnew technologies by taking up various projects and participating in contests. I\nam passionate about system software development and competitive programming, and\nI also actively contribute to open-source projects. At college, I joined the\nMobile Development Group ([MDG][2]), IIT Roorkee - a student group that fosters\nmobile development within the campus. I have been an active part of the Git\ncommunity since February of this year, contributing to git-for-windows.\n\n\n### Dev-Env\n\nI am fluent in C/C++, Java and Shell Scripting, otherwise, I can also program in\nPython, JavaScript. I use both Ubuntu 18.04 and Windows 10 x64 on my laptop. I\nprefer Linux for development unless the work is specific to Windows. \\\nVCS **:** git \\\nEditor **:** VS Code with gdb integrated\n\n\n## Contributions to Open Source\n\nMy contributions to open source have helped me gain experience in understanding\nthe flow of any pre-written code at a rapid pace and enabled me to edit/add new\nfeatures.\n\n### List of Contributions at Git:\n\nRepo |Status |Title\n----------------------------------|----------------------------|-----------------------------------------------------------------------\n[git/git][8] | [Will merge in master][13] | [Micro][3]**:** Use helper functions in test script\n[git-for-windows/git][9] | Merged and released | [#2077][4]**:** [FIX] git-archive error, gzip -cn : command not found.\n[git-for-windows/build-extra][10] | Merged and released | [#235][5]**:** installer: Fix version of installer and installed file.\n\n\n## The Project\n\n### _Improve consistency of sequencer commands_\n\n#### Overview\n\nSince when it was created in 2005, the `git rebase` command has been\nimplemented using shell scripts that are calling other git commands. Commands\nlike `git format-patch` to create a patch series for some commits, and then\n`git am` to apply the patch series on top of a different commit in case of\nregular rebase and the interactive rebase calls `git cherry-pick` repeatedly\nfor the same.\n\nNeither of these approaches has been very efficient though, and the main reason\nbehind that is that repeatedly calling a git command has a significant\noverhead. Even the regular git rebase would do that as `git am` had been\nimplemented by launching `git apply` on each of the patches.\n\nThe overhead is especially big on Windows where creating a new process is quite\nslow, but even on other Operating Systems it requires setting up everything\nfrom scratch, then reading the index from disk, and then, after performing some\nchanges, writing the index back to the disk.\n\nStephan Beyer \\ tried to introduce git-sequencer as his GSoC\n2008 [project][6] which executed a sequence of git instructions to \\ or\n\\ and the sequence was given by a \\ or through `stdin`. The\ngit-sequencer wants to become the common backend for git-am, git-rebase and\nother git commands, so as to improve performance, since then it eliminated the\nneed to spawn a new process.\n\nUnfortunately, most of the code did not get merged during the SoC period but he\ncontinued his contributions to the project along with Christian Couder\n\\ and then mentor Daniel Barkalow\n\\.\n\nThe project was continued by Ramkumar Ramachandra \\ in\n[2011][7], extending its domain to git-cherry-pick. The sequencer code got\nmerged and it was now possible to \"continue\" and \"abort\" when cherry-picking or\nreverting many commits.\n\nA patch series by Christian Couder \\ was merged in\n[2016][16] to the `master` branch that makes `git am` call `git apply`’s\ninternal functions without spawning the latter as a separate process. So the\nregular rebase will be significantly faster especially on Windows and for big\nrepositories in the next Git feature release.\n\nDespite the success (of GSoC '11), Dscho had to improve a lot of things to make\nit possible to reuse the sequencer in the interactive rebases making it faster.\nHis work can be found [here][15].\n\nThe learnings from all those works will serve as a huge headstart this year for\nme.\n\nAs of now, there are still some inconsistencies among these commands, e.g.,\nthere is no `--skip` flag in `git-cherry-pick` while one exists for\n`git-rebase`. This project aims to remove inconsistencies in how the command\nline options are handled.\n\n\n#### Points to work on:\n\n1. Suggest relevant flags for operations that have such a concept like\n `git cherry-pick --skip`\n2. Unify the suggestive messages of `git (cherry-pick|rebase-i)` with\n `git (am|rebase)`\n3. Implement flags that am-based rebases support, but not interactive,\n in interactive rebases, e.g.:\n```\n * --ignore-whitespace\n * --committer-date-is-author-date or --ignore-date\n * --whitespace=...\n * -C\n```\n4. Test and Documentation\n5. `[Bonus]` Make a flag to allow rebase to rewrite commit messages that\n refer to older commits that were also rebased\n6. `[Bonus]` Performance run on different backends of rebasing, if everything\n agrees, deprecate am-based rebases\n\n\n#### \"The Plan\"\n\n1. Start by introducing `git cherry-pick --skip`, this will help in step 2 of\n\"the plan\", since we are required to unify the advice messages that show during\nan interrupt of `git (cherry-pick|rebase -i)` when the incoming commit has\nbecome \"empty\" (no change between commits).\n\n **_Files changed_ :**\n - revert.c: Introduce option `--skip` under `run_sequencer()`\n\n2. There are two backends available for rebasing/cherry-picking, _viz_, the `am`\nand the `interactive`. Naturally, there shall be some features that are\nimplemented in one but not in the other. One such quality is suggestive\nmessages. The am-based rebases (and am itself) will give advice to the user to\nuse `git rebase --skip` (or `git am --skip`) when a patch isn't needed. In\ncontrast, interactive-based and cherry-pick will suggest the user `git reset`.\nChange this to match the message of `am` backend, so that everything appears\nsymmetric.\n\n **_Files changed_ :**\n - rebase.c: change flow so that `--skip` calls `git reset` while interactive\n rebasing\n - commit.c: change messages\n - sequencer.c: change suggestive message under `create_seq_dir()`\n\n3. Now that I'm familiar with the code, I'll start picking the pace now. And\nstart implementing the meat of the project. The flags. I'll start implementing\nthe flags in the following order as [Elijah suggested][12]:\n 1. --ignore-whitespace\n 2. --committer-date-is-author-date\n 3. --ignore-date\n 4. --whitespace=...\n\n **_Files changed_ :**\n - rebase: introduce the flag\n - builtin/rebase--interactive: introduce the flag under `cmd_rebase__interactive()`\n - change messages wherever required\n\n4. Testing and Documentation will go in sync with implementation. I intend to\nfollow `Test Driven Development` but let's see how it turns out.\n\n5. `[Bonus]` As familiarity with the code increases, I might be able to implement\na flag to allow rebase to rewrite commit messages that refer to older commits that\nwere also rebased in time.\n\n6. `[Bonus]` If everything goes well and time permits, discuss with the mentor(s)\nthe possibility of deprecating the am backend of rebase. This point is last to\nwork on as it provides no \"cosmetic\" difference on the user side. Elijah\n[mentioned][12] the possibility of a \"social\" problem that might occur which shall\nbe discussed then.\n\n\n#### Proposed Timeline\n\n+ Community Bonding (May 6th - May 26th):\n - Introduction to community\n - Get familiar with the dataflow\n - Study and understand the workflow and implementation of the project in\n detail\n\n+ Phase 1 (May 27th - June 23rd):\n - Start with implementing `git cherry-pick --skip`\n - Write new tests for the just introduced flag(s)\n - Analyse the requirements and differences of am-based and other rebases\n flags\n\n+ Phase 2 (June 24th - July 21st):\n - Introduce flags of am-based rebases to other kinds.\n - Add tests for the same.\n\n+ Phase 3 (July 22th - August 19th):\n - Act on [Bonus] features\n - Documentation\n - Clean up tasks\n\n\n#### Relevant Work\n\nDscho and I had a talk on how a non-am backend should implement `git rebase\n--whitespace=fix`, which he warned may become a large project (as it turns out\nit is a sub-task in one of the [proposed ideas][11]), we were trying to\nintegrate this on git-for-windows first.\n\nKeeping warning in mind, I discussed this project with Rafael and he suggested\n(with a little bit uncertainty in mind) that I should work on implementing a\ngit-diff flag that generates a patch that when applied, will remove whitespace\nerrors which I am currently working on.\n\n\n## Availability\n\nMy vacations start on 7 May and end on 15 July. The official GSoC period is from\n6 May to 19 August. I can easily devote 40-45 hours a week until my college\nreopens and 35-40 hours per week after that. I'm also free on the weekends and I\nintend to complete most of the work before my college reopens.\n\nOther than this project, I have no commitments/vacations planned for the summer.\nI shall keep my status posted to all the community members on a weekly basis and\nmaintain transparency in the project.\n\n## After GSoC\n\nEven after the Google Summer of Code, I plan on continuing my contributions to\nthis organization, by adding to my project and working on open issues or\nfeature requests. With the community growing continuously, I feel responsible\nfor all the projects I'm a part of. Having picked up a lot of developing skills,\nmy major focus would be to develop mentorship skills so that I can give back\nthis community by helping other people navigate around and reviewing\ncontributions.\n\n\n[0]: https://git.github.io/SoC-2019-Ideas/\n[1]: https://www.iitr.ac.in/\n[2]: http://mdg.iitr.ac.in/\n[3]: https://public-inbox.org/git/20190303122842.30380-1-rohit.ashiwal265@gmail.com/\n[4]: https://github.com/git-for-windows/git/pull/2077\n[5]: https://github.com/git-for-windows/build-extra/pull/235\n[6]: https://public-inbox.org/git/20080607220101.GM31040@leksak.fem-net/\n[7]: https://public-inbox.org/git/20110403172054.GA10220@kytes/\n[8]: https://github.com/git/git/commit/404110d2910aa617c7fb7e326694f8e085c5b2a0\n[9]: https://github.com/git-for-windows/git/commit/ed2b22adeb760d967c567c5664d33d5d641db10e\n[10]: https://github.com/git-for-windows/build-extra/commit/2e879f7fa5808f5f9cbfdd08ca456209f9ac5f1b\n[11]: https://git.github.io/SoC-2019-Ideas/#improve-consistency-of-sequencer-commands\n[12]: https://public-inbox.org/git/CABPp-BEdgSHGTkUcg_UDRu50Ag+cCqigmvU4_JaRZRnDpgWcdA@mail.gmail.com/\n[13]: https://public-inbox.org/git/xmqqr2aidpxw.fsf@gitster-ct.c.googlers.com/\n[14]: https://git.github.io/rev_news/2016/10/19/edition-20/\n[15]: https://public-inbox.org/git/cover.1472457609.git.johannes.schindelin@gmx.de/\n[16]: https://public-inbox.org/git/20160904201833.21676-1-chriscool@tuxfamily.org/\n"},{"id":"373344","messageId":"CAP8UFD12GXV80SVi5UR=mpBox9DFWw0Fp2wrf+1FEXbUdX1ReA@mail.gmail.com","threadId":"50576","inReplyTo":"20190405213100.9577-1-rohit.ashiwal265@gmail.com","subject":"Re: [GSoC][RFC v3] Proposal: Improve consistency of sequencer commands","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-04-07T07:15:30Z","receivedAt":"2019-04-07T07:16:08Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi Rohit,\n\nOn Fri, Apr 5, 2019 at 11:32 PM Rohit Ashiwal\n wrote:\n>\n> Here is one more iteration of my draft proposal[1]. RFC.\n\nNice, thanks for iterating on this!\n\nAs we are close to the deadline (April 9th) for proposal submissions,\nI think it's a good idea to already upload your draft proposal on the\nGSoC site. I think you will be able to upload newer versions until the\ndeadline, but uploading soon avoid possible last minute issues and\nmistakes.\n\nIn the version you upload, please add one or more links to the\ndiscussion of your proposal on the mailing list.\n\n> ### List of Contributions at Git:\n>\n> Repo |Status |Title\n> ----------------------------------|----------------------------|-----------------------------------------------------------------------\n> [git/git][8] | [Will merge in master][13] | [Micro][3]**:** Use helper functions in test script\n> [git-for-windows/git][9] | Merged and released | [#2077][4]**:** [FIX] git-archive error, gzip -cn : command not found.\n> [git-for-windows/build-extra][10] | Merged and released | [#235][5]**:** installer: Fix version of installer and installed file.\n\nNice!\n\n> #### Overview\n>\n> Since when it was created in 2005, the `git rebase` command has been\n> implemented using shell scripts that are calling other git commands. Commands\n> like `git format-patch` to create a patch series for some commits, and then\n> `git am` to apply the patch series on top of a different commit in case of\n> regular rebase and the interactive rebase calls `git cherry-pick` repeatedly\n> for the same.\n>\n> Neither of these approaches has been very efficient though, and the main reason\n> behind that is that repeatedly calling a git command has a significant\n> overhead. Even the regular git rebase would do that as `git am` had been\n> implemented by launching `git apply` on each of the patches.\n>\n> The overhead is especially big on Windows where creating a new process is quite\n> slow, but even on other Operating Systems it requires setting up everything\n> from scratch, then reading the index from disk, and then, after performing some\n> changes, writing the index back to the disk.\n>\n> Stephan Beyer \\ tried to introduce git-sequencer as his GSoC\n> 2008 [project][6] which executed a sequence of git instructions to \\ or\n> \\ and the sequence was given by a \\ or through `stdin`. The\n> git-sequencer wants to become the common backend for git-am, git-rebase and\n> other git commands, so as to improve performance, since then it eliminated the\n> need to spawn a new process.\n>\n> Unfortunately, most of the code did not get merged during the SoC period but he\n> continued his contributions to the project along with Christian Couder\n> \\ and then mentor Daniel Barkalow\n> \\.\n>\n> The project was continued by Ramkumar Ramachandra \\ in\n> [2011][7], extending its domain to git-cherry-pick. The sequencer code got\n> merged and it was now possible to \"continue\" and \"abort\" when cherry-picking or\n> reverting many commits.\n>\n> A patch series by Christian Couder \\ was merged in\n> [2016][16] to the `master` branch that makes `git am` call `git apply`’s\n> internal functions without spawning the latter as a separate process. So the\n> regular rebase will be significantly faster especially on Windows and for big\n> repositories in the next Git feature release.\n\nIt looks like you copy pasted the Git Rev News article without\nupdating the content. The improvement has been released a long time\nago.\n\n> Despite the success (of GSoC '11), Dscho had to improve a lot of things to make\n> it possible to reuse the sequencer in the interactive rebases making it faster.\n\nMaybe s/rebases/rebase/\n\n> His work can be found [here][15].\n\nIt seems to me that there has been more recent work than this and also\nperhaps interesting suggestions and discussions about possible\nsequencer related improvements on the mailing list.\n\n> The learnings from all those works will serve as a huge headstart this year for\n> me.\n>\n> As of now, there are still some inconsistencies among these commands, e.g.,\n> there is no `--skip` flag in `git-cherry-pick` while one exists for\n> `git-rebase`. This project aims to remove inconsistencies in how the command\n> line options are handled.\n"},{"id":"373349","messageId":"20190407121640.3737-1-rohit.ashiwal265@gmail.com","threadId":"50576","inReplyTo":"CAP8UFD12GXV80SVi5UR=mpBox9DFWw0Fp2wrf+1FEXbUdX1ReA@mail.gmail.com","subject":"Re: [GSoC][RFC v3] Proposal: Improve consistency of sequencer commands","fromName":"Rohit Ashiwal","fromEmail":"rohit.ashiwal265@gmail.com","sentAt":"2019-04-07T12:16:40Z","receivedAt":"2019-04-07T12:17:49Z","isPatch":false,"sender":{"key":"rohit.ashiwal265@gmail.com","avatar":"https://avatars.githubusercontent.com/u/31043830?v=4"},"body":"Hey Chris!\n\nOn Sun, 7 Apr 2019 09:15:30 +0200 Christian Couder wrote:\n\n> As we are close to the deadline (April 9th) for proposal submissions,\n> I think it's a good idea to already upload your draft proposal on the\n> GSoC site. I think you will be able to upload newer versions until the\n> deadline, but uploading soon avoid possible last minute issues and\n> mistakes.\n\nSure, I'll upload my proposal as soon as possible.\n\n> It looks like you copy pasted the Git Rev News article without\n> updating the content. The improvement has been released a long time\n> ago.\n\nThe intention was to document how the project started and *major* milestones or\nturning points of the project. Here they are.\n\n> Maybe s/rebases/rebase/\n\nYes, :P\n\n> It seems to me that there has been more recent work than this and also\n> perhaps interesting suggestions and discussions about possible\n> sequencer related improvements on the mailing list.\n\nAgain the idea was to document earlier stages of project, \"recent\" discussions\nhave been on the optimizations which are not exactly relevant.\n\nShould I write more about recent developments?\n\nRegards\nRohit\n\n"},{"id":"373376","messageId":"CAP8UFD05JDsh2v15GgP+LpPKVAK-Dg4k0aicScY5p=za4gsTGw@mail.gmail.com","threadId":"50576","inReplyTo":"20190407121640.3737-1-rohit.ashiwal265@gmail.com","subject":"Re: [GSoC][RFC v3] Proposal: Improve consistency of sequencer commands","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-04-07T23:07:53Z","receivedAt":"2019-04-07T23:08:33Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi Rohit,\n\nOn Sun, Apr 7, 2019 at 2:17 PM Rohit Ashiwal wrote:\n>\n> On Sun, 7 Apr 2019 09:15:30 +0200 Christian Couder wrote:\n>\n> > As we are close to the deadline (April 9th) for proposal submissions,\n> > I think it's a good idea to already upload your draft proposal on the\n> > GSoC site. I think you will be able to upload newer versions until the\n> > deadline, but uploading soon avoid possible last minute issues and\n> > mistakes.\n>\n> Sure, I'll upload my proposal as soon as possible.\n\nGreat!\n\n> > It looks like you copy pasted the Git Rev News article without\n> > updating the content. The improvement has been released a long time\n> > ago.\n>\n> The intention was to document how the project started and *major* milestones or\n> turning points of the project. Here they are.\n\nYeah, the intention is good, though it would be nice if the details\nwere a bit more polished.\n\n> > Maybe s/rebases/rebase/\n>\n> Yes, :P\n>\n> > It seems to me that there has been more recent work than this and also\n> > perhaps interesting suggestions and discussions about possible\n> > sequencer related improvements on the mailing list.\n>\n> Again the idea was to document earlier stages of project, \"recent\" discussions\n> have been on the optimizations which are not exactly relevant.\n\nI think there were ideas (from Elijah) about using the sequencer in\nthe regular (non interactive) rebase too.\n\n> Should I write more about recent developments?\n\nI think Alban's GSoC project was relevant too.\n\nSo yeah, if you have time after uploading your proposal to the GSoC\nweb site, it would be nice if you can update it with a bit more\ninformation about what happened recently.\n\nThanks,\nChristian.\n"}]}