On Wed, Nov 15, 2006 at 05:32:06AM CET, Nicolas Pitre wrote: > 1) make "git init" an alias for "git init-db". > > What's the point of "-db"? Sure we're initializing the GIT database. > But who cares? The user doesn't care if GIT uses a "database" or > whatever. And according to some people's definition of a "database" it > could be argued that GIT doesn't use a database at all in the purist > sense of it. What the user wants is to get started and "init" (without > the "-db" is so much more to the point. Doesn't matter if incidentally > it happens to be the same keyword HG uses for the same operation because > we are not afflicted by the NIH disease, right? And it has 3 chars less > to type which is for sure a premium improvement to the very first GIT > user experience! (This is somewhat related to the HEAD issue, e.g. <7v1wo3d6g4.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>, by virtue of basically eliminating it.) Let's see. If you are adding the alias, you can as well add some porcelain stuffing in it, too. What are the 99% of use cases when doing "init"? (a) You are going to do an initial commit right away; the repository is at this point basically useless for anything but initial commit. So you might have "init" well just perform it for you right away. (b) You are setting up a bare repository on a server and you will push to it in a minute. Cogito has a separate cg-admin-setuprepo command for it, which will also prepare it for usage by dumb servers and optionally for shared usage in a group of users. Git could have something similar. > 2) "pull" and "push" should be symmetrical operations ..snip.. > Conclusion: git-pull must not perform any merge. It is the symmetrical > operation of a push meaning that it pulls content from a remote branch > and does no more. People understands that pretty well, . This makes > git-fetch redundant (or an alias to git-pull) in that case, and again we > don't mind it becoming similar to in HG because we admit HG was right > about it. If you _really_ want to do it in Git, the only sensible way to do it is to stop using the "pull" verb for a command name altogether for at least some rather long period of time, otherwise that's a blatant backwards compatibility breakage. > 3) remote branch handling should become more straight forward. > > OK! Now that we've solved the pull issue and that everybody agrees with > me (how can't you all agree with me anyway) let's have a look at remote > branches. It should be simple: ..snip.. By the way, due to the way you describe it, it's not all that clear to me how is this (in)compatible with the current way we do it, on other than the usage and git-pull's auto-creation magic level. Is it that what you are describing _is_ in fact what we do support now, with "branch groups" meaning "remotes" etc, and you are only proposing some enhancements to automatically create remotes in git-pull, or are there some other differences I've missed? -- 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