Re: Cleaning up git user-interface warts

On Wednesday 2006, November 15 17:55, Junio C Hamano wrote:

I think the latter is what clone has done always; take remote's
HEAD and use that to initialize local master (there is no

It's this sort of thing that is confusing though - the remote HEAD branch 
could be anything, and yet that is made to be origin locally as a tracking 
branch and then master as the writable branch.  What if upstream /has/ a 
master but "next" is its HEAD?  You'd then get

 next:remotes/origin
 master:remotes/master

Then a local master which is actually upstream next!  Oh dear.

I may well have misunderstood what you've said above above clone always 
initialising master from remote's HEAD; if so please disregard what I'm 
saying.

quoted

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?

Absolutely, that was why I said clone shouldn't have special abilities.  In 
fact, if you're willing you don't need clone at all; you just need 
git-init-db and to write the correct remotes file.  

quoted

branches from two other local repositories that have the objects hard
linked?

fetch by second local repository with git-local-fetch perhaps.

Is that not plumbing?  I thought this was about porcelain.

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.

Of course, I only suggested it because the same suggestions were popping up 
multiple times.  Anyway; I put it in the GitWiki at 
http://git.or.cz/gitwiki/Wishlist

Andy

-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE