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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
