`git submit` doesn't like it when commits have 2+ branches
claytonrcarter opened this issue · comments
Description of the bug
git submit behaves strangely when a commit has 2 branches pointing at it. From what I can tell, it just skips the commit entirely, though the implementation1 suggests that it may depend on the order in which the branches are processed by submit.
Repro:
touch test-file.txt
git add test-file.txt
git commit -m 'temp'
git branch test-1
git submit
# this should report:
# Skipped 1 branch (not yet on remote): test-1
git branch test-2
git submit
# uh oh, this reports nothing! 😱 This seems to also "work" if one of the branches is already pushed, and a new branch is added.
I haven't actually encountered this in the wild, but I ran into it while pushing some of my recent PRs, when I unstacked a bunch of commits and assigned them each a branch to push independently. I accidentally doubled up one of them ... et voila.
Expected behavior
I expect it push all branches, or all applicable branches is some but not all of them exist on the remote.
Actual behavior
The multi-branch commits are just skipped.
Version of rustc
rustc 1.71.0 (8ede3aae2 2023-07-12)
Automated bug report
n/a
Version of git-branchless
master
Version of git
git version 2.41.0
Footnotes
I don't think this depends on the branch ordering. If there is more than one branch pointing to the same commit, then it will trigger that code path.
IIRC the main thing I was worried about was if one of the branches was a long-lived branch like main. This could happen if you create a branch off of main, intending to start work, and then run git submit for some reason. It would be quite bad if you also force-pushed the main branch! (Maybe there's a check/exclusion for the main branch already?)
Obviously there should be some kind of diagnostic in this case.