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.
Does it? That's also a thing that confuses me: Consider commit 1cc21ef0320ecb734d4db5b85dbdc0406815e38e, which is a grafted merge from 7.8 to 7.6.
In gitk, it shows a three-way merge, where the diff from the 7.6 parent shows the patch, as expected. The diff from 7.8 apparently shows whatever differences there are between 7.8 and 7.6 that happens to be in the context of the 7.6 parent diff (e.g. the "verify_mexec_hdr" line).
That's odd imho. Assuming parent pointers mean merges, I'd expect to see all differences between the 7.8 and 7.6 versions of the file. If this was a real merge rather than a cherry-pick, the three-way diff would have a lot of essential information missing.
If, otoh, gitk can tell that the parent pointer into the 7.8 branch is a cherry-pick relation (using a property I've yet to understand), then I'd expect to see a two-way diff on the 7.6 branch only - the differences to 7.8 would just be garbage.
I also get confused with git-log: Look at the same commit with "git log -p 1cc21ef0". Then it doesn't show any diff at all, neither against 7.6 nor 7.8.
What's worse, if I use only "git log -p" on the 7.6 branch and search for the commit there then I don't see the diff either. If I look at the log on a branch, I really expect to see _all_ diffs that leads up to the current content. Maybe this can be explained with that the log due to all the backport merges skips over to the 7.8 tree after a while, but using --first-parent doesn't help.
Btw, speaking of git-log, how does one make it print out the branches like gitk does?
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, /.../
I'm curious, how does that work? I guess this could explain the (imo) strange results I'm discussing above.
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.
Sounds sane to me, but I'm only a n00b.
Btw, my main use case for cherry-pick links are, as I've said elsewhere, to get an accurate log of the difference with "git log A..B". I see now that git-log has a --cherry-pick option which claims to detect cherry-picked patches anyway. How does it work? The commit diffs have to be byte-for-byte identical?