Add support for submitting partial stacks

[Zacharias Fisches]

Dear @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

[Edward Z. Yang]

Partial stack updates would be great. The last time I thought about how to implement this natively I got a bit stuck and wrote it up here: https://github.com/ezyang/ghstack#ripley-cupboard Maybe you will have better luck than me.

[Brandon Bennett]

Partial stack updates would be great.

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.

[Edward Z. Yang]

oh if you want to submit a prefix of the stack, the hack I use is git rebase -i $(git merge-base origin/master HEAD), get to the commit I want to submit, run ghstack there, and then finish off the rebase or whatever. But integrated support for this would be good too

[Brandon Bennett]

Ah yes that makes sense. I guess this is still more of a sl problem where HEAD is a bit more nebulous and the idea of being halfway up a stack doesn't exist in pure Git.

[Edward Z. Yang]

yeah, i heard stackless might actually be really good for this workflow but i've been too lazy to try it lol