add mechanism to create a patch stack
drewdeponte opened this issue · comments
Ideally what I am thinking is something like the following:
git ps create <patch-stack-name> <base-ref>
where <base-ref> would be the reference it would base the patch stack on. Maybe this <base-ref> should be optional and if not provided it defaults to being based on what the current patch stacks base is.
Lets say I want to work on a series of patches in isolation from the rest of the patch stack. In theory this could be a two step process.
- create a new patch stack based on the same thing the current patch stack is based on (e.g.
origin/main). - copy range of patches over to new patch stack (this doesn't exist yet either) - but in theory it would just cherry pick the series of patches over to the top of the new stack. ( #41 )
I feel like this is similar to this issue, so I decided to leave this here rather than making a new issue. Potentially a new issue should be opened for this.
After talking last night about "sub stacks" I was thinking a potential way to automatically rearrange and group stacks could be by looking for a prefix like XX-## following the Jira methodology of adding your issue number to the start of a commit message.
For example I am about to move 5 down below 4, this isn't a great example since not all the messages are following the naming convention. That's easily fixed by hand, but also a case to handle -- do you try to get them as close together assuming that no prefix means it's part of the nearest previous prefix, or do you just abort because not every message is following the convention. There's also likely other conventions like Github prefixing the #issueNumber.
I also like the idea of isolated/substacks, because ideally you could request a review against that feature stack and it would know the associated patches to go in that stack.
I am not sure I would want to bake some convention like that into git ps itself. But maybe we provide the underlying features so people could easily extend git-ps to support a naming convention like that.
Given that git-ps supports multiple stacks already. It just doesn't provide a easy mechanism to create them and doesn't really facilitate copying & moving patches between stacks. Which seems like a natural robust direction to go.