Junio C Hamano [off-list ref] writes:
Andy Parkins [off-list ref] writes:
quoted
On Wednesday 2006, October 25 19:38, Junio C Hamano wrote:
quoted
quoted
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).
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?
quoted
"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
On Thu, 26 Oct 2006, Josef Weidendorfer wrote:
On Thursday 26 October 2006 00:20, Junio C Hamano wrote:
quoted
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".