Re: RFC: allowing multiple parallel sequencers
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 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: allowing multiple parallel sequencers
On Tue, Apr 02, 2013 at 11:06:28AM -0700, Junio C Hamano wrote: > Neil Horman 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: allowing multiple parallel sequencers
Neil Horman 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 ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: allowing multiple parallel sequencers
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
