Re: branch description

> 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.