> On Jun 6, 2016, at 1:29 PM, Richard Smith via llvm-dev
> <llvm-...@lists.llvm.org> wrote:
>
> On 6 Jun 2016 12:52 p.m., "Bruce Hoult via cfe-dev" <cfe-...@lists.llvm.org
> <mailto:cfe-...@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!
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
