[PATCH 0/7] New sequencer workflow!

[Ramkumar Ramachandra <artagnon@gmail.com>]

Hi,

After days of bending my mind around the backward-compatibility
problem, I'm happy to announce that we finally have an implementation!
This series preserves the old workflow:

  $ git cherry-pick foo
  ... conflict ...
  $ echo "resolved" >problematicfile
  $ git add problematicfile
  $ git commit

  $ git cherry-pick foo..bar
  ... conflict ...
  $ echo "resolved" >problematicfile
  $ git add problematicfile
  $ git commit
  $ git revert --continue # No, there are no typos

And introduces a brand new workflow:

  $ git cherry-pick foo
  ... conflict ...
  $ echo "resolved" >problematicfile
  $ git add problematicfile
  $ git sequencer --continue

  $ git cherry-pick foo..bar
  ... conflict ...
  $ echo "resolved" >problematicfile
  $ git add problematicfile
  $ git sequencer --continue

  $ git revert moo..baz
  ... conflict ...
  $ echo "resolved" >problematicfile
  $ git add problematicfile
  $ git sequencer --continue

In other words, it just doesn't matter how you started what sequencing
operation: you can always continue a it with "git sequencer
--continue" and reset it with "git sequencer --reset".

This series is reasonably well-polished and based on
rr/revert-cherry-pick (since the topic hasn't made it to 'master'
yet).  The only downside is that it's very complicated, and I've tried
my best to explain the motivation for everything in the commit
messages.  Needless to say, it requires a huge amount of testing to
catch unpleasant corner cases.

Part 1 moves a lot of code from builtin/revert.c to sequencer.c.

Parts 2, 3, 4 carefully work around some complex issues related to
'.git/CHERRY_PICK_HEAD'.

Part 5 introduces a new git-sequencer builtin.  Although it's
empty'ish now, I'd argue that adding it now helps think about the
unified interface.  Any suggestions on what concrete function it
should implement?  I'm thinking of something along the lines of
'rebase -i'.

Part 6 is the patch that tells the sequencer "how to continue".  As
more commands grow sequencer functionalities, it will become clear
that committing isn't the only way to continue, but I think it's good
for the moment.

Part 7 is the icing on the cake.  Enjoy.

I'd sent out $gmane/184859 last week as a sanity check: thanks to
Junio and Jonathan for looking at it.  It's always comforting to know
that I haven't lost my head yet :)

If you're looking to get involved before this series hits 'pu', use
the "sequencer" branch of my Git fork on Github:
http://github.com/artagnon/git

Thanks.

-- Ram

Ramkumar Ramachandra (7):
  sequencer: factor code out of revert builtin
  sequencer: invalidate sequencer state without todo
  sequencer: handle single-commit pick as special case
  sequencer: handle cherry-pick conflict in last commit
  sequencer: introduce git-sequencer builtin
  sequencer: teach '--continue' how to commit
  sequencer: teach parser about CHERRY_PICK_HEAD

 .gitignore                                         |    1 +
 Documentation/git-sequencer.txt                    |   33 +
 Makefile                                           |    1 +
 builtin.h                                          |    1 +
 builtin/revert.c                                   |  821 +-------------------
 builtin/sequencer.c                                |   52 ++
 git.c                                              |    1 +
 sequencer.c                                        |  842 +++++++++++++++++++-
 sequencer.h                                        |   26 +
 ...-cherry-pick-sequence.sh => t3510-sequencer.sh} |  140 +---
 ...-sequence.sh => t3511-cherry-pick-sequencer.sh} |  124 +---
 11 files changed, 1002 insertions(+), 1040 deletions(-)
 create mode 100644 Documentation/git-sequencer.txt
 create mode 100644 builtin/sequencer.c
 copy t/{t3510-cherry-pick-sequence.sh => t3510-sequencer.sh} (60%)
 rename t/{t3510-cherry-pick-sequence.sh => t3511-cherry-pick-sequencer.sh} (59%)

-- 
1.7.6.351.gb35ac.dirty