RFC: allowing multiple parallel sequencers

RFC: allowing multiple parallel sequencers

[Neil Horman]

Hey-
	I've recently started looking into the possibility of having git support
multiple in-progress sequencers, and wanted to solicit opinions for how best to
do it.  The use case is primarily for cherry-pick - i.e. I often have need to
cherry pick a large set of commits to an older kernel, and I may do this for
several work efforts in parallel.  As such, it would be great if I could be able
to have multiple sequencer states in progress that could be swapped out with one
another.  I know this could be done manually by saving the sequencer directory
to another name and moving it back, but it would be really nice if there was
something a bit more polished and integrated.  The thoughts I had were:

1) A per branch sequence directory - when creating the sequence directory,
prepend the name of the branch that you are on to the sequencer directory name,
and lookup the sequencer using that prefix.  This would fit quite well I think.
It would allow us to maintain a sequencer per branch, and would be relatively
easy to implement (we would need to have a generic function to return the
current branch name, and some extra check to delete sequencers when branches are
deleted, but nothing too difficult).  It would be problematic however, in that
working in detached head state would preclude the use of the mechanism (we could
work around that by using a global sequencer in detached head mode, or we could
add an option to specify a sequencer prefix).

2) Augment the git-stash command to save sequencer state optionally.  This would
be somewhat more difficult to implement I think (we would need to add
.git/sequencer/* to the untracked file list when creating the stash commit).  It
would however allow arbitrary sequencers to be used on arbitrary branches
(including detached head mode, if thats useful).

So, before I went implementing, I wanted to solicit opinions here.  Does anyone
have any thoughts (including completely different directions to move in for this
feature)?

Thanks!
Neil

Re: RFC: allowing multiple parallel sequencers

[Junio C Hamano]

Neil Horman <nhorman@tuxdriver.com> writes:

> 	I've recently started looking into the possibility of having git support
> multiple in-progress sequencers, and wanted to solicit opinions for how best to
> do it.... The thoughts I had were:
>
> 1) A per branch sequence directory...
> 2) Augment the git-stash command...

3) A per branch working tree.

That is how I would do this myself, anyway ;-)

Re: RFC: allowing multiple parallel sequencers

[Neil Horman]

On Tue, Apr 02, 2013 at 11:06:28AM -0700, Junio C Hamano wrote:
> Neil Horman <nhorman@tuxdriver.com> writes:
> 
> > 	I've recently started looking into the possibility of having git support
> > multiple in-progress sequencers, and wanted to solicit opinions for how best to
> > do it.... The thoughts I had were:
> >
> > 1) A per branch sequence directory...
> > 2) Augment the git-stash command...
> 
> 3) A per branch working tree.
> 
> That is how I would do this myself, anyway ;-)
> 
Not sure I completely follow.  Are you suggesting that all untracked
files, indexes and meta data in .git be saved during a branch switch?

Thanks
Neil

Re: RFC: allowing multiple parallel sequencers

[Neil Horman]

On Tue, Apr 02, 2013 at 03:06:51PM -0400, Neil Horman wrote:
> On Tue, Apr 02, 2013 at 11:06:28AM -0700, Junio C Hamano wrote:
> > Neil Horman <nhorman@tuxdriver.com> writes:
> > 
> > > 	I've recently started looking into the possibility of having git support
> > > multiple in-progress sequencers, and wanted to solicit opinions for how best to
> > > do it.... The thoughts I had were:
> > >
> > > 1) A per branch sequence directory...
> > > 2) Augment the git-stash command...
> > 
> > 3) A per branch working tree.
> > 
> > That is how I would do this myself, anyway ;-)
> > 
> Not sure I completely follow.  Are you suggesting that all untracked
> files, indexes and meta data in .git be saved during a branch switch?
> 
> Thanks
> Neil
> 
> --
Scratch that, after some digging I located the git-new-workdir script in the
contrib directory, which does what we're talking about here.

Thanks!
Neil

> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>