threads / discuss / 43245

Re: (unknown)

Subject: Re: (unknown)

## tl;dr

14 messages between Oct 25, 2006 and Oct 26, 2006.

replies: 13people: 7as markdown or json

andyparkins@gmail.com· Oct 25, 2006, 14:47 UTC · lore

(unknown)

From cd4366ed4e3f765c00310c35c0eabeccf433acdb Mon Sep 17 00:00:00 2001
From: Andy Parkins <andyparkins@gmail.com>
Date: Wed, 25 Oct 2006 15:47:19 +0100
Subject: [PATCH] Use "up/" prefix for all the upstream branches
To: git@vger.kernel.org
X-TUID: aba1ff8a0c61615e
X-UID: 126
X-Length: 1359
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200610251547.19208.andyparkins@gmail.com>

To easily differentiate the read-only upstream branches, from normal branches,
default to cloning them with the prefix "up/" added to their branch names.
This also abandons the idea of an "origin" branch which is now simply
"up/master" and hence removes the special treatment that master was getting.
(cherry picked from 33d89375652222c41fbf225f1e1c3bfb38b755b2 commit)
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
I'm sure this will be an unwanted patch.  However, I really do think it's 
important to highlight these upstream branches in some way.  I realise 
renaming "origin" is probably not going to fly, but perhaps it would be okay 
to have at least the non-origin branches prefixed?

 git-clone.sh |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/git-clone.sh b/git-clone.sh
index 3f006d1..ebd93da 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -185,7 +185,7 @@ fi
 
 if test -z "$origin"
 then
-	origin=origin
+	origin=up/master
 fi
 
 # Turn the source into an absolute path if
@@ -389,7 +389,7 @@ Pull: refs/heads/$head_points_at:$origin
 			then
 				continue
 			fi
-			echo "Pull: refs/heads/${name}:$remote_top/${name}"
+			echo "Pull: refs/heads/${name}:$remote_top/up/${name}"
 		done >>"$GIT_DIR/remotes/$origin" &&
 		case "$use_separate_remote" in
 		t)

-- 
1.4.2.3

Jakub Narebski· Oct 25, 2006, 14:53 UTC · re: andyparkins@gmail.com · lore

andyparkins@gmail.com wrote:

Show 11 quoted lines

> To easily differentiate the read-only upstream branches, from normal branches,
> default to cloning them with the prefix "up/" added to their branch names.
> This also abandons the idea of an "origin" branch which is now simply
> "up/master" and hence removes the special treatment that master was getting.
> (cherry picked from 33d89375652222c41fbf225f1e1c3bfb38b755b2 commit)
> Signed-off-by: Andy Parkins <andyparkins@gmail.com>
> ---
> I'm sure this will be an unwanted patch.  However, I really do think it's 
> important to highlight these upstream branches in some way.  I realise 
> renaming "origin" is probably not going to fly, but perhaps it would be okay 
> to have at least the non-origin branches prefixed?

Check if "git clone --use-separate-remote" isn't what you want.

And please correct mail sending.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Andy Parkins· Oct 25, 2006, 15:10 UTC · re: Jakub Narebski · lore

On Wednesday 2006 October 25 15:53, Jakub Narebski wrote:

> Check if "git clone --use-separate-remote" isn't what you want.

I did try that, but then the branches don't appear in git branch. I still like that they exist.

> And please correct mail sending.

AHHHH!!! I thought I had. Dagnamit; I think an upgrade in Debian overwrote my manual git-imap-send compile. The git-imap-send bug was fixed in e0b0830726286287744cc9e1a629a534bbe75452, but doesn't seem to have made it into debian yet.

I'm getting so sick of looking like an idiot.

My apologies to everyone for the constant noise I keep dumping on the list. I promise I'm trying really hard to be good.

Andy

-- 
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com

Karl Hasselström· Oct 25, 2006, 15:31 UTC · re: Andy Parkins · lore

