On Thu, 11 Sep 2008, Stephen R. van den Berg wrote: > Nicolas Pitre wrote: > >First, its name. The word "origin" probably has a too narrow meaning > >that creates confusion. I'd suggest something like a > >"may-be-related-to" field that would be like a weak link. > > Well, the important properties of the name/field would be: > - It should be as specific as possible, in order to minimise the > potential for abuse in the future. I distill the desirability of this > requirement out of the various earlier discussions about commitheaders > in the past on this mailinglist held by others. Well, sure. But being too specific sometimes limits its usefulness. There could be other usages for such a link which IMHO should be defined in terms of graph connectivity semantics rather than high level purpose. > - It should convey a sense of direction (it's a directed graph). Well, isn't that already obvious? > Any generic may-be-related-to field is therefore probably a non-starter. Well, my whole argument is that if it has no generic purpose then it probably doesn't belong in the commit header. > The origin field as currently proposed tightens the requirements that > it either is dangling and ignored or points to a commit. > rev-list --topo-order should use the origin links to order the output. > gc/prune won't delete commits referenced *by* an origin link. And I disagree on the gc/prune point, as mentioned previously. As to rev-list --topo-order, it doesn't need for this link to actually be part of the commit object to accomplish the desired effect. > The only two other arguments one might give to actually keep the field > in the header of the commit as opposed to the trailer is that the > physical field can be kept machine readable, and the actual display can be > beautified like: Origin: 2abcdef..1234567 > The output of the field could be suppressed (if so desired) if the > target commit isn't reachable. > All this is of course possible for a trailer field in the free-form > area as well, but it seems a bit silly to have two places for "headers". And I think you should simply create a file within the repository with that info instead of either thecommit header or the free form text. It gives all the usability advantages you wish for and more. Nicolas -- 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
