Git Sequencer
Hi,
I'd like to re-apply this year as a student because I really want to see (among other things), a sequencer in git.git. Also, since I worked on areas related to fast-import and remote helpers last year, I thought I should work on something completely orthogonal this year.
I now have a draft of my proposal ready, and I'd really appreciate feedback. Also, could someone mentor me?
======================================================================
Project Proposal: Git Sequencer
Student: Ramkumar Ramachandra
Mentor: ?
== The Objective ==
To write git-sequencer, a new builtin command, and implement existing commands on top of that. This should give the commands more functionality, improve their error handling, and make them faster. The project can only be considered successful if all (or most) of the code written gets merged into upstream.
The Git Sequencer was a 2008 GSoC project as well; unfortunately most of the code did not get merged into git.git. The learning from all that work should serve as a huge headstart this year.
=== The Plan ===
1. Extend 'cherry-pick' with '--continue', '--abort', and '--skip' features, so that it works like (a subset of) the current 'git-rebase--interactive.sh'. This will require patching 'builtin/revert.c' in place, and merging it immediately. I plan to roughly follow the road laid out by Christian's 2010 series [1].
1.1. Factor out all calls to 'die' with 'return error' so so that we can pause the entire process when a commit doesn't apply automatically.
1.2. Create and populate TODO and DONE files, similar to the one that 'git-rebase--interactive.sh' creates. For now, it should simply give us information about why a 'cherry-pick' failed. Use these files with 'git-rebase--interactive.sh' to resume.
1.3. Port selective tests from the current 't3404' to make sure that TODO and DONE are populated correctly; "stop on conflicting pick" is a good candidate.
1.4. Decouple the 'revert' functionality from the 'cherry-pick' functionality in 'revert.c'. Implement '--abort' for 'cherry-pick' and port "abort" test from 't3404'.
1.5. Implement parsing the TODO and DONE files into suitable data structures. Derive inspiration from the code written in 2008 to do this.
1.6. Implement '--continue' and '--skip', and write suitable tests. Merge into upstream.
2. Factor out the 'cherry-pick' code from 'revert.c' into a new 'builtin/sequencer.c', and expose a simple cherry-picking API in 'sequencer.h'.
3. Implement a fresh 'cherry-pick.c' as a simple API call to the sequencer, and make sure that all the existing tests pass. After this, cherry-pick will not be a builtin command anymore*. Merge into upstream.
4. Extend the sequncer to parse commands like 'execute', 'reword', 'squash', and 'fixup' that are specific to interactive rebasing. Carefully implement the functionality for each of these keywords in a step-wise manner, making sure that it inter-operates with 'rebase -i' seamlessly.
5. Port the entire testsuite from 'rebase -i', and rewrite 'git-rebase.sh', 'git-rebase--interactive.sh' to call the sequncer. The script should essentially build to a list of TODO instructions and pass it to the 'git-sequencer' binary. Merge into upstream.
6. [Optional] Lib'ify the sequncer: modify the sequencer API to include rebase-related functionality. Write 'rebase.c' as a bunch of API calls to the sequencer. Make sure that the existing tests pass. Merge into upstream.
7. [Optional] Re-implement 'git-am.sh' as a thin wrapper over the
sequncer: 'am.c'. Bulk of this should be mbox parsing code. Make sure that all existing tests pass. Merge into upstream.
* Is this a good change? Are there any forseeable issues? ** [Optional] should be read as "If time permits"
== Timeline ===
Deriving from last year's experience, I've decided not to present a tight timeline. Instead, I simply have an outline: Get the extended cherry-pick functionality merged before mid-term evaluations, and the rest before the final evaluations.
== Who am I? ==
I'm Ramkumar Ramachandra, and I first started contributing to git.git in January 2010. Apart from doing fast-import and remote helper related work last year, I also authored and merged svnrdump into Subversion trunk in the same period.
== Notes ==
[1]: http://thread.gmane.org/gmane.comp.version-control.git/162183
======================================================================
Thanks for reading.
-- Ram
Hi Ram,
first, some notes on my git-sequencer 2008 branches that can be found at
http://repo.or.cz/w/git/sbeyer.git ... (Not sure if I remember everything correctly)
I've settled to develop within the "seq-builtin-dev" branch and I sometimes merged Junio's "master" into that branch to catch up. The "seq-builtin-dev" branch is the important one.
Using git rebase -i (using git-sequencer) I sometimes remanaged the branch to "seq-builtin-rfc" that should represent a snapshot of a potential patch queue. My last rebase processes of the seq-builtin-rfc branch were pretty unmotivated and hence messy.
I have not touched the repo very often after GSOC'08 and I stopped touching it (as I stopped following recent Git development) "20 months ago" apparently. Quite many things may have changed since then.
The file A_SEQUENCER_TODO_FILE (added 2009-08-03) in the repo describes the missing and buggy pieces to fix so that _I_ (only me) would have been 100 per cent satisfied with that git-sequencer.
http://repo.or.cz/w/git/sbeyer.git/blob/9e4b4d92f681a47e3d7ad2152d2391b2ab125a0c:/A_SEQUENCER_TODO_FILE
[Some notes are also "strategy notes" to get things accepted, like the changes on "rebase -i -p" which are "not loved by everyone". ;-)]
Quoted 1 line · Ramkumar Ramachandra
* Is this a good change? Are there any forseeable issues?
I want to mention an issue that I have not foreseen before: merges. (You need merges, for example, when doing rebase -i -p ... -p as in --preserve-merges.)
When I began, there was code in the "next" branch that added the TODO instructions "mark", "reset" and "merge" to do merges properly and I based my work on it. The original pieces by Jörg Sommer can still be found here:
http://repo.or.cz/w/git/sbeyer.git/shortlog/6fabd85e8a777c26f3ae8ce11cb7f4265502ea7f
However, there have been strong opinions that the "mark"/"reset"/"merge" instructions are ugly and unpleasant to users and not even necessary (at least for rebase--interactive... and for sequencer, maybe, maybe not). Hence, the code in "next" has been rejected later.
During GSOC 2008 I regrettably underestimated the importance to communicate with the Git folks about these things. That's one of the main reasons the sequencer pieces did not get into master. And after GSOC'08 I had too little time for this... :-/
Well, the merging thing is the only *real* issue I remember.
Good luck and regards,
Stephan
Hi Stephen,
Quoted 7 lines · Stephan Beyer
first, some notes on my git-sequencer 2008 branches that can be found at
http://repo.or.cz/w/git/sbeyer.git ... (Not sure if I remember everything correctly)I've settled to develop within the "seq-builtin-dev" branch and I sometimes merged Junio's "master" into that branch to catch up. The "seq-builtin-dev" branch is the important one.
Thanks! Jonathan told me about it earlier, and I've already started ripping out code from the seq-builtin-dev branch :) I found your 't3350-sequencer.sh' especially interesting.
Quoted 8 lines
Using git rebase -i (using git-sequencer) I sometimes remanaged the branch to "seq-builtin-rfc" that should represent a snapshot of a potential patch queue. My last rebase processes of the seq-builtin-rfc branch were pretty unmotivated and hence messy.
I have not touched the repo very often after GSOC'08 and I stopped touching it (as I stopped following recent Git development) "20 months ago" apparently. Quite many things may have changed since then.
Okay, got it. I saw a few patches in 'master' that were based on your work though. Some of the patches in Christian's series also refer to your work.
Quoted 6 lines
The file
A_SEQUENCER_TODO_FILE(added 2009-08-03) in the repo describes the missing and buggy pieces to fix so that _I_ (only me) would have been 100 per cent satisfied with that git-sequencer.
http://repo.or.cz/w/git/sbeyer.git/blob/9e4b4d92f681a47e3d7ad2152d2391b2ab125a0c:/A_SEQUENCER_TODO_FILE
[Some notes are also "strategy notes" to get things accepted, like the changes on "rebase -i -p" which are "not loved by everyone". ;-)]
Okay.
Quoted 6 lines · Ramkumar Ramachandra
Quoted 1 line
* Is this a good change? Are there any forseeable issues?
I want to mention an issue that I have not foreseen before: merges. (You need merges, for example, when doing rebase -i -p ... -p as in --preserve-merges.)
Ah, that's not something I thought about immediately.
Quoted 10 lines
When I began, there was code in the "next" branch that added the TODO instructions "mark", "reset" and "merge" to do merges properly and I based my work on it. The original pieces by Jörg Sommer can still be found here:
http://repo.or.cz/w/git/sbeyer.git/shortlog/6fabd85e8a777c26f3ae8ce11cb7f4265502ea7fHowever, there have been strong opinions that the "mark"/"reset"/"merge" instructions are ugly and unpleasant to users and not even necessary (at least for rebase--interactive... and for sequencer, maybe, maybe not). Hence, the code in "next" has been rejected later.
Interesting historical note.
Quoted 6 lines
During GSOC 2008 I regrettably underestimated the importance to communicate with the Git folks about these things. That's one of the main reasons the sequencer pieces did not get into master. And after GSOC'08 I had too little time for this... :-/
Well, the merging thing is the only *real* issue I remember.
Point noted. Yes, I noticed that your sequencer was mostly functionally complete. I'll make sure that I spend a lot of interacting with the community.
Thank you for your elaborate note! I really appreciate it :) Hopefully, we will have that sequencer by next year.
-- Ram
Quoted 9 lines · Stephan Beyer
I want to mention an issue that I have not foreseen before: merges. (You need merges, for example, when doing rebase -i -p ... -p as in --preserve-merges.)
When I began, there was code in the "next" branch that added the TODO instructions "mark", "reset" and "merge" to do merges properly and I based my work on it. The original pieces by Jörg Sommer can still be found here:
http://repo.or.cz/w/git/sbeyer.git/shortlog/6fabd85e8a777c26f3ae8ce11cb7f4265502ea7f
[etc]
Some more pointers:
http://thread.gmane.org/gmane.comp.version-control.git/148059
IIRC there's some rough consensus about the design, even if I'm not sure what it is :).
Of course a dream would be a way to rebase merge conflict resolutions instead of being limited to replaying conflict-free merges or resolving conflicts by hand. But that's a more complex story.
Quoted 9 lines · On Sunday 03 April 2011 19:20:56 Ramkumar Ramachandra wrote:
Hi,
I'd like to re-apply this year as a student because I really want to see (among other things), a sequencer in git.git. Also, since I worked on areas related to fast-import and remote helpers last year, I thought I should work on something completely orthogonal this year.
I now have a draft of my proposal ready, and I'd really appreciate feedback. Also, could someone mentor me?
Yeah! I would be happy to mentor you (or co-mentor you if someone else want to be involved)!
Quoted 10 lines
======================================================================
Project Proposal: Git Sequencer
Student: Ramkumar Ramachandra
Mentor: ?== The Objective ==
To write git-sequencer, a new builtin command, and implement existing commands on top of that. This should give the commands more functionality, improve their error handling, and make them faster.
You should first talk about extending git cherry-pick with --continue, --abort and --skip, because it can be very valuable already if done properly with many tests and if it's merged of course.
Quoted 2 lines
The project can only be considered successful if all (or most) of the code written gets merged into upstream.
Yeah, just say "most of the code". It is definitely good enough.
Quoted 11 lines
The Git Sequencer was a 2008 GSoC project as well; unfortunately most of the code did not get merged into git.git. The learning from all that work should serve as a huge headstart this year.
=== The Plan ===
1. Extend 'cherry-pick' with '--continue', '--abort', and '--skip' features, so that it works like (a subset of) the current '
git-rebase--interactive.sh'. This will require patching 'builtin/revert.c' in place, and merging it immediately. I plan to roughly follow the road laid out by Christian's 2010 series [1].
Yeah, the first step should be 'cherry-pick' with '--continue', '--abort', and '--skip' merged.
Quoted 8 lines
1.1. Factor out all calls to 'die' with 'return error' so so that we can pause the entire process when a commit doesn't apply automatically.
1.2. Create and populate TODO and DONE files, similar to the one that '
git-rebase--interactive.sh' creates. For now, it should simply give us information about why a 'cherry-pick' failed. Use these files with 'git-rebase--interactive.sh' to resume.
I am not sure it's a good thing to use 'git-rebase--interactive.sh' to resume the cherry-pick. The parsing code already exists, is not very big, is in C and has been reviewed and tested, so I think it's better to use.
Quoted 7 lines
1.3. Port selective tests from the current 't3404' to make sure that TODO and DONE are populated correctly; "stop on conflicting pick" is a good candidate.
1.4. Decouple the 'revert' functionality from the 'cherry-pick' functionality in '
revert.c'. Implement '--abort' for 'cherry-pick' and port "abort" test from 't3404'.
I am not sure decoupling revert and cherry-pick functionnalities is really needed, or I don't know what you mean exactly.
Quoted 3 lines
1.5. Implement parsing the TODO and DONE files into suitable data structures. Derive inspiration from the code written in 2008 to do this.
Yeah, you can use this patch:
http://article.gmane.org/gmane.comp.version-control.git/162198
Quoted 2 lines
1.6. Implement '--continue' and '--skip', and write suitable tests. Merge into upstream.
Great!
Quoted 3 lines
2. Factor out the 'cherry-pick' code from '
revert.c' into a new 'builtin/sequencer.c', and expose a simple cherry-picking API in 'sequencer.h'.
Yeah!
Quoted 4 lines
3. Implement a fresh '
cherry-pick.c' as a simple API call to the sequencer, and make sure that all the existing tests pass. After this, cherry-pick will not be a builtin command anymore*. Merge into upstream.
Yeah, it is closely linked with the previous point. So maybe this can be 2.2 and the previous one can be 2.1. And this way we know that at the end of 1) and at the end of 2) everything should be merged upstream.
Quoted 5 lines
4. Extend the sequncer to parse commands like 'execute', 'reword', 'squash', and 'fixup' that are specific to interactive rebasing. Carefully implement the functionality for each of these keywords in a step-wise manner, making sure that it inter-operates with 'rebase -i' seamlessly.
Great!
Quoted 4 lines
5. Port the entire testsuite from 'rebase -i', and rewrite '
git-rebase.sh', 'git-rebase--interactive.sh' to call the sequncer. The script should essentially build to a list of TODO instructions and pass it to the 'git-sequencer' binary. Merge into upstream.
Great! But as it is closely llinked with the previous point, maybe these 2 points should be 3.1 and 3.2.
Quoted 10 lines
6. [Optional] Lib'ify the sequncer: modify the sequencer API to include rebase-related functionality. Write '
rebase.c' as a bunch of API calls to the sequencer. Make sure that the existing tests pass. Merge into upstream.7. [Optional] Re-implement '
git-am.sh' as a thin wrapper over the
sequncer: 'am.c'. Bulk of this should be mbox parsing code. Make sure that all existing tests pass. Merge into upstream.* Is this a good change?
I think it is a good proposal.
Quoted 1 line
Are there any forseeable issues?
I don't see anything that others didn't told you about.
Quoted 8 lines
** [Optional] should be read as "If time permits"
== Timeline ===
Deriving from last year's experience, I've decided not to present a tight timeline. Instead, I simply have an outline: Get the extended cherry-pick functionality merged before mid-term evaluations, and the rest before the final evaluations.
I agree, but still you could perhaps state something like this:
- before mid june:
some patch series for everything in 1) should have been sent to the list
- before midterm evaluation:
everything in 1) should be merged upstream
some patch series for everything in 2) and 3) (or 2.1 and 2.2 if you use
the numbering I suggest) should have been sent to the list
- before the end of July:
everything in 2) and 3) should be merged upstream
some patch series for everything in 4) and 5) (or 3.1 and 3.2 if you use
the numbering I suggest) should have been sent to the list
- before final evaluation:
everything should be merged
I think it is better to have more details like the above because this way we can realize early that there is not a lot of time after the midterm evaluation.
Quoted 7 lines
== Who am I? ==
I'm Ramkumar Ramachandra, and I first started contributing to git.git in January 2010. Apart from doing fast-import and remote helper related work last year, I also authored and merged svnrdump into Subversion trunk in the same period.
Quoted 6 lines
== Notes ==
[1]: http://thread.gmane.org/gmane.comp.version-control.git/162183
======================================================================Thanks for reading.
Thanks for applying,
Christian.
Hi Christian,
Quoted 10 lines · Christian Couder
Quoted 7 lines · On Sunday 03 April 2011 19:20:56 Ramkumar Ramachandra wrote:
I'd like to re-apply this year as a student because I really want to see (among other things), a sequencer in git.git. Also, since I worked on areas related to fast-import and remote helpers last year, I thought I should work on something completely orthogonal this year.
I now have a draft of my proposal ready, and I'd really appreciate feedback. Also, could someone mentor me?
Yeah! I would be happy to mentor you (or co-mentor you if someone else want to be involved)!
Awesome! Thanks :)
Quoted 6 lines
Quoted 5 lines
== The Objective ==
To write git-sequencer, a new builtin command, and implement existing commands on top of that. This should give the commands more functionality, improve their error handling, and make them faster.
Quoted 8 lines
You should first talk about extending git cherry-pick with --continue, --abort and --skip, because it can be very valuable already if done properly with many tests and if it's merged of course.
Quoted 2 lines
The project can only be considered successful if all (or most) of the code written gets merged into upstream.
Yeah, just say "most of the code". It is definitely good enough.
Okay, here's the new objective:
Extend 'git cherry-pick' with '--continue', '--abort', and '--skip' features. This will ultimately be used to write git-sequencer, a new builtin command. The sequencer will provide a uniform interface over which existing commands like 'rebase', 'rebase -i' and 'am' can be re-implented. This should give the commands more functionality, improve their error handling, and make them faster. The project can only be considered successful if most of the code written gets merged into upstream.
Quoted 4 lines
Quoted 4 lines
1.1. Factor out all calls to 'die' with 'return error' so so that we can pause the entire process when a commit doesn't apply automatically.
Quoted 8 lines
Quoted 4 lines
1.2. Create and populate TODO and DONE files, similar to the one that '
git-rebase--interactive.sh' creates. For now, it should simply give us information about why a 'cherry-pick' failed. Use these files with 'git-rebase--interactive.sh' to resume.I am not sure it's a good thing to use '
git-rebase--interactive.sh' to resume the cherry-pick. The parsing code already exists, is not very big, is in C and has been reviewed and tested, so I think it's better to use.
Okay, noted.
Quoted 10 lines
Quoted 7 lines
1.3. Port selective tests from the current 't3404' to make sure that TODO and DONE are populated correctly; "stop on conflicting pick" is a good candidate.
1.4. Decouple the 'revert' functionality from the 'cherry-pick' functionality in '
revert.c'. Implement '--abort' for 'cherry-pick' and port "abort" test from 't3404'.I am not sure decoupling revert and cherry-pick functionnalities is really needed, or I don't know what you mean exactly.
What I was thinking when I wrote that: we should have a 'revert.c' independent of 'cherry-pick.c' after the sequencer is implemented (see 2). By "decouple" I meant: move code around so we don't have to use the enum { REVERT, CHERRY_PICK }.
Quoted 7 lines
Quoted 3 lines
1.5. Implement parsing the TODO and DONE files into suitable data structures. Derive inspiration from the code written in 2008 to do this.
Yeah, you can use this patch:
http://article.gmane.org/gmane.comp.version-control.git/162198
Yeah, this is exactly the patch I was referring to. I just forgot to include the link :p
Quoted 11 lines
Quoted 2 lines
1.6. Implement '--continue' and '--skip', and write suitable tests. Merge into upstream.
Great!
Quoted 3 lines
2. Factor out the 'cherry-pick' code from '
revert.c' into a new 'builtin/sequencer.c', and expose a simple cherry-picking API in 'sequencer.h'.Yeah!
Quoted 8 lines
Quoted 4 lines
3. Implement a fresh '
cherry-pick.c' as a simple API call to the sequencer, and make sure that all the existing tests pass. After this, cherry-pick will not be a builtin command anymore*. Merge into upstream.Yeah, it is closely linked with the previous point. So maybe this can be 2.2 and the previous one can be 2.1. And this way we know that at the end of 1) and at the end of 2) everything should be merged upstream.
Okay.
Quoted 8 lines
Quoted 5 lines
4. Extend the sequncer to parse commands like 'execute', 'reword', 'squash', and 'fixup' that are specific to interactive rebasing. Carefully implement the functionality for each of these keywords in a step-wise manner, making sure that it inter-operates with 'rebase -i' seamlessly.
Great!
Quoted 7 lines
Quoted 4 lines
5. Port the entire testsuite from 'rebase -i', and rewrite '
git-rebase.sh', 'git-rebase--interactive.sh' to call the sequncer. The script should essentially build to a list of TODO instructions and pass it to the 'git-sequencer' binary. Merge into upstream.Great! But as it is closely llinked with the previous point, maybe these 2 points should be 3.1 and 3.2.
Okay.
Quoted 8 lines
Quoted 8 lines
6. [Optional] Lib'ify the sequncer: modify the sequencer API to include rebase-related functionality. Write '
rebase.c' as a bunch of API calls to the sequencer. Make sure that the existing tests pass. Merge into upstream.7. [Optional] Re-implement '
git-am.sh' as a thin wrapper over the
sequncer: 'am.c'. Bulk of this should be mbox parsing code. Make sure that all existing tests pass. Merge into upstream.
I'll append Daniel's single-step-interrupt idea here, once I understand how to implement it fully.
Quoted 22 lines
Quoted 6 lines
== Timeline ===
Deriving from last year's experience, I've decided not to present a tight timeline. Instead, I simply have an outline: Get the extended cherry-pick functionality merged before mid-term evaluations, and the rest before the final evaluations.
I agree, but still you could perhaps state something like this:
- before mid june:
some patch series for everything in 1) should have been sent to the list
- before midterm evaluation:
everything in 1) should be merged upstream
some patch series for everything in 2) and 3) (or 2.1 and 2.2 if you use
the numbering I suggest) should have been sent to the list
- before the end of July:
everything in 2) and 3) should be merged upstream
some patch series for everything in 4) and 5) (or 3.1 and 3.2 if you use
the numbering I suggest) should have been sent to the list
- before final evaluation:
everything should be merged
Quoted 3 lines
I think it is better to have more details like the above because this way we can realize early that there is not a lot of time after the midterm evaluation.
Great suggestion! I'll include this in the next iteration of my proposal.
Thanks for the detailed review and the suggestions.
-- Ram
Quoted 2 lines · Christian Couder
Yeah, the first step should be 'cherry-pick' with '--continue', '--abort', and '--skip' merged.
I haven't looked at rebase-i machinery recently, but I wonder if it would just be a matter of making a multi-commit cherry-pick just prepare a bunch of "pick XXX" lines into .git/rebase-merge/rebase-todo file, make other trivial setups (like detaching HEAD, writing head-name and head files) and then execing "git rebase --continue"?
Quoted 9 lines · On Monday 04 April 2011 07:20:18 Junio C Hamano wrote:
Quoted 2 lines · Christian Couder
Yeah, the first step should be 'cherry-pick' with '--continue', '--abort', and '--skip' merged.
I haven't looked at rebase-i machinery recently, but I wonder if it would just be a matter of making a multi-commit cherry-pick just prepare a bunch of "pick XXX" lines into .git/rebase-merge/rebase-todo file, make other trivial setups (like detaching HEAD, writing head-name and head files) and then execing "git rebase --continue"?
It is probably quite easy to do that, but it would result in cherry-pick in C calling rebase-i in shell that itself calls cherry-pick in C (to pick individual commit). Instead with this GSoC I think we have the opportunity to have everything we needed in C.
Best regards,
Christian.
Hi Christian and Junio,
Quoted 11 lines · Christian Couder
Quoted 9 lines · On Monday 04 April 2011 07:20:18 Junio C Hamano wrote:
Quoted 2 lines · Christian Couder
Yeah, the first step should be 'cherry-pick' with '--continue', '--abort', and '--skip' merged.
I haven't looked at rebase-i machinery recently, but I wonder if it would just be a matter of making a multi-commit cherry-pick just prepare a bunch of "pick XXX" lines into .git/rebase-merge/rebase-todo file, make other trivial setups (like detaching HEAD, writing head-name and head files) and then execing "git rebase --continue"?
Quoted 4 lines
It is probably quite easy to do that, but it would result in cherry-pick in C calling rebase-i in shell that itself calls cherry-pick in C (to pick individual commit). Instead with this GSoC I think we have the opportunity to have everything we needed in C.
I thought I should clarify- in the original proposal, I didn't mean for cherry-pick to call "rebase -i" at all. When I said "use rebase to resume", I meant "try resuming by hand using rebase --continue to verify that cherry-pick has written the state information correctly" as an intermediate step in the cherry-pick development.
-- Ram
Heya,
Quoted 7 lines · Ramkumar Ramachandra
I'd like to re-apply this year as a student because I really want to see (among other things), a sequencer in git.git. Also, since I worked on areas related to fast-import and remote helpers last year, I thought I should work on something completely orthogonal this year.
I now have a draft of my proposal ready, and I'd really appreciate feedback. Also, could someone mentor me?
While I'm very interested in this project, I have no relevant experience. I'll definitely +1 your proposal though :).
Signature · 3 lines
Cheers, Sverre Rabbelier
Quoted 23 lines · Ramkumar Ramachandra
Hi,
I'd like to re-apply this year as a student because I really want to see (among other things), a sequencer in git.git. Also, since I worked on areas related to fast-import and remote helpers last year, I thought I should work on something completely orthogonal this year.
I now have a draft of my proposal ready, and I'd really appreciate feedback. Also, could someone mentor me?
======================================================================
Project Proposal: Git Sequencer
Student: Ramkumar Ramachandra
Mentor: ?== The Objective ==
To write git-sequencer, a new builtin command, and implement existing commands on top of that. This should give the commands more functionality, improve their error handling, and make them faster. The project can only be considered successful if all (or most) of the code written gets merged into upstream.
Quoted 3 lines
The Git Sequencer was a 2008 GSoC project as well; unfortunately most of the code did not get merged into git.git. The learning from all that work should serve as a huge headstart this year.
One of the things that is hard about sequencer is that it is ultimately a complete replacement for several differently-implemented programs in different languages, with different temporary file formats and differrent supported operations. As such, you could probably spend an entire summer just getting it reviewed, revised, and accepted, starting with a working implementation.
So I think your proposal is good in how [1/5] includes getting something useful merged. My suspicion is that the outcome will be something like that you implemented all 7 tasks and got 4 of them merged, assuming that you really push getting things merged as soon as they're ready, without spending too much time porting other things to use the core and getting the ports reviewed before the core is accepted.
I actually think that it would be a worthwhile feature for git's library code to have a uniform mechanism for communicating that it is requesting human intervention in the middle of a particular operation, where library operations which conflict with being able to continue this operation are either blocked or abort the operation, and the library is able to be told in general that the human intervention is done and the library operation should be finished now (or produce complaints about the user's work). That is, a library-level, single-interrupted-step "sequencer". For that matter, it should also apply to the common '"git merge" gets a conflict' case, and it would be useful to get some representational uniformity between that and cherry-pick getting a conflict.
I think replacing existing multi-step processes is going to be a lot more contentious and involve user-visible changes which involve matters of taste and such. But I think you can make a valuable contribution in how a single current step is handled before getting tangled in that, and be much more likely to get a useful outcome than if you try to tackle the whole problem.
-Daniel
*This .sig left intentionally blank*
Hi Daniel,
Quoted 11 lines · Daniel Barkalow
Quoted 9 lines · Ramkumar Ramachandra
To write git-sequencer, a new builtin command, and implement existing commands on top of that. This should give the commands more functionality, improve their error handling, and make them faster. The project can only be considered successful if all (or most) of the code written gets merged into upstream.
The Git Sequencer was a 2008 GSoC project as well; unfortunately most of the code did not get merged into git.git. The learning from all that work should serve as a huge headstart this year.
Quoted 6 lines
One of the things that is hard about sequencer is that it is ultimately a complete replacement for several differently-implemented programs in different languages, with different temporary file formats and differrent supported operations. As such, you could probably spend an entire summer just getting it reviewed, revised, and accepted, starting with a working implementation.
Agreed. I've chosen to use the same commands and temporary files as 'git-rebase--interactive.sh', because I think those commands are sufficient to implement everything else.
Quoted 6 lines
So I think your proposal is good in how [1/5] includes getting something useful merged. My suspicion is that the outcome will be something like that you implemented all 7 tasks and got 4 of them merged, assuming that you really push getting things merged as soon as they're ready, without spending too much time porting other things to use the core and getting the ports reviewed before the core is accepted.
Hm. In that case, we'll just have a sequencer that can cherry-pick -- I personally wouldn't be too happy with this outcome either.
Quoted 11 lines
I actually think that it would be a worthwhile feature for git's library code to have a uniform mechanism for communicating that it is requesting human intervention in the middle of a particular operation, where library operations which conflict with being able to continue this operation are either blocked or abort the operation, and the library is able to be told in general that the human intervention is done and the library operation should be finished now (or produce complaints about the user's work). That is, a library-level, single-interrupted-step "sequencer". For that matter, it should also apply to the common '"git merge" gets a conflict' case, and it would be useful to get some representational uniformity between that and cherry-pick getting a conflict.
Until 4/7, I'd only planned to make the 'git-sequencer' binary like the 'git-rebase--interactive.sh' script, except that it would accept a TODO file on stdin, instead of interactively opening up an editor.
Your idea is a slightly more ambitious version of what I'd planned for 6/7, especially since 'merge' contains a lot of cruft like MERGE_HEAD and CHERRY_PICK_HEAD. I can shift my focus after 4/7 though -- here's what I have in mind. Do you have something similar in mind?
enum commit_todo_action {
ACTION_PICK;
ACTION_REWORD;
ACTION_EDIT;
ACTION_SQUASH;
ACTION_FIXUP;
ACTION_EXEC;
};struct commit_todo_list {
struct commit *item;
enum commit_todo_action action;
struct commit_todo_list *next;
};int sequencer_cherry_pick(struct commit *base, struct commit_list *list); int sequncer_rebase(struct commit *base, struct commit_todo_list *list); int sequencer_handle_conflict(); /* Returns ABORT (1) or RESOLVED (0) */
/**
* The sequencer_handle_conflict function essentially starts with a
* working tree with unmerged files and results in either a working
* tree without unmerged files (in which case it returns 0), or simply
* returns 1. Advantage: Consistency. Each individual script will not
* have to maintain its own temporary files.
*/
Quoted 6 lines
I think replacing existing multi-step processes is going to be a lot more contentious and involve user-visible changes which involve matters of taste and such. But I think you can make a valuable contribution in how a single current step is handled before getting tangled in that, and be much more likely to get a useful outcome than if you try to tackle the whole problem.
Okay. I'll replace 5/7 - 7/7 in my proposal with an alternative as soon as I sketch out the details more clearly.
Thanks for your suggestions!
-- Ram
Hi Daniel,
Quoted 12 lines · Ramkumar Ramachandra
Quoted 11 lines · Daniel Barkalow
I actually think that it would be a worthwhile feature for git's library code to have a uniform mechanism for communicating that it is requesting human intervention in the middle of a particular operation, where library operations which conflict with being able to continue this operation are either blocked or abort the operation, and the library is able to be told in general that the human intervention is done and the library operation should be finished now (or produce complaints about the user's work). That is, a library-level, single-interrupted-step "sequencer". For that matter, it should also apply to the common '"git merge" gets a conflict' case, and it would be useful to get some representational uniformity between that and cherry-pick getting a conflict.
[...]
Quoted 9 lines
int
sequencer_handle_conflict(); /* Returns ABORT (1) or RESOLVED (0) *//**
* Thesequencer_handle_conflictfunction essentially starts with a
* working tree with unmerged files and results in either a working
* tree without unmerged files (in which case it returns 0), or simply
* returns 1. Advantage: Consistency. Each individual script will not
* have to maintain its own temporary files.
*/
Uh, no. I wrote this part in too quickly. Clearly needs more thought.
-- Ram
Quoted 28 lines · Ramkumar Ramachandra
Hi Daniel,
Quoted 12 lines · Ramkumar Ramachandra
Quoted 11 lines · Daniel Barkalow
I actually think that it would be a worthwhile feature for git's library code to have a uniform mechanism for communicating that it is requesting human intervention in the middle of a particular operation, where library operations which conflict with being able to continue this operation are either blocked or abort the operation, and the library is able to be told in general that the human intervention is done and the library operation should be finished now (or produce complaints about the user's work). That is, a library-level, single-interrupted-step "sequencer". For that matter, it should also apply to the common '"git merge" gets a conflict' case, and it would be useful to get some representational uniformity between that and cherry-pick getting a conflict.
[...]
Quoted 9 lines
int
sequencer_handle_conflict(); /* Returns ABORT (1) or RESOLVED (0) *//**
* Thesequencer_handle_conflictfunction essentially starts with a
* working tree with unmerged files and results in either a working
* tree without unmerged files (in which case it returns 0), or simply
* returns 1. Advantage: Consistency. Each individual script will not
* have to maintain its own temporary files.
*/
Quoted 2 lines
Uh, no. I wrote this part in too quickly. Clearly needs more thought.
Here's how I'm thinking about a single step:
The non-conflict case is:
$ git cherry-pick ... figure out what we're asked to do make the change to the working directory and index make the commit with info from the commit we're cherry-picking
The conflict case should be:
$ git cherry-pick ...
figure out what we're asked to do
make the change to the working directory and index
discover problem, set up for human assistance, tweak info to say that we
needed help
$ fix stuff
$ git continue
check that everything is how it should be
make the commit with info from the commit we're cherry-pickingThat is, the code that cherry-picks one commit can quit in the middle and resume after the user finishes helping, and the main entry point to git can resume that operation.
So, my thought was that you'd have something like:
cherry_pick_conflict = {
"cherry-pick", APPLIES_TO_CURRENT_BRANCH | IN_MIDDLE_OF_COMMIT, cherry_pick_verify_resolution,
cherry_pick_abort,
cherry_pick_post_resolution
};
int cherry_pick(struct commit *item)
{
save info on the commit, flags, etc needed to understand what we're doing
try to apply diff...
if (!rejected)
return cherry_pick_post_resolution();
try to use merge recursive...
if (!conflict)
return cherry_pick_post_resolution(); return report_conflict(cherry_pick_conflict);
}
int cherry_pick_verify_resolution(void)
{
if (still unmerged files) {
describe work still needed
return 1;
}
return 0;
}
int cherry_pick_abort(void)
{
restore info on what we'd started and delete state
clean up the working directory, index, etc
return 0;
}
int cherry_pick_post_resolution(void)
{
restore info on what we'd started and delete state
make the commit
return 0;
}
The important things are:
- arbitrary code can determine that you're in the middle of resolving some conflict, that the resolution of that conflict is about doing something to your current branch, and how to abort what you're doing, and how to finish it
- the same code gets run after the conflict has been resolved that would have been run immediately if the merge went smoothly
- cherry-pick can save whatever it needs to in its state file; that's its business, and the semantics here don't have to interact with other commands, because report_conflict() has taken care of interaction with other commands
The next step is to be able to have:
int sequencer()
{
save the list of steps, with no in-progress step return sequencer_post_resolution();
}
int sequencer_post_resolution()
{
finish any in-progress step
get the next step
if (no steps left)
return 0;
attempt step
if (!got_conflict)
return sequencer_post_resolution(); return report_conflict(sequencer_conflict);
}
Where the sequencer-level conflict nests around the cherry-pick-level conflict, and the generic "continue" completes things from the inside out.
I think, ultimately, that with this code structure in place, the am/rebase/rebase--interactive/sequencer details of how the multi-step process is recorded becomes less important. That way, your project can be successful even if you can't find a syntax for the sequencer file that meets the needs of all of these use cases. (Which is where I suspect you'll get bogged down.) If you can get all of the cases where git exits in order to get human intervention to share "everything that matters" and the core to "know what's in progress as far as anything else cares", I think that would be success, even if the various multi-step programs continue using their own state files.
-Daniel
*This .sig left intentionally blank*
Hi Daniel,
Quoted 15 lines · Daniel Barkalow
Quoted 14 lines · Ramkumar Ramachandra
Quoted 12 lines · Ramkumar Ramachandra
Quoted 11 lines · Daniel Barkalow
I actually think that it would be a worthwhile feature for git's library code to have a uniform mechanism for communicating that it is requesting human intervention in the middle of a particular operation, where library operations which conflict with being able to continue this operation are either blocked or abort the operation, and the library is able to be told in general that the human intervention is done and the library operation should be finished now (or produce complaints about the user's work). That is, a library-level, single-interrupted-step "sequencer". For that matter, it should also apply to the common '"git merge" gets a conflict' case, and it would be useful to get some representational uniformity between that and cherry-pick getting a conflict.
Quoted 1 line
Quoted 1 line
[...]
Thanks for the detailed response- I've rearragned your response and added some comments. I initially wanted to design it so that all state is persisted by the sequencer, but I can clearly see what's wrong with that approach now.
Quoted 10 lines
I think, ultimately, that with this code structure in place, the am/rebase/rebase--interactive/sequencer details of how the multi-step process is recorded becomes less important. That way, your project can be successful even if you can't find a syntax for the sequencer file that meets the needs of all of these use cases. (Which is where I suspect you'll get bogged down.) If you can get all of the cases where git exits in order to get human intervention to share "everything that matters" and the core to "know what's in progress as far as anything else cares", I think that would be success, even if the various multi-step programs continue using their own state files.
Excellent. The crux of the idea: The sequencer should serve as the entry/ exit point for Git when any operation requires user intervention to proceed. For this, it should have information about how we got to this point, and how to proceed after the user intervention is complete; this information is contained in:
Quoted 6 lines
cherry_pick_conflict= {
"cherry-pick",APPLIES_TO_CURRENT_BRANCH|IN_MIDDLE_OF_COMMIT,cherry_pick_verify_resolution,
cherry_pick_abort,
cherry_pick_post_resolution
};
Wait -- isn't it missing a skip callback?
cherry_pick_conflict = {
"cherry-pick", APPLIES_TO_CURRENT_BRANCH | IN_MIDDLE_OF_COMMIT, cherry_pick_verify_resolution,
cherr_pick_skip,
cherry_pick_abort,
cherry_pick_post_resolution
};
This information is passed to report_conflict(), which takes care of user intervention. The user can do whatever she wants and then ask the sequencer to "continue", "skip" or "abort":
Quoted 2 lines
Where the sequencer-level conflict nests around the cherry-pick-level conflict, and the generic "continue" completes things from the inside out.
Right. And then the sequencer fires the appropriate callback and returns control to the parent command. More notes:
Quoted 4 lines
- cherry-pick can save whatever it needs to in its state file; that's its business, and the semantics here don't have to interact with other commands, because
report_conflict()has taken care of interaction with other commands
At the end of a merge for example, the MERGE_MSG needs to be retrieved to create a new merge commit. The sequencer des not need to know anything about this, since this is specific to 'merge'.
Quoted 4 lines
- arbitrary code can determine that you're in the middle of resolving some conflict, that the resolution of that conflict is about doing something to your current branch, and how to abort what you're doing, and how to finish it
Any arbitrary code simply has to ask the sequencer about the state of the intermediate files that report_conflict() uses. They don't have to worry about command-specific intermediate files.
Quoted 2 lines
- the same code gets run after the conflict has been resolved that would have been run immediately if the merge went smoothly
Using these callbacks, there is no need for if-else ugliness inside the specific command to decide what to do next.
I suppose we can call this idea a "generic conflict handler". I like it very much, and I'll definitely include this as part of my GSoC work. Thanks for taking the time to explain it in such detail :)
-- Ram
Quoted 36 lines · Ramkumar Ramachandra
Hi Daniel,
Quoted 15 lines · Daniel Barkalow
Quoted 14 lines · Ramkumar Ramachandra
Quoted 12 lines · Ramkumar Ramachandra
Quoted 11 lines · Daniel Barkalow
I actually think that it would be a worthwhile feature for git's library code to have a uniform mechanism for communicating that it is requesting human intervention in the middle of a particular operation, where library operations which conflict with being able to continue this operation are either blocked or abort the operation, and the library is able to be told in general that the human intervention is done and the library operation should be finished now (or produce complaints about the user's work). That is, a library-level, single-interrupted-step "sequencer". For that matter, it should also apply to the common '"git merge" gets a conflict' case, and it would be useful to get some representational uniformity between that and cherry-pick getting a conflict.
Quoted 1 line
Quoted 1 line
[...]
Thanks for the detailed response- I've rearragned your response and added some comments. I initially wanted to design it so that all state is persisted by the sequencer, but I can clearly see what's wrong with that approach now.
Quoted 10 lines
I think, ultimately, that with this code structure in place, the am/rebase/rebase--interactive/sequencer details of how the multi-step process is recorded becomes less important. That way, your project can be successful even if you can't find a syntax for the sequencer file that meets the needs of all of these use cases. (Which is where I suspect you'll get bogged down.) If you can get all of the cases where git exits in order to get human intervention to share "everything that matters" and the core to "know what's in progress as far as anything else cares", I think that would be success, even if the various multi-step programs continue using their own state files.
Quoted 3 lines
Excellent. The crux of the idea: The sequencer should serve as the entry/ exit point for Git when any operation requires user intervention to proceed.
I'm a bit surprised by the idea of calling that "the sequencer" (rather than having "the sequencer" be a command), but I actually think you're entirely right to do so. Be sure to be very explicit about that, though, because people will probably start with the wrong idea of what you're proposing otherwise.
Quoted 4 lines
For this, it should have information about
how we got to this point, and how to proceed after the user intervention is complete; this information is contained in:
Quoted 8 lines
Quoted 6 lines
cherry_pick_conflict= {
"cherry-pick",APPLIES_TO_CURRENT_BRANCH|IN_MIDDLE_OF_COMMIT,cherry_pick_verify_resolution,
cherry_pick_abort,
cherry_pick_post_resolution
};Wait -- isn't it missing a skip callback?
I think "skip" is actually: abort the lowest-level conflict and continue the next-level conflict. If you're doing a rebase, and the rebase is doing a "pick", and the pick got a conflict, --skip means that you abort the pick (to get back to the state where the earlier commits have been picked but this one hasn't been started, followed by having the rebase continue with what it was going to do after the pick completed.
So I don't think you need a "skip" callback, as long as you've untangled the levels cleanly and get the nesting support right.
Quoted 11 lines
cherry_pick_conflict= {
"cherry-pick",APPLIES_TO_CURRENT_BRANCH|IN_MIDDLE_OF_COMMIT,cherry_pick_verify_resolution,
cherr_pick_skip,
cherry_pick_abort,
cherry_pick_post_resolution
};This information is passed to
report_conflict(), which takes care of user intervention. The user can do whatever she wants and then ask the sequencer to "continue", "skip" or "abort":
Right, although I think:
$ git cheery-pick some-sha1 Conflict needs to be fixed now!
$ git skip
should give an error message about the current conflict not being a step of a larger process. That is, you can always "continue" or "abort", but you can only "skip" if there's something to skip to, even if it's only the higher-order sequence reporting that it's completed successfully.
Quoted 6 lines
Quoted 2 lines
Where the sequencer-level conflict nests around the cherry-pick-level conflict, and the generic "continue" completes things from the inside out.
Right. And then the sequencer fires the appropriate callback and returns control to the parent command. More notes:
Quoted 8 lines
Quoted 4 lines
- cherry-pick can save whatever it needs to in its state file; that's its business, and the semantics here don't have to interact with other commands, because
report_conflict()has taken care of interaction with other commandsAt the end of a merge for example, the
MERGE_MSGneeds to be retrieved to create a new merge commit. The sequencer des not need to know anything about this, since this is specific to 'merge'.
Right. And remove_branch_state() wouldn't even need to know about MERGE_MSG like it does now, because that would be handled by aborting any in-progress merge.
Quoted 8 lines
Quoted 4 lines
- arbitrary code can determine that you're in the middle of resolving some conflict, that the resolution of that conflict is about doing something to your current branch, and how to abort what you're doing, and how to finish it
Any arbitrary code simply has to ask the sequencer about the state of the intermediate files that
report_conflict()uses. They don't have to worry about command-specific intermediate files.
Right.
Quoted 9 lines
Quoted 2 lines
- the same code gets run after the conflict has been resolved that would have been run immediately if the merge went smoothly
Using these callbacks, there is no need for if-else ugliness inside the specific command to decide what to do next.
I suppose we can call this idea a "generic conflict handler". I like it very much, and I'll definitely include this as part of my GSoC work. Thanks for taking the time to explain it in such detail :)
You're welcome. Thanks for proposing to actually implement it. :)
-Daniel
*This .sig left intentionally blank*
Hi Daniel,
Quoted 10 lines · Daniel Barkalow
Quoted 3 lines · Ramkumar Ramachandra
Excellent. The crux of the idea: The sequencer should serve as the entry/ exit point for Git when any operation requires user intervention to proceed.
I'm a bit surprised by the idea of calling that "the sequencer" (rather than having "the sequencer" be a command), but I actually think you're entirely right to do so. Be sure to be very explicit about that, though, because people will probably start with the wrong idea of what you're proposing otherwise.
Ah. I'll make sure to word it unambiguously in the proposal, and link to this thread :)
Quoted 20 lines
Quoted 4 lines
For this, it should have information about
how we got to this point, and how to proceed after the user intervention is complete; this information is contained in:Quoted 8 lines
Quoted 6 lines
cherry_pick_conflict= {
"cherry-pick",APPLIES_TO_CURRENT_BRANCH|IN_MIDDLE_OF_COMMIT,cherry_pick_verify_resolution,
cherry_pick_abort,
cherry_pick_post_resolution
};Wait -- isn't it missing a skip callback?
I think "skip" is actually: abort the lowest-level conflict and continue the next-level conflict. If you're doing a rebase, and the rebase is doing a "pick", and the pick got a conflict, --skip means that you abort the pick (to get back to the state where the earlier commits have been picked but this one hasn't been started, followed by having the rebase continue with what it was going to do after the pick completed.
Quoted 2 lines
So I don't think you need a "skip" callback, as long as you've untangled the levels cleanly and get the nesting support right.
Okay. I'm not yet entirely clear about this yet, but I think it should be sorted out during implementation.
Quoted 17 lines
Quoted 11 lines
cherry_pick_conflict= {
"cherry-pick",APPLIES_TO_CURRENT_BRANCH|IN_MIDDLE_OF_COMMIT,cherry_pick_verify_resolution,
cherr_pick_skip,
cherry_pick_abort,
cherry_pick_post_resolution
};This information is passed to
report_conflict(), which takes care of user intervention. The user can do whatever she wants and then ask the sequencer to "continue", "skip" or "abort":Right, although I think:
$ git cheery-pick some-sha1 Conflict needs to be fixed now!
Quoted 6 lines
$ git skipshould give an error message about the current conflict not being a step of a larger process. That is, you can always "continue" or "abort", but you can only "skip" if there's something to skip to, even if it's only the higher-order sequence reporting that it's completed successfully.
Right, got it.
-- Ram
PATCH v2 1/1 Git Sequencer
In reply to Ramkumar RamachandraHi,
Thanks for all the feedback on the first iteration!
This iteration of the proposal has already been submitted via the Melange interface. More comments/ feedback are always welcome.
======================================================================
Project Proposal: Git Sequencer
Student: Ramkumar Ramachandra
Mentor: Christian Couder
== The Objective ==
Extend 'git cherry-pick' with '--continue', '--abort', and '--skip' features. This will ultimately be used to write git-sequencer, a new builtin command. The sequencer will provide a uniform interface over which existing commands like 'rebase', 'rebase -i' and 'am' can be re-implented. This should give the commands more functionality, improve their error handling, and make them faster. The project can only be considered successful if most of the code written gets merged into upstream.
The Git Sequencer was a 2008 GSoC project as well; unfortunately most of the code did not get merged into git.git. The learning from all that work should serve as a huge headstart this year [1].
=== The Plan ===
1. Extend 'cherry-pick' with '--continue', '--abort', and '--skip' features, so that it works like (a subset of) the current 'git-rebase--interactive.sh'. This will require patching 'builtin/revert.c' in place, and merging it immediately. I plan to roughly follow the road laid out by Christian's 2010 series [2].
1.1. Factor out all calls to 'die' with 'return error' so so that we can pause the entire process when a commit doesn't apply automatically.
1.2. Create and populate TODO and DONE files, similar to the one that 'git-rebase--interactive.sh' creates. For now, it should simply give us information about why a 'cherry-pick' failed.
1.3. Port selective tests from the current 't3404' to make sure that TODO and DONE are populated correctly; "stop on conflicting pick" is a good candidate.
1.4. Decouple the 'revert' functionality from the 'cherry-pick' functionality in 'revert.c'. Implement '--abort' for 'cherry-pick' and port "abort" test from 't3404'.
1.5. Implement parsing the TODO and DONE files into suitable data structures. Derive inspiration from the code written in 2008 to do this [3].
1.6. Implement '--continue' and '--skip', and write suitable tests.
2. Build a sequencer so that just has cherry-picking functionality. This mostly involves moving code written in (1) around, and crafting a general API for handling conflicts.
2.1. Factor out the 'cherry-pick' code from 'revert.c' into a new 'builtin/sequencer.c'.
2.2. Write an API for handling conflicts, so that the sequencer is ultimate entry/ exit point for all user intervention in a multi-step process [4].
2.3. Implement a fresh 'cherry-pick.c' on top of the sequencer. Make sure that all the existing tests pass.
2.4 [Optional] Patch 'builtin/merge.c' to use the conflict handler in the sequencer.
3. Extend the sequencer to accomodate the functionality provided by 'rebase -i'.
3.1. Parse commands like 'execute', 'reword', 'squash', and 'fixup' that are specific to interactive rebasing. Carefully implement the functionality for each of these keywords in a step-wise manner.
3.2. [Optional] Port the '--preserve-merges' option of 'rebase' to the sequencer. Port relevant tests from 't3409'.
4. [Optional] Lib'ify the sequncer. Modify the API to include rebase-related functionality. Write 'rebase.c' as a bunch of API calls to the sequencer. Make sure that the existing tests pass.
5. [Optional] Re-implement 'git-am.sh' as a thin wrapper over the
sequncer: 'am.c'. Bulk of this should be mbox parsing code. Make sure that all existing tests pass.
[Optional] should be read as "If time permits"
== Timeline ===
- Before mid june: (1) should be implemented, and a series should be sent out to the list for review.
- Before midterm evaluation: (1) should be merged, and an implementation of (2) should be sent to the list.
- Before the end of July: (2) should be merged, and an implementation of (3) should be sent to the list.
- Before final evaluation: (3) should be merged.
== Who am I? ==
I'm Ramkumar Ramachandra, and I first started contributing to git.git in January 2010. Apart from doing fast-import and remote helper related work last year, I also authored and merged svnrdump into Subversion trunk in the same period.
== Notes ==
[1]: http://repo.or.cz/w/git/sbeyer.git
[2]: http://thread.gmane.org/gmane.comp.version-control.git/162183
[3]: http://article.gmane.org/gmane.comp.version-control.git/162198
[4]: http://thread.gmane.org/gmane.comp.version-control.git/170834
======================================================================
Thanks for reading.
-- Ram
Hi,
Quoted 11 lines · Ramkumar Ramachandra
2. Build a sequencer so that just has cherry-picking functionality. This mostly involves moving code written in (1) around, and crafting a general API for handling conflicts.
2.1. Factor out the 'cherry-pick' code from '
revert.c' into a new 'builtin/sequencer.c'.2.2. Write an API for handling conflicts, so that the sequencer is ultimate entry/ exit point for all user intervention in a multi-step process [4].
This one may be more difficult than we can guess right now, and it is linked with 2.4 that is optional too. And I wouldn't like you to spend too much time on it if it appears to be quite difficult. So I'd suggest that you switch 2.2 and 2.3 and make the new 2.3 optional.
Quoted 8 lines
2.3. Implement a fresh '
cherry-pick.c' on top of the sequencer. Make sure that all the existing tests pass.2.4 [Optional] Patch '
builtin/merge.c' to use the conflict handler in the sequencer.3. Extend the sequencer to accomodate the functionality provided by 'rebase -i'.
s/accomodate/accommodate/
Quoted 3 lines
3.1. Parse commands like 'execute', 'reword', 'squash', and 'fixup' that are specific to interactive rebasing. Carefully implement the functionality for each of these keywords in a step-wise manner.
I think that here you could add something like:
3.2. Make 'rebase -i' use the sequencer when '--preserve-merges' option is not used.
Quoted 4 lines
3.2. [Optional] Port the '--preserve-merges' option of 'rebase' to the sequencer. Port relevant tests from 't3409'.
4. [Optional] Lib'ify the sequncer.
s/sequncer/sequencer/
Quoted 6 lines
Modify the API to
include rebase-related functionality. Write 'rebase.c' as a bunch of API calls to the sequencer. Make sure that the existing tests pass.5. [Optional] Re-implement '
git-am.sh' as a thin wrapper over the
sequncer: 'am.c'.
s/sequncer/sequencer/
Quoted 4 lines
Bulk of this should be mbox parsing code. Make sure that all existing tests pass.
[Optional] should be read as "If time permits"
Otherwise I like it very much.
Thanks,
Christian.
Hi Christian,
Quoted 14 lines · Christian Couder
Quoted 11 lines · Ramkumar Ramachandra
2. Build a sequencer so that just has cherry-picking functionality. This mostly involves moving code written in (1) around, and crafting a general API for handling conflicts.
2.1. Factor out the 'cherry-pick' code from '
revert.c' into a new 'builtin/sequencer.c'.2.2. Write an API for handling conflicts, so that the sequencer is ultimate entry/ exit point for all user intervention in a multi-step process [4].
Quoted 6 lines
This one may be more difficult than we can guess right now, and it is linked with 2.4 that is optional too. And I wouldn't like you to spend too much time on it if it appears to be quite difficult. So I'd suggest that you switch 2.2 and 2.3 and make the new 2.3 optional.
[...]
Okay. Fixed other nits as well.
Thanks.
-- Ram