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

Jakub Narebski wrote:

Junio C Hamano wrote:

quoted

Jakub Narebski [off-list ref] writes:

quoted

Actually, this can be resolved using automatic history grafts to the
remote repository we pulled from, if the commit is not present on local
side (and removing graft when commit appears on local side).

You do not even need history grafts.  The "cherry-pick source"
was a bad example.  Maybe using "related" as a way to implement
"bind" would have been a better example -- we want inter-commit
relationship that requires connectivity but without ancestry for
them.

You can just have two kinds of 'related'.  One that means
connectivity, the other that does not.

Good idea.

Another problem for core git, but I think orthogonal to the
"related"/"note" distinction is if the relation (or note) should be used
as helper in merges, perhaps by some agreed upon convention on the
comment/description/value part (e.g. "mergehelper" or "mergeinfo").

Scratch that. It would be better for merge strategy just to check for
defined set of "links" and "notes", e.g. "prior" (pu-prior) and
"original" (cherrypick).

But there would be problem with connectivity provided by "link" relations,
namely info/grafts file, which deal only with parents. For example when we
cauterize history using grafts (e.g. for shallow clone) the "link" like
"prior" reaching to the cut-off part of the history might make your day ;-)

Well, we could always drop all the connectivity, and make
  link sha1 description...
shortcut for
  note link sha1 description...

-- 
Jakub Narebski
Warsaw, Poland