Provide button to create and checkout new local branch for remote-onl…

[AlterDepp]

I create new branches in bitbucket and fetch them locally. With this change I get a button to checkout this as local branch in gitv if I type co on the line containing the remote branch.

[rbong]

I think I would be more comfortable with finding a way to pass in `--track'.

From the git docs:

-t
--track

    When creating a new branch, set up "upstream" configuration. See "--track" in git-branch[1] for details.

    If no -b option is given, the name of the new branch will be derived from the remote-tracking branch, by looking at the local part of the refspec configured for the corresponding remote, and then stripping the initial part up to the "*". This would tell us to use "hack" as the local branch when branching off of "origin/hack" (or "remotes/origin/hack", or even "refs/remotes/origin/hack"). If the given name has no slash, or the above guessing results in an empty name, the guessing is aborted. You can explicitly give a name with -b in such a case.

We already have g:Gitv_MergeArgs, which allows implementing custom merge behaviour, so something similar might be consistent. I'm open to arguments to the contrary, though.

This will solve a couple things that you'll need to address if the implementation is kept the same:

• This is probably more appropriate for the utils file because of its similarity to the #refs function. I'd like to both expose this and keep target parsing utilties in one place.
• This only supports the origin remote name. I'm not sure there's a great way to solve this until we refactor line parsing.
• This only accomodates this checkout workflow. It's a possibly common workflow, sure, and it integrates nicely with the commit selection feature. However I'm worried about accomodating all possible checkout workflows, same as with merging, which is why g:Gitv_MergeArgs was implemented.
• This will increase the number of commits listed, up to doubling them, when selecting a commit for those who don't use this workflow.

[AlterDepp]

The `--track' argument is not nescessarry:

git checkout \ … If \ is not found but there does exist a tracking branch in exactly one remote (call it ) with a matching name, treat as equivalent to $ git checkout -b <branch> --track <remote>/<branch>

The points about origin and people not using this workflow could be handled by parameters perhaps.

[rbong]

Yes, -t is not necessary if this implementation is used. Similarly, if the checkout function is extended in the same way that the merge function is and you can pass in -t, the extra options added to the list are not necessary. The two approaches end up with the same result, I am just looking for the benefits of this approach to get past my reservations about it given all of my issues with it above.

Consider all of the different ways that it's possible to use git checkout: https://git-scm.com/docs/git-checkout

Allowing for customizing arguments allows anyone to handle passing in their own options quite easily without changing the base behaviour. In contrast, this approach changes the base behaviour. If we were to accomodate every workflow in this way the checkout functionality would become bloated, especially if we start passing in parameters for each different workflow as you've suggested. Bloating is in all honesty is a problem that gitv is already facing and I would like to not make worse.

I'm still open for arguments to the advantages of this approach, such as other reasons to have these targets in the list that is not handled by arguments.

[AlterDepp]

I don’t think that the checkout behaviour is changed. By my approach only a local branch is created before the checkout. The checkout itself is just default. I’d really like to get this feature in Gitv and I do not yet understand if you’d like another implementation or you don’t like the feature at all.

[rbong]

I don’t think that the checkout behaviour is changed.

I mean that additional targets are added to the list of options for checkout.

I’d really like to get this feature in Gitv and I do not yet understand if you’d like another implementation or you don’t like the feature at all.

I like this feature but I currently believe it should be implemented through a similar interface to g:Gitv_MergeArgs. I just want you to let me know if there's some reason setting git checkout -t myremote/branch wouldn't work for you, or if there's another reason that we should have additional targets available in the checkout workflow.

[AlterDepp]

Ok, I understand. git checkout -t myremote/branch would do the desired checkout. But how to deside, when the -t should be added? I think the easiest way is, to add an additional choice, how I did. Another approach would be, to always add -t if the branch is remote. Anyway, I can changed the regular expression, so it does not only work with origin.

[rbong]

I am just not sure I would like the additional maintenance overhead of this change right now, and I'm not sure if there's enough community engagement right now to allow for discussion of whether people want the number of commits they have to look through when they checkout something doubled or more if they don't want this feature. If people don't want that, gitv definitely does not need the maintenance overhead of an option to disable or toggle this feature. I am leaving this open to revisit in 1.5, and hopefully, more people can weigh in by then.

[AlterDepp]

I changed the concept to check out remote only branches. Before this pull request, when you check out a remote branch it’s the same as a checkout of the git-hash: you get a detached head. So these buttons are redundant. I changed them to create and checkout a new local branch. This is, what I would expect. So now, there are the same buttons as before the pull request, but the behavior is improved.