[cfe-dev] [llvm-dev] [lldb-dev] GitHub anyone?

[Craig, Ben via cfe-dev]

On 6/6/2016 2:51 PM, Bruce Hoult via cfe-dev wrote:
> - 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.
The previous statement (sort-of) contradicts the following statement:
> That gives a master history with exactly one commit per feature or bug 
> fix.
In the master history, I would prefer the test and associated code 
change to be in the same commit.  I will suggest my own workflow.  I 
will note that others have already voiced their disapproval of the 
squash commits that you will see.

- developer commits locally to a feature/bug dev branch. You can commit 
work in progress, experiments, have bad commit messages etc

- developer pushes their feature/bug dev branch to their github fork of 
llvm, issues a pull request

- the appropriate maintainer (or or automatic system) causes build and 
tests to be run on the proposed bug fix.

- if the tests work, then do a "git merge --squash" to master.  TBD: 
which commit message(s) should be used?  First commit? Last commit? Pull 
Request description?

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project