Re: GIT vs Other: Need argument

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 23 Apr 2007, Linus Torvalds wrote:

> On Mon, 23 Apr 2007, Carl Worth wrote:
> >
> > And with the recent talk about phasing cogito out and just merging its 
> > functionality into git itself, why not just use the cogito syntax for 
> > this:
> > 
> > 	git clone <url>#<branch>
> 
> That's a fundamentally weaker operation than the current "git clone", so I 
> really don't think it's a good idea. The syntax also absolutely sucks, 
> it's so horribly non-unixy.
> 
> I'd personally be ok with a
> 
> 	git clone --default=<branch> <url>
> 
> to create something where "master" defaults to some other remote branch, 
> but that just addresses the syntax. And quite frankly, I don't think we 
> *need* to. We shoud just tell people how _easy_ it is to track some other 
> branch now.

I've converted all my coworkers to git recently, and it was helpful to be 
able to go two weeks without explaining branches, due to the fact that our 
repositories only have one branch each (at least that people care about). 
It was also nice that, when one of them did learn about branches, he had 
the two weeks of experience with the absolute basics. I think that a first 
time user should be able to get, from the clone command:

[remote "origin"]
	url = ...
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
	remote = origin
	merge = refs/heads/<something>

if the first-time user's first repository for learning has the interesting 
stuff in a non-default branch. Now, a second-time user can learn about 
branches, but I think that branches are confusing and scary if you don't 
already have a bit of experience with the operations that affect a branch.

Obviously, if you want to track two branches in one repository, you need 
to know how to *have* additional local branches, but you can put off 
learning that until you recognize the need for it, if there's any easy way 
to get your initial branch to track the remote branch you're interested 
in.

Someone can get work done with clone, add, commit -a, pull, and push (or 
format-patch). Two commands and an additional fundamental concept is a lot 
of overhead at that stage.

For that matter, I sometimes want a repository where master tracks a 
branch that isn't default for other people and "mainline" tracks the 
upstream master, which requires a small amount of config file editing, and 
can't be made to just happen.

	-Daniel
*This .sig left intentionally blank*
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]