Johannes Schindelin <[EMAIL PROTECTED]> writes:
> I'd prefer $GIT_DIR/remotes/. And I propose another extension: Since the
> files stored therein right now contain only one <remote> string, it should
> be possible to add the default head(s) to the file.
That makes sense. Currently my arrangement is:
$ cd .git/branches && grep . public-*
public-master:http://www.kernel.org/pub/scm/git/git.git/
public-pu:http://www.kernel.org/pub/scm/git/git.git/#pu
public-rc:http://www.kernel.org/pub/scm/git/git.git/#rc
and in order to get the references on the public server to make
sure people are seeing what I want them to see, I say:
$ for h in master pu rc
do
echo $h
git fetch public-$h
git-rev-parse $h public-$h
done
Instead, I should be able to say:
$ cat .git/remotes/public
http://www.kernel.org/pub/scm/git/git.git/#pu:public-pu,rc:public-rc
to mean that the following two are equivalent:
$ git fetch public
$ git fetch public pu:public-pu rc:public-rc
that is, fetch pu there and store it in refs/heads/public-pu
(same for rc). When I want to fetch only pu from there:
$ git fetch public pu:public-pu
or even
$ git fetch public pu
should work. If I happen to want to fetch pu one-shot but not
want to update my local refs/heads/public-pu, then I should be
able to say
$ git fetch public pu:
Another thing I need to worry about is that I would want to use
this remotes information for pushing as well, but probably the
reference mappings are different when fetching and pushing.
With something like this:
$ cat .git/remotes/ko
kernel.org:/pub/scm/git/git.git/#master:ko-master,pu:ko-pu,rc:ko-rc
$ git fetch ko rc
I would fetch the remote ref "rc" and store it in
refs/heads/ko-rc, which is fine, but after that I would do my
work in the local repository, merge things up and update my
local "rc" (not ko-rc, which to me is a "reference only"
branch), and eventually when pushing I would want to store my
"rc" (again not ko-rc) in "rc" over there.
This means the reference mapping in these two shorthand
notations should be flexible enough to allow me to do:
$ git fetch ko rc ;# get rc from there store it under ko-rc here
which is equivalent to
$ git fetch ko rc:ko-rc
and
$ git push ko rc ;# push rc here to rc there
which is equivalent to
$ git push ko rc:rc
Maybe its time to do a file format that is a bit more flexible.
For example:
$ cat .git/remotes/ko
URL: kernel.org:/pub/scm/git/git.git/
Fetch-Reference: master:ko-master pu:ko-pu rc:ko-rc
Push-Reference: master pu rc
Note that I do not mean "Push-Reference" can not do the rename.
I could have written "master:master" but I did not because I do
_not_ want renaming push in this example.
People who do not need different mappings for fetch/push should
be able to say:
$ cat .git/remotes/public
URL: http://www.kernel.org/pub/scm/git/git.git/
Reference: pu:public-pu rc:public-rc
Another thing I should mention is that Fetch-Reference mapping
is <remote>:<local>, while Push-Reference is <local>:<remote>.
This is only because I feel always using <src>:<dst> is easy to
remember, is the way it works for the command line refs for git
push already, and is the way I plan to enhance fetch to grok.
My current thinking is Reference should take <remote>:<local>
because fetching/pulling is probably more common than pushing,
but I need to think a bit more about it.
Johannes, sorry for doing my design work in an e-mail buffer
to you ;-).
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
