On Wednesday 2006 November 15 04:32, Nicolas Pitre wrote:
> OK..... let's pretend this is my follow-up to your "If I were redoing
Personally, I agree with almost everything in this email. Except the
implementation of point 3.
> 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".
* 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
--
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@xxxxxxxxx
-
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