[PATCh] jit-trackdown

[PATCh] jit-trackdown

[David Greaves]

Hi Junio

Excellent tool :)
Should really be cg-trackdown

David


This patch allows the use of symbolic commits from Cogito's
.git/refs/heads and tags structure eg:
  jit-trackdown HEAD etc/db/schema.sql
or
  jit-trackdown v3.2 etc/db/schema.sql


Signed-off-by: David Greaves <david@dgreaves.com>
---


--- jit-trackdown.orig  2005-04-29 16:57:40.278707704 +0100
+++ jit-trackdown       2005-04-29 16:47:16.495483693 +0100
@@ -1,6 +1,8 @@
 #!/bin/sh

 # Usage: jit-trackdown <commit> paths...
+# <commit> can be the symbolic name HEAD
+# or a tag or head identifier.

 tmp=.jit-trackdown.$$
 hits=$tmp-hits
@@ -10,6 +12,14 @@
 tty -s || to_tty=:

 head="$1"
+if [ $head == "HEAD" ]; then
+  head=$(cat .git/HEAD)
+elif [ -f .git/refs/tags/$head ]; then
+  head=$(cat .git/refs/tags/$head)
+elif [ -f .git/refs/heads/$head ]; then
+  head=$(cat .git/refs/heads/$head)
+fi
+
 shift
 rev-list "$head" |
 while read commit

Re: [PATCh] jit-trackdown

[Junio C Hamano]

>>>>> "DG" == David Greaves <david@dgreaves.com> writes:

DG> Should really be cg-trackdown

Thanks for your kind words and the patch.

     head="$1"
    +if [ $head == "HEAD" ]; then
    +  head=$(cat .git/HEAD)
    +elif [ -f .git/refs/tags/$head ]; then
    +  head=$(cat .git/refs/tags/$head)
    +elif [ -f .git/refs/heads/$head ]; then
    +  head=$(cat .git/refs/heads/$head)
    +fi
    +

I have been primarily looking at the plumbing side and not the
toilet side, and I still have not grokked cg-* yet.  That's why
I did not do the right thing with these .git/refs/* stuff.  If
this were to become part of cg-* suite, I would recommend just
using $(commit-id) there, which should be the only one that
needs to know the .git/* structure convention.

Have toilet side gitters reached a concensus (or semi-concensus)
on how things under .git/ should be organized?  Is there a
summary somewhere, something along the following lines?

    In subdirectories under $GIT_PROJECT_TOP/.git, you have
    files that have some special meaning to the Cogito layer.
    These files are all 41-byte long, which stores a 40-byte
    SHA1 with terminating newline.  What is stored in each
    location is as follows:

    .git/HEAD           	Head commit object of the
                                current tree. 

    .git/refs/heads/$ext	Head commit object of the
                                external tree $ext.  [*Q1*]

    .git/refs/tags/$tag		Named Tag object. [*Q2*]

    *Q1* What is the syntax and semantics rule for $ext, like
         "$ext matches '^[-A-Za-z0-9_]$' and is one of the
         entries in .git/remotes"?

    *Q2* What is the syntax and semantics rule for $tag, like
         "$tag matches '^[-A-Za-z0-9_]$' and can be anything not
         just commit"?

Re: [PATCh] jit-trackdown

[Daniel Barkalow]

On Fri, 29 Apr 2005, Junio C Hamano wrote:

> Have toilet side gitters reached a concensus (or semi-concensus)
> on how things under .git/ should be organized?  Is there a
> summary somewhere, something along the following lines?

I've made a proposal like the following:

.git/
  objects/    (traditional)
  refs/       Directories of hex SHA1 + newline files
    heads/    Commits which are heads of various sorts
    tags/     Tags, by the tag name (or some local renaming of it)
  info/       Other shared information
    remotes
  ...         Everything else isn't shared
  HEAD        Symlink to refs/heads/<something>

The plumbing doesn't care what you name heads or tags, but expects things
to be in heads to be commit objects and tags to be tag objects (which can
tag whatever).

AFAICT, there is general concensus that this is how things should be, but
I haven't convinced Linus that the plumbing should know about anything
other than objects/.

	-Daniel
*This .sig left intentionally blank*

Re: [PATCh] jit-trackdown

[Junio C Hamano]

>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:

DB> I've made a proposal like the following:

DB> .git/
DB>   objects/    (traditional)
DB>   refs/       Directories of hex SHA1 + newline files
DB>     heads/    Commits which are heads of various sorts
DB>     tags/     Tags, by the tag name (or some local renaming of it)
DB>   info/       Other shared information
DB>     remotes
DB>   ...         Everything else isn't shared
DB>   HEAD        Symlink to refs/heads/<something>

Thank you for clear description.

I agree with Linus that plumbing does not need to know anything
but objects/.  What the porcelain passes fsck-cache to implement
prune/garbage-collect does not concern it.  Of course it matters
to the users and that is the reason why I asked.