No. The diff is the input, but it uses it to determine file ranges and then
formats the actual files.
On Tue, Aug 19, 2014 at 11:41 AM, Zachary Turner <ztur...@google.com> wrote:
> 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
