Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Unfortunately that won't help (if we) in the future use git for backports, since the new backports will get the same graphs once again.
I don't understand this. What graphs?
I presume Grubba means the parent-pointer(s).
I believe the problem lies in how gitk determines what branch(es) a commit is on rather than on our use of grafts for backports.
Correct me if I'm wrong, but a graft is a way to artificially add a parent/child relation, isn't it?
Correct. And apparently it was/is intended for merges only, even though the diff-machinery already delivers correct results even if it's a cherry-pick instead of a merge.
If a commit has two (or more) parents, isn't that per definition a merge of them, which should cause a join of their respective branches? Cherry-picked patches are rather different since only the patch itself is taken from the other branch, not the whole content of that branch.
This is indeed how the current git developers and most of its users expect it.
If parent pointers are used for both of these, then how would git tell a merge from a cherry-pick?
Well, the difference can be inferred from the content, but it's not the way the git community wants to go, so I'm proposing the cherry-pick links instead.
The properties I'm going to propose are that the link: - Is called something like "origin". - That it contains the SHA1 of the commit we're picking from in addition to the --mainline parent-number (in case there are multiple parents). - A commit can have an arbitrary number of "origin" links. - The origin link is weak by default, i.e. once inside a repository it will keep alive any referenced commits, but it will not cause the linked to commit to be fetched or pulled from a remote repository automatically.
Yes, I know this is not Pike specific, but since we're going to make heavy use of this feature in the Pike repository (due to the frequent backports), this is the time to tell me if I missed something in that design definition, because it might make the difference to get the feature accepted into git in a way which works for all typical use cases (or not).