RFC: allowing multiple parallel sequencers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]