<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Jun 6, 2016, at 10:07 AM, James Y Knight via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<div><blockquote type="cite" class=""><div class=""><p dir="ltr" class="">+1 to that. I would strongly suggest that we continue to commit to master first, like we've always done in llvm.</p></div></blockquote><div>More generally, I suggest that we keep a discussion about moving hosting and svn->git to *just* those topics. Any changes of workflow should be deferred until after and if these changes happen.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class="">
<div class="gmail_extra"><br class=""><div class="gmail_quote">On Jun 6, 2016 11:44 AM, "Joerg Sonnenberger via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br type="attribution" class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev wrote:<br class="">
> My only hesitation with this is that this requires use of cherry-pick,<br class="">
> which is not idea. The way most git repositories work is to put<br class="">
> everything that should go into a release branch in the release branch<br class="">
> *first* and then merge the release branch to master, ensuring that<br class="">
> everything going out in a release will make it into the next release.<br class="">
> This is how the gitflow workflow works, for example.<br class="">
<br class="">
The model of "commit to oldest first" is IMO one of the most stupid<br class="">
concepts I have ever seen in git "workflows". It is contrary to the way<br class="">
software development works and essentially just a bad workaround for<br class="">
broken cherry picks. I've seen more than one project starting to use<br class="">
this model due to advocacy after deciding to use git, stumble around<br class="">
with it for a release or two and then going back to a normal release<br class="">
management approach. Even the argument you have presented here does not<br class="">
make sense to me. Just because a change has been committed to a release<br class="">
branch, doesn't mean it won't get replaced later.<br class="">
<br class="">
Joerg<br class="">
_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</blockquote></div></div>
_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></div></blockquote></div><br class=""></body></html>