That appears to only work against a diff though. Which means I would have
to generate a diff, format it, reset my HEAD back to before I generated the
diff, then re-apply it. Is there nothing that just operates directly on
the repo?
On Tue, Aug 19, 2014 at 11:38 AM, Daniel Jasper <djas...@google.com> wrote:
> 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
