Re[2]: [Gc]: [PATCH 3/3] Use leading tabs followed by spaces.

Ivan Maidanski ivmai at mail.ru
Tue Jul 9 03:48:49 PDT 2013


 Hi Ondrej,

I prefer to explicitly type "git diff -w" only if I see that I cannot understand the changes w/o -w. Otherwise it is easy to miss change in code like this:
printf("value is<space>" N); // N is macro

Regards,
Ivan

Tue,  9 Jul 2013, 12:17 +02:00 from Ondřej Bílka <neleai at seznam.cz>:
>Hi Ivan,
>
>On Tue, Jul 09, 2013 at 01:06:22PM +0400, Ivan Maidanski wrote:
>>    Hi Ondrej,
>> 
>>    Thank you for trying to make GC source code well-formatted.
>> 
>>    I use an editor which expands tabs (except for .mk files). So most files
>>    that I've edited over 5 years don't have tabs.
>>    As for formatting, you could try but for this you should cleanly
>>    understand existing formatting rules (which are somewhat informal and seem
>>    to be documented nowhere, but you could check win32_threads.c - it's
>>    almost formatted according to our rules).
>>
>This tends to be hardest part. I will try to ask, 
> 
>>    However there is trade-off between keeping a file strictly formated and
>>    applying modifications. E.g.:
>> 
>Well trade-offs here are that first formatting is helpful, then in
>middle a formatting is problematic until you reach point where it will
>make correct decisions most of time. Then it can greatly simplify work.
>
>>    {
>>    <space><space><some code>
>>    .... // many lines of code
>>    <space><space><some code>
>>    }
>> 
>>    If I need to "ifdef" the above code, I do it like this (mostly) so that
>>    git diff reports only the code change (not the code+format change):
>
>You need to use -w option for that. I tend to forget that so I added
>following shortcuts to my .bashrc and got used to them.
>
>alias gdiff='git diff -w' 
>alias gblame='git blame -w'
>
>In your example it could be possible to send patch with just -w version
>for easier review and then do mechanic reformatting.
>
>Other desirable commands is merging with whitespaces ignored, in git
>
>git apply --ignore-space-change
>git merge --ignore-space-change
>
>This is desirable for example when you change control flow and enclose big 
>piece of code in if () { etc. Sorting merge conflicts manually is
>hassle.
>
>There is problem that you need to check if changes have whitespaces
>correct, here again helps to have explicit rules so program can do that
>for you.
>
>
>Ondra
>_______________________________________________
>Gc mailing list
>Gc at linux.hpl.hp.com
>http://www.hpl.hp.com/hosted/linux/mail-archives/gc/


-- 
Иван Майданский
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20130709/3df197e7/attachment-0001.htm


More information about the Gc mailing list