Linus Torvalds <torvalds@xxxxxxxx> writes: > On a slightly related note, I absolutely _hate_ how cherry-picking adds > "(cherry-picked from commit <sha1>)" at the end. It's wrong for so many > reasons, one of them being that it then breaks things like this, but the > main one being that <sha1> will quite often actually end up not even > _existing_ in the resulting archive (you cherry-picked from your private > branch, and even if you keep your branch, you don't necessarily push it > out). > > Junio, can we make the default _not_ to do it, please? I understand that it can be annoying. I was hoping that however when you do something like this: git log --filter-backported-commits v2.6.16.9..v2.6.17 an improved log-inspection tool could notice and filter out the ones that was backported from the mainline to the maintenance branch. But I realize that is probably a faulty logic. First of all, not all backports are cherry-picked (the same patch can be applied from an e-mail, for example), so if we really want to do the above filtering, we would need to be able to detect the same patch anyway without "cherry-picked from" information. To a certain degree, git-patch-id would help detecting such a duplicated patch, but it would not help you detect "moral equivalent" changes that are textually different. A cherry-pick after a conflict resolution that ends up applying a textually different patch would still leave the "cherry-picked from" message in the commit log (or a "note " header if we implement it to reduce cluttering the log message), which would be the only advantage of recording the information somehow. But that is probably not worth it -- it means "moral equivalent" changes need to be recorded somehow by hand, which is unnecessarly developer burden if it is rare enough to want to filter such duplicates when inspecting the log. Do people find "cherry-picked from" information useful? Does anybody mind if we change the default not to record it? - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html