> On Aug 7, 2018, at 3:27 PM, Derek Dagit <der...@oath.com.INVALID> wrote:
>
>> It not only makes it difficult to know what commits are associated with a
> PR
>> it also makes back porting / cherry-picking PRs from master to an LTS
> branch really problematic
>
>
> Counter-proposal: Use merge commits.
>
> Part of git's design is the element of a commit, whose sha1 ID can be used
> to track changes across branches.
if I recall, these merge commits were *REALLY* annoying, and rather confusing.
You’d get one such merge commit for every PR. I’m not strictly opposed to this,
but we should think about this very carefully.
Anyone else remember this ?
>
> Finally, as I take cover from the rotten fruit I expect will be thrown my
> way, I'll offer what I've found to be maybe a quick way to identify commits
> that are "destructively" merged across branches:
Right, I’m not saying it’s impossible, it’s just tricky, and you have to use
git log commands. I’ve done this numerous times to “decipher” PRs to be
cherry-picked / back ported, it’s just tedious, and sometimes, fragile (because
you can mess it up).
Cheers,
— leif
