Re: branch description

[Johan Herland <johan@herland.net>]

On Saturday 19 April 2008, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> 
> > The problem with (3) vs. (4) is that in (3) we must make sure that whenever
> > a branch is moved/renamed (e.g. "git clone", "git branch -m", probably more
> > as well), the corresponding description is moved/renamed as well. This is
> > elegantly solved in (4).
> 
> If your "elegently solved" is coming from an assumption that it is enough
> for "git mv" (for example) to just copy whatever is in .git/refs/heads/foo
> to .git/refs/heads/bar without understanding what is contained in it, that
> assumption unfortunately does not hold.
> 
> You must support packed refs, so you need to teach the refs infrastructure
> what per-branch attributes there are other than the commit object name it
> points at anyway.
> 
> And we already do -- when you do "branch -m foo bar", corresponding config
> entries are also renamed.  We also move reflogs.
> 
> A possible approach that would work, which contains elements from (4), is
> to change implementations of loose ref to have this extra info in loose
> ref files (that is what (4) is), *and* introduce another separate
> mechanism to store corresponding information for packed refs elsewhere.
> Propagation needs to deal with both representations, renaming needs to
> deal with both representations, looking up needs to deal with both
> representations, everybody needs to deal with both representations.
> 
> If you are going to invent "another separate mechanism" to support packed
> refs anyway, why not use that same mechanism to record information for
> loose ones as well?  That is the approach suggested by (3).  In either way
> we need to teach relevant parts of the code for propagation, renaming,
> looking up etc about the new mechanism.

You're right. Also, after thinking some more about this, it occured to me
that most code paths will probably _not_ be interested in branch
descriptions at all. It therefore makes sense to keep the descriptions away
from the refs themselves, so that they don't impact performance.

So #3 (keeping descriptions in $GIT_DIR/info/refs_description) is probably
the best solution.


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net