Re: [RFC] origin link for cherry-pick and revert

[Theodore Tso <tytso@MIT.EDU>]

On Thu, Sep 11, 2008 at 05:32:02PM +0200, Stephen R. van den Berg wrote:
> gc will preserve the commits the origin links point to once they are
> reachable.  I.e. if the developer doesn't care about the commits the
> origin links point to (i.e. if the branches are not reachable) then gc
> just skips them, if the developer *does* care, the origin links are used
> to keep those objects alive (and, of course, all their parenthood).

This seems wrong.  OK, suppose you have branches A, B, C, and D, while
you are on branch C, you cherry pick commit 'p' from branch B, so that
there is a new commit q on branch C which has an origin link
containing the commit ID's p^ and 'p.    

Now suppose branch B gets deleted, and you do a "git gc".  All of the
commits that were part of branch B will vanish except for p^ and p,
which in your model will stick around because they are origin links
commit q on branch C.  But what good is are these two commits?  They
represent two snapshots in time, with no context now that branch B has
been deleted.  99% of the time, the diff between p^ and p will result
in the equivalent of the diff between q^ and q.  But even if they
aren't, what use are these isolated, disconnected commits?  So having
"git gc" retain them commits that are pointed to be this proposed
origin link doesn't seem to make any sense, and doesn't seem to be
well thought through.

Oh, BTW, suppose you then further do a "git cherry-pick -o" of commit
q while you are on branch D.  Presumably this will create a new
commit, r.  But will the origin-link of commit r be p^ and p, or q^
and q?  And will this change depending on whether or not -o is
specified?

> >I'll also note that having a ***local*** database to cache the origin
> >link is a great way of short-circuiting the performance difficulties.
> >If it works, then it will be a lot easier to convince people that
> >perhaps it should be done git-core, and by modifying core git functions.
> 
> Creating local databases for these kinds of structures feels kludgy
> somehow, since the git hash objects essentially *are* a working
> database.  I have not checked yet if git already has some kind of
> ready-to-use local database lib inside which I could reuse for that.

Gitk already keeps a cache (.git/gitk.cache) to speed up some of its
operations.  And in some ways the index file is a cache, although it
does far more than that.

     	      	       	 		    - Ted