Johan Herland [off-list ref] 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.
On Saturday 19 April 2008, Junio C Hamano wrote:
Johan Herland [off-list ref] writes:
quoted
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, [off-list ref]
www.herland.net