Local virtual branches get renamed when updating local workspace to origin

[SnaveSutit]

Version

0.14.8

Operating System

Windows

Distribution Method

msi (Windows)

Describe the issue

Whenever I click the update button, all unpushed branches in my local workspace get renamed (or shadowed?) to s-branch-X.

E.g. If the branch's name happens to be s-branch-1, it would get renamed to s-branch-2. Or if it's named fix/my_cool_bugfix, it would become s-branch-1 assuming that name isn't already taken.

If I attempt to rename said branches back to their original names, Gitbutler stops me with the error "That branch name already exists".

How to reproduce (Optional)

1. Create a branch named merge, and a branch named test.
2. Make some changes on the merge branch, and push them.
3. Optionally, make some changes on the test branch, but do not push them.
4. Create a PR for the merge branch.
5. Merge the PR for merge on the remote.
6. In Gitbutler, refresh the target, and click Update.
7. Note that the test branch is no longer named test, but instead s-branch-X.

gitbutler-tauri_O6GmcTt2Ze.mp4

Expected behavior (Optional)

The local branch names shouldn't be affected when updating from origin.

Relevant log output (Optional)

[Byron]

Thanks a lot for reporting!

Unfortunately I can't serve with a workaround right now.
Also CC @krlvi who may have more intuition on what might be causing this.

[homburg]

(From diagnosing with sonnet-3.7)

Root Cause

The issue occurs in the archive_integrated_heads function in the branch management system. When a branch is fully integrated (all of its commits are now part of the target branch), GitButler archives the branch by moving it to the archive. However, when creating a new empty reference to represent the archived branch, the code was not preserving the original branch name.

Specifically:

1. When updating the local workspace to match the remote, GitButler identifies which local branches have been fully integrated into the target branch.
2. These branches are archived by moving their references to the archive.
3. For each archived branch, a new empty reference is created to maintain the branch's presence in the UI.
4. The issue was that this new empty reference was being created with a generated name (using the deduplication system) rather than preserving the original branch name.
5. This resulted in branches being renamed to the format s-branch-X instead of keeping their original names.

Solution

The fix involves modifying the archive_integrated_heads function to preserve the original branch name when creating a new empty reference after archiving. Instead of generating a new name, we now use the original branch name for the new empty reference, ensuring that branch names remain consistent during updates.

This change ensures that when a branch is archived and a new empty reference is created, it maintains the same name as the original branch, preventing the unexpected renaming behavior.

[Byron]

That's fascinating, thank you!
I hope @krlvi will get around to reviewing the PR soon so the fix can land in a nightly.

[Caleb-T-Owens]

@homburg

(Response generated by a human)

The issue is as follows:

The function archive_integrated_heads is given a Stack which has many branches. After we rebase all the branches, we want to clear out any branches from the stack that have become empty (no commits).

Currently, we just assume that all empty branches should be archived.

That assumption is what occasionally causes confusing behaviour. By archiving all empty branches, if you simply had a branch with no commits that you were about to start working on, then it mistakenly gets archived and replaced with a new one.

Simply giving the new branch the same name as the old top branch is not the solution. This is because if a branch was legitimately archived, it would then have a new branch created with the same name, which would be confusing.

The actual solution will be to give the archival mechanism more information from the upstream integration logic, so it knows what has actually be archived.