Junio C Hamano venit, vidit, dixit 07.10.2011 21:59: > Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > >> I am surprised that you seem to have missed what I meant by "branch >> names are local".... >> This matters, a lot, because there is no easy way to partition a >> namespace of names descriptive for humans without a central authority >> to negotiate conflicts. > > I think we are in total agreement. The branch names are local, but the > users may want to annotate to describe _the history_ they intend to build > on it. > > Various ways to convey the description when the end product (i.e. the > history built on it) is shiped were outlined in the series, so that the > shipper can help the receiver understand the history. The information in > the annotation (i.e. the _value_ of branch.$name.description) is something > the shipper wants to share with the receiver, but the mapping between the > local name of the branch the shipper used to build that history (i.e. the > key "$name" in branch.$name.description) is immaterial in the end result. It just seems we judge the "local" aspect completely differently. The point that I don't get is: How to share a branch without sharing a branch name? You cannot. Of course you may "change the name" during the push, or during a fetch, and at that point you know both and can map the description. Note that I'm not tied to the notes implementation. But versioned branch descriptions would be nice for several purposes, for example series cover letters, or descriptions on long lived feature branches. And I don't see how else to have versioned descriptions. Also, for transporting descriptions via config, you have to have an updated git on the server side, whereas anything object/ref based would work now, right? Michael -- 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