Support seamless switching to remote branches

[stevage]

I was quite surprised that this didn't "just work":

gl switch gh-pages

I'd expect it to automatically check out and switch to origin/gh-pages, creating the local branch gh-pages (and explain what it's doing). If there's more than one remote with that branch name, prompt for more information. If there's already a local branch of that name, obviously it should switch to that instead.

[chmike]

gh-pages has to be a local branch.

Unfortunately you have to do the following steps.

1. $ gl branch -c gh-pages creates the local branch
2. $ gl switch gh-pages
3. $ gl branch -su origin/gh-pages

It may be possible to combine these, but I didn't test it. Could you try this ? I can't test it now. This might do what you want. The help doesn't make clear if such combinations is possible.

$ gl branch -c gh-pages -su origin/gh-pages

[spderosso]

For the time being, you have to follow the steps provided by @chmike (note though that the -c, -su combo won't work) but we should probably do what you suggested.

[stevage]

Sorry, yeah - I'm making a suggestion for an enhancement. (Not sure how to make that clearer).

Perhaps Gitless should have a concept of the "current remote"...or maybe more usefully, the "current upstream" and the "current downstream".

[chmike]

This doesn't look like a good idea. What if you wanted to create a local branch foo and origin (the default remote) had also a branch foo you were not aware of. Your local branch foo would start tracking origin/foo and this is not what you wanted. To avoid this we would have to add a command flag that says create a local branch only. This adds a new flag and increases the complexity.

It is preferable to keep things explicit and intuitive.

It could eventually be interesting to support the following shortcut when the local branch name is the same as the branch name on the remote:

gl branch -c foo -su origin

But things start to become cryptic.

[stevage]

What if you wanted to create a local branch foo and origin (the default remote) had also a branch foo you were not aware of. Your local branch foo would start tracking origin/foo and this is not what you wanted.

This is the kind of edge case that Git is so good at supporting, at the expense of all the normal cases :)

It's pretty easy: just provide explicit output about what is happening.

$ gl switch foo
No local branch named "foo", so switching to origin/foo, and setting that as upstream.
Warning: 438 different commits found in origin/foo.

In this scenario, you're better off, because now you've discovered the existence of the remote branch straight away. In Git, you would only discover that much later, when you tried to push your changes, and got very confusing error messages.

[techtonik]

For the sake of clarity gitless should impose some limits on git "flexibility" regarding remote and local branches. Every remote branch should be clearly 1:1 linked to one local branch. Is that possible?

[cougarhawk]

I love the freedom and flexibility of naming local branches anything I want and not having Gitless automatically perform some sort of discovery to search for the local branch name in remote repositories or otherwise forcing a link between a local and remote branch.

You can specify -dp option of gl branch -c to create a new local branch that mirrors the branch specified in the option. The command works regardless of the local branch you execute the command from (you don't need to call gl switch). You can even use it to create a new branch in a remote repository that mirrors a local branch. See my other comment: https://github.com/sdg-mit/gitless/issues/96#issuecomment-323352284

I can freely work on my local branches until which time I need to publish. When it becomes necessary to do a 1:1 link between a local and remote branch, then I have several choices:

1. If the local branch is already a 1:1 match of an existing remote branch: Specify the -su option of the gl branch command to establish the link between the two branches. I would then use gl publish to push my commits.

2. If the local branch is NOT a 1:1 match of an existing remote branch: Create a new local branch that mirrors the remote branch, switch to the new local branch, link the local branch to the remote branch, fuse the commits from the previous local branch to the new local branch, resolve conflicts when necessary then publish to the remote branch: https://github.com/sdg-mit/gitless/issues/59#issuecomment-323364306

Sincerely, Al

[techtonik]

@cougarhawk does gl improve your workflow in any way, because I don't see how that's is different from using plain git command, which is always a choice for total flexibility and freedom. )

[cougarhawk]

@techtonik - Yes, I have continued to use gitless and it has improved my workflow. The benefit of using gitless over git is clearly documented in the "Gitless vs. Git" section of the Gitless website. This is what convinced me of its value. While I can see how others might benefit more from gitless by having it enforce 1:1 correspondence between local branches and remote branches, I also feel that this should not be a requirement that is imposed for everyone. Sometimes, we should give pause to introducing automatic features as is the case of automatically discovering and downloading from remote branches because, even if they seem nice, the application can end up taking some control away from the end user and potentially behave in a way that is unexpected. For example, in my team's Github environment, users have permission to create remote branches with their updates that are later deleted by the administrator after he merges the updates into the main branch. With this type of environment, where branches are created and deleted on the fly, we can have dozens of branches at a given time. I do not feel safe leaving it up to the application to assume that I want to download from certain remote branches especially since I may not have control over their existence.