<div dir="ltr">I'd suggest a workflow like the following:<div><br></div><div>- developer commits locally to a feature/bug dev branch. You can commit work in progress, experiments, have bad commit messages etc</div><div><br></div><div>- developer commits locally to a feature/bug release branch. Tidy up into a small number of logical commits, nice messages etc. I'd suggest it's good to have at least two commits: 1) a commit adding a test that fails, and is marked as expected to fail, demonstrating the bug or lack of feature. 2) a commit that fixes the bug or adds the feature, and marks the test as expected to pass.</div><div><br></div><div>- developer rebases to master and tests</div><div><br></div><div>- developer pushes their feature/bug release branch to their github fork of llvm, issues a pull request</div><div><br></div><div>- the appropriate maintainer (or or automatic system) causes build and tests to be run on the proposed bug fix.</div><div><br></div><div>- if the tests work, then do a "git merge --no-ff" to master</div><div><br></div><div>There's room to discuss the last part. That gives a master history with exactly one commit per feature or bug fix. The details of how it was done are on a different branch that merges back.</div><div><br></div><div>You might prefer merge --ff-only. This means that the merge can only happen if the new feature has been rebased to the head of master. The commits in the new feature each become a commit in master. In this case you should make very sure that every commit works -- which is defined as no crashes; tests expected to work, work; tests expected to fail, fail.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 6, 2016 at 8:07 PM, James Y Knight via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">+1 to that. I would strongly suggest that we continue to commit to master first, like we've always done in llvm.</p>
<div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Jun 6, 2016 11:44 AM, "Joerg Sonnenberger via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br type="attribution"></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev wrote:<br>
> My only hesitation with this is that this requires use of cherry-pick,<br>
> which is not idea.  The way most git repositories work is to put<br>
> everything that should go into a release branch in the release branch<br>
> *first* and then merge the release branch to master, ensuring that<br>
> everything going out in a release will make it into the next release.<br>
> This is how the gitflow workflow works, for example.<br>
<br>
The model of "commit to oldest first" is IMO one of the most stupid<br>
concepts I have ever seen in git "workflows". It is contrary to the way<br>
software development works and essentially just a bad workaround for<br>
broken cherry picks. I've seen more than one project starting to use<br>
this model due to advocacy after deciding to use git, stumble around<br>
with it for a release or two and then going back to a normal release<br>
management approach. Even the argument you have presented here does not<br>
make sense to me. Just because a change has been committed to a release<br>
branch, doesn't mean it won't get replaced later.<br>
<br>
Joerg<br>
_______________________________________________<br></span>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>