[Openmp-dev] LLVM coding conventions an the OpenMP runtime

[C Bergström via Openmp-dev]

>>
>> In terms of the actual logistics - if the entire clean-up is done as a single
>> commit - it should be fairly easy for that to rebase against an out-of-tree
>> fork. Worst case the research just isn't in sync with upstream, but not all
>> research projects track git HEAD or svn ToT..
>
> Disagree here, what I've seen so far: Neither git nor SVN can easily handle whitespace reformatting on rebase or merge.
>

I'm not sure what you're exactly disagreeing with, but to clarify - I
mean taking the master branch commit, exporting it as a patch and
using patch[0] to fuzzy apply it. This is not a zero cost effort, but
it's a 1x cost and hopefully wouldn't be so expensive. I think it
would largely depend on how localized your changes are. I suspect it's
unlikely that you've changed every file and most changes which would
conflict are likely 1-4 files with probably 1-2 being more LOC impact.
This is just the cost of an out-of-tree fork you must maintain. clang
and llvm afaik also aren't super friendly to out-of-tree branches. For
example, I strongly objected to the old r600/ AMD GPU target being
renamed "amdgpu". The name change did nothing technical, but it did
make it a pita for us.. I lost the argument and we just had to pay the
price to stay in sync.. c'est la vie..

Anyway - if it's not open source research, then my view is it carries
little to no weight. Intel is the exception since catering to them
will hopefully make things easier long term, as I hope they continue
to migrate over bug fixes and stuff.



[0] http://www.gnu.org/software/diffutils/manual/html_node/patch-Options.html