Re: [boost] [git] Why are we using Github (was: The any library does not pull cleanly because of a forced update on develop and

Subject: Re: [boost] [git] Why are we using Github (was: The any library does not pull cleanly because of a forced update on develop and
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-12-18 21:11:03

On 19/12/2013 14:30, Quoth Niall Douglas:
> I think Linus is mostly annoyed that there isn't a toggle for an
> advanced pull request UI for github, because with very little extra
> work (a few extra form fields with the signer etc) you'd be a lot
> closer to good enough.

That's true.  And Boost might be at a scale where it will want to use 
signed commits (though personally I think that attributing it to the 
maintainer who finally pushes it is probably sufficient, since 
presumably they're well-known and are warranting a change as tested 
and/or approved -- and should know how to find the original submitter if 
not self-generated).

>> And about the word wrapping, he's just *wrong*. :)
>
> I get his point about not being able to easily mix up commentary (72
> char wrap) with source code quotes (no wrap). A lot of github issues
> I see contain patches which are utterly useless after github has
> mangled them. Why github so mangles text in so many inconsistent ways
> depending on which part of github you're in I really don't get, and
> on that I definitely agree with Linus.

The solution there is to simply not wrap commentary at all.  72 char 
wrap is arbitrary and completely wrong in most cases other than Ye Olde 
Terminal Window (and sometimes even there).  Wrapping should only occur 
at the very last UA presentation level and not be preserved when 
submitting.  (Which is NOT the same thing as stripping or reconstructing 
newlines, which is worse.)

This does require something in the editor itself to indicate which lines 
are code lines and not supposed to be wrapped at all, but most editors 
and/or markup formats have some way to indicate that.

Even in email, which is hard-word-wrapped by convention, there are 
standards to indicate which newlines are soft and which are hard, such 
as format=flowed, where [SP][NL] indicates a soft newline that should be 
removed by the UA and allowed to word-wrap.

Though he's right that GitHub's web-based editor doesn't seem to support 
that for the commit message itself, despite supporting it for the actual 
file edits.  But it's not hard to manually wrap code to keep it 
readable, leaving commentary to auto-wrap.  (And it's fairly rare to put 
code in the commit message anyway, isn't it?)