Andy Parkins <andyparkins@xxxxxxxxx> writes: >> 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". I think the naming is just a minor detail and can be overridden with "clone --origin" already. Renaming it to default is just like making separate-remote the default to me -- it is fine as long as it does not break people's expectations. > * If clone really wants to have a non-read-only master, then that should > be .git/refs/heads/master and will initialise > to .git/refs/remotes/$name/master after cloning. Personally I think this is > dangerous because it assumes there is a "master" upstream - which git doesn't > mandate at all. Maybe it would be better to take the upstream HEAD and > create a local branch for /that/ branch rather than require that it is > called "master". I think the latter is what clone has done always; take remote's HEAD and use that to initialize local master (there is no confusion coming from multiple peer repositories because you clone from only one place to initialize the repository -- that one _is_ the origin), and we even keep the HEAD pointing at the remote's master or whatever it points at at the remote. Using "$name" as an object name uses .git/refs/remotes/$name/HEAD. > * git-clone should really just be a small wrapper around >... > 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. That is not entirely true. clone has convenience because people asked. It does not have to mean you are not allowed to give similar convenience to other commands. Patches? > branches from two other local repositories that have the objects hard linked? fetch by second local repository with git-local-fetch perhaps. > There have been lots of "wishlist" posts lately; would it be > useful if I tried to collect all these suggestions from > various people into one place to try and get a picture of any > consensus? A list of common things wished by people certainly is a handy thing to have. A consensus would not write code and it generally does not take technology into account to tell what is realistic and what is not, so the result needs to be take with a grain of salt, though. - 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