On 2006-10-25 16:10:02 +0100, Andy Parkins wrote:

> My apologies to everyone for the constant noise I keep dumping on
> the list. I promise I'm trying really hard to be good.

I always try sending the patch to myself first, since something almost always goes wrong on the first try. This helps against most problems, but certainly not all. :-)

-- 
Karl Hasselström, kha@treskal.com

Junio C Hamano· Oct 25, 2006, 18:38 UTC · re: Andy Parkins · lore

Andy Parkins <andyparkins@gmail.com> writes:

Show 6 quoted lines

> On Wednesday 2006 October 25 15:53, Jakub Narebski wrote:
>
>> Check if "git clone --use-separate-remote" isn't what you want.
>
> I did try that, but then the branches don't appear in git branch.  I still 
> like that they exist.

"git branch -r" perhaps.

Andy Parkins· Oct 25, 2006, 22:03 UTC · re: Junio C Hamano · lore

On Wednesday 2006, October 25 19:38, Junio C Hamano wrote:

> > I did try that, but then the branches don't appear in git branch.  I
> > still like that they exist.
>
> "git branch -r" perhaps.

That's pretty good.  It makes things like

  git-log remotes/origin/master..master

A bit long winded, but it's certainly what I asked for.

You guys really have thought of everything.

Andy

-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE

Junio C Hamano· Oct 25, 2006, 22:16 UTC · re: Andy Parkins · lore

Andy Parkins <andyparkins@gmail.com> writes:

Show 12 quoted lines

> On Wednesday 2006, October 25 19:38, Junio C Hamano wrote:
>
>> > I did try that, but then the branches don't appear in git branch.  I
>> > still like that they exist.
>>
>> "git branch -r" perhaps.
>
> That's pretty good.  It makes things like
>
>   git-log remotes/origin/master..master
>
> A bit long winded, but it's certainly what I asked for.

"git log remotes/origin..master" perhaps?

The point being, remotes/origin when origin is a directory that has HEAD that points at something, it stands for remotes/origin/HEAD.

Junio C Hamano· Oct 25, 2006, 22:20 UTC · re: Junio C Hamano · lore

Junio C Hamano <junkio@cox.net> writes:

Show 20 quoted lines

> Andy Parkins <andyparkins@gmail.com> writes:
>
>> On Wednesday 2006, October 25 19:38, Junio C Hamano wrote:
>>
>>> > I did try that, but then the branches don't appear in git branch.  I
>>> > still like that they exist.
>>>
>>> "git branch -r" perhaps.
>>
>> That's pretty good.  It makes things like
>>
>>   git-log remotes/origin/master..master
>>
>> A bit long winded, but it's certainly what I asked for.
>
> "git log remotes/origin..master" perhaps?
>
> The point being, remotes/origin when origin is a directory that
> has HEAD that points at something, it stands for
> remotes/origin/HEAD.

Heh, I spoke too fast.

	"git log origin..master"

If you do not have none of .git/origin, .git/refs/origin, .git/refs/tags/origin, .git/refs/heads/origin, nor .git/refs/remotes/origin, then .git/refs/remotes/origin/HEAD is what "origin" means (see get_sha1_basic() in sha1_name.c).

Andy Parkins· Oct 26, 2006, 07:14 UTC · re: Junio C Hamano · lore

Show 14 quoted lines

> > "git log remotes/origin..master" perhaps?
> >
> > The point being, remotes/origin when origin is a directory that
> > has HEAD that points at something, it stands for
> > remotes/origin/HEAD.
>
> Heh, I spoke too fast.
>
> 	"git log origin..master"
>
> If you do not have none of .git/origin, .git/refs/origin,
> .git/refs/tags/origin, .git/refs/heads/origin, nor
> .git/refs/remotes/origin, then .git/refs/remotes/origin/HEAD is
> what "origin" means (see get_sha1_basic() in sha1_name.c).

