Push to multiple branches, deletes remote branch as well

[nomoderator]

Current behaviour

Pushing to multiple branch, without selecting "Delete Remote Branch" IS DELETING remote branch

Expected behaviour

Pushing to multiple branch, without selecting "Delete Remote Branch" SHOULD NOT DELETE any remote branch

Steps to reproduce

Simply push to multiple branches, without selecting "Delete Remote Branch" and say bye bye to remote branch

Screenshots

Did this work in previous version of GitExtensions

I'm not sure because I recently started using this functionality

Environment

• Git Extensions 3.1.1.6049
• Build 2f87210
• Git 2.23.0.windows.1
• Microsoft Windows NT 10.0.18362.0
• .NET Framework 4.8.3815.0
• DPI 96dpi (no scaling)

[nomoderator]

Hi @gerhardol , is somebody looking onto this bug? I'm new here, so not sure what is the progress on this ticket, as it's been 11 days since I posted this.

[gerhardol]

is somebody looking onto this bug?

Probably not.
Everything cannot be investigated, bugs will split. There is a limit to much time the core maintainers can spend on GE. (I have basically stopped developing, just looking at issues.)

The Git command log is a good start to investigate.

[hieuxlu]

I can't reproduce this. So probably not just "simply push to multiple branches". @nomoderator Can you verify with other repositories, or send your git log? There must be something special with your repo.

[nomoderator]

@hieuxlu Apologies for the late reply.
My organization is using OracleCloud for repo management. I could reproduce the issue by creating dummy branches and pushing a commit in all of them together. Here are the steps I followed:

1. Commit a file (package.json)
2. Push to multiple branches:
   
3. After the push, branches are automatically deleted:
   

Git Command Log:
git push multiple branch issue.txt

[hieuxlu]

@nomoderator I don't have Oracle Cloud account, so can you verify with Github instead? Probably a bug with Oracle Cloud git.

[RussKie]

This looks sus:

2019-10-21T10:27:15.6681414+05:30	25608		UI	0	git	push --progress "origin" :refs/heads/rahul_t1 :refs/heads/rahul_t2 :refs/heads/rahul_t3	D:\Work\RecVue\contracts\rahul-contracts\

[nomoderator]

@hieuxlu might be a bug with Oracle Git. I don't actively work on GitHub now to test it further.
@RussKie what can be done on my part?

[RussKie]

@nomoderator not sure at this stage, it could be a bug in our code... The above line looks like we are deleting refs.

@hieuxlu do you think you could dig through the code and see why we may be issuing the above command?

[hieuxlu]

@RussKie I would. Think I understand the bug, please assign it to me. It is somehow missing the first part before :, isn't it? Mine would be like this, notice the part before :

git push --progress "fork" refs/heads/test1:refs/heads/test1 refs/heads/test2:refs/heads/test2

[hieuxlu]

@nomoderator I think I know the root cause: you haven't checked out local branch before pushing to multiple branches. So a quick work around is check out branches before you push.
@RussKie For this case, should we disable the push check box for branches that haven't been checked out yet?

[pmiossec]

@hieuxlu Interesting. I don't understand what checking out branches before pushing changes.

Could you elaborate a little more?

[mast-eu]

Confirm @hieuxlu
The key is that you are pushing to remote branches, without having matching local branches.

So basically you are doing git push <empty> to origin:rahul_t1. Which git interprets as delete origin:rahul_t1. This is even a documented behaviour:

Pushing an empty <src> allows you to delete the <dst> ref from the remote repository. 

I'd argue that technically it is not really a bug, because the system acts as specified. However, the UX has room for improvement, because it doesn't do what most users would expect.
GE could disable the push checkboxes if there's no local branch. Or, at least, show a warning.

[gerhardol]

GE could disable the push checkboxes if there's no local branch

Seem reasonable to me - there is not anything to push for these branches anyway

[hieuxlu]

We could even not show them at all. Imagine 1000 remote branches.

[nomoderator]

@mast-eu Thank you for the insight. But now I've a related query.
I do have a local branch for master. But the attached screenshot is not showing it, because I'm already in rahul branch, which has a separate folder.

Then how should I push to multiple branches without any issues?

The day I raised this issue, I did select master branch as well (I had a locally assigned folder for it, but it was not showing in the Local Branch column).
Multiple push action deleted all the branches, except for master, only because it got error-ed out, as it's the default branch!

[hieuxlu]

