On Saturday 19 April 2008, Junio C Hamano wrote: > Johan Herland <johan@xxxxxxxxxxx> 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@xxxxxxxxxxx> www.herland.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