Again: you guys have thought of everything.

I believe then, that my problem is that I didn't find this written anywhere - would it be useful if I were to write a Documentation/ file about commit-ish/tree-ish that covered these issues? Have I overlooked the existence of such a file already?

Andy

-- 
Dr Andy Parkins, M Eng (hons), MIEE

Junio C Hamano· Oct 26, 2006, 08:17 UTC · re: Andy Parkins · lore

[PATCH] Documentation: clarify refname disambiguation rules.

Nobody should create ambiguous refs (i.e. have tag "foobar" and branch "foobar" at the same time) that need to be disambiguated with these rules to keep sanity, but the rules are there so document them.

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

  >> Heh, I spoke too fast.
  >>
  >> 	"git log origin..master"
  >>
  >> If you do not have none of .git/origin, .git/refs/origin,
  >> .git/refs/tags/origin, .git/refs/heads/origin, nor
  >> .git/refs/remotes/origin, then .git/refs/remotes/origin/HEAD is
  >> what "origin" means (see get_sha1_basic() in sha1_name.c).

  Something like this.

 Documentation/git-rev-parse.txt |   25 +++++++++++++++++++++----
 1 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 5d42570..ed938aa 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -122,14 +122,30 @@ blobs contained in a commit.
   your repository whose object name starts with dae86e.
 
 * An output from `git-describe`; i.e. a closest tag, followed by a
-  dash, a 'g', and an abbreviated object name.
+  dash, a `g`, and an abbreviated object name.
 
 * A symbolic ref name.  E.g. 'master' typically means the commit
   object referenced by $GIT_DIR/refs/heads/master.  If you
   happen to have both heads/master and tags/master, you can
   explicitly say 'heads/master' to tell git which one you mean.
+  When ambiguous, a `<name>` is disambiguated by taking the
+  first match in the following rules:
 
-* A suffix '@' followed by a date specification enclosed in a brace
+  . if `$GIT_DIR/<name>` exists, that is what you mean (this is usually
+    useful only for `HEAD`, `FETCH_HEAD` and `MERGE_HEAD`);
+
+  . otherwise, `$GIT_DIR/refs/<name>` if exists;
+
+  . otherwise, `$GIT_DIR/refs/tags/<name>` if exists;
+
+  . otherwise, `$GIT_DIR/refs/heads/<name>` if exists;
+
+  . otherwise, `$GIT_DIR/refs/remotes/<name>` if exists;
+
+  . otherwise, `$GIT_DIR/refs/remotes/<name>/HEAD` if exists.
+
+* A ref followed by the suffix '@' with a date specification
+  enclosed in a brace
   pair (e.g. '\{yesterday\}', '\{1 month 2 weeks 3 days 1 hour 1
   second ago\}' or '\{1979-02-26 18:30:00\}') to specify the value
   of the ref at a prior point in time.  This suffix may only be
@@ -146,8 +162,9 @@ blobs contained in a commit.
 * A suffix '{tilde}<n>' to a revision parameter means the commit
   object that is the <n>th generation grand-parent of the named
   commit object, following only the first parent.  I.e. rev~3 is
-  equivalent to rev{caret}{caret}{caret} which is equivalent to\
-  rev{caret}1{caret}1{caret}1.
+  equivalent to rev{caret}{caret}{caret} which is equivalent to
+  rev{caret}1{caret}1{caret}1.  See below for a illustration of
+  the usage of this form.
 
 * A suffix '{caret}' followed by an object type name enclosed in
   brace pair (e.g. `v0.99.8{caret}\{commit\}`) means the object

-- 
1.4.3.3.g43f1

Jakub Narebski· Oct 26, 2006, 08:40 UTC · re: Junio C Hamano · lore

Re: [PATCH] Documentation: clarify refname disambiguation rules.

Junio C Hamano wrote:

> -* A suffix '@' followed by a date specification enclosed in a brace

[...]

> +* A ref followed by the suffix '@' with a date specification
> +  enclosed in a brace
>    pair (e.g. '\{yesterday\}', '\{1 month 2 weeks 3 days 1 hour 1

This introduces strange line breaking. Is it only in source?

Here diff didn't produce optimal for review patch, separating changed from part and changed to part with large block of added code.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Josef Weidendorfer· Oct 26, 2006, 13:22 UTC · re: Junio C Hamano · lore

On Thursday 26 October 2006 00:20, Junio C Hamano wrote:

Show 5 quoted lines

> Heh, I spoke too fast.
> 
> 	"git log origin..master"
> 
> If you do not have none of .git/origin

Really? I thought refs are always looked up in ".git/refs" only?

> , .git/refs/origin, 
> .git/refs/tags/origin, .git/refs/heads/origin, nor
> .git/refs/remotes/origin, then .git/refs/remotes/origin/HEAD is
> what "origin" means (see get_sha1_basic() in sha1_name.c).

Yes.

However, IMHO it really should be a alias to "remotes/origin/<branch>", depending on current "<branch>" you are on. AFAI can remember, when implementing it, HEAD was choosen as sha1_name.c should not cope with porcelain issues (e.g. getting current branch name). It was the intention to change remotes/origin/HEAD in the porcelain command before actual use.

Is this still sensible?

Linus Torvalds· Oct 26, 2006, 15:35 UTC · re: Josef Weidendorfer · lore

On Thu, 26 Oct 2006, Josef Weidendorfer wrote:

Show 8 quoted lines

> On Thursday 26 October 2006 00:20, Junio C Hamano wrote:
> > Heh, I spoke too fast.
> > 
> > 	"git log origin..master"
> > 
> > If you do not have none of .git/origin
> 
> Really? I thought refs are always looked up in ".git/refs" only?

Yes and no.

The "iterate over all refs" code only ever looks in the "refs" subdirectory, so when you _list_ refs, they won't ever be shown unless they are there. That affects a lot of programs (like "git ls-remote").

Also, a symlink-ref has to point into "refs/" or it is considered invalid.

But, there are two extra rules:

 - ".git/HEAD" is obviously special, and will show up separately even for 
   things like "git ls-remote", so even processes that _list_ things will 
   show it.

 - when you do a named lookup, stuff directly in ".git" will take 
   precedence over EVERYTHING, even if it is never listed. So for example, 
   if you have a branch named HEAD in .git/refs/heads/HEAD, it doesn't 
   matter. Your ".git/HEAD" will still be looked up first.

   Similarly, other "special heads", like ORIG_HEAD or MERGE_HEAD will be 
   looked up in .git, even though they will never be listed by anything.

So the "refs/" requirement is a real requirement for a "true ref", but it is still overruled by the rule that we have special refs in $GIT_DIR that always take precedence.

This also means, for example, that you can always give the "full" refname for lookup, ie

	git-rev-parse refs/heads/master

works, because that's the "full path" from the ".git" subdirectory. If we only ever looked things up inside "refs", you'd have to use "heads/master".

Shawn Pearce· Oct 25, 2006, 22:16 UTC · re: Andy Parkins · lore

Andy Parkins <andyparkins@gmail.com> wrote:

Show 14 quoted lines

> On Wednesday 2006, October 25 19:38, Junio C Hamano wrote:
> 
> > > I did try that, but then the branches don't appear in git branch.  I
> > > still like that they exist.
> >
> > "git branch -r" perhaps.
> 
> That's pretty good.  It makes things like
> 
>   git-log remotes/origin/master..master
> 
> A bit long winded, but it's certainly what I asked for.
> 
> You guys really have thought of everything.

Try the bash completion support in contrib/completion. If you are using the bash shell it does branch name completions for most commands, including both sides of the '..' in log there. At this point I can't use Git without it.