I do have a local branch for master. But the attached screenshot is not showing it, because I'm already in rahul branch, which has a separate folder.

What do you mean by folder? Can you share the folder screenshot so that I could understand? I think you checked out master branch to a different folder outside of this local git repo. And then checked out branch rahul in another local folder. That's why there's only 1 local rahul branch in this local repo.

Normally we don't do that. We only check out repo to a local folder once, and in this repo, we check out branches...

[hieuxlu]

@gerhardol @mast-eu Can we remove all the checkboxes for remote branch without matching local branch, instead of disabling them? I think for the most cases, we only have < 10 local branches, while there can be >100s remote branches. So why don't we hide all the extra push checkboxes?

What do you think?

[nomoderator]

@hieuxlu Folder structure looks like this:

Each having this nested structure:

[hieuxlu]

@nomoderator That's what I think. You have checked out git twice, to 2 different local repos.
In master-contracts, you only have 1 local master branch
In rahul-contracts, you only have 1 local rahul branch
That's why there's no local master branch in rahul folder. You should've used check out branch instead.

[pmiossec]

Or used `git worktree` feature (supported by Gitextensions) instead of cloning twice...

[gerhardol]

@gerhardol @mast-eu Can we remove all the checkboxes for remote branch without matching local branch, instead of disabling them? I think for the most cases, we only have < 10 local branches, while there can be >100s remote branches. So why don't we hide all the extra push checkboxes?

I consider the UI be easier to understand if the control is disabled instead of removed. No question why it disappeared...

[mast-eu]

Then how should I push to multiple branches without any issues?

@nomoderator If I understand correctly, you want to push the same changes from 1 local branch to multiple remote branches at the same time. Is this correct?
If yes, I don't think you can. There's a 1:1 relation between local and remote branches in git. No way to set up a 1:n relationship.
You would need a dedicated local branch for each remote branch and merge locally as needed before pushing them.

But why all this? It feels way to complicated. What do you try to achieve?

[hieuxlu]

I consider the UI be easier to understand if the control is disabled instead of removed. No question why it disappeared...

OK, disabled it is then.

Or used git worktree feature (supported by Gitextensions) instead of cloning twice...

After 4 years using GE, now I know how to use Worktree. Would have saved countless time when I have to check out different folders for develop, master, forks...

[hieuxlu]

I didn't know that WinForms has no disabled style for checkbox cell. If we are going to hard-code cell style, that would be problematic with the upcoming dark theme features. Any idea how we should handle disabled checkbox style here?

Below is readonly checkbox cell, no difference to editable ones.

[gerhardol]

I didn't know that WinForms has no disabled style for checkbox cell

Then it seem better to delete

[hieuxlu]

Delete it is then... (make it hidden)

[RussKie]

@hieuxlu would this work https://stackoverflow.com/a/10356938/2338036?

[hieuxlu]

As I said earlier, I dont know how hard coding color will work with upcoming dark theme feature. I consider this to be low priority compared to dark theme.

[RussKie]

I think you can proceed with the fix using the SO suggestion. @NikolayXHD can advise you on the color.

[hieuxlu]

@RussKie That will trigger an infinite paint loop, so I have to modify a little bit. Anyway, here's the result, the selection state looks strange.

For perspective, this is how it looks when hiding checkboxes. Personally I like this better.

So should we go on with disabling or hiding?

[RussKie]

nice! I like when the boxes are hidden

…

On Wed, Oct 23, 2019, 4:20 PM Hieu Do ***@***.***> wrote: @RussKie <https://github.com/RussKie> That will trigger an infinite paint loop, so I have to modify a little bit. Anyway, here's the result, the selection state looks strange. [image: image] <https://user-images.githubusercontent.com/11418231/67360029-12707880-f58f-11e9-98ef-e69ca601477c.png> For perspective, this is how it looks when hiding checkboxes. Personally I like this better. [image: image] <https://user-images.githubusercontent.com/11418231/67360054-1f8d6780-f58f-11e9-87ef-da4db1e0d7fb.png> So should we go on with disabling or hiding? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7077?email_source=notifications&email_token=ABBTEXR6LJRWLVRGRADQYADQP7NJ5A5CNFSM4ISJMG5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECAC4SY#issuecomment-545271371>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBTEXWPLN62MODSYGMZB7LQP7NJ5ANCNFSM4ISJMG5A> .

[gerhardol]

I conceptually prefer disabling, but not by adding complexity. Suggest to remove
This is not an important issue, just do something