[PATCH] Teach git push .git/branches shorthand

[PATCH] Teach git push .git/branches shorthand

[Junio C Hamano]

Although it is uncertain if we would keep .git/branches for
long, the shorthand stored there can be used for pushing if it
is host:path/to/git format, so let's make use of it.  This does
not use git-parse-remote because that script will be rewritten
quite a bit for updated pulling.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

I hear a lot of people mention $GIT_DIR/branches/ is confusing.
Maybe we should rename it to $GIT_DIR/remote/ directory?

 git-push-script |   63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 62 insertions(+), 1 deletions(-)

c781a84b5204fb294c9ccc79f8b3baceeb32c061
diff --git a/git-push-script b/git-push-script
--- a/git-push-script
+++ b/git-push-script
@@ -1,3 +1,64 @@
 #!/bin/sh
 . git-sh-setup-script || die "Not a git archive"
-git-send-pack "$@"
+
+# Parse out parameters and then stop at remote, so that we can
+# translate it using .git/branches information
+has_all=
+has_force=
+has_exec=
+remote=
+
+while case "$#" in 0) break ;; esac
+do
+	case "$1" in
+	--all)
+		has_all=--all ;;
+	--force)
+		has_force=--force ;;
+	--exec=*)
+		has_exec="$1" ;;
+	-*)
+		die "Unknown parameter $1" ;;
+        *)
+		remote="$1"
+		shift
+		set x "$@"
+		shift
+		break ;;
+	esac
+	shift
+done
+
+case "$remote" in
+*:* | /* | ../* | ./* )
+	# An URL, host:/path/to/git, absolute and relative paths.
+	;;
+* )
+	# Shorthand
+	if expr "$remote" : '..*/..*' >/dev/null
+	then
+		# a short-hand followed by a trailing path
+		shorthand=$(expr "$remote" : '\([^/]*\)')
+		remainder=$(expr "$remote" : '[^/]*\(/.*\)$')
+	else
+		shorthand="$remote"
+		remainder=
+	fi
+	remote=$(sed -e 's/#.*//' "$GIT_DIR/branches/$remote") &&
+	expr "$remote" : '..*:' >/dev/null &&
+	remote="$remote$remainder" ||
+	die "Cannot parse remote $remote"
+	;;
+esac
+
+case "$remote" in
+http://* | https://* | git://* | rsync://* )
+	die "Cannot push to $remote" ;;
+esac
+
+set x "$remote" "$@"; shift
+test "$has_all" && set x "$has_all" "$@" && shift
+test "$has_force" && set x "$has_force" "$@" && shift
+test "$has_exec" && set x "$has_exec" "$@" && shift
+
+exec git-send-pack "$@"

Re: [PATCH] Teach git push .git/branches shorthand

[Johannes Schindelin]

Hi,

On Sun, 7 Aug 2005, Junio C Hamano wrote:

> I hear a lot of people mention $GIT_DIR/branches/ is confusing.
> Maybe we should rename it to $GIT_DIR/remote/ directory?

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.

Ciao,
Dscho

Re: [PATCH] Teach git push .git/branches shorthand

[Josef Weidendorfer]

On Monday 08 August 2005 11:10, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 7 Aug 2005, Junio C Hamano wrote:
> > I hear a lot of people mention $GIT_DIR/branches/ is confusing.
> > Maybe we should rename it to $GIT_DIR/remote/ directory?
>
> I'd prefer $GIT_DIR/remotes/.

IMHO, $GIT_DIR/branches/ is really confusing.
Hmmm... in $GIT_DIR/branches/ there are named references to remote (named) 
references.
Perhaps we should call it "remoterefs/" instead?

Josef

Re: [PATCH] Teach git push .git/branches shorthand

[Johannes Schindelin]

Hi,

On Mon, 8 Aug 2005, Josef Weidendorfer wrote:

> IMHO, $GIT_DIR/branches/ is really confusing.
> Hmmm... in $GIT_DIR/branches/ there are named references to remote (named) 
> references.

Not necessarily. The following is perfectly valid:

echo "rsync://rsync.kernel.org/pub/scm/git/git.git > .git/branches/x

It does not contain a named reference, just a host.

Ciao,
Dscho

