understanding how remote tracking works

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

Hi Geoff,

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

Hi Ralf,

On Mon, Aug 9, 2010 at 11:01 AM, Ralf Ebert <info@ralfebert.de> wrote:

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

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

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

Michael Witten wrote:

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?

On Mon, Aug 9, 2010 at 11:49 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:

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

Geoff

Jonathan Nieder <jrnieder@gmail.com> writes:

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.

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.

Junio C Hamano wrote:

[...]

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

Jonathan Nieder wrote:

That should have read as

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

Sorry about that.

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

Looks good; thanks.