threads / patch / 1450

patchTeach git push .git/branches shorthand

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

## tl;dr

11 messages between Aug 8, 2005 and Aug 11, 2005. Diffs are folded; open one to read it.

replies: 10people: 5as markdown or json

Junio C Hamano· Aug 8, 2005, 06:12 UTC · lore

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
Show changes to git-push-script +62 −1
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 "$@"
Johannes Schindelin· Aug 8, 2005, 09:10 UTC · re: Junio C Hamano · lore

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

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

Josef Weidendorfer· Aug 8, 2005, 09:41 UTC · re: Johannes Schindelin · lore

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

On Monday 08 August 2005 11:10, Johannes Schindelin wrote:
Show 7 quoted lines
> 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
Johannes Schindelin· Aug 8, 2005, 09:55 UTC · re: Josef Weidendorfer · lore

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

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

Josef Weidendorfer· Aug 8, 2005, 10:25 UTC · re: Johannes Schindelin · lore

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

On Monday 08 August 2005 11:55, Johannes Schindelin wrote:
Show 12 quoted lines
> 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
Show 7 quoted lines
> 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
Johannes Schindelin· Aug 8, 2005, 10:36 UTC · re: Josef Weidendorfer · lore

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

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

Josef Weidendorfer· Aug 8, 2005, 16:22 UTC · re: Johannes Schindelin · lore

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

On Monday 08 August 2005 12:36, Johannes Schindelin wrote:
Show 10 quoted lines
> 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
Show 7 quoted lines
>
> 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
Junio C Hamano· Aug 9, 2005, 02:48 UTC · re: Josef Weidendorfer · lore

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

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
Show 7 quoted lines
>> 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.
Show 5 quoted lines
> 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.

Matthias Urlichs· Aug 11, 2005, 16:29 UTC · re: Josef Weidendorfer · lore

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

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
Junio C Hamano· Aug 9, 2005, 02:48 UTC · re: Johannes Schindelin · lore

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

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 ;-).

← back to recent threads