Sometimes Git sync -a leave me with conflicts after branchs have been deleted on remote #4872

AugustinUpway · 2025-05-07T09:19:28Z

AugustinUpway
May 7, 2025

And I don't get why 🥲
That's annoying because I really like Git Town, it's a really great tool !
But I haven't recommended it to my team yet because sometimes sync -a leave me in a totally random state, with conflict that are not justified.

It just happen to me again, wanting to sync my local copy after two unrelated branches have been deleted on remote.

Here is a summary of the console:

git:(feature_branch_1) > running "git sync -a"

[feature_branch_1] git fetch --prune --tags
[feature_branch_1] git checkout main
[main] git merge --ff-only origin/main
[main] git branch -D feature_branch_1
[main] git rebase --onto main observed_branch_1 <-- CONFLICTS ARISE
[main] git rm another_branch
[main] git -c core.editor=true rebase --continue
[main] git branch -D observed_branch_1
[main] git push --tags

deleted branch "feature_branch_1"
deleted branch "observed_branch_1"

git:(82e5a705c) <-- NOT ON MAIN, LEFT WITH CONFLICTS
git:(82e5a705c): git rebase --abort
git:(main): git sync -a

Everything up-to-date

Any idea what's happening here ?

I'm using Git town 18.1.0 and here is my config:

push.autosetupremote=true
rerere.enabled=true
rerere.autoupdate=true
git-town.sync-perennial-strategy=ff-only
git-town.main-branch=main
git-town.sync-feature-strategy=rebase
git-town.sync-prototype-strategy=rebase

kevgo · 2025-05-07T15:16:54Z

kevgo
May 7, 2025
Maintainer

Thanks for reaching out about this!

As a general best practice, we recommend updating to the latest version (currently Git Town 20), as newer versions include bug fixes and make it easier to diagnose issues.

From the output you shared, it looks like branch observed_branch_1 has changes to a file named another_branch that conflict with changes in main. Git Town resolves these conflicts by deleting the file and running git rebase --continue, which seems to succeed (it would have aborted otherwise). After that, it continues with other Git operations like deleting branch observed_branch_1 and running git push --tags. Both would succeed if a merge conflict exists.

To investigate this further, it would be helpful to have a minimal set of steps to reproduce the issue. Alternatively, the full output of git town sync -a -v when the issue occurs would provide the necessary context to pinpoint what exactly is going wrong here.

Also, just to confirm: does running git town continue resolve the issue in your case?

If this happens again in the future, you should be able to run git town undo to go back to the state before the botched sync.

0 replies

AugustinUpway · 2025-05-07T16:19:48Z

AugustinUpway
May 7, 2025
Author

Hey Kevin, thanks for the quick answer ! 🙏

I've updated Git Town and will let you know if I see any improvement.
Unfortunately my branches are gone so I don't know if it git town continue would have solved the issue or not, will keep that in mind for next time.

What I don't get is that:

both feature_branch_1 & observed_branch_1 have been merged into main on Github (we squash & merge)
main is fast forwarded (as chosen by me in git-town.sync-perennial-strategy=ff-only)
both feature_branch_1 & observed_branch_1 end up being deleted by Git Town (as expected 🙌 )
but between 2 & 3 there is this [main] git rebase --onto main observed_branch_1

Why try to rebase main onto [main, observed_branch_1] in the first place ?
I though setting git-town.sync-perennial-strategy=ff-only would never try to mess with main this way 😅

4 replies

kevgo May 7, 2025
Maintainer

Great question! This behavior is documented here.

A possible scenario that the rebasing of branches to delete is trying to protect against looks like this:

You open a PR for a feature.
A reviewer suggests some changes and approves it.
You address some of the feedback on your machine and then get pulled into something urgent.
When you return, you see the approval, forget about the unpushed local changes, and hit “Squash & Merge” on GitHub.
You run git town sync, and your unpushed local changes silently vanish.

Git Town's prime directive is to make sure no changes ever get lost. It would be reckless to delete local branches without checking for unpushed changes, even though that's probably okay in 99% of the cases.

That said, I agree that syncing before deleting can be surprising, especially when it leads to merge conflicts in a branch you thought was done. It might help if Git Town provides a better explanation when asking users to resolve those conflicts.

To avoid this situation, one best practice is to run git sync -a more frequently. As long as Git Town sees that your local branch was in sync with its tracking branch before running git fetch, Git Town knows you have no unpushed changes and deletes your local branch right away, without rebasing.

Alternatively, you can mark a branch as observed using 10000 git town observe. Observed branches track someone else's work. So when their remote branch is gone, Git Town skips the rebase and just deletes them, even with unpushed changes.

Does this make sense?

AugustinUpway May 7, 2025
Author

Yes, it perfectly make sense ! Well though out !

However my observed_branch_1 that created the conflict was indeed an observed branch (that's why I named it that way in my example). Anyway, the conflicts are gone, so I will not be able to get down to why this happened.
I will be extra careful if I come against such case in the future !

It might help if Git Town provides a better explanation when asking users to resolve those conflicts.

I'm all for that ! You can't be too verbose when working with Git 😅

Thanks again for taking the time to explain all of this !

kevgo May 7, 2025
Maintainer

Glad it makes sense! If you have any ideas for improving the explanations on the website or in the app to make more sense to somebody who uses the tool the first time, please send a pull request. We'd really appreciate it. Also, if you haven't already, you can embed the Git Town status into your shell prompt to get a handy reminder to run git town continue when your Git workspace ends up in an active rebase again.

kevgo May 8, 2025
Maintainer

However my observed_branch_1 that created the conflict was indeed an observed branch

Thanks for mentioning this! Your comment has inspired me to look deeper and just submit #4877. In your example, the rebase was not done to verify unpushed local commits (since it's an observed branch), but to remove the commits of this branch from its child branches. Which is unnecessary, since this branch has no child branches in your case.

The code to remove commits from child branches is relatively new, and this was a corner case we didn't handle so far. The less rebases and merge conflicts, the better. Great feedback! 🙏

kevgo · 2025-05-08T18:47:10Z

kevgo
May 8, 2025
Maintainer

A fix for the unnecessary rebase is now available as part of Git Town 20.1.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sometimes Git sync -a leave me with conflicts after branchs have been deleted on remote #4872

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 3 comments 4 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

Select a reply

Sometimes Git sync -a leave me with conflicts after branchs have been deleted on remote #4872

AugustinUpway May 7, 2025

Replies: 3 comments · 4 replies

kevgo May 7, 2025 Maintainer

AugustinUpway May 7, 2025 Author

kevgo May 7, 2025 Maintainer

AugustinUpway May 7, 2025 Author

kevgo May 7, 2025 Maintainer

kevgo May 8, 2025 Maintainer

kevgo May 8, 2025 Maintainer

AugustinUpway
May 7, 2025

Replies: 3 comments 4 replies

kevgo
May 7, 2025
Maintainer

AugustinUpway
May 7, 2025
Author

kevgo May 7, 2025
Maintainer

AugustinUpway May 7, 2025
Author

kevgo May 7, 2025
Maintainer

kevgo May 8, 2025
Maintainer

kevgo
May 8, 2025
Maintainer