monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Lists in Makefile.am


From: Zack Weinberg
Subject: [Monotone-devel] Lists in Makefile.am
Date: Tue, 15 Aug 2006 16:45:50 -0400

Someone thought it would be a good idea to reformat all the lists in
Makefile.am. I just spent something like an hour putting most of them
back approximately the way they were.  Why?  Because I needed to merge
mainline into nvm.wm.migration, and with the reformatting, I had no
way of telling what content changes had actually taken place.  meld
threw up its hands and said that the entire top half of the file
conflicted.  Even Ediff, which has very powerful difference refinement
heuristics, couldn't tell what had happened.

Please do not reformat these lists.  It is especially important not to
change the order of the files; adding or removing line breaks is less
troublesome, and adjusting whitespace causes no real trouble.
(Provided one uses Ediff, but I am becoming convinced that any tool
less clever than Ediff is not worth bothering with.)  You should also
realize that there's a very good reason why MOST_SOURCES has just one
or two files per line: it's so that it is easy to add one or two files
to a line without overflowing the width of the screen and feeling like
it's necessary to reformat.  It is also easier to see that each .cc
file is next to its associated .hh file that way.

I contradict myself a little because I did reorganize LUA_SOURCES
(again).  However, that list really did change drastically with the
Lua 5.1 import and the switch to .cc source files; and as an external
library, there aren't going to be real conflicts in there.
MOST_SOURCES, by contrast, is likely to grow or lose files on
branches, and therefore it is especially important that it not be
reformatted.  Same goes for the other lists of source files that we
wrote (CMD_SOURCES, LUAEXT_SOURCES, ...)

As a final note, yes, we all have wide screens these days, but that
does not mean it is okay to make files wider than 80 columns.  If you
keep your files to 80 columns then it's possible to get two files side
by side on the screen at a reasonable font size.

zw




reply via email to

[Prev in Thread] Current Thread [Next in Thread]