On Wed, Nov 15, 2006 at 10:17:22AM CET, Andy Parkins wrote: > On Wednesday 2006 November 15 04:32, Nicolas Pitre wrote: > > > 3) remote branch handling should become more straight forward. > > I was completely confused by this origin/master/clone stuff when I started > with git. In hindsight, now I understand git a bit more, this is what I > would have liked: > > * Don't use the name "origin" twice. In fact, don't use it at all. In a > distributed system there is no such thing as a true origin. > > * .git/remotes/origin should be ".git/remotes/default". "origin" is only > special because it is the default to push and pull - it's very nice to have a > default, but it should therefore be /called/ "default". But "default" is way too generic a name, it's much more confusing I think. As the one guilty of inventing master and origin, I agree that they are somewhat silly, but if I would have to pick which one to replace with something "better", I'd much rather pick master. Yes, Git can operate in a completely distributed manner. People do use it as it. And there are also people that have no origin branch in their repository. But the vast (overwhelming!) majority of people _does_ work in some kind of hierarchical setup, and for them origin does have a meaning. And origin URL can even change over time! > * git-clone should really just be a small wrapper around > - git-init-db > - create .git/remotes/default > - maybe create specific .git/config > - git-fetch default > If git-clone does anything that can't be done with settings in the config > and the remotes/default file then it's wrong. The reason I say this is that > as soon as git-clone has special capabilities (like --shared, --local > and --reference) then you are prevented from doing magic with existing > repositories. For example; how do you create a repository that contains > branches from two other local repositories that have the objects hard linked? Here I think that modulo the lack of remotes support (which is not a fundamental thing here), the general setup of how Cogito does stuff is much more saner than the current Git mess. It does basically exactly what you've said above, and even the fetching itself is IMHO written much more cleanly than in Git. In an ideal world, Git would just take Cogito's code here. :-) > While I'm writing wishes, I'd like to jump on Junio's integration with other > fetch-backends wish. I use git-svn, and it would be fantastic if I could > replace: > > git-svn init --id upstream/trunk svn://host/path/trunk > git-svn fetch --id upstream/trunk > git-svn init --id upstream/stable svn://host/path/branches/stable > git-svn fetch --id upstream/stable > > With a .git/remotes/svn > SVN-URL: svn://host/path > Pull: trunk:refs/remotes/upstream/trunk > Pull: branches/stable:refs/remotes/upstream/stable > and > git fetch svn > > Obviously, the syntax is just made up; but you get the idea. Even better, > would be if it could cope with my "*" syntax suggested above: > SVN-URL: svn://host/path > Pull: trunk:refs/remotes/upstream/trunk > Pull: branches/*:refs/remotes/upstream/* It shouldn't be hard to do at all. Have the porcelain call "protocol drivers" based on protocol in some generic way, like /usr/lib/git/protocol/$proto. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) - 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