Michael J Gruber wrote: > But my main point here is that we should discuss the pros and cons of > each approach in context (the context of the original thread), and I > haven't heard many pros and cons for either. Ok, here are some thoughts (you can file them under the "pro" or "con" column according to your taste): Branch names are local. The same tip commit can belong to multiple branches, which would make using the tip commit as a key for the branch description problematic. I don't think git notes are a good fit for this purpose. I personally would prefer my branch descriptions to be non-versioned, though I realize that is a matter of taste. Some other information about a branch (such as which upstream branch it pulls from) is stored in the [branch "<branchname>"] section of the git configuration, so it makes a certain kind of sense to put the branch description there, too. On the other hand, the possibility of a [branch "<branchname>"] section in ~/.gitconfig has always been strange, and this is no exception. > I'd be surprised if we changed the protocol just to be able to share > some descriptions, when we have everything we need for sharing refs. The impact of such a protocol change would not have to be as dramatic as you seem to be suggesting. Virtual hosts and peeled ref values were added as backward-compatible extensions to the reference discovery protocol (see Documentation/technical/pack-protocol.txt) which can be taken as examples for inspiration. Here's some discussion of the implementation based on branchname-keyed notes that you mentioned [1]. It is nice to have multiple designs available for trying out, and I hope experience using each reveals potential improvements in the other. [1] http://thread.gmane.org/gmane.comp.version-control.git/181953/focus=182000 -- 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