Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and

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