Re: Cleaning up git user-interface warts

On Wednesday 2006 November 15 04:32, Nicolas Pitre wrote:

Personally, I agree with almost everything in this email. Except the implementation of point 3.

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".

 * Whatever git-clone calls the remote, it should be matched by a directory 
in .git/refs/remotes.  So .git/remotes/$name contains "Pull"s to get all the 
remote branches to .git/refs/remotes/$name/*.   This implies that 
git /always/ does --use-separate-remote in clone.  If a branch is practically 
read-only it should be technically read-only too.

 * 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".

 * Ensuring we have /all/ upstream branches at a later date is hard, and not 
automatic.  Here is the .git/remotes/default file that should be possible:
    URL: git://host/project.git
    Pull: refs/heads/*:refs/remotes/default/*
   Now, every git-pull would check for new upstream branch refs and sync them 
into the local remotes list.  These are read-only so it'd be perfectly safe 
to delete any locally that no longer exist upstream.

 * 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?

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/*

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?

Andy