Linus Torvalds wrote: > - Case 1: the > > merge-base <sha1> [...] > - Case 2: the > > note merge-base <sha1> [...] > - Case 3: the > > link <sha1> merge-base [...] > In short, the difference between three headers that on the face of it say > exactly the same thing: "merge-base <sha1>", "note merge-base <sha1>", and > "link merge-base <sha1>" is not that they have different syntax (hey, even > the syntax itself is almost identical), but exactly the fact that they > have different implications and _meaning_. > > Two of the three have no unintended consequences. One ("note") has no > technical "consequences" at _all_, by definition. The other "merge-base" > has no technical "unintended" at all, because it's throught through, and > has been fully defined. > > The third? "unintended consequences". It doesn't have a clear definition > ("It's cool. You can use it for any link you want"). So pretty much BY > DESIGN, it's set up so that you don't know what the consequences of it > will be for a project. > > And that's why "case 3" it's bad. Even though it looks very much like the > two other ones. IF (and that is big if) git commit header will be extended to have some extra "link" (enforcing connectivity) headers, like proposed "bind" for subprojects, "prev" for pu-like union branches, "merge-base" for merges, there would be repeated work on enforcing connectivity. Hence generic "link" header (formerly "related") proposal. Having fsck report broken links (or not), having purge removing commits (objects) reachable only via "link" headers, having pull download commits via "link" headers... have I forgot anything? It _seems_ that this part is common, and does not depend on semantics. But with "links" (connectivity headers) there always would be some other consequences. For example info/grafts deals for now only with commit parents, and extending the format could be difficult. And of course if we want connectivity, this is for some reason, so the "link" has some other consequences, for example "prev" and "merge-base" for merging, "bind" for checkout, merge (but differently), etc. I think that if it is 'helper' information (i.e. information which is helpful, but we can do without it) and of no real importance to user then use "note". If it is of importance to user (for example "cherrypick" or "reverted") and of use to git, then repeat such info in "note" header to avoid relying on parsing free-form part aka. commit comment. If connectivity is needed... hmmm... -- Jakub Narebski Warsaw, Poland - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Sun Apr 30 04:08:33 2006
This archive was generated by hypermail 2.1.8 : 2006-04-30 04:08:54 EST