<p dir="ltr">On 6 Jun 2016 12:52 p.m., "Bruce Hoult via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> I'd suggest a workflow like the following:<br>
><br>
> - developer commits locally to a feature/bug dev branch. You can commit work in progress, experiments, have bad commit messages etc<br>
><br>
> - 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.</p>
<p dir="ltr">Our policy and workflow is to upstream small, incremental changes wherever possible (rather than presenting reviewers with a complete, monolithic change to review), and that seems to conflict somewhat with your suggestion of working on feature branches. But so long as the changes we receive for review are sufficiently small and authors are happy to receive feedback that the design of the first patch in a series of N is problematic (so the whole series needs rework), I don't think we need to care how they produced the patch.</p>
<p dir="ltr">> - developer rebases to master and tests<br>
><br>
> - developer pushes their feature/bug release branch to their github fork of llvm, issues a pull request<br>
><br>
> - the appropriate maintainer (or or automatic system) causes build and tests to be run on the proposed bug fix.<br>
><br>
> - if the tests work, then do a "git merge --no-ff" to master<br>
><br>
> 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.</p>
<p dir="ltr">I assume you're simplifying for exposition; that's not really how git works (commits aren't associated with any particular branch except perhaps by a convention of annotations in the commit message; a branch is just a label for its current head commit). More precisely, what this would give us is a linear one-commit-per-merge history *if we follow the first parent of each commit from master*. I think that should be fine in practice, but it might be better to instead only allow a commit to be pushed to master on github if its first parent is the current master; that would allow us to avoid merge commits in most cases.</p>
<p dir="ltr">> 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.<br>
><br>
><br>
> On Mon, Jun 6, 2016 at 8:07 PM, James Y Knight via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> +1 to that. I would strongly suggest that we continue to commit to master first, like we've always done in llvm.<br>
>><br>
>><br>
>> On Jun 6, 2016 11:44 AM, "Joerg Sonnenberger via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
>>><br>
>>> 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>
>>> cfe-dev mailing list<br>
>>> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
>><br>
>><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">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
></p>