{"thread":{"id":"2114","subject":"What's in git.git repository","startedAt":"2005-10-15T05:48:35Z","lastAt":"2005-10-16T02:20:10Z","messageCount":4,"participants":["Junio C Hamano","Sven Verdoolaege"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"10119","messageId":"7vwtkfpbyk.fsf@assigned-by-dhcp.cox.net","threadId":"2114","inReplyTo":null,"subject":"What's in git.git repository","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-15T05:48:35Z","receivedAt":"2005-10-15T05:48:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The \"master\" branch has been updated with some \"obviously\ncorrect\" updates, as usual.\n\nIn proposed updates, there are currently two topics.\n\nOne is the new tag dereference notation and showing the deref'ed\ntag from the remote side via ls-remote I posted last night. \n\nI'd have this graduate to the \"master\" branch after some more\ntesting, only if people are interested in it; otherwise I'm\nthinking about dropping this (I am not particularly interested\nin this enhancement myself).\n\nAnother is the improved handling of funny characters in\npathnames. The final notation follows what Paul Eggert outlined\nin his message a couple of days ago -- C-style quoted string\nenclosed in a pair of double-quotes. I have not written formal\nset of tests, but updated git-diff-*, git-ls-files, git-ls-tree,\nand git-apply seem to do the right thing with my limited\nhand-tests.\n"},{"id":"10121","messageId":"20051015100309.GR8383MdfPADPa@greensroom.kotnet.org","threadId":"2114","inReplyTo":"7vwtkfpbyk.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git repository","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2005-10-15T10:03:09Z","receivedAt":"2005-10-15T10:03:09Z","isPatch":false,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Fri, Oct 14, 2005 at 10:48:35PM -0700, Junio C Hamano wrote:\n> I'd have this graduate to the \"master\" branch after some more\n> testing, only if people are interested in it; otherwise I'm\n> thinking about dropping this (I am not particularly interested\n> in this enhancement myself).\n\nDereferencing of tags to trees could be interesting for tools\nsuch as dirdiff. Of course, you can always do the dereferencing\nyourself and I'm planning on rewriting it in C anyway.\n\nskimo\n"},{"id":"10143","messageId":"7vr7amjqa1.fsf@assigned-by-dhcp.cox.net","threadId":"2114","inReplyTo":"46a038f90510142340r2fe24ce6j5d0d96535fbb2517@mail.gmail.com","subject":"Re: What's in git.git repository","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-15T23:48:06Z","receivedAt":"2005-10-15T23:48:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Langhoff writes:\n\n>> I'd have this graduate to the \"master\" branch after some more\n>> testing, only if people are interested in it; otherwise I'm\n>> thinking about dropping this (I am not particularly interested\n>> in this enhancement myself).\n>\n> Fair enough -- it simplifies (and speeds up) the git-findtags script I\n> posted. Actually, it makes it redundant. But if it's not\n> elegant/needed/wanted in the C core, git-findtags can deal with it in\n> the soft and sloppy sphere of perl scripts.\n> Most people don't need this at all, and I guess that's why we managed\n> so long without it. But I think it's a basic plumbing service.\n\nOh, I did not mean that I did not *like* the implementation or\nfeature. I just was unsure if that was what you and Pasky would\nfind useful.\n\nI was trying to add something that would be useful in general,\nbut if what I did was missing the mark and wasn't something you\ntwo found useful, there was no need to add it.\n\nSo, thanks for the feedback and background rationale. Let's\nhave it in \"master\" then.\n"},{"id":"10145","messageId":"7vpsq6fbj9.fsf@assigned-by-dhcp.cox.net","threadId":"2114","inReplyTo":"46a038f90510151734k141f218crc2ccfbb78769e518@mail.gmail.com","subject":"Re: What's in git.git repository","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-16T02:20:10Z","receivedAt":"2005-10-16T02:20:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Langhoff writes:\n\n> One thought I had this morning is that given that the\n> tree->commit->tagobj relation is unique and stable, it'd be a valid\n> strategy to have files in .git/refs/tags/ optionally contain the 3\n> identifiers. It is plainly safe to cache this permamently, the only\n> pain now is to deal with teaching all the porcelains about it.\n>\n> What do you think?\n\nMany ref readers read just the first 40 bytes and ignore the\nrest, so storing \"tag-SHA1 followed by optional information\"\nthere would not hurt them that much. But the question now is\nwhat optional information to place there?\n\nObviously, we could do:\n\n echo '5dc01c59... tree=c39ae07f...' >.git/refs/tags/v2.6.11\n echo '26791a8b... commit=9ee1c9... tree=e4660ac...' >.git/refs/tags/v2.6.12\n\techo '0918385d... blob=b92c9c0...' >.git/refs/tags/junio-gpg-pub\n\nBut, then we could also do:\n\n\t(\n \techo '5dc01c59...'\n git-cat-file tag v2.6.11\n\t) >.git/refs/tags/v2.6.11\n\nThere is no need to read 'tag' object separately -- it is all\nthere. The same thing can be said for a tag that refers to\nanother tag that refers to a commit that contains a tree. So\nthe question becomes \"where to stop?\".\n\nI suspect the answer to that question is \"it depends\". And I\nalso suspect \"sed -e '...' <.git/refs/tags/v2.6.11\" after we add\nminimum optional information (not tag text but only commit and\nperhaps tree object name) to these files would not be that much\ncheaper than doing \"git-cat-file commit v2.6.11 | sed -e '...'\".\nIn other words, my gut feeling tells me that it would not buy us\nthat much.\n\nI've also thought about showing v2.6.12^{tree} in addition to\nv2.6.12^{} from ls-remote, and showing v2.6.12^{commit} instead\nof v2.6.12^{}, to make the type of what it dereferences to more\nexplicit. I did not do things that way because I was not quite\nsure how much the additional complexity and additional output\nfrom ls-remote would buy us.\n"}]}