(unknown)

(unknown)

[andyparkins]

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

Re: (unknown)

[Jakub Narebski]

andyparkins@gmail.com wrote:

> 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

Re: (unknown)

[Andy Parkins]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: (unknown)

[Karl Hasselström]

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

Re: (unknown)

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> writes:

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

Re: (unknown)

[Andy Parkins]

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

Re: (unknown)

[Junio C Hamano]

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.

Re: (unknown)

[Shawn Pearce]

Andy Parkins <andyparkins@gmail.com> wrote:
> 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.

-- 

Re: (unknown)

[Junio C Hamano]

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

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

Re: (unknown)

[Andy Parkins]

> > "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

[PATCH] Documentation: clarify refname disambiguation rules.

[Junio C Hamano]

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

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

[Jakub Narebski]

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

Re: (unknown)

[Josef Weidendorfer]

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?

> , .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?

Re: (unknown)

[Linus Torvalds]

On Thu, 26 Oct 2006, Josef Weidendorfer wrote:

> 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".