Re: [PATCH] Teach git push .git/branches shorthand

[Josef Weidendorfer]

On Monday 08 August 2005 11:55, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 8 Aug 2005, Josef Weidendorfer wrote:
> > IMHO, $GIT_DIR/branches/ is really confusing.
> > Hmmm... in $GIT_DIR/branches/ there are named references to remote
> > (named) references.
>
> Not necessarily. The following is perfectly valid:
>
> echo "rsync://rsync.kernel.org/pub/scm/git/git.git > .git/branches/x
>
> It does not contain a named reference, just a host.

Not really.
Your example defaults to the master head. It is perfectly valid (at least 
cogito usage), to have the reference appended as an anchor:

echo "rsync://rsync.kernel.org/pub/scm/git/git.git#pu" > .git/branches/pu

For lightweight remote tag, even a SHA1 as anchor should be possible.

Josef

> Ciao,
> Dscho
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Teach git push .git/branches shorthand

[Johannes Schindelin]

Hi,

On Mon, 8 Aug 2005, Josef Weidendorfer wrote:

> Your example defaults to the master head.

My point being that I still can say

	git pull x some_non_default_head

with a file "x" in .git/branches. Anyway, I don't care much either way, if 
it be "remotes/" or "remoterefs/" or 
"magic_mapping_for_remote_repositories/" or even "repositories/".

Ciao,
Dscho

Re: [PATCH] Teach git push .git/branches shorthand

[Josef Weidendorfer]

On Monday 08 August 2005 12:36, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 8 Aug 2005, Josef Weidendorfer wrote:
> > Your example defaults to the master head.
>
> My point being that I still can say
>
> 	git pull x some_non_default_head
>
> with a file "x" in .git/branches.

Is this currently possible?

My understanding of .git/branches was that Cogito uses this as mapping of 
remote branches/heads to local branches/refs, and not to store shortcuts for 
remote git repositories.
IMHO, the above usage is a kind of "type mismatch", as the "x" already 
contains the branch.

But perhaps for git it is enough to only have a directory of shortcuts for 
remote repositories, to be found in .git/remotes?

And cogito can use its own subdirectory for remote/local head mappings. This 
mapping even could use the shortcuts from .git/remotes.

> Anyway, I don't care much either way, if 
> it be "remotes/" or "remoterefs/" or
> "magic_mapping_for_remote_repositories/" or even "repositories/".

Me either.

Josef

>
> Ciao,
> Dscho
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Teach git push .git/branches shorthand

[Junio C Hamano]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

>> My point being that I still can say
>>
>> 	git pull x some_non_default_head
>>
>> with a file "x" in .git/branches.
>
> Is this currently possible?

Not right now, but that is the plan.

> My understanding of .git/branches was that Cogito uses this as mapping of 
> remote branches/heads to local branches/refs, and not to store shortcuts for 
> remote git repositories.
> IMHO, the above usage is a kind of "type mismatch", as the "x" already 
> contains the branch.

You can look at it this way: "x which already contains the
branch" can specify the default branch if command line did not
say anything, but the command line can override it.

Re: [PATCH] Teach git push .git/branches shorthand

[Matthias Urlichs]

Hi, Josef Weidendorfer wrote:

> My understanding of .git/branches was that Cogito uses this as mapping of 
> remote branches/heads to local branches/refs, and not to store shortcuts for 
> remote git repositories.

That seems to be the case, yes.

I'd argue that the shortcut idea is inherently more flexible, as it can
emulate mappings, but not vice versa -- for instance, if my local branch
foo corresponds to more than one remote branch, .git/branches/* cannot
comprehend that idea.

That being said, I do like Junio's
>>    $ 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
idea. A lot.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Sometimes I think my head is like a gas tank -- you have to be really
careful what you put into it 'cos it might affect the whole system.
-- I'VE HEARD THE MERMAIDS SINGING

Re: [PATCH] Teach git push .git/branches shorthand

[Darrin Thompson]

On Mon, 2005-08-08 at 11:41 +0200, Josef Weidendorfer wrote:
> Perhaps we should call it "remoterefs/" instead?
> 

How about .git/peers/ ?

--
Darrin

Re: [PATCH] Teach git push .git/branches shorthand

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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 ;-).