[GSoC] Introduction

[GSoC] Introduction

[Rohit Ashiwal]

Hello
I am Rohit Ashiwal, a computer science and engineering student from
IIT Roorkee. I am a git user for 2 years now and want to contribute
towards its development.
I have read the microproject list available [here](1) and project
titled `Use test_path_is_*  functions in test scripts` caught my eye.
I want to work on this one if anyone is not working on it (I was not
able to find related threads on public-inbox).
I am somewhat familiar with git's code as I was previously working on
git-for-windows and I have solved 1 [issue](2), which is a reason for
my concern. Should this count as a microproject? As the webpage
instructs us to work only on 1 microproject.
If you disregard that contribution, here is my approach to solving
this microproject: search for `test -f` in `t/**` and replace all
occurrences with `test_path_is_file` and similarly for other mentioned
commands. Is it correct?

Regards
Rohit Ashiwal

[1]: https://git.github.io/SoC-2019-Microprojects/
[2]: https://github.com/git-for-windows/git/issues/1970

Re: [GSoC] Introduction

[Johannes Schindelin]

Hi Rohit,

On Sun, 24 Feb 2019, Rohit Ashiwal wrote:

> Hello

Hi there!

> I am Rohit Ashiwal, a computer science and engineering student from
> IIT Roorkee. I am a git user for 2 years now and want to contribute
> towards its development.

Great!

> I have read the microproject list available [here](1) and project
> titled `Use test_path_is_*  functions in test scripts` caught my eye.
> I want to work on this one if anyone is not working on it (I was not
> able to find related threads on public-inbox).

Go for it ;-) The microprojects are basically a straight-forward way to
introduce prospective GSoC students to Git's code contribution process.

In that sense, while it would be better for students not to have
overlapping microprojects, it is not the end of the world, either.

In your case, it is relatively easy to figure out that no other student
mentioned this project on the Git mailing list:
https://public-inbox.org/git/?q=test_path_is_file

> I am somewhat familiar with git's code as I was previously working on
> git-for-windows and I have solved 1 [issue](2), which is a reason for
> my concern. Should this count as a microproject? As the webpage
> instructs us to work only on 1 microproject.

True. You could brush up that pair of patches to teach `git archive` to
avoid spawning `gzip` when generating `.tar.gz` archives, and submit them
using the process suggested in https://git-scm.com/docs/SubmittingPatches.

