<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Yup, totally. This dream falls apart very quickly as the workflow
becomes more complex.<br>
<br>
Of course, you can still think of it as "the new commit represents
the work of backporting the fix to the release branch", but that's
kinda wonky.<br>
<br>
<div class="moz-cite-prefix">On 3/21/19 9:22 AM, Andrea Bocci wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAAK6D=46eieLxbVetaXGD-naYurnzJvu1Uid1A4ubzJDWiaL8Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">On Thu, 21 Mar 2019 at 16:34, Artem Dergachev via
cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org"
moz-do-not-send="true">cfe-dev@lists.llvm.org</a>> wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
If you're doing merge commits, you might lose linear
history, but you <br>
obtain another fancy invariant: every piece of work - i.e.,
every patch, <br>
every merge conflict resolution - appears in the repository
exactly <br>
once, under a unique identifier, and the non-linear source
control <br>
history becomes an accurate representation of the real
history of <br>
development.<br>
</blockquote>
<div><br>
</div>
<div>Actually, this is not always true: as soon as one applies
the same patch to different branches (e.g. to backport a fix
from the master branch to a previous release) the patch and
eventual merge conflict resolution will appear as a
different commit, with a different identifier.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>.Andrea<br>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>