Re: [PATCH v2] git-clone: Add option --branch to override initial branch

["Tor Arne Vestbø" <torarnv@gmail.com>]

Johannes Schindelin wrote:
> Leaving unnecessary initialization and funny indentation aside for a 
> moment,

I do appreciate the feedback though. C is not my primary language, and
I'm happy to learn from my mistakes :-)

> Keep in mind: your change (as every change) bears the potential to 
> introduce bugs and to complicate the user interface.  The change must be 
> worth those risks.

I fully understand. Here is my rationale for why it's worth the risk:

Imagine you have a project called Foo, which has active development on 
the 'master' branch, and not quite so active development on the more 
stable version branch '1.6' (which v1.6.0 and v1.6.1 was tagged from).

Now, you want to put up info on the project web page / wiki on how to 
contribute to project Foo. This information is for new contributors -- 
who may be unfamiliar with git and it's inner workings. You write:

"To get started contributing to project Foo, please clone using:

   $ git clone git://git.foo.com/project.git

"

This looks nice and inviting.

You also want to provide instructions for those who would like to 
contribute to the more stable branch of project Foo, 1.6:

"If you would like to contribute to the stable 1.6 branch, do:

   $ git clone -n git://git.foo.com/project.git
   $ cd project
   $ git checkout -t origin/1.6
   $ git branch -D master

"

Which is not so nice and inviting. At least not compared to:

"If you would like to contribute to the stable 1.6 branch, do:

   $ git clone git://git.foo.com/project.git --branch 1.6

"

Remember these are new contributors, unfamiliar with git. Presenting 
them with a list of four commands that have to be run to get started 
(commands which incidentally also are the first-ones new users mix up), 
is not ideal. "What does -n do?", "What does -t do?", "What's a tracking
branch?", "Origin? What's that?", "What does -D do?", "Delete?! Will I 
delete the main development line!?", etc.. :)

Also, remember that these commands are not something that can be 
scripted or put into an alias, because these users have not cloned 
anything yet.

I know Subversions is perhaps not the best ideal, but to contrast:

   $ svn import http://svn.foo.bar/project/trunk
   $ svn import http://svn.foo.bar/project/branches/1.6

Easy to get to a different branch without having to dive into the full 
feature set of the SCM.

So, to conclude, I see this as a usability-feature of git-clone, which 
outweighs the possible risk of introducing new bugs. It's not a feature 
I will personally use that often, but it's one that I think new users 
will appreciate.


Tor Arne