Option to specify target branch

[pimjansen]

Hey,

Im trying to run GWS and target it on a specific branch but seems it is not possible? In this case i tried with a tag but also branches do not seem to work. Is this valid or did i miss something?

customer | git@bitbucket.org:acc/customer.git -b 0.1.0

customer | git@bitbucket.org:acc/customer.git 0.1.0

[emlun]

Hi! Specifying the initial branch to check out as HEAD is indeed not currently supported. On the other hand, running gws clone or gws fetch will fetch all remote branches, and gws ff will fast-forward all local branches to their respective latest upstream. So all that this feature would add in practice is to manually check out the branch you want as HEAD.

I guess it could make sense to add that feature, but like I said above I'm not sure it would actually do much.

[pimjansen]

@emlun thanks for the quick reply. I was just checking the source and tried to add some things but got a bit stick in the sed commands though. Overall i think it is pretty easy since it is native GIT to run such commands. The use case where im having it is that my dev team uses it for development to setup their development box but on default all is target on master. I also have some sub references which i want to have on a certain tag instead (1.0.1) for them to default use it.

Wouldnt it be an easy fix to add native git params to the remotes? For example:

customer | git@bitbucket.org:myuser/customer.git -b 1.0.1 | git@myremote.git | git@myotherremote.git 2.0.0

So in this case it will clone on default (what it already does) the first remote locally but with the -b it hops to that specific branch? Giving the clone command it would do this in that case:

# from
if ! git_clone "$repo" "$dir"; then
#to
if ! git_clone "$repo" "$params" "$dir"; then

The only difference is that the params should be stripped and put in a variable during the read of the projects list. In that case GWS will be 100% backwards compatible with the native git commands as well

[emlun]

Yeah, that's a good idea. I'll take a look at it, maybe I can find some time in the next 2 weeks. You're also welcome to contribute a PR before that, of course. I think the way I would go about it is to enable this only if the remote has an explicit name (the first two are implicitly named origin and upstream if none is given), to avoid ambiguity in parsing it.