Home » Mailing list archives » git » 2006 » October » 25

Re: (unknown)

Previous thread: by andyparkins on Wednesday, October 25, 2006 - 7:50 am. (1 message)

Next thread: Re: [PATCH] Minor grammar fixes for git-diff-index.txt by Andy Parkins on Wednesday, October 25, 2006 - 8:02 am. (2 messages)
[view original message]
From: Jakub Narebski
Subject: Re: (unknown)
Date: Wednesday, October 25, 2006 - 7:53 am

> I'm sure this will be an unwanted patch. 
[ message continues ]
[view original message]
From: Andy Parkins
Subject: Re: (unknown)
Date: Wednesday, October 25, 2006 - 8:10 am

I did try that, but then the branches don't appear in git branch.  I still=
=20

AHHHH!!! I thought I had.  Dagnamit; I think an upgrade in Debian overwrote=
 my=20
manual git-imap-send compile.  The git-imap-send bug was fixed in=20
e0b0830726286287744cc9e1a629a534bbe75452, but doesn't seem to have made it=
=20
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=20
promise I'm trying really hard to be good.


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

[ message continues ]
[view original message]
From: Karl
Subject: Re: (unknown)
Date: Wednesday, October 25, 2006 - 8:31 am

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
[ message continues ]
[view original message]
From: Junio C Hamano
Subject: Re: (unknown)
Date: Wednesday, October 25, 2006 - 11:38 am

"git branch -r" perhaps.

-


[ message continues ]
[view original message]
From: Andy Parkins
Subject: Re: (unknown)
Date: Wednesday, October 25, 2006 - 3:03 pm

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
andyparkins@gmail.com
-


[ message continues ]
[view original message]
From: Junio C Hamano
Subject: Re: (unknown)
Date: Wednesday, October 25, 2006 - 3:16 pm

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

-


[ message continues ]
[view original message]
From: Junio C Hamano
Subject: Re: (unknown)
Date: Wednesday, October 25, 2006 - 3:20 pm

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



-


[ message continues ]
[view original message]
From: Andy Parkins
Subject: Re: (unknown)
Date: Thursday, October 26, 2006 - 12:14 am

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
andyparkins@gmail.com
-


[ message continues ]
[view original message]
From: Junio C Hamano
Subject: [PATCH] Documentation: clarify refname disambiguation rules.
Date: Thursday, October 26, 2006 - 1:17 am

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, ...
[ message continues ]
[view original message]
From: Josef Weidendorfer
Subject: Re: (unknown)
Date: Thursday, October 26, 2006 - 6:22 am

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?

Josef
-


[ message continues ]
[view original message]
From: Linus Torvalds
Subject: Re: (unknown)
Date: Thursday, October 26, 2006 - 8:35 am

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

		Linus
-


[ message continues ]
[view original message]
From: Shawn Pearce
Subject: Re: (unknown)
Date: Wednesday, October 25, 2006 - 3:16 pm

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.

-- 
Shawn.
-


[ message continues ]
Previous thread: by andyparkins on Wednesday, October 25, 2006 - 7:50 am. (1 message)

Next thread: Re: [PATCH] Minor grammar fixes for git-diff-index.txt by Andy Parkins on Wednesday, October 25, 2006 - 8:02 am. (2 messages)