[phobos] [D-Programming-Language/phobos] a15e68: Accidentally committed with a bunch of debugging c...

[Andrei Alexandrescu]

On 5/4/11 2:38 AM, Don Clugston wrote:
> On 3 May 2011 18:04, Andrei Alexandrescu<andrei at erdani.com>  wrote:
>> Second, in the (hopefully) rare cases when the trunk does break, it's not
>> difficult to turn the clock back to a working version. That makes the
>> slowdown, when it does occur, nowhere near dramatic.
>
> Yes, but that's a general property of a version control system.
> Generally speaking, breaking the trunk is not so bad, provided it gets
> fixed quickly.
> The person who does the merge should be responsible for reverting it,
> if it breaks. Which thus far has not worked well; we've had trunk
> broken
> for extended periods of time (including now!)

One property that git has that probably many other VCSs don't is that 
you can work on an older tree and then easily merge it with the trunk.

> But I just think there's a whole class of commits where pull requests
> will NEVER add value. I don't see *any* value in pull requests for
> improvements to comments, fixes of internal bugs inside functions,
> etc.
> In such cases, pull requests are just busy work. Creating pull
> requests for such things dilutes the value of the pull request system,
> IMHO.
> I agree with David. Would be worth thinking about the process a bit more.

It's difficult to define the "trivial" category. Again, at work we did 
have the experience that something was considered trivial but caused 
breakages when deployed. Anyhow, probably we're not at the size we can 
afford to review each change.


Andrei