Use clang-format-diff.py checked into cfe/tools/clang-format.
On Tue, Aug 19, 2014 at 11:25 AM, Zachary Turner <ztur...@google.com> wrote:
> +djasper
>
> Ok, just for the record, here's what I do (for context, this discussion is
> about how to reformat the contents of an existing CL, without touching
> lines that were not modified by the CL).
>
> 1) Checkout chrome (wtf right? I'm sure there's a better workflow, I
> just don't know what it is. djasper might though, which is why I've added
> him)
> 2) set the CHROMIUM_BUILDTOOLS_PATH environment variable to point to
> d:\src\chromium\src\buildtools (update this for your situation)
> 3) Update PATH environment variable to point to the version of git that is
> in chrome's depot_tools
> 4) Commit some changes to my local git repo, but don't dcommit them yet.
> 5) git cl format
>
> This will look through your commit log and collect all the changes that
> are not upstreamed yet, and reformat those changes, leaving the result in
> your working copy. For me, this is usually just a single commit that
> hasn't been upstreamed yet, so I just git commit --amend to add the
> formatting to it.
>
> I'm not sure how to do this without chrome's "git cl format" command.
> Daniel?
>
>
> On Tue, Aug 19, 2014 at 11:13 AM, Todd Fiala <tfi...@google.com> wrote:
>
>> Hey Zach,
>>
>> It'd be great if you posted the command line you run to do that. I'm
>> sure there are others (myself included) that would love to see how that
>> works.
>>
>> Thanks!
>>
>> -Todd
>>
>>
>> On Tue, Aug 19, 2014 at 11:06 AM, Zachary Turner <ztur...@google.com>
>> wrote:
>>
>>> Definitely agree with you on this. I have no plans to go fixup old
>>> code, and I don't think others should either. And if we see a change go
>>> through that does attempt to fix up old code, we should block it.
>>>
>>> That said, I'm working on a clang-format file that will automate this
>>> formatting for us (or at least, for me, should nobody else choose to use
>>> it), and I plan to run it against all my changelists before submitting
>>> them. Note that this only reformats lines that have already been touched
>>> by the CL, so there's no risk of formatting-only changes making it in.
>>>
>>>
>>> On Tue, Aug 19, 2014 at 11:00 AM, Sean Callanan <scalla...@apple.com>
>>> wrote:
>>>
>>>> One point about this discussion, by the way.
>>>>
>>>> While I support adherence to a consistent style for new/changed code,
>>>> this should in no way be taken as support for going through and fixing
>>>> indentation/style on old code.
>>>> We have internal branches that become hell to merge when e.g. spacing
>>>> has been altered subtly, or brace depth is changed…
>>>> If we all do our part to clean the parts we’re touching, then I think
>>>> that will be enough to keep LLDB clean.
>>>>
>>>> Sean
>>>>
>>>> On Aug 19, 2014, at 10:16 AM, Zachary Turner <ztur...@google.com>
>>>> wrote:
>>>>
>>>> I brought this up in a thread on lldb-commits, but since it is of more
>>>> general interest, I want to make a thread here as well.
>>>>
>>>> Can we have clear direction on LLDB coding style? Ideally in the form
>>>> of an update to lldb.llvm.org, but as that might require a little more
>>>> effort, even some details in a response to this thread would be a help.
>>>> Some things I've deduced from looking at the code, and other things I'm
>>>> not so sure about, because of inconsistencies in the code or just no clear
>>>> rule.
>>>>
>>>> Indentation width: 4
>>>> Column limit: 140 (does this apply to comments too? Most
>>>> function-declaration comments seem to wrap at 80)
>>>> Brace style: Allman
>>>> if (foo)
>>>> {
>>>> // code here
>>>> }
>>>>
>>>> Break after function return type: Always, only on declarations, only on
>>>> definitions, only in headers, or never?
>>>>
>>>> Space before function parentheses: When?
>>>>
>>>> Indent case labels inside switch: A or B below?
>>>> switch (foo)
>>>> {
>>>> case A:
>>>> case B:
>>>> }
>>>>
>>>> Indent braces inside of a case: A or B below?
>>>> switch (foo)
>>>> {
>>>> case A:
>>>> {
>>>> }
>>>> case B:
>>>> {
>>>> }
>>>> }
>>>>
>>>> Any other rules I should be cognizant of?
>>>> _______________________________________________
>>>> lldb-dev mailing list
>>>> lldb-dev@cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev@cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>
>>>
>>
>>
>> --
>> Todd Fiala | Software Engineer | tfi...@google.com | 650-943-3180
>>
>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
