<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 22, 2019 at 3:40 PM Joerg Sonnenberger via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Fri, Mar 22, 2019 at 04:39:26PM +0000, David Greene via llvm-dev wrote:<br>
> One consequence of this is that release branches can be more easily<br>
> validated.  In a world with merge commits, many projects make fixes on<br>
> the release branch *first*, then merge the release branch to master,<br>
> ensuring that fixes in the current release make it into the next release<br>
> (when that is branched off master in the future).<br>
<br>
This always felt strongly like a design deficit of git and not a feature<br>
that should be advertised. That is, lack of proper cherry-picking meta<br>
data is the main bug and the back-way model of committing to the oldest<br>
release branch first is the consequence.</blockquote><div><br></div><div>I'm not sure I understand? In a model where you would commit to trunk and cherry-pick to a release branch, and never commit directly to the release branch (which looks like what LLVM is doing), what is the issue with the lack of cherry-picking metadata?</div><div> </div><div>-- </div><div>Mehdi</div><div><br></div></div></div></div>