Debarshi 'Rishi' Ray <[EMAIL PROTECTED]> wrote: >> I see that your recent indentation changes modify nearly every line >> of parted/ui.c. Did you realize that with such a change, nearly any >> delta from 1.8's ui.c will no longer apply to the one on the trunk? >> I.e., there will *always* be a merge conflict for any change to that file. > > Yes. It occurred to me, but since Otavio said it would be alright to make the > indentation changes in a separate patch I thought it would be fine. Such > formatting related changes have been intrusive in the past too. eg., > 'commit 93ca20d8aebd0d04dbb00b86a2903c992e59a96b' on the master branch. This > problem may occur there also. > >> This means that either the exact same changes should be made to the copy >> of ui.c on any other branch likely to share patches with the trunk, or >> (more likely) the indentation changes should just be backed out. >> >> [snip] >> >> Here's what I'll probably be doing: >> 1) identify which style of indentation (spaces or TABs) applies to each file >> 2) if it's uniformly one or the other, codify that via comments for emacs and >> vim at the bottom of the file >> 3) if it's nearly uniformly one or the other, make the few changes and codify >> as in #2 >> 4) if there's a significant mix, convert to spaces-only[*] and codify > > Do we have a coding style for each file or one for the whole tree? I would > prefer a uniform coding style for the entire tree, and then have comments > in them for Emacs and Vim.
Above, I'm talking only about one small aspect of coding style: whether to indent with spaces or TABs. > This is because I feel having a separate style for every file would only > lead to more confusion and lesser readability. Each file is not totally > self-contained, and one has to consult others while working on one of them. > Moreover there is the possibility of multiple subtly and not so subtly > different coding styles in the entire code base. I agree, but I'm not talking about formatting. Just indentation, in an attempt to make the status quo a little more workable, with minimum impact to ongoing development. > Maybe we need to modify/improve/enforce > http://www.gnu.org/software/parted/snippets/CodingStyle at some point of > time. I too would like to switch to the "GNU" coding style, but any sane style, as long as it is uniform and mechanically verifiable, would be nearly as good. >> Depending on how many files are "irregular", I might add comments >> only to the minority, with the assumption that developers will >> use the proper settings to do the right thing in the "regular" case. > > I would rather have a regular style in every file, and comments to avoid the > odd deviation. :-) So would I, but wholesale reformatting would cause serious disruption among those who are actually trying to apply patches and merge fixes from one branch to another. > The problem is that if we want to enforce a uniform coding style throughout > the code base, there will be the odd file (like parted/ui.c) which will need > to be majorly re-formatted. If we were all to agree to reformat *both* the stable branch and the trunk, then we'd be done, modulo any pending patches relative to the pre-global-format date. Modulo the little detail of deciding on a formatting style, and installing a hook or two to help people check and adhere to the standard. _______________________________________________ parted-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/parted-devel
