Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Apr 29, 2006, 14:59 UTC
- Message-ID
- <e2vuuj$nhp$1@sea.gmane.org>
- In-Reply-To
- <e2kset$lk2$1@sea.gmane.org>
Jakub Narebski wrote:
Show 23 quoted lines
> Junio C Hamano wrote: > >> Jakub Narebski <jnareb@gmail.com> writes: >> >>> 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