-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for submitting partial stacks #101
Comments
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. |
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. |
oh if you want to submit a prefix of the stack, the hack I use is |
Ah yes that makes sense. I guess this is still more of a |
yeah, i heard stackless might actually be really good for this workflow but i've been too lazy to try it lol |
Fixes #123 Fixes #101 Signed-off-by: Edward Z. Yang <[email protected]> [ghstack-poisoned]
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 theHEAD
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 ifghstack <commit sha>
would be run (in my humble opinion :) )(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
The text was updated successfully, but these errors were encountered: