understanding how remote tracking works

understanding how remote tracking works

[Geoff Russell]

I'm trying to get my head around tracking/remote repositories.

Why does "git show-ref" show me far more than in
in .git/refs/remotes/origin?

$ ls -l .git/refs/remotes/origin
total 12
-rw-r--r-- 1 geoff ssh 41 2010-08-09 10:17 BBBB
-rw-r--r-- 1 geoff ssh 41 2010-08-09 10:27 CCCC
-rw-r--r-- 1 geoff ssh 32 2010-08-09 10:13 HEAD

$ git show-ref
...
21ff181dc71a2fb0ef161b3f55f93b8197312515 refs/remotes/origin/BBBB
d2e8aa93940f42c4017f0029d94b9e0ead1d392d refs/remotes/origin/BRANCH
e8ee2fb060589114d8fd5cf1d5c568365f2b3dbb refs/remotes/origin/CCCC
979133b0762ed7b4b8b6e0ef0387a2a11e89c8ba refs/remotes/origin/HEAD
2b568d757d92e8fd581a90888dc8b0bc95355565 refs/remotes/origin/LCG
fe91bc2a45753830b832a9ccf24fdea5d7b73b4c refs/remotes/origin/SWAN
83f9795420b54eb23327ec33d1907757ba8141cc refs/remotes/origin/brA
2a0ea3f9823db8fb9f74171e38531f5be3cd66a5 refs/remotes/origin/brB
979133b0762ed7b4b8b6e0ef0387a2a11e89c8ba refs/remotes/origin/master
85bffc07ee7f3b07717c4ed74e0a6a56e52a48e4 refs/remotes/origin/mmmm
e02730027b1b85d515bce08c17010408610061f4 refs/remotes/origin/nnnn



Cheers,
Geoff Russell

P.S. my git is at 1.6.2.3

Re: understanding how remote tracking works

[Ralf Ebert]

Hi Geoff,

> Why does "git show-ref" show me far more than in
> in .git/refs/remotes/origin?

probably the other refs come from .git/packed-refs . See 
http://www.kernel.org/pub/software/scm/git/docs/git-pack-refs.html .

Greetings,
Ralf

[PATCH/RFC] Documentation: add a FILES section for show-ref

[Jonathan Nieder]

A peek at where the refs are kept might help understanding, even if,
as the DESCRIPTION section suggests, direct access is not part of the
public API.

Balance that out with a pointer to update-ref.

Suggested-by: Geoff Russell <geoffrey.russell@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
 Documentation/git-show-ref.txt |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
index 3f9d9c6..3fe961d 100644
--- a/Documentation/git-show-ref.txt
+++ b/Documentation/git-show-ref.txt
@@ -163,9 +163,15 @@ flag, so you can do
 
 to get a listing of all tags together with what they dereference.
 
+FILES
+-----
+`.git/refs/*`, `.git/packed-refs`
+
 SEE ALSO
 --------
-linkgit:git-ls-remote[1]
+linkgit:git-ls-remote[1],
+linkgit:git-update-ref[1],
+linkgit:gitrepository-layout[5]
 
 AUTHORS
 -------
-- 
1.7.2.1.544.ga752d.dirty

Re: understanding how remote tracking works

[Geoff Russell]

Hi Ralf,

On Mon, Aug 9, 2010 at 11:01 AM, Ralf Ebert <info@ralfebert.de> wrote:
> Hi Geoff,
>
>> Why does "git show-ref" show me far more than in
>> in .git/refs/remotes/origin?
>
> probably the other refs come from .git/packed-refs . See
> http://www.kernel.org/pub/software/scm/git/docs/git-pack-refs.html .

Yes. Many thanks. I'm working my way through Jon Loeliger's Git book and it's
confusing when the actual behaviour differs from that in the book :)

Cheers,
Geoff

Re: understanding how remote tracking works

[Michael Witten]

On Sun, Aug 8, 2010 at 20:53, Geoff Russell <geoffrey.russell@gmail.com> wrote:
> I'm working my way through Jon Loeliger's Git book and it's
> confusing when the actual behaviour differs from that in the book

This probably results from the git culture's conflation (or should I
say confusion?) of low-level and high-level representations and
commands.

Re: understanding how remote tracking works

[Jonathan Nieder]

Michael Witten wrote:
> On Sun, Aug 8, 2010 at 20:53, Geoff Russell <geoffrey.russell@gmail.com> wrote:

>> I'm working my way through Jon Loeliger's Git book and it's
>> confusing when the actual behaviour differs from that in the book
>
> This probably results from the git culture's conflation (or should I
> say confusion?) of low-level and high-level representations and
> commands.

I guess I’ll bite.  What does that mean?  We have “show-ref” and
“update-ref” precisely as low-level commands that are independent
of representation.

Probably the more relevant question: what do you want to do about it?

Re: understanding how remote tracking works

[Geoff Russell]

On Mon, Aug 9, 2010 at 11:49 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Michael Witten wrote:
>> On Sun, Aug 8, 2010 at 20:53, Geoff Russell <geoffrey.russell@gmail.com> wrote:
>
>>> I'm working my way through Jon Loeliger's Git book and it's
>>> confusing when the actual behaviour differs from that in the book
>>
>> This probably results from the git culture's conflation (or should I
>> say confusion?) of low-level and high-level representations and
>> commands.

I often find the low-level commands easier to understand ... and they
don't change as often.

Geoff

Re: understanding how remote tracking works

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Michael Witten wrote:
>> On Sun, Aug 8, 2010 at 20:53, Geoff Russell <geoffrey.russell@gmail.com> wrote:
>
>>> I'm working my way through Jon Loeliger's Git book and it's
>>> confusing when the actual behaviour differs from that in the book
>>
>> This probably results from the git culture's conflation (or should I
>> say confusion?) of low-level and high-level representations and
>> commands.
>
> I guess I’ll bite.  What does that mean?  We have “show-ref” and
> “update-ref” precisely as low-level commands that are independent
> of representation.

I tend to agree with Michael (modulo s/ culture/'s early&/) here.  Many
documents written in the early days, the "tutorial" document by Linus
being the most prominent example, were written in a way to focus exposing
the implementation details to show how simple the structure is.  These
documents and tips by early adopters, simply by virtue of being old, are
found more easily by search engines.  Later we started encouraging use of
show-ref and update-ref to isolate users from the implementation details
that can be changed for performance reasons.

> Probably the more relevant question: what do you want to do about it?

Continue the current course of encouraging the use of plumbing commands
and not looking at the low-level implementation detail.  Perhaps help
people update their documents, moving stale descriptions into "historical
note" sections.

Re: [PATCH/RFC] Documentation: add a FILES section for show-ref

[Junio C Hamano]

Looks good; thanks.

Re: understanding how remote tracking works

[Jonathan Nieder]

Junio C Hamano wrote:

> I tend to agree with Michael (modulo s/ culture/'s early&/) here.  Many
> documents written in the early days, the "tutorial" document by Linus
> being the most prominent example, were written in a way to focus exposing
> the implementation details to show how simple the structure is.
[...]
>> Probably the more relevant question: what do you want to do about it?
>
> Continue the current course of encouraging the use of plumbing commands
> and not looking at the low-level implementation detail.  Perhaps help
> people update their documents, moving stale descriptions into "historical
> note" sections.

Thanks for deciphering.

So here’s a list from a quick Google search for “.git/refs” (alas, the
search engine is not strong enough to return the right hits for “git
"layering violation"”).  Some nice pages here, actually.

 . http://linux.yyz.us/git-howto.html#diff_branch
 . http://www.lostechies.com/blogs/jason_meridth/archive/2009/06/07/git-for-windows-developers-git-series-part-3.aspx
 . http://gitfu.wordpress.com/2008/05/25/git-describe-great-another-way-to-refer-to-commits/
 . http://www-cs-students.stanford.edu/~blynn/gitmagic/ch08.html
 . http://google-opensource.blogspot.com/2008/05/export-git-project-to-google-code.html
   and http://code.google.com/p/support/wiki/ImportingFromGit
 . http://blog.stevecoinc.com/2010/02/stupid-git-tricks.html

It would be nice to find ways to suggest updates (but please
coordinate so as not to flood the authors with mail).

There are a lot of instances of “rm -r .git/refs/original” after
running filter-branch, too.  Maybe filter-branch ought to provide
some synonym for

 eval "$(
	git for-each-ref refs/heads/\* --shell --format='git update-ref -d %(refname) &&' &&
	echo :
 )"

discarding refs/original/* after filter-branch (Re: understanding how remote tracking works)

[Jonathan Nieder]

Jonathan Nieder wrote:

> There are a lot of instances of “rm -r .git/refs/original” after
> running filter-branch, too.  Maybe filter-branch ought to provide
> some synonym for
> 
>  eval "$(
> 	git for-each-ref refs/heads/\* --shell --format='git update-ref -d %(refname) &&' &&
> 	echo :
>  )"

That should have read as

 ...
	git for-each-ref refs/original --shell ...

Sorry about that.