(You might want to make it easier on yourself and use GitGitGadget, which
takes out the challenge of sending patches in the required format via
email, see https://gitgitgadget.github.io/ for details.)

On the other hand, it might make more sense to start afresh with the
test_path_is_* microproject, as I already took custody of your patches and
planned on submitting them (via GitGitGadget) right after v2.21.0 comes
out.

> If you disregard that contribution, here is my approach to solving
> this microproject: search for `test -f` in `t/**` and replace all
> occurrences with `test_path_is_file` and similarly for other mentioned
> commands. Is it correct?

This is a good first step, indeed. You may want to be careful about it,
though, as there *might* be instances where replacing the `test -f` would
not make sense (such as instances where scripts are written via
`write_script`, and those scripts would not have access to the
`test_path_is_file` function).

You probably also want to inspect instances of `test -e` (which
technically only ask whether a path exists, whether it is a file, a
directory, or a symbolic link), as it might be possible that some tests
use that invocation when they really want to ask whether a file exists.

Then, you want to also look for `test -d` for the `test_path_is_dir`
conversion.

Good luck,
Johannes

Re: [GSoC] Introduction

[Christian Couder]

Hi Rohit,

On Sun, Feb 24, 2019 at 11:08 AM Rohit Ashiwal
<rohit.ashiwal265@gmail.com> wrote:

> If you disregard that contribution, here is my approach to solving
> this microproject: search for `test -f` in `t/**` and replace all
> occurrences with `test_path_is_file` and similarly for other mentioned
> commands. Is it correct?

In addition to what Dscho (alias Johannes Schindelin) wrote, please
just send one patch that replaces `test -d`, `test -d` and similar
code in only one t/tXXXX-*.sh file. No need to do more than that.

Thanks,
Christian.

Re: [GSoC] Introduction

[Rohit Ashiwal]

Hey Christian

On Mon, Feb 25, 2019 at 12:20 PM Christian Couder
<christian.couder@gmail.com> wrote:

> In addition to what Dscho (alias Johannes Schindelin) wrote, please
> just send one patch that replaces `test -d`, `test -d` and similar
> code in only one t/tXXXX-*.sh file. No need to do more than that.

I don't think I quite understood this. Were you asking for replacing
all `test -X` calls with `test_path_is_*` calls in only one tXXXX-*.sh
file or `test -d` calls with `test_path_is_dir` in all tXXXX-*.sh? As
of now, I've changed almost all `test -d` in all relevant tXXXX-*.sh
files.

Thanks
Rohit

Re: [GSoC] Introduction

[Christian Couder]

Hi Rohit,

On Mon, Feb 25, 2019 at 12:36 PM Rohit Ashiwal
<rohit.ashiwal265@gmail.com> wrote:
>
> Hey Christian
>
> On Mon, Feb 25, 2019 at 12:20 PM Christian Couder
> <christian.couder@gmail.com> wrote:
>
> > In addition to what Dscho (alias Johannes Schindelin) wrote, please
> > just send one patch that replaces `test -d`, `test -d` and similar
> > code in only one t/tXXXX-*.sh file. No need to do more than that.
>
> I don't think I quite understood this. Were you asking for replacing
> all `test -X` calls with `test_path_is_*` calls in only one tXXXX-*.sh
> file or `test -d` calls with `test_path_is_dir` in all tXXXX-*.sh? As
> of now, I've changed almost all `test -d` in all relevant tXXXX-*.sh
> files.

First on the micro-project page
(https://git.github.io/SoC-2019-Microprojects/) there is "Please
attempt only ONE microproject. We want quality, not quantity!"

And the description of the micro-project you selected is:

"Find a test script that verifies the presence/absence of
files/directories with ‘test -(e|f|d|…)’ and replace them with the
appropriate test_path_is_file, test_path_is_dir, etc. helper
functions."

This asks you to change only 1 test script, that is one t/tXXXX-*.sh file only.

So yes I am asking for replacing all `test -X` calls with
`test_path_is_*` calls in only one tXXXX-*.sh file.

Thanks,
Christian.

Re: [GSoC] Introduction

[Eric Sunshine]

On Mon, Feb 25, 2019 at 3:22 PM Christian Couder
<christian.couder@gmail.com> wrote:
> On Mon, Feb 25, 2019 at 12:36 PM Rohit Ashiwal
> <rohit.ashiwal265@gmail.com> wrote:
> > I don't think I quite understood this. Were you asking for replacing
> > all `test -X` calls with `test_path_is_*` calls in only one tXXXX-*.sh
> > file or `test -d` calls with `test_path_is_dir` in all tXXXX-*.sh? As
> > of now, I've changed almost all `test -d` in all relevant tXXXX-*.sh
> > files.
>
> So yes I am asking for replacing all `test -X` calls with
> `test_path_is_*` calls in only one tXXXX-*.sh file.

Not stated outright, but an important reason for limiting the scope of
this change (and, indeed, the scope of any patch series) is to ease
the burden on people who review your submission. Large patch series
tend to tax reviewers heavily, even (and often) when repetitive and
simple, like replacing `test -d` with `test_path_is_dir()`. The
shorter and more concise a patch series is, the more likely that it
will receive quality reviews.

Another reason for keeping the scope of changes limited is to ease the
burden of the project maintainer. Patch series which touch a lot of
areas tend to conflict with in-flight topics from other people, and
the project maintainer has to juggle and resolve these problems.
Concise patch series, on the other hand, are less likely to conflict
with changes elsewhere.

[GSoC][RFC] Proposal: Improve consistency of sequencer commands

[Rohit Ashiwal]

Hey People

I am Rohit Ashiwal and here my first draft of the proposal for the project
titled: `Improve consistency of sequencer commands' this summer. I need your
feedback and more than that I need help to improve the timeline of this
proposal since it looks very weak. Basically, it lacks the "how" component
as I don't know much about the codebase in detail.

Thanks
Rohit

PS: Point one is missing in the timeline from the ideas page[0], can someone
    explain what exactly it wants?


######################################################################################
                  Improve consistency of sequencer commands
######################################################################################


About Me
========

Personal Information
---------------+-----------------------------------------------------------------------
Name           |     Rohit Ashiwal
Major          |     Computer Science and Engineering
E-mail         |     rohit.ashiwal265@gmail.com
IRC            |     __rohit
Skype          |     rashiwal
Ph no          |     [ ph_no ]
Github         |     r1walz
Linkedin       |     rohit-ashiwal
Address        |     [                             Address                            ]
Postal Code    |     [ postal_code ]
Time Zone      |     IST (UTC +0530)
---------------+-----------------------------------------------------------------------


Background
----------
I am a sophomore at the Indian Institute of Technology Roorkee[1], pursuing
my bachelor's degree in Computer Science and Engineering. I was introduced
to programming at a very early stage of my life. Since then, Ive been trying
out new technologies by taking up various projects and participating in contests.
I am passionate about system software development and competitive programming,
and I also actively contribute to open-source projects. At college, I joined
the Mobile Development Group [MDG](2), IIT Roorkee - a student group that fosters
mobile development within the campus. I have been an active part of the Git
community since February of this year, contributing to git-for-windows.


Dev-Env
-------
I am fluent in C/C++, Java and Shell Scripting, otherwise, I can also program
in Python, JavaScript. I use both Ubuntu 18.04 and Windows 10 x64 on my laptop.
I prefer Linux for development unless the work is specific to Windows.
VCS: 	git
Editor: VS Code with gdb integrated


Contributions to Open Source
============================
My contributions to open source have helped me gain experience in understanding
the flow of any pre-written code at a rapid pace and enabled me to edit/add new
features.

List of Contributions at Git:
-----------------------------
Status: Merge in next revision
git/git:
[Micro](3): Use helper functions in test script.

Status: Merged
git-for-windows/git:
[#2077](4): [FIX] git-archive error, gzip -cn : command not found.

Status: Merged
git-for-windows/build-extra:
[#235](5): installer: Fix version of installer and installed file.


The Project: `Improve consistency of sequencer commands'
========================================================

Overview
--------
git-sequencer was introduced by Stephan Beyer <s-beyer@gmx.net> as his
GSoC 2008 project[6]. It 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. The project was continued by Ramkumar <artagnon@gmail.com>
in 2011[7], converting it to a builtin and extending its domain to git-cherry-pick.
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.


Points to work on:
------------------
    - Add `git cherry-pick --skip` 
    - Implement flags that am-based rebases support, but not interactive
	  or merge based, in interactive/merge based rebases
    - [Bonus] Deprecate am-based rebases
    - [Bonus] Make a flag to allow rebase to rewrite commit messages that
	  refer to older commits that were also rebased


Proposed Timeline
-----------------
    + Community Bonding (May 6th - May 26th):
        - Introduction to community
        - Get familiar with the workflow
        - Study and understand the workflow and implementation of the project in detail

    + Phase 1  (May 27th - June 23rd):
        - Start with implementing `git cherry-pick --skip`
        - Write new tests for the just introduced flag(s)
        - Analyse the requirements and differences of am-based and other rebases flags

    + Phase 2  (June 24th - July 21st):
        - Introduce flags of am-based rebases to other kinds.
        - Add tests for the same.

    + Phase 3  (July 22th - August 19th):
        - Act on [Bonus] features
        - Documentation
        - Clean up tasks


Relevant Work
=============
Dscho and I had a talk on how a non-am backend should implement `git rebase
--whitespace=fix`, which he warned may become a large project (as it turns
out it is a sub-task in one of the proposed ideas[0]), we were trying to
integrate this on git-for-windows first.
Keeping warning in mind, I discussed this project with Rafael and he suggested
(with a little bit uncertainty in mind) that I should work on implementing
a git-diff flag that generates a patch that when applied, will remove whitespace
errors which I am currently working on.


Availability
============
My vacations start on 7 May and end on 15 July. The official GSoC period
is from 6 May to 19 August. I can easily devote 40-45 hours a week until
my college reopens and 35-40 hours per week after that. Im also free on
the weekends and I intend to complete most of the work before my college
reopens.

Other than this project, I have no commitments/vacations planned for the
summer. I shall keep my status posted to all the community members on a
weekly basis and maintain transparency in the project.


After GSoC
==========
Even after the Google Summer of Code, I plan on continuing my contributions
to this organization, by adding to my project  and working on open issues
or feature requests. With the community growing continuously, I feel
responsible for all the projects Im a part of. Having picked up a lot of
developing skills, my major focus would be to develop mentorship skills so
that I can give back to this community by helping other people navigate
around and reviewing their contributions.


[0]: https://git.github.io/SoC-2019-Ideas/
[1]: https://www.iitr.ac.in/
[2]: http://mdg.iitr.ac.in/
[3]: https://public-inbox.org/git/20190303122842.30380-1-rohit.ashiwal265@gmail.com/
[4]: https://github.com/git-for-windows/git/pull/2077
[5]: https://github.com/git-for-windows/build-extra/pull/235
[6]: https://public-inbox.org/git/20080607220101.GM31040@leksak.fem-net/
[7]: https://public-inbox.org/git/20110403172054.GA10220@kytes/

Re: [GSoC][RFC] Proposal: Improve consistency of sequencer commands

[Christian Couder]

Hi Rohit,

On Fri, Mar 22, 2019 at 4:12 PM Rohit Ashiwal
<rohit.ashiwal265@gmail.com> wrote:
>
> Hey People
>
> I am Rohit Ashiwal and here my first draft of the proposal for the project
> titled: `Improve consistency of sequencer commands' this summer. I need your
> feedback and more than that I need help to improve the timeline of this
> proposal since it looks very weak. Basically, it lacks the "how" component
> as I don't know much about the codebase in detail.
>
> Thanks
> Rohit
>
> PS: Point one is missing in the timeline from the ideas page[0], can someone
>     explain what exactly it wants?

You mean this point from the idea page:

"The suggestion to fix an interrupted rebase-i or cherry-pick due to a
commit that became empty via git reset HEAD (in builtin/commit.c)
instead of git rebase --skip or git cherry-pick --skip ranges from
annoying to confusing. (Especially since other interrupted am’s and
rebases both point to am/rebase –skip.). Note that git cherry-pick
--skip is not yet implemented, so that would have to be added first."

or something else?

By the way it is not very clear if the proposal uses markdown or
another related format and if it is also possible (and perhaps even
better visually) to see it somewhere else (maybe on GitHub). If that's
indeed possible, please provide a link. It is a good thing though to
still also send it attached to an email, so that it can be easily
reviewed and commented on by people who prefer email discussions.

> List of Contributions at Git:
> -----------------------------
> Status: Merge in next revision

Maybe "Merged into the 'next' branch"

> git/git:
> [Micro](3): Use helper functions in test script.

Please give more information than that, for example you could point to
the commit in the next branch on GitHub and perhaps to the what's
cooking email from Junio where it can be seen that the patch has been
merged into next and what's its current status.

> Status: Merged
> git-for-windows/git:
> [#2077](4): [FIX] git-archive error, gzip -cn : command not found.
>
> Status: Merged
> git-for-windows/build-extra:
> [#235](5): installer: Fix version of installer and installed file.

For Git for Windows contributions I think a link to the pull request
is enough. It could be nice to know though if the commits are part of
a released version.

> The Project: `Improve consistency of sequencer commands'
> ========================================================
>
> Overview
> --------
> git-sequencer was introduced by Stephan Beyer <s-beyer@gmx.net> as his
> GSoC 2008 project[6]. It 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. The project was continued by Ramkumar <artagnon@gmail.com>
> in 2011[7], converting it to a builtin and extending its domain to git-cherry-pick.

Yeah, you can say that it was another GSoC project and maybe give his
full name (Ramkumar Ramachandra).

There have been more related work to extend usage of the sequencer
after these GSoC projects, at least from Dscho and maybe from Alban
Gruin and Elijah too. I would be nice if you could document that a
bit.

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


> Points to work on:
> ------------------
>     - Add `git cherry-pick --skip`
>     - Implement flags that am-based rebases support, but not interactive
>           or merge based, in interactive/merge based rebases

Maybe the flags could be listed.

>     - [Bonus] Deprecate am-based rebases
>     - [Bonus] Make a flag to allow rebase to rewrite commit messages that
>           refer to older commits that were also rebased

This part of your proposal ("Points to work on") looks weak to me.

Please try to add more details about what you plan to do, how you
would describe the new flags in the documentation, which *.c *.h and
test files might be changed, etc.

> Proposed Timeline
> -----------------
>     + Community Bonding (May 6th - May 26th):
>         - Introduction to community
>         - Get familiar with the workflow
>         - Study and understand the workflow and implementation of the project in detail
>
>     + Phase 1  (May 27th - June 23rd):
>         - Start with implementing `git cherry-pick --skip`
>         - Write new tests for the just introduced flag(s)
>         - Analyse the requirements and differences of am-based and other rebases flags
>
>     + Phase 2  (June 24th - July 21st):
>         - Introduce flags of am-based rebases to other kinds.
>         - Add tests for the same.
>
>     + Phase 3  (July 22th - August 19th):
>         - Act on [Bonus] features
>         - Documentation
>         - Clean up tasks
>
>
> Relevant Work
> =============
> Dscho and I had a talk on how a non-am backend should implement `git rebase
> --whitespace=fix`, which he warned may become a large project (as it turns
> out it is a sub-task in one of the proposed ideas[0]), we were trying to
> integrate this on git-for-windows first.
> Keeping warning in mind, I discussed this project with Rafael and he suggested
> (with a little bit uncertainty in mind) that I should work on implementing
> a git-diff flag that generates a patch that when applied, will remove whitespace
> errors which I am currently working on.

You mean Rafael Ascensão? Please CC him if he is involved in this.

Thanks,
Christian.

Re: [GSoC][RFC] Proposal: Improve consistency of sequencer commands

[Elijah Newren]

Hi Rohit!

On Fri, Mar 22, 2019 at 8:12 AM Rohit Ashiwal
<rohit.ashiwal265@gmail.com> wrote:
>
> Hey People
>
> I am Rohit Ashiwal and here my first draft of the proposal for the project
> titled: `Improve consistency of sequencer commands' this summer. I need your
> feedback and more than that I need help to improve the timeline of this
> proposal since it looks very weak. Basically, it lacks the "how" component
> as I don't know much about the codebase in detail.
>
> Thanks
> Rohit
>
> PS: Point one is missing in the timeline from the ideas page[0], can someone
>     explain what exactly it wants?

I don't understand the question; could you restate it?

> Points to work on:
> ------------------
>     - Add `git cherry-pick --skip`

I'd reword this section as 'Consistently suggest --skip for operations
that have such a concept'.[1]

Adding a --skip flag to cherry-pick is useful, but was only meant as a
step.  Let me explain in more detail and use another comparison point.
Each of the git commands cherry-pick, merge, rebase take the flags
"--continue" and "--abort"; but they didn't always do so and so
continuing or aborting an operation often used special case-specific
commands for each (e.g. git reset --hard (or later --merge) to abort a
merge, git commit to continue it, etc.)  Those commands don't
necessarily make sense to users, whereas '<operation> --continue' and
'<operation> --abort' do make intuitive sense and is thus memorable.
We want the same for --skip.

Both am-based rebases and am itself will give advice to the user to
use 'git rebase --skip' or 'git am --skip' when a patch isn't needed.
That's good.  In contrast, interactive-based rebases and cherry-pick
will suggest that the user run 'git reset' (with no arguments). The
place that suggests that command should instead suggest either 'git
rebase --skip' or 'git cherry-pick --skip', depending on which
operation is in progress.  The first step for doing that, is making
sure that cherry-pick actually has a '--skip' option.

>     - Implement flags that am-based rebases support, but not interactive
>           or merge based, in interactive/merge based rebases

The "merge-based" rebase backend was deleted in 2.21.0, with all its
special flags reimplemented on the top of the interactive backend.  So
we can omit the deleted backend from the descriptions (instead just
talk about the am-based and interactive backends).

>     - [Bonus] Deprecate am-based rebases
>     - [Bonus] Make a flag to allow rebase to rewrite commit messages that
>           refer to older commits that were also rebased

I'd reorder these two.  I suspect the second won't be too hard and
will provide a new user-visible feature, while the former will
hopefully not be visible to users; if the former has more than
cosmetic differences visible to user, it might transform the problem
into more of a social problem than a technical one or just make into
something we can't do.

> Proposed Timeline
> -----------------
>     + Community Bonding (May 6th - May 26th):
>         - Introduction to community
>         - Get familiar with the workflow
>         - Study and understand the workflow and implementation of the project in detail
>
>     + Phase 1  (May 27th - June 23rd):
>         - Start with implementing `git cherry-pick --skip`
>         - Write new tests for the just introduced flag(s)
>         - Analyse the requirements and differences of am-based and other rebases flags

Writing or finding tests to trigger all the --skip codepaths might be
the biggest part of this phase.  Implementing `git cherry-pick --skip`
just involves making it run the code that `git reset` invokes.  The
you change the error message to reference `<command> --skip` instead
of `git reset`.  What you're calling phase 1 here isn't quite
microproject sized, but it should be relatively quick and easy; I'd
plan to spend much more of your time on phase 2.

>     + Phase 2  (June 24th - July 21st):
>         - Introduce flags of am-based rebases to other kinds.
>         - Add tests for the same.

You should probably mention the individual cases from "INCOMPATIBLE
FLAGS" of the git rebase manpage.  Also, some advice for order of
tackling these: I think you should probably do --ignore-whitespace
first; my guess is that one is the easiest.  Close up would be
--committer-date-is-author-date and --ignore-date.  Re-reading, I'm
not sure -C even makes sense at all; it might be that the solution is
just accepting the flag and ignoring it, or perhaps it remains the one
flag the interactive backend won't support, or maybe there is
something that makes sense to be done.  There'd need to be a little
investigation for that one, but it might turn out simple too.  The
--whitespace={nowarn|warn|fix|error|error-all} flag will be the
kicker.  I don't know how long that one will take, but I'm certain
it's harder than the other flags and it might conceivably take up most
the summer or even extend beyond.

>     + Phase 3  (July 22th - August 19th):
>         - Act on [Bonus] features
>         - Documentation
>         - Clean up tasks

I'd prefer that Documentation updates were made as you went; you'll
particularly need to look at Documentation/git-cherry-pick.txt and
Documentation/rebase.txt, especially the "INCOMPATIBLE OPTIONS" and
"BEHAVIORAL DIFFERENCES" sections of the latter.

Also, as far as timing goes, the rewriting of commit messages seems
relatively straightforward; you may want to consider doing it before
the --whitespace flag (despite the fact that I originally suggested it
as a bonus item).  Deprecating am-based rebases, on the other hand, is
a bit of a wildcard.  It depends on Phase 2 being completed so it
definitely makes sense to be last.  If phase 2 is complete, it's
conceivable that deprecating am-based rebases only takes a little more
work, but it might expand to use up a lot of time.

> Relevant Work
> =============
> Dscho and I had a talk on how a non-am backend should implement `git rebase
> --whitespace=fix`, which he warned may become a large project (as it turns
> out it is a sub-task in one of the proposed ideas[0]), we were trying to
> integrate this on git-for-windows first.
> Keeping warning in mind, I discussed this project with Rafael and he suggested
> (with a little bit uncertainty in mind) that I should work on implementing
> a git-diff flag that generates a patch that when applied, will remove whitespace
> errors which I am currently working on.

It's awesome that you're looking in to this, but it may make more
sense to knock out the easy parts of this project first.  That way the
project gets some value out of your work for sure, you gain confidence
and familiarity with the codebase, and then you can tackle the more
difficult items.  Of course, if you're just exploring to learn what's
possible in order to write the proposal, that's fine, I just think
once you start on this project, it'd make more sense to do the easier
ones first.


Hope that helps,
Elijah

Re: [GSoC][RFC] Proposal: Improve consistency of sequencer commands

[Rohit Ashiwal]

Hi Christian

On 2019-03-23 22:17 UTC Christian Couder <> wrote:
> On Fri, Mar 22, 2019 at 4:12 PM Rohit Ashiwal
> <rohit.ashiwal265@gmail.com> wrote:
> >
> > Hey People
> >
> > I am Rohit Ashiwal and here my first draft of the proposal for the project
> > titled: `Improve consistency of sequencer commands' this summer. I need your
> > feedback and more than that I need help to improve the timeline of this
> > proposal since it looks very weak. Basically, it lacks the "how" component
> > as I don't know much about the codebase in detail.
> >
> > Thanks
> > Rohit
> >
> > PS: Point one is missing in the timeline from the ideas page[0], can someone
> >     explain what exactly it wants?
> 
> You mean this point from the idea page:
> 
> "The suggestion to fix an interrupted rebase-i or cherry-pick due to a
> commit that became empty via git reset HEAD (in builtin/commit.c)
> instead of git rebase --skip or git cherry-pick --skip ranges from
> annoying to confusing. (Especially since other interrupted am’s and
> rebases both point to am/rebase –skip.). Note that git cherry-pick
> --skip is not yet implemented, so that would have to be added first."

Yes.

> or something else?
> 
> By the way it is not very clear if the proposal uses markdown or
> another related format and if it is also possible (and perhaps even
> better visually) to see it somewhere else (maybe on GitHub). If that's
> indeed possible, please provide a link. It is a good thing though to
> still also send it attached to an email, so that it can be easily
> reviewed and commented on by people who prefer email discussions.

This was intentional. Here is the link of the proposal hosted at gist.github.com[1],
those who prefer text only version here[2] is mailing list link.

> > List of Contributions at Git:
> > -----------------------------
> > Status: Merge in next revision
> 
> Maybe "Merged into the 'next' branch"
> 
> > git/git:
> > [Micro](3): Use helper functions in test script.
> 
> Please give more information than that, for example you could point to
> the commit in the next branch on GitHub and perhaps to the what's
> cooking email from Junio where it can be seen that the patch has been
> merged into next and what's its current status.

Current proposal has added links to those commits.

> > Status: Merged
> > git-for-windows/git:
> > [#2077](4): [FIX] git-archive error, gzip -cn : command not found.

This was released in v2.21.0 [3]

> > Status: Merged
> > git-for-windows/build-extra:
> > [#235](5): installer: Fix version of installer and installed file.
> 
> For Git for Windows contributions I think a link to the pull request
> is enough. It could be nice to know though if the commits are part of
> a released version.

> > The Project: `Improve consistency of sequencer commands'
> > ========================================================
> >
> > Overview
> > --------
> > git-sequencer was introduced by Stephan Beyer <s-beyer@gmx.net> as his
> > GSoC 2008 project[6]. It 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. The project was continued by Ramkumar <artagnon@gmail.com>
> > in 2011[7], converting it to a builtin and extending its domain to git-cherry-pick.
> 
> Yeah, you can say that it was another GSoC project and maybe give his
> full name (Ramkumar Ramachandra).
> 
> There have been more related work to extend usage of the sequencer
> after these GSoC projects, at least from Dscho and maybe from Alban
> Gruin and Elijah too. I would be nice if you could document that a
> bit.
> 
> > 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.
> 
> 
> > Points to work on:
> > ------------------
> >     - Add `git cherry-pick --skip`
> >     - Implement flags that am-based rebases support, but not interactive
> >           or merge based, in interactive/merge based rebases
> 
> Maybe the flags could be listed.
> 
> >     - [Bonus] Deprecate am-based rebases
> >     - [Bonus] Make a flag to allow rebase to rewrite commit messages that
> >           refer to older commits that were also rebased
> 
> This part of your proposal ("Points to work on") looks weak to me.
> 
> Please try to add more details about what you plan to do, how you
> would describe the new flags in the documentation, which *.c *.h and
> test files might be changed, etc.

I'll soon add details to the proposal, currently digging deep into the mailing list.

> > Proposed Timeline
> > -----------------
> >     + Community Bonding (May 6th - May 26th):
> >         - Introduction to community
> >         - Get familiar with the workflow
> >         - Study and understand the workflow and implementation of the project in detail
> >
> >     + Phase 1  (May 27th - June 23rd):
> >         - Start with implementing `git cherry-pick --skip`
> >         - Write new tests for the just introduced flag(s)
> >         - Analyse the requirements and differences of am-based and other rebases flags
> >
> >     + Phase 2  (June 24th - July 21st):
> >         - Introduce flags of am-based rebases to other kinds.
> >         - Add tests for the same.
> >
> >     + Phase 3  (July 22th - August 19th):
> >         - Act on [Bonus] features
> >         - Documentation
> >         - Clean up tasks
> >
> >
> > Relevant Work
> > =============
> > Dscho and I had a talk on how a non-am backend should implement `git rebase
> > --whitespace=fix`, which he warned may become a large project (as it turns
> > out it is a sub-task in one of the proposed ideas[0]), we were trying to
> > integrate this on git-for-windows first.
> > Keeping warning in mind, I discussed this project with Rafael and he suggested
> > (with a little bit uncertainty in mind) that I should work on implementing
> > a git-diff flag that generates a patch that when applied, will remove whitespace
> > errors which I am currently working on.
> 
> You mean Rafael Ascensão? Please CC him if he is involved in this.

Yes, I'll CC him.

Thanks
Rohit

[1]: https://gist.github.com/r1walz/5588d11065d5231ee451c0136400610e
[2]: https://public-inbox.org/git/20190322151157.9550-1-rohit.ashiwal265@gmail.com/
[3]: https://github.com/git-for-windows/git/releases/tag/v2.21.0.windows.1

Re: [GSoC][RFC] Proposal: Improve consistency of sequencer commands

[Rohit Ashiwal]

Hi Elijah!

On Sat, 23 Mar 2019 18:07:17 -0700 Elijah Newren <newren@gmail.com> wrote:
> Hi Rohit!
> 
> On Fri, Mar 22, 2019 at 8:12 AM Rohit Ashiwal
> <rohit.ashiwal265@gmail.com> wrote:
> > PS: Point one is missing in the timeline from the ideas page[0], can someone
> >     explain what exactly it wants?
> 
> I don't understand the question; could you restate it?

I was talking about this point: " The suggestion to fix an interrupted rebase-i
or cherry-pick due to a commit that became empty via git reset HEAD (in builtin/commit.c)
instead of git rebase --skip or git cherry-pick --skip ranges from annoying to confusing.".

> > Points to work on:
> > ------------------
> >     - Add `git cherry-pick --skip`
> 
> I'd reword this section as 'Consistently suggest --skip for operations
> that have such a concept'.[1]

Alright! I'll correct this in comming revisions.

> >     - [Bonus] Deprecate am-based rebases
> >     - [Bonus] Make a flag to allow rebase to rewrite commit messages that
> >           refer to older commits that were also rebased
> 
> I'd reorder these two.  I suspect the second won't be too hard and
> will provide a new user-visible feature, while the former will
> hopefully not be visible to users; if the former has more than
> cosmetic differences visible to user, it might transform the problem
> into more of a social problem than a technical one or just make into
> something we can't do.

There is no "order" in these points, just a rough TODO list, but I get your point here.
 
> > Proposed Timeline
> > -----------------
> >     + Community Bonding (May 6th - May 26th):
> >         - Introduction to community
> >         - Get familiar with the workflow
> >         - Study and understand the workflow and implementation of the project in detail
> >
> >     + Phase 1  (May 27th - June 23rd):
> >         - Start with implementing `git cherry-pick --skip`
> >         - Write new tests for the just introduced flag(s)
> >         - Analyse the requirements and differences of am-based and other rebases flags
> 
> Writing or finding tests to trigger all the --skip codepaths might be
> the biggest part of this phase.  Implementing `git cherry-pick --skip`
> just involves making it run the code that `git reset` invokes.  The
> you change the error message to reference `<command> --skip` instead
> of `git reset`.  What you're calling phase 1 here isn't quite
> microproject sized, but it should be relatively quick and easy; I'd
> plan to spend much more of your time on phase 2.
> 
> >     + Phase 2  (June 24th - July 21st):
> >         - Introduce flags of am-based rebases to other kinds.
> >         - Add tests for the same.
> 
> You should probably mention the individual cases from "INCOMPATIBLE
> FLAGS" of the git rebase manpage.  Also, some advice for order of
> tackling these: I think you should probably do --ignore-whitespace
> first; my guess is that one is the easiest.  Close up would be
> --committer-date-is-author-date and --ignore-date.  Re-reading, I'm
> not sure -C even makes sense at all; it might be that the solution is
> just accepting the flag and ignoring it, or perhaps it remains the one
> flag the interactive backend won't support, or maybe there is
> something that makes sense to be done.  There'd need to be a little
> investigation for that one, but it might turn out simple too.  The
> --whitespace={nowarn|warn|fix|error|error-all} flag will be the
> kicker.  I don't know how long that one will take, but I'm certain
> it's harder than the other flags and it might conceivably take up most
> the summer or even extend beyond.
> 
> >     + Phase 3  (July 22th - August 19th):
> >         - Act on [Bonus] features
> >         - Documentation
> >         - Clean up tasks
> 
> I'd prefer that Documentation updates were made as you went; you'll
> particularly need to look at Documentation/git-cherry-pick.txt and
> Documentation/rebase.txt, especially the "INCOMPATIBLE OPTIONS" and
> "BEHAVIORAL DIFFERENCES" sections of the latter.

Thanks for advice, yes, of course, the documentation and implementation will go
hand in hand.
 
> Also, as far as timing goes, the rewriting of commit messages seems
> relatively straightforward; you may want to consider doing it before
> the --whitespace flag (despite the fact that I originally suggested it
> as a bonus item).  Deprecating am-based rebases, on the other hand, is
> a bit of a wildcard.  It depends on Phase 2 being completed so it
> definitely makes sense to be last.  If phase 2 is complete, it's
> conceivable that deprecating am-based rebases only takes a little more
> work, but it might expand to use up a lot of time.
> 
> > Relevant Work
> > =============
> > Dscho and I had a talk on how a non-am backend should implement `git rebase
> > --whitespace=fix`, which he warned may become a large project (as it turns
> > out it is a sub-task in one of the proposed ideas[0]), we were trying to
> > integrate this on git-for-windows first.
> > Keeping warning in mind, I discussed this project with Rafael and he suggested
> > (with a little bit uncertainty in mind) that I should work on implementing
> > a git-diff flag that generates a patch that when applied, will remove whitespace
> > errors which I am currently working on.
> 
> It's awesome that you're looking in to this, but it may make more
> sense to knock out the easy parts of this project first.  That way the
> project gets some value out of your work for sure, you gain confidence
> and familiarity with the codebase, and then you can tackle the more
> difficult items.  Of course, if you're just exploring to learn what's
> possible in order to write the proposal, that's fine, I just think
> once you start on this project, it'd make more sense to do the easier
> ones first.

Yes, I'm looking into the code to get some clear vision.

> Hope that helps,
Yes! The vision in now clearer. Thanks Elijah. :)
> Elijah

Thanks for the review
Rohit

[GSoC][RFC v2] Improve consistency of sequencer commands

[Rohit Ashiwal]

Hiya

This is the v2 of the draft proposal[1]. I've added some details to the proposal,
it talks more about what to implement instead of how. It is still incomplete.

I'm currently adding more to the overview section, where I'll document the work
done by Dscho and Alban. After that I'll find files that will be changed while
implementing rest of the flags, finally add the basic control and/or data flow
of the 'how' part.

Thanks
Rohit

[1]: https://gist.github.com/r1walz/5588d11065d5231ee451c0136400610e
https://public-inbox.org/git/20190322151157.9550-1-rohit.ashiwal265@gmail.com/

------------------------------- >8 -------------------------------------

# Improve consistency of sequencer commands

## About Me

### Personal Information

Name           |     Rohit Ashiwal
---------------|----------------------------------------------------------------
Major          |     Computer Science and Engineering
E-mail         |     \<rohit.ashiwal265@gmail.com>
IRC            |     __rohit
Skype          |     rashiwal
Ph no          |     [ ph_no ]
Github         |     [r1walz](https://github.com/r1walz/)
Linkedin       |     [rohit-ashiwal](https://linkedin.com/in/rohit-ashiwal/)
Address        |     [                         Address                         ]
Postal Code    |     [ postal_code ]
Time Zone      |     IST (UTC +0530)


### Background

I am a sophomore at the [Indian Institute of Technology Roorkee][1], pursuing my
bachelor's degree in Computer Science and Engineering. I was introduced to
programming at a very early stage of my life. Since then, I've been trying out
new technologies by taking up various projects and participating in contests.  I
am passionate about system software development and competitive programming, and
I also actively contribute to open-source projects. At college, I joined the
Mobile Development Group ([MDG][2]), IIT Roorkee - a student group that fosters
mobile development within the campus. I have been an active part of the Git
community since February of this year, contributing to git-for-windows.


### Dev-Env

I am fluent in C/C++, Java and Shell Scripting, otherwise, I can also program in
Python, JavaScript. I use both Ubuntu 18.04 and Windows 10 x64 on my laptop.  I
prefer Linux for development unless the work is specific to Windows. \
VCS **:** git \
Editor **:** VS Code with gdb integrated


## Contributions to Open Source

My contributions to open source have helped me gain experience in understanding
the flow of any pre-written code at a rapid pace and enabled me to edit/add new
features.

### List of Contributions at Git:

Repo                              |        Status           |                   Title
-|-|-
[git/git][8]                      | Merged in 'next' branch | [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                  | [#235][5]**:** installer: Fix version of installer and installed file.


## The Project

### _Improve consistency of sequencer commands_

#### Overview

Stephan Beyer \<s-beyer@gmx.net> 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. 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@tuxfamily.org> and then mentor Daniel Barkalow
\<barkalow@iabervon.org>.

The project was continued by Ramkumar Ramachandra \<artagnon@gmail.com> in
[2011][7], converting it to a builtin and extending its domain to
git-cherry-pick.

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.


#### Points to work on:

1. Suggest relevant flags for operations that have such a concept like
    `git cherry-pick --skip`
2. Unify the suggestive messages of `git (cherry-pick|rebase-i)` with
    `git (am|rebase)`
3. Implement flags that am-based rebases support, but not interactive,
    in interactive rebases, e.g.:
```
    * --ignore-whitespace
    * --committer-date-is-author-date or --ignore-date
    * --signoff
    * --whitespace=...
    * -C
```
4. Test and Documentation
5. `[Bonus]` Make a flag to allow rebase to rewrite commit messages that
  refer to older commits that were also rebased
6. `[Bonus]` Deprecate am-based rebases


#### "The Plan"

1. Start by introducing `git cherry-pick --skip`, this will help in step 2 of
"the plan", since we are required to unify the advice messages that show during
an interrupt of `git (cherry-pick|rebase -i)` when the incoming commit has
become "empty" (no change between commits).

    **_Files changed_ :**
    - revert.c: Introduce option `--skip` under `run_sequencer()`

2. There are two backends available for rebasing/cherry-picking, _viz_, the `am`
and the `interactive`.  Naturally, there shall be some features that are
implemented in one but not in the other.  One such quality is suggestive
messages. The am-based rebases (and am itself) will give advice to the user to
use `git rebase --skip` (or `git am --skip`) when a patch isn't needed. In
contrast, interactive-based and cherry-pick will suggest the user `git reset`.
Change this to match the message of `am` backend, so that everything appears
symmetric.

    **_Files changed_ :**
    - rebase.c: change flow so that `--skip` calls `git reset` while interactive
      rebasing
    - commit.c: change messages
    - sequencer.c: change suggestive message under `create_seq_dir()`

3. Now that I'm familiar with the code, I'll start picking the pace now. And
start implementing the meat of the project. The flags. I'll start implementing
the flags in the following order as [Elijah suggested][12]:
    1. --ignore-whitespace
    2. --committer-date-is-author-date
    3. --ignore-date
    4. --whitespace=...
    5. `[Bonus]` --signoff

    **_Files changed_ :** [currently searching for files to be changed]

4. Testing and Documentation will go in sync with implementation. I intend to
follow `Test Driven Development` but let's see how it turns out.

5. `[Bonus]` As familiarity with the code increases, I might be able to implement
the feature of rewriting commits in time.

6. `[Bonus]` If everything goes well and time permits, discuss with the mentor(s)
the possibility of deprecating the am backend of rebase. This point is last to
work on as it provides no "cosmetic" difference on the user side. Elijah
[mentioned][12] the possibility of a "social" problem that might occur which shall
be discussed then.


#### Proposed Timeline

+ Community Bonding (May 6th - May 26th):
    - Introduction to community
    - Get familiar with the dataflow
    - Study and understand the workflow and implementation of the project in
      detail

+ Phase 1 (May 27th - June 23rd):
    - Start with implementing `git cherry-pick --skip`
    - Write new tests for the just introduced flag(s)
    - Analyse the requirements and differences of am-based and other rebases
      flags

+ Phase 2 (June 24th - July 21st):
    - Introduce flags of am-based rebases to other kinds.
    - Add tests for the same.

+ Phase 3 (July 22th - August 19th):
    - Act on [Bonus] features
    - Documentation
    - Clean up tasks


#### Relevant Work

Dscho and I had a talk on how a non-am backend should implement `git rebase
--whitespace=fix`, which he warned may become a large project (as it turns out
it is a sub-task in one of the [proposed ideas][11]), we were trying to
integrate this on git-for-windows first.

Keeping warning in mind, I discussed this project with Rafael and he suggested
(with a little bit uncertainty in mind) that I should work on implementing a
git-diff flag that generates a patch that when applied, will remove whitespace
errors which I am currently working on.


## Availability

My vacations start on 7 May and end on 15 July. The official GSoC period is from
6 May to 19 August. I can easily devote 40-45 hours a week until my college
reopens and 35-40 hours per week after that. I'm also free on the weekends and I
intend to complete most of the work before my college reopens.

Other than this project, I have no commitments/vacations planned for the summer.
I shall keep my status posted to all the community members on a weekly basis and
maintain transparency in the project.

## After GSoC

Even after the Google Summer of Code, I plan on continuing my contributions to
this organization, by adding to my project and working on open issues or
feature requests. With the community growing continuously, I feel responsible
for all the projects I'm a part of. Having picked up a lot of developing skills,
my major focus would be to develop mentorship skills so that I can give back
this community by helping other people navigate around and reviewing
contributions.


[0]: https://git.github.io/SoC-2019-Ideas/
[1]: https://www.iitr.ac.in/
[2]: http://mdg.iitr.ac.in/
[3]: https://public-inbox.org/git/20190303122842.30380-1-rohit.ashiwal265@gmail.com/
[4]: https://github.com/git-for-windows/git/pull/2077
[5]: https://github.com/git-for-windows/build-extra/pull/235
[6]: https://public-inbox.org/git/20080607220101.GM31040@leksak.fem-net/
[7]: https://public-inbox.org/git/20110403172054.GA10220@kytes/
[8]: https://github.com/git/git/commit/404110d2910aa617c7fb7e326694f8e085c5b2a0
[9]: https://github.com/git-for-windows/git/commit/ed2b22adeb760d967c567c5664d33d5d641db10e
[10]: https://github.com/git-for-windows/build-extra/commit/2e879f7fa5808f5f9cbfdd08ca456209f9ac5f1b
[11]: https://git.github.io/SoC-2019-Ideas/#improve-consistency-of-sequencer-commands
[12]: https://public-inbox.org/git/CABPp-BEdgSHGTkUcg_UDRu50Ag+cCqigmvU4_JaRZRnDpgWcdA@mail.gmail.com/

Re: [GSoC][RFC v2] Improve consistency of sequencer commands

[Elijah Newren]

Hi Rohit,

On Fri, Mar 29, 2019 at 3:33 PM Rohit Ashiwal
<rohit.ashiwal265@gmail.com> wrote:
>
> Hiya
>
> This is the v2 of the draft proposal[1]. I've added some details to the proposal,
> it talks more about what to implement instead of how. It is still incomplete.
>
> I'm currently adding more to the overview section, where I'll document the work
> done by Dscho and Alban. After that I'll find files that will be changed while
> implementing rest of the flags, finally add the basic control and/or data flow
> of the 'how' part.

Overall this looks pretty good to me, just one question...

> 3. Now that I'm familiar with the code, I'll start picking the pace now. And
> start implementing the meat of the project. The flags. I'll start implementing
> the flags in the following order as [Elijah suggested][12]:
>     1. --ignore-whitespace
>     2. --committer-date-is-author-date
>     3. --ignore-date
>     4. --whitespace=...
>     5. `[Bonus]` --signoff

--signoff is new and surprises me.  What's the plan with that one?

Re: [GSoC][RFC v2] Improve consistency of sequencer commands

[Rohit Ashiwal]

Hi Elijah

On Sat, Mar 30, 2019 at 4:56 AM Elijah Newren <newren@gmail.com> wrote:
>
> Overall this looks pretty good to me, just one question...
>

:)

> >     5. `[Bonus]` --signoff
>
> --signoff is new and surprises me.  What's the plan with that one?
>

I was reading the documentation of git-rebase[1], where I found that
`--signoff` flag is not available for interactive backend, i.e., it is not
possible to convert a commit into `Signed-off-by` commit while interactive
rebasing.

I though it might be a nice bonus to add, hence I listed it in "the plan".

Thanks
Rohit

[1]: https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---signoff

Re: [GSoC][RFC v2] Improve consistency of sequencer commands

[Elijah Newren]

On Fri, Mar 29, 2019 at 4:35 PM Rohit Ashiwal
<rohit.ashiwal265@gmail.com> wrote:
>
> Hi Elijah
>
> On Sat, Mar 30, 2019 at 4:56 AM Elijah Newren <newren@gmail.com> wrote:
> >
> > Overall this looks pretty good to me, just one question...
> >
>
> :)
>
> > >     5. `[Bonus]` --signoff
> >
> > --signoff is new and surprises me.  What's the plan with that one?
> >
>
> I was reading the documentation of git-rebase[1], where I found that
> `--signoff` flag is not available for interactive backend, i.e., it is not
> possible to convert a commit into `Signed-off-by` commit while interactive
> rebasing.

I'm curious if you're looking at an old version of the documentation
(...or maybe the documentation just isn't that clear?).  Interactive
rebases have supported --signoff since commit a852ec7f273c ("rebase:
extend --signoff support", 2018-03-20)

Re: [GSoC][RFC v2] Improve consistency of sequencer commands

[Christian Couder]

Hi Rohit,

On Fri, Mar 29, 2019 at 11:33 PM Rohit Ashiwal
<rohit.ashiwal265@gmail.com> wrote:
>
> This is the v2 of the draft proposal[1]. I've added some details to the proposal,
> it talks more about what to implement instead of how. It is still incomplete.
>
> I'm currently adding more to the overview section, where I'll document the work
> done by Dscho and Alban. After that I'll find files that will be changed while
> implementing rest of the flags, finally add the basic control and/or data flow
> of the 'how' part.

The plan to improve it looks good to me.

> ### List of Contributions at Git:
>
> Repo                              |        Status           |                   Title
> -|-|-
> [git/git][8]                      | Merged in 'next' branch | [Micro][3]**:** Use helper functions in test script

It would be nice to have a link to the last "What's cooking in
git.git" email from Junio so we can easily see the current status of
your patch/patch series.

> [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                  | [#235][5]**:** installer: Fix version of installer and installed file.
>
>
> ## The Project
>
> ### _Improve consistency of sequencer commands_
>
> #### Overview
>
> Stephan Beyer \<s-beyer@gmx.net> 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. 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@tuxfamily.org> and then mentor Daniel Barkalow
> \<barkalow@iabervon.org>.
>
> The project was continued by Ramkumar Ramachandra \<artagnon@gmail.com> in
> [2011][7], converting it to a builtin and extending its domain to
> git-cherry-pick.

I don't think the sequencer has been converted into a builtin. I am
not sure why Ram wrote that he would do that in his proposal as I
don't think it was really a goal we had.

By the way, you might want to read the sequencer related article in
https://git.github.io/rev_news/2016/10/19/edition-20/ for things that
Dscho did.

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

[...]

> 5. `[Bonus]` As familiarity with the code increases, I might be able to implement
> the feature of rewriting commits in time.

I had to go back to the "Points to work on" section to understand what
this was about. Please describe what this is about in a clearer way.

> 6. `[Bonus]` If everything goes well and time permits, discuss with the mentor(s)
> the possibility of deprecating the am backend of rebase. This point is last to
> work on as it provides no "cosmetic" difference on the user side. Elijah
> [mentioned][12] the possibility of a "social" problem that might occur which shall
> be discussed then.

Maybe it would be interesting to see if there is a performance
difference between the 2 backends.

[...]

> #### Relevant Work
>
> Dscho and I had a talk on how a non-am backend should implement `git rebase
> --whitespace=fix`, which he warned may become a large project (as it turns out
> it is a sub-task in one of the [proposed ideas][11]), we were trying to
> integrate this on git-for-windows first.
>
> Keeping warning in mind, I discussed this project with Rafael and he suggested
> (with a little bit uncertainty in mind) that I should work on implementing a
> git-diff flag that generates a patch that when applied, will remove whitespace
> errors which I am currently working on.

Nice!

Re: [GSoC][RFC v2] Improve consistency of sequencer commands

[Rohit Ashiwal]

Hi Elijah

On 2019-03-30  0:38 UTC Elijah Newren <newren@gmail.com> wrote:

> I'm curious if you're looking at an old version of the documentation
> (...or maybe the documentation just isn't that clear?).  Interactive
> rebases have supported --signoff since commit a852ec7f273c ("rebase:
> extend --signoff support", 2018-03-20)

Oh~ after having a quick look at my currently installed version of git,
it was 2.17.1, which has outdated man pages :sweat_smile:. Yes, you are
correct, I'm sorry.

Feeling dumb
Rohit

Re: [GSoC][RFC v2] Improve consistency of sequencer commands

[Elijah Newren]

On Sat, Mar 30, 2019 at 12:16 AM Christian Couder
<christian.couder@gmail.com> wrote:

> > 6. `[Bonus]` If everything goes well and time permits, discuss with the mentor(s)
> > the possibility of deprecating the am backend of rebase. This point is last to
> > work on as it provides no "cosmetic" difference on the user side. Elijah
> > [mentioned][12] the possibility of a "social" problem that might occur which shall
> > be discussed then.
>
> Maybe it would be interesting to see if there is a performance
> difference between the 2 backends.

Yes, it may make sense to repeat
https://public-inbox.org/git/nycvar.QRO.7.76.6.1901312310280.41@tvgsbejvaqbjf.bet/
to verify we're still in a good state, and maybe even try to figure
out why split-index is weird.  However, more important is the handling
of empty commits (both start-empty and become-empty) and trying to
bring some consistency there or at least implementing more options for
the interactive backend and figuring out which empty-handling options
should be the default for which sets of flags.  It's kind of a mess.

Re: [GSoC][RFC v2] Improve consistency of sequencer commands

[Elijah Newren]

On Sat, Mar 30, 2019 at 1:49 AM Rohit Ashiwal
<rohit.ashiwal265@gmail.com> wrote:
>
> Hi Elijah
>
> On 2019-03-30  0:38 UTC Elijah Newren <newren@gmail.com> wrote:
>
> > I'm curious if you're looking at an old version of the documentation
> > (...or maybe the documentation just isn't that clear?).  Interactive
> > rebases have supported --signoff since commit a852ec7f273c ("rebase:
> > extend --signoff support", 2018-03-20)
>
> Oh~ after having a quick look at my currently installed version of git,
> it was 2.17.1, which has outdated man pages :sweat_smile:. Yes, you are
> correct, I'm sorry.
>
> Feeling dumb
> Rohit

Don't feel dumb.  I like the initiative.  Also, since you highlighted
it, there might be an issue with picking merge commits; either they
aren't affected by --signoff and should be, or the documentation
should be updated to mention they are handled too.  So there is
actually something here, I think.

[GSoC][RFC v3] Proposal: Improve consistency of sequencer commands

[Rohit Ashiwal]

Hiya

Here is one more iteration of my draft proposal[1]. RFC.

Thanks
Rohit

[1]: https://gist.github.com/r1walz/5588d11065d5231ee451c0136400610e

---------------------------------- >8 ------------------------------------------


# Improve consistency of sequencer commands

## About Me

### Personal Information

Name           |     Rohit Ashiwal
---------------|----------------------------------------------------------------
Major          |     Computer Science and Engineering
E-mail         |     \<rohit.ashiwal265@gmail.com>
IRC            |     __rohit
Skype          |     rashiwal
Ph no          |     [ ph_no ]
Github         |     [r1walz](https://github.com/r1walz/)
Linkedin       |     [rohit-ashiwal](https://linkedin.com/in/rohit-ashiwal/)
Address        |     [                         Address                         ]
Postal Code    |     [ postal_code ]
Time Zone      |     IST (UTC +0530)


### Background

I am a sophomore at the [Indian Institute of Technology Roorkee][1], pursuing my
bachelor's degree in Computer Science and Engineering. I was introduced to
programming at a very early stage of my life. Since then, I've been trying out
new technologies by taking up various projects and participating in contests.  I
am passionate about system software development and competitive programming, and
I also actively contribute to open-source projects. At college, I joined the
Mobile Development Group ([MDG][2]), IIT Roorkee - a student group that fosters
mobile development within the campus. I have been an active part of the Git
community since February of this year, contributing to git-for-windows.


### Dev-Env

I am fluent in C/C++, Java and Shell Scripting, otherwise, I can also program in
Python, JavaScript. I use both Ubuntu 18.04 and Windows 10 x64 on my laptop.  I
prefer Linux for development unless the work is specific to Windows. \
VCS **:** git \
Editor **:** VS Code with gdb integrated


## Contributions to Open Source

My contributions to open source have helped me gain experience in understanding
the flow of any pre-written code at a rapid pace and enabled me to edit/add new
features.

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


## The Project

### _Improve consistency of sequencer commands_

#### 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@gmx.net> 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@tuxfamily.org> and then mentor Daniel Barkalow
\<barkalow@iabervon.org>.

The project was continued by Ramkumar Ramachandra \<artagnon@gmail.com> 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@tuxfamily.org> 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.

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.
His work can be found [here][15].

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.


#### Points to work on:

1. Suggest relevant flags for operations that have such a concept like
    `git cherry-pick --skip`
2. Unify the suggestive messages of `git (cherry-pick|rebase-i)` with
    `git (am|rebase)`
3. Implement flags that am-based rebases support, but not interactive,
    in interactive rebases, e.g.:
```
    * --ignore-whitespace
    * --committer-date-is-author-date or --ignore-date
    * --whitespace=...
    * -C
```
4. Test and Documentation
5. `[Bonus]` Make a flag to allow rebase to rewrite commit messages that
  refer to older commits that were also rebased
6. `[Bonus]` Performance run on different backends of rebasing, if everything
  agrees, deprecate am-based rebases


#### "The Plan"

1. Start by introducing `git cherry-pick --skip`, this will help in step 2 of
"the plan", since we are required to unify the advice messages that show during
an interrupt of `git (cherry-pick|rebase -i)` when the incoming commit has
become "empty" (no change between commits).

    **_Files changed_ :**
    - revert.c: Introduce option `--skip` under `run_sequencer()`

2. There are two backends available for rebasing/cherry-picking, _viz_, the `am`
and the `interactive`.  Naturally, there shall be some features that are
implemented in one but not in the other.  One such quality is suggestive
messages. The am-based rebases (and am itself) will give advice to the user to
use `git rebase --skip` (or `git am --skip`) when a patch isn't needed. In
contrast, interactive-based and cherry-pick will suggest the user `git reset`.
Change this to match the message of `am` backend, so that everything appears
symmetric.

    **_Files changed_ :**
    - rebase.c: change flow so that `--skip` calls `git reset` while interactive
      rebasing
    - commit.c: change messages
    - sequencer.c: change suggestive message under `create_seq_dir()`

3. Now that I'm familiar with the code, I'll start picking the pace now. And
start implementing the meat of the project. The flags. I'll start implementing
the flags in the following order as [Elijah suggested][12]:
    1. --ignore-whitespace
    2. --committer-date-is-author-date
    3. --ignore-date
    4. --whitespace=...

    **_Files changed_ :**
    - rebase: introduce the flag
    - builtin/rebase--interactive: introduce the flag under `cmd_rebase__interactive()`
    - change messages wherever required

4. Testing and Documentation will go in sync with implementation. I intend to
follow `Test Driven Development` but let's see how it turns out.

5. `[Bonus]` As familiarity with the code increases, I might be able to implement
a flag to allow rebase to rewrite commit messages that refer to older commits that
were also rebased in time.

6. `[Bonus]` If everything goes well and time permits, discuss with the mentor(s)
the possibility of deprecating the am backend of rebase. This point is last to
work on as it provides no "cosmetic" difference on the user side. Elijah
[mentioned][12] the possibility of a "social" problem that might occur which shall
be discussed then.


#### Proposed Timeline

+ Community Bonding (May 6th - May 26th):
    - Introduction to community
    - Get familiar with the dataflow
    - Study and understand the workflow and implementation of the project in
      detail

+ Phase 1 (May 27th - June 23rd):
    - Start with implementing `git cherry-pick --skip`
    - Write new tests for the just introduced flag(s)
    - Analyse the requirements and differences of am-based and other rebases
      flags

+ Phase 2 (June 24th - July 21st):
    - Introduce flags of am-based rebases to other kinds.
    - Add tests for the same.

+ Phase 3 (July 22th - August 19th):
    - Act on [Bonus] features
    - Documentation
    - Clean up tasks


#### Relevant Work

Dscho and I had a talk on how a non-am backend should implement `git rebase
--whitespace=fix`, which he warned may become a large project (as it turns out
it is a sub-task in one of the [proposed ideas][11]), we were trying to
integrate this on git-for-windows first.

Keeping warning in mind, I discussed this project with Rafael and he suggested
(with a little bit uncertainty in mind) that I should work on implementing a
git-diff flag that generates a patch that when applied, will remove whitespace
errors which I am currently working on.


## Availability

My vacations start on 7 May and end on 15 July. The official GSoC period is from
6 May to 19 August. I can easily devote 40-45 hours a week until my college
reopens and 35-40 hours per week after that. I'm also free on the weekends and I
intend to complete most of the work before my college reopens.

Other than this project, I have no commitments/vacations planned for the summer.
I shall keep my status posted to all the community members on a weekly basis and
maintain transparency in the project.

## After GSoC

Even after the Google Summer of Code, I plan on continuing my contributions to
this organization, by adding to my project and working on open issues or
feature requests. With the community growing continuously, I feel responsible
for all the projects I'm a part of. Having picked up a lot of developing skills,
my major focus would be to develop mentorship skills so that I can give back
this community by helping other people navigate around and reviewing
contributions.


[0]: https://git.github.io/SoC-2019-Ideas/
[1]: https://www.iitr.ac.in/
[2]: http://mdg.iitr.ac.in/
[3]: https://public-inbox.org/git/20190303122842.30380-1-rohit.ashiwal265@gmail.com/
[4]: https://github.com/git-for-windows/git/pull/2077
[5]: https://github.com/git-for-windows/build-extra/pull/235
[6]: https://public-inbox.org/git/20080607220101.GM31040@leksak.fem-net/
[7]: https://public-inbox.org/git/20110403172054.GA10220@kytes/
[8]: https://github.com/git/git/commit/404110d2910aa617c7fb7e326694f8e085c5b2a0
[9]: https://github.com/git-for-windows/git/commit/ed2b22adeb760d967c567c5664d33d5d641db10e
[10]: https://github.com/git-for-windows/build-extra/commit/2e879f7fa5808f5f9cbfdd08ca456209f9ac5f1b
[11]: https://git.github.io/SoC-2019-Ideas/#improve-consistency-of-sequencer-commands
[12]: https://public-inbox.org/git/CABPp-BEdgSHGTkUcg_UDRu50Ag+cCqigmvU4_JaRZRnDpgWcdA@mail.gmail.com/
[13]: https://public-inbox.org/git/xmqqr2aidpxw.fsf@gitster-ct.c.googlers.com/
[14]: https://git.github.io/rev_news/2016/10/19/edition-20/
[15]: https://public-inbox.org/git/cover.1472457609.git.johannes.schindelin@gmx.de/
[16]: https://public-inbox.org/git/20160904201833.21676-1-chriscool@tuxfamily.org/

Re: [GSoC][RFC v3] Proposal: Improve consistency of sequencer commands

[Christian Couder]

Hi Rohit,

On Fri, Apr 5, 2019 at 11:32 PM Rohit Ashiwal
<rohit.ashiwal265@gmail.com> 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@gmx.net> 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@tuxfamily.org> and then mentor Daniel Barkalow
> \<barkalow@iabervon.org>.
>
> The project was continued by Ramkumar Ramachandra \<artagnon@gmail.com> 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@tuxfamily.org> 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.

Re: [GSoC][RFC v3] Proposal: Improve consistency of sequencer commands

[Rohit Ashiwal]

Hey Chris!

On Sun, 7 Apr 2019 09:15:30 +0200 Christian Couder <christian.couder@gmail.com> wrote:

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

Sure, I'll upload my proposal as soon as possible.

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

The intention was to document how the project started and *major* milestones or
turning points of the project. Here they are.

> Maybe s/rebases/rebase/

Yes, :P

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

Again the idea was to document earlier stages of project, "recent" discussions
have been on the optimizations which are not exactly relevant.

Should I write more about recent developments?

Regards
Rohit

Re: [GSoC][RFC v3] Proposal: Improve consistency of sequencer commands

[Christian Couder]

Hi Rohit,

On Sun, Apr 7, 2019 at 2:17 PM Rohit Ashiwal <rohit.ashiwal265@gmail.com> wrote:
>
> On Sun, 7 Apr 2019 09:15:30 +0200 Christian Couder <christian.couder@gmail.com> wrote:
>
> > 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.
>
> Sure, I'll upload my proposal as soon as possible.

Great!

> > It looks like you copy pasted the Git Rev News article without
> > updating the content. The improvement has been released a long time
> > ago.
>
> The intention was to document how the project started and *major* milestones or
> turning points of the project. Here they are.

Yeah, the intention is good, though it would be nice if the details
were a bit more polished.

> > Maybe s/rebases/rebase/
>
> Yes, :P
>
> > 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.
>
> Again the idea was to document earlier stages of project, "recent" discussions
> have been on the optimizations which are not exactly relevant.

I think there were ideas (from Elijah) about using the sequencer in
the regular (non interactive) rebase too.

> Should I write more about recent developments?

I think Alban's GSoC project was relevant too.

So yeah, if you have time after uploading your proposal to the GSoC
web site, it would be nice if you can update it with a bit more
information about what happened recently.

Thanks,
Christian.