[cryptography] openssl on git
noloader at gmail.com
Tue Jan 8 13:36:04 EST 2013
On Tue, Jan 8, 2013 at 1:21 PM, Ben Laurie <ben at links.org> wrote:
> On 8 January 2013 18:06, Jeffrey Walton <noloader at gmail.com> wrote:
>> On Tue, Jan 1, 2013 at 1:02 PM, Ben Laurie <ben at links.org> wrote:
>>> We're experimenting with moving openssl to git. Again.
>>> We've tried an import using cvs2git - does anyone have any views on
>>> better tools?
>>> You can see the results here (not all branches pushed to github yet,
>>> let me know if there's a particular branch you'd like me to add):
>>> Any comments?
>> Would you consider adding a hook to git (assuming it include the ability).
>> Have the hook replace tabs with white space. This is necessary because
>> different editors render tabs in different widths. So white space
>> makes thing consistent for everyone.
>> Then have the hook format the source code against some standard. I
>> don't care which, as long as its consistent.
> Funnily enough we've been discussing this.
> The problem is that the vast majority of the code is formatted to look
> OK with pure tab indentation. Which means that with tabs set to a
> standard 8 columns it sucks (though that does appear to be what was
> used in the original code base).
I [respectfully] think the fallacy is "standard 8 columns". Two
problems: (1) I use either 4 columns or 2 columns on occasion. (2) I'm
not aware of editors adhering to such standards (gedit vs emacs vs
visual Studio vs Xcode vs Notepad vs ....). They all seem to get white
space correct, though.
> People are reluctant to change _all_ the code for the sake of
> indentation and so the current favourite option is to adopt a code
> style that works with different tab widths (specifically 4 and 8
> column) and use no spaces. I realise that almost no-one works this
> way, but it does seem like a sensible option in this case.
Again, spaces are known and every editor gets them right.
> I would certainly like to have an agreed style that is consistent.
Yes, I'm not making any recommendations. Let the Dev Team choose what
they want amongst themselves, and then do it consistently. The git
plug-in will ensure its applied consistently without prejudice.
More information about the cryptography