Add options for deciding when a branch is ready

[Gelio]

Hey, I've got another idea that would ease my workflow.

At the moment, git stack --push will push all ready branches. Ignoring WIP commits (I don't use them at the moment), a branch will be considered ready if it is not stacked on top of another development branch.

This is great when there are many branches on top of the protected branch directly, since git stack --push will be able to push all of them. It is not helping, however, if I want to push out a single stack of branches to create multiple PRs (master <- a <- b <- c) and allow reviewing all of them in parallel.

I am often facing situations where I need to work on one feature and cannot branch out of the protected branch because I rely on the changes done previously that haven't been merged yet (they are earlier in the stack).

I would love to be able to tell git stack --push to push all branches on the current stack instead of pushing only the one that is directly on top of the protected branch.

Possible solutions

I see the following possible solutions to this problem:

1. Allow manually marking a branch as ready with a new command. This branch will be pushed even if it contains WIP commits or is not on top of the protected branch directly.

2. Add configuration options for deciding when a branch is ready:

   • is directly on top of a protected branch
   • has WIP commits

   This would let users decide when they want their branches to be pushed.

Workaround

Thanks to git stack displaying a nice preview of the stacks, I can see which branches are on the current stack and do git push origin [branch names here]). It requires me to write the branch names manually, but git stack makes it easier than the generic git branch.

One thing that would make it easier is a command that would list the branches on the current stack. Then, I could do:

git push origin $(git stack --current-stack-branches)

or something similar, depending on how newlines are handled.

That is a workaround in case the solution to the pushing problem is not so easy

[epage]

It is not helping, however, if I want to push out a single stack of branches to create multiple PRs (master <- a <- b <- c) and allow reviewing all of them in parallel.

Part of the reason for that limitation is we are making the assumption that the stacked PR review workflow is too busted to support :). If there have been improvements to it, that'd be great! I can see this being made configurable since the ability to handle stacked PR reviews is contingent on the service being used.

I have also considered taking the approach "if there is already a remote branch, push" so only the first push is an issue (though I'm unsure if I'd want to take WIP into account with that).

One thing that would make it easier is a command that would list the branches on the current stack. T

This would be quite easy. The command would look something like git stack --stack current --format branch-names. current means it would list your current branch and all parent branches back to master. There is also dependents and descendants

[epage]

v0.6.0 is released. The syntax is git stack --format list --stack current

• current selects BASE..HEAD (ie all parents of HEAD)
• dependents selects BASE..HEAD.. (ie all parent and children of HEAD)
• descendants selects BASE.. (ie all children of BASE)
• all selects everything

[Gelio]

Thanks for another very fast change! I appreciate it ❤️ The command you listed looks like exactly what I'm looking for!

09:29 $ echo $(git stack --format list --stack current)
improve-repository-name-form-integration-CU-24ape6r smart-csv-preview-submit-button-CU-1zg1bv6 simplify-ingestion-mutation-logic-CU-257cdmb
09:29 $ git push origin $(git stack --format list --stack current)
Everything up-to-date

We can close/resolve this discussion

---

Mind opening an issue about that so we can make sure we continue to track it?

I have created https://github.com/epage/git-stack/issues/191 to track the "push what's already pushed" feature.

[OlivierLDff]

Hi I've been looking for this workflow too, I like the workaround git push origin $(git stack --format list --stack current).
I would have wished to find that sooner (or in an easier way). Was this documented somewhere that I missed? Or is the Readme the only source of documentation?

[epage]

The README links out to some documents in docs/. We could add one for different tips or as a FAQ

[OlivierLDff]

Sorry for late reply.
Thanks I didn't even the docs folder as the README is quite big, so I stopped my exploration there. I learned a lot there, so thanks.
It would have been helpful for me to have a link in README, or the best would be a doc website generated from the .mdfiles.