git-town
git-town copied to clipboard
Git Town Ship fails trying to run merge abort
I've run into this issue a few times and I haven't figured out what I'm doing wrong. When trying to run git town ship, where I have merge conflicts, I'm getting the following error after resolving my merge conflicts:
[chris-work:(main[|])] git town ship branch
...
[branch1] git merge --no-edit main
...
Automatic merge failed; fix conflicts and then commit the result.
Error: exit status 1
To abort, run "git-town abort".
To continue after having resolved conflicts, run "git-town continue".
[chris-work:(branch[|]*)] vim file
[chris-work:(branch[|]*)] git add file
[chris-work:(branch[|]*)] git merge --continue
[chris-work:(branch[|]*)] git town continue
[branch] git checkout main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
[main] git push -u origin branch
...
[main] git merge --squash branch
Updating 6a9dd42..a8767e4
Fast-forward
Squash commit -- not updating HEAD
...
[main] git merge --abort
fatal: There is no merge to abort (MERGE_HEAD missing).
Error: cannot run the abort steps: cannot abort current merge: exit status 128
To abort, run "git-town abort".
To continue after having resolved conflicts, run "git-town continue".
Rerunning git town ship resolves the issue by shipping the branch.
We have an end-to-end test for this scenario (except it doesn't use the Github API but this shouldn't matter here): https://github.com/git-town/git-town/blob/master/features/ship/supplied_branch/feature_branch/conflicts/feature_branch_merge_main_branch_conflict.feature.
It shouldn't run git merge --abort. I guess this happens because your computer contains an outdated run-state from a previous Git Town command, and git town continue uses that wrong run-state. What is puzzling is that git town ship doesn't throw away the old run-state first. @charlierudolph git town sync checks for existing run-states in its preRunE step ( https://github.com/git-town/git-town/blob/master/src/cmd/sync.go#L72) but git town ship does not. Is that an omission that would explain the behavior described in this ticket?
@cirego btw git merge --continue should not be needed, all you need to do is git add all the files, then call git town continue.
It shouldn't run git merge --abort. I guess this happens because your computer contains an outdated run-state from a previous Git Town command, and git town continue uses that wrong run-state.
git town continue should load the last run state no matter what command it was (we only have a single run state per repo). git merge --abort can be triggered if we are auto-aborting (totally forgot about this initially) https://github.com/git-town/git-town/blob/master/src/steps/run.go#L46
Thus appears that the squash is erroring somehow and our auto-abort case is missing some output. We should update that to we print out the run error and alert the user we are auto-aborting. Probably need to do that in order to have more info about what exactly is the issue here (as one of the silent commands in the squash step may be failing: https://github.com/git-town/git-town/blob/master/src/steps/squash_merge_branch_step.go#L39)
git town sync checks for existing run-states in its preRunE step ( https://github.com/git-town/git-town/blob/master/src/cmd/sync.go#L72) but git town ship does not. Is that an omission that would explain the behavior described in this ticket?
We should add the handleUnfinishedState call to all other commands. Don't think that effects this but would be good to do.