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

[Matthias Braun via llvm-dev]

> On Jun 6, 2016, at 1:29 PM, Richard Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On 6 Jun 2016 12:52 p.m., "Bruce Hoult via cfe-dev" <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> >
> > I'd suggest a workflow like the following:
> >
> > - developer commits locally to a feature/bug dev branch. You can commit work in progress, experiments, have bad commit messages etc
> >
> > - 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
> 
While I applaud small patches, this is going too far in my opinion. In my opinion the system should be designed to ease reading and understanding the changes (since a change is usually read by more people than it is written...). In this specific instance I really like the fact to have the testcase together with the commit that fixes it because it often present a short understandable and concrete example of the issue getting fixed [1]

- Matthias

[1] I should mention here that we have a number of testcases in the repository that fail this crtiterium! Cases where the test is just extracted from a real world input but still a lot of instructions and information irrelevant to the problem. Just because a testcase is bugpoint-reduced does not mean it is minimal!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160606/bd17cc89/attachment.html>