Committing happens to a new branch with the name suffixed -1?

[OJFord]

Version

0.12.5

Operating System

Mac OSX

Distribution Method

dmg

Describe the issue

When you commit to one of the branches on your virtual branch branch & push it seems to create a new branch origin/branch-1 and the origin/branch (nor the local ref) is not updated?

How to reproduce

Have a virtual branch, make a change, commit it to one of the branches, push that branch

Expected behavior

Update the existing branch

Relevant log output

No response

[Byron]

Thanks for reporting!

Following the instructions, I wasn't able to reproduce the issue though. Naming the virtual branch branch, and pushing one new commit did just push to refs/heads/branch on the remote, a branch that was tracked under refs/remotes/mine/branch like I would expect (the remote is called mine).

Is there anything else that might be required for a reproduction? Maybe refs/remotes/mine/branch already existed when the virtual branch was pushed? Thanks for the clarification.

I could imagine that remote/branch already existed and GitButler created a suffixed branch as to not overwrite the existing tracking branch. That mapping can be changed in the context menu of the virtual branch.

[OJFord]

Yes it did already exist, I was trying out GitButler for the first time on an existing project (probably quite a common scenario for newcomers?).

It pushed to the suffixed remote branch, creating it, and left the local branch set to that upstream where previously it had been the unsuffixed one.

I thought I'd enabled allow it to force-push anyway, but either way I think this is confusing behaviour and unlikely to be what you wanted - I would have expected that if it couldn't force push (or lease expired or something) that it would just error and let me work out what I want to do.

[Byron]

Thanks for elaborating! Being a newcomer with the application myself I still have trouble in retracing your footsteps.

Maybe @krlvi would immediately know what's going on though, he knows all the nooks and crannies.

[davidolrik]

I too experienced this when trying to push to my main branch.

After clicking push I ended up with a main-1 branch on the remote.

What I really wanted was just to push a single commit to main without a PR.

I clicked "Set remote branch name", and changed it from main-1 to main and pushed again with success.

When this happens, maybe refuse to push before confirmation and then just push to the named branch?
This should be ok to do, because ff there is a mismatch in history the push will be rejected by the server.

[mtsgrd]

Hi @OJFord @davidolrik, we have been primarily focused on supporting a workflow where you push feature branches and merge them into e.g. main. That said, you guys aren't the first people to ask about support for pushing directly to master.

If you don't mind me asking, what are your main drivers for wanting to use GitButler outside the scope of concurrent feature branches?

[davidolrik]

@mtsgrd I've always had a workflow where I rebase my work into logical chunks, and doing this manually takes a bit of time.

What I like about GitButler is that I can do this way faster by just dragging by commits from virtual branch to virtual branch.

And feature branches are not always needed, eg when working on solo projects or the "it must go out now!" bug fix.

[OJFord]

@mtsgrd Mine was a feature branch, called fix-python-reqs or something like that, not master or main.

[davidolrik]

@mtsgrd Mine was a feature branch, called fix-python-reqs or something like that, not master or main.

I think the -1 but affects all pre-existing branches, mine just happened to be main.
Was that also the case for you?

[OJFord]

Yes, I mentioned that above: #4124 (comment)

As I said there I think that's probably really common for people using GitButler for the first time, not only because it's more likely to have an existing than a brand new project, but because that's where you're going to have the problem that makes the GB solution appealing - at work or otherwise collaborating with many people, on an established project working on multiple things (or with bugs that need a workaround) at once.