From: Christian Couder <firstname.lastname@example.org>
To: Rohit Ashiwal <email@example.com>
Cc: git <firstname.lastname@example.org>, Elijah Newren <email@example.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Thomas Gummerer <firstname.lastname@example.org>,
Ramkumar Ramachandra <email@example.com>,
Stephan Beyer <firstname.lastname@example.org>
Subject: Re: [GSoC][RFC] Proposal: Improve consistency of sequencer commands
Date: Sat, 23 Mar 2019 23:17:54 +0100 [thread overview]
Message-ID: <CAP8UFD22PMjQBsAf1GYphmtmt8x+sO=q=c_4bHDsS8L31Y_3AA@mail.gmail.com> (raw)
On Fri, Mar 22, 2019 at 4:12 PM 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.
> PS: Point one is missing in the timeline from the ideas page, 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"
> [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
> [#2077](4): [FIX] git-archive error, gzip -cn : command not found.
> Status: Merged
> [#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'
> git-sequencer was introduced by Stephan Beyer <email@example.com> as his
> GSoC 2008 project. 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 <firstname.lastname@example.org>
> in 2011, 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
> 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
> 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), 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.
next prev parent reply other threads:[~2019-03-23 22:18 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-24 10:05 [GSoC] Introduction Rohit Ashiwal
2019-02-24 14:47 ` Johannes Schindelin
2019-02-25 6:50 ` Christian Couder
2019-02-25 11:35 ` Rohit Ashiwal
2019-02-25 20:21 ` Christian Couder
2019-02-25 21:09 ` Eric Sunshine
2019-03-22 15:11 ` [GSoC][RFC] Proposal: Improve consistency of sequencer commands Rohit Ashiwal
2019-03-23 22:17 ` Christian Couder [this message]
2019-03-24 1:21 ` Rohit Ashiwal
2019-03-24 1:07 ` Elijah Newren
2019-03-24 1:45 ` Rohit Ashiwal
2019-03-29 22:32 ` [GSoC][RFC v2] " Rohit Ashiwal
2019-03-29 23:25 ` Elijah Newren
2019-03-29 23:34 ` Rohit Ashiwal
2019-03-30 0:38 ` Elijah Newren
2019-03-30 8:48 ` Rohit Ashiwal
2019-03-30 17:13 ` Elijah Newren
2019-03-30 7:16 ` Christian Couder
2019-03-30 17:12 ` Elijah Newren
2019-04-05 21:31 ` [GSoC][RFC v3] Proposal: " Rohit Ashiwal
2019-04-07 7:15 ` Christian Couder
2019-04-07 12:16 ` Rohit Ashiwal
2019-04-07 23:07 ` Christian Couder
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).