Add support for submitting partial stacks
See original GitHub issueDear @ezyang,
one of the beautiful things of ghstack is that I don’t need to handle so many branches for a stacked PR workflow anymore. However, I usually have part of the stack I’m working on ready for review and another part (the tail) that is still WIP, where I don’t want to open PRs yet, because I don’t want to commit (no pun intended) to a final look of my chain of commits that are yet to come and delete them without poluting github with many PRs.
As far as I know ghstack
submits/updates from the HEAD
up.
I now see that submitting a partial stack is as easy as checking out the respective most-downstream commit and running ghstack
from this detached HEAD state. This is however not perfect because next I need to rebase my working branch on top of the detached HEAD (which has a new commit ID now!) etc.
I came up with a porcelain bash function ghpartial <commit sha>
that takes care of what would ideally happen if ghstack <commit sha>
would be run (in my humble opinion 😃 )
ghpartial () {
BRANCH=$(git rev-parse --abbrev-ref HEAD)
SUBMIT_BRANCH=$BRANCH-submit
SUBMIT_COMMIT=$1
DIRTY=false
if [[ ! -z $(git status -s) ]]
then
echo "stashing uncommited changes..."
DIRTY=true
git stash -u
fi
if ! git show-ref --quiet refs/heads/$SUBMIT_BRANCH
then
echo "creating submit branch"
git checkout -b $SUBMIT_BRANCH
fi
git checkout $SUBMIT_BRANCH
git reset --hard $SUBMIT_COMMIT
ghstack
git checkout $BRANCH
git rebase $SUBMIT_BRANCH
if [ "$DIRTY" = true ]
then
git stash pop
fi
echo "All done. continue chipping away..."
}
(This keeps a branch around that shows how much of the work was submitted already, which is nice for my personal needs because I rebase the current working branch a lot and then it can be handy to have this marker in a prettyfied git log --graph --full-history
view)
Would you like a PR for adding such an argument to ghstack natively? Maybe you have ideas how you would like it to be implemented?
Anyway, this tool is just a blaze to use and I convinced half of the people on my team to switch over after presenting it to them recently! Incredibly useful work ❤️
Best, Zacharias
Issue Analytics
- State:
- Created a year ago
- Comments:5 (3 by maintainers)
Top GitHub Comments
I am not sure these are the same thing. There is submitting of a new stack and the updating of a stack. Submitting a new stack should be up to a defined point (and default to the current rev in the stack) . Commits above that stack should be omitted and potentially added at a later date.
Updating a stack can still just update the entire stack even if it means adding another pr to the stack.
But perhaps I am not fully understanding the issue.
yeah, i heard stackless might actually be really good for this workflow but i’ve been too lazy to try it lol