Pushing a series to a branch

[WhyNotHugo]

TLDR: I want to push 84db4c..94dec to origin under a new branch named something.

---

When working on changes locally, I often need to push individual commits (or series of commits) into their own branches, so that I can open a single MR for each of them.

This requires several manual steps:

• Create a new branch.
• Cherry-pick the commits.
• Push the branch.
• Return to original branch.

These steps need to be repeated for each commit/series.

I'm in need of something like git send-branch origin 84db4c..94dec:something, which would push that series into branch something. I don't care if the branch something is left over locally or not.

I've been reading through the wiki, and it would seem that the mindset with which this project was written is close to my own. But I don't see a way of doing that I'm trying to do.

Is there some way to do this with git-branchless? How do you deal with this sort of scenario?

[arxanas]

In most cases, I use git-branchless to manage stacks of commits, rather than independent lines of work, so I currently push branches without cherry-picking their constituent commits.

Normally, I use git submit to push multiple branches simultaneously, but it doesn't have the desired cherry-picking behavior. (That could be a useful extension to git submit itself.)

I'm not sure if I understand your workflow fully; do you intend to cherry-pick the commits every time you want to re-push, or just for the initial push? If every time, you may find a tool like git-branchstack helpful (cc @krobelus).

You may also find the Jujutsu "mega-merge" workflow useful, since then you can keep your individual branches separate to begin with, but also have their contents merged in the working copy for development.

---

Unfortunately, in git-branchless, there's currently no way to programmatically cherry-pick the range and address the resulting commits:

• git move can't duplicate commits currently (there should be an open issue for this, and it might be easy to implement, but not sure).
• There's no established programmatic output format for the result of git move yet.
  • I think even git query, which is meant for programmatic use, only has a --raw format, and nothing more structured yet, such as JSON.
  • With some hacking, you might be able to get a useful result from git query after executing git move.

---

There might be a workaround in your case where you run something like

$ git test run -s worktree && -x 'git rebase X Y --onto main && git push origin @:some-branch

The design for git test run is that the operations to the commit graph (like committing and rebasing) shouldn't be reflected outside of the git test run invocation.

(If you can work out a command that can determine the root or head commit for a range automatically, perhaps using git query, then you can also use git test run to push multiple branches in parallel.)

[WhyNotHugo]

Thanks for your thoughtful reply, it's taking me a while to fully process all of it.

I'm not sure if I understand your workflow fully; do you intend to cherry-pick the commits every time you want to re-push, or just for the initial push?

Essentially, I clone a remote repository and do some work and create multiple commits. I now have five consecutive commits, but they need to be submitted as four different branches to create four different merge requests. If I had to use git send-email this would be easy, since I'd do something like:

git send-email 84db4c..94dec
git send-email 834fda..a938c
...

But when it comes to GitHub (and its clones), I need to create a branch for each series, and then cherry-pick individual commits into each one. I'd instead want to do git send-branch origin 84db4c..94dec:something to push some commits to the something branch, and so forth. I.e.: I crave the simplicity of git-send-email.

Perhaps I'm asking the wrong question here though: how would you deal with such a situation?

---

There might be a workaround in your case where you run something like

$ git test run -s worktree && -x 'git rebase X Y --onto main && git push origin @:some-branch

The && here is a typo, yes?

Are you using git test to ensure that the working copy returns to the same state after all the rebase+push operations?

Why do you need to specify Y here? What value would you use for it?

X would typically be origin/main, or its equivalent, right?

I was unfamiliar with the @ syntax, nice to know of it 👍

If you can work out a command that can determine the root or head commit for a range automatically, perhaps using git query, then you can also use git test run to push multiple branches in parallel.

This should be just origin/main or the equivalent, no?

[arxanas]

But when it comes to GitHub (and its clones), I need to create a branch for each series, and then cherry-pick individual commits into each one. I'd instead want to do git send-branch origin 84db4c..94dec:something to push some commits to the something branch, and so forth. I.e.: I crave the simplicity of git-send-email.

Can you confirm what the value of cherry-picking the individual commits is for you and your workflow?

• What happens if you attach a branch to the end of each range and push them that way?
• Are the code reviews meant to be dependent or "stacked", or are they truly independent?

In my own workflow:

• There's no way for me to know that 84db4c..94dec actually applies cleanly on top of the main branch.
  • Therefore: I wouldn't try to push it without first confirming that it applies cleanly by itself.
    • In your workflow, how would you know that the patch you're sending via send-email actually applies cleanly for the recipient?
  • Instead: I'd usually rebase all of those ranges as separate stacks on top of the main branch.
    • At that point, I can directly attach branches and push them, without worrying about including the ancestry unnecessarily.
• Alternatively: I'll push all commits without separating them into separate branches:
  • Either: I'll put multiple commits in one PR;
  • Or: I'll create a stacked set of PRs.
    • Oftentimes, I'll do this manually with the gh CLI and the --base flag.
    • The git submit command supports --forge github to create a stacked PR series, but it's buggy (see Github forge problems #1259; it's therefore not yet documented in the Wiki).

By the way, if you're using GitLab, I believe one of the git-branchless users has published a script to created stacked MRs (and I suspect that the stacked MR workflow is better on GitLab than on GitHub, though I haven't personally tried it).

The && here is a typo, yes?

This isn't a typo; see e.g. What is the purpose of "&&" in a shell command?. In this case, the git rebase may fail (such as if there's a conflict), so we don't want to proceed with git push in that case.

Are you using git test to ensure that the working copy returns to the same state after all the rebase+push operations?

That's one reason. The other reason is to ensure that the git-branchless commit graph and event log are also unchanged:

• If you were to run the same git rebase command yourself, then git-branchless would observe that you rewrote the commits, and it would try to encourage you to clean up the old, superseded versions of the same commits.
• Alternatively: If you were to run the relevant git cherry-pick command yourself, then git-branchless would start showing the new commits in the smartlog.
• It sounded like you specifically wanted to maintain two logical versions of the same commit range: one which is independent and suitable for pushing, and one which is nested in the commit stack you're working. But possibly you don't specifically value this?

Why do you need to specify Y here? What value would you use for it?

X would typically be origin/main, or its equivalent, right?

In this case, X Y represents the commit range to rebase, so you would use e.g. X = 84db4c and Y = 94dec.

• The interface for git rebase is unintuitive here because it behaves quite differently if you pass one vs two arguments.
  • X would not be origin/main unless that happens to be 84db4c in your situation.
  • If you run just git rebase X, then it's more like running git rebase HEAD..X, or something like that (it should specify in the docs).
  • The behavior I want to actually execute here is something like git move --copy -x 'X::Y' -d 'main()', except that the --copy flag doesn't exist yet. But basically, I'm rebasing/cherry-picking a range of commits.
  • You could also write git checkout main && git cherry-pick X..Y, probably.
• Can you draw a more specific commit graph for our example purposes?
  • My assumption was that you had a bunch of commits in your local stack, and you wanted to specifically select a sub-range of those commits to push.
  • Namely, the topology goes something like main [...] 84db4c [...] 94dec [...] HEAD. Is that correct?
  • When you write .., do you mean a linear range of commits, or are you also leveraging its behavior to handle non-linear ranges?
    • Specifically: If neither 84db4c nor 94dec is an ancestor of the other, but they share a common ancestor, then your example is much different than I was visualizing.

I was unfamiliar with the @ syntax, nice to know of it 👍

Oops, it's something I inadvertently picked up from jj 😅 .

This should be just origin/main or the equivalent, no?

Usually not; it should be X in your expression X..Y. This remark makes me wonder if maybe I'm providing a more complicated solution than necessary to support your actual workflow?

The main thing I was alluding to is just an optimization that probably doesn't warrant implementing unless we've figured out the rest of your workflow. Specifically: You can run git test -x '...' --jobs N 'expr()' and run the same command in parallel after checking out each commit in expr().

• Therefore: If you can design a static command that works correctly to push each range in expr(), then you can leverage the parallelism in git test.
• Otherwise: You'd have to hardcode your commit hashes in the command string, so you wouldn't be able to do multiple pushes simultaneously.

[WhyNotHugo]

There's no way for me to know that 84db4c..94dec actually applies cleanly on top of the main branch.
Therefore: I wouldn't try to push it without first confirming that it applies cleanly by itself.

The truth is, I don't have a mechanism to assert this, but I also have no doubt that this is true.

This is the main reason I've taken a long time to reply: because I both don't have an answer to your question, but know for a fact that this is true.

I'll lead with two specific scenarios which I encounter every week:

Scenario 1: aports

I contribute to Alpine's aports repository, which contains package recipes for all of Alpine's packages. I work on my main branch, where I keep all my local changes. When some of these changes are ready to be submitted upstream, I create a new branch, push it, and create an MR.

Individual changes typically affect only one package, so each commit only touches files inside one directory. So I never have two different MRs which touch the same files.

The problem comes around when I need to update one of these changes: they live both in my main branch and the branch which I created for the MR. I typically work on my main branch and continuously rebase it, but updating the MR requires juggling around branches and (I basically re-create the MR's branch with the new commits from scratch).

Scenario 2: zk

I have my own fork of the zk project, where my main branch has a variety of features and fixes which I've submitted upstream.

I build from main and use this on my own hosts.

Some of the features in main are submitted upstream as PRs: https://github.com/zk-org/zk/pulls/WhyNotHugo

Some features are not ready for submission, so only exist in my main branch.

Again, I work on my main branch, but when I need to update a PR, I need to delete the PR branch, create a new branch with the new commits, and push that. It would be much easier for me to do something along the lines of git send-branch origin 84db4c..94dec:something.

The && here is a typo, yes?

This isn't a typo; see e.g. What is the purpose of "&&" in a shell command?. In this case, the git rebase may fail (such as if there's a conflict), so we don't want to proceed with git push in that case.

I understand the basics of sh, my question is about semantics, not syntax. git test run -s worktree is missing any command to run. It just produces an error:

Could not determine test command to run. No test command was provided with -c/--command or
-x/--exec, and the configuration value 'branchless.test.alias.default' was not set.

Can you draw a more specific commit graph for our example purposes?

For example, 93baa52~..e08b37 in the zk repository above. This is just a simple range which includes two linear commits, one the parent of the other. Typical scenarios are 1-3 sequential commits.

[WhyNotHugo]

Based on your answer, it seems that I could just use a script which produces a new worktree with the temporary branch, cherry-picks my range, pushes it, and drops the worktree.