Re: Questionable "cosmetic changes" commits

[Danny Milosavljevic <dannym@scratchpost.org>]

[-- Attachment #1: Type: text/plain, Size: 3114 bytes --]

Hi Raghav,

first, let me say that as far as I'm concerned, you did nothing wrong--although
it caused a lot of work for you to do the rearranging in the first place
(and also some work for us).

Guix irregularities also annoy the hell out of me.  You can check out some
earlier patches by me (when I joined the project) in the archives.  I wanted
(and still want!) to rearrange a LOT of stuff--because, let's face it, Guix's
module layout in general is a mess.  But for better or for worse, it's
not easy to do anything about it and also keep backward compatibility with
what external projects expect of Guix and also keep using the tools that we
have been using so far (git, diff, patch etc).  So even though I still would
prefer Guix module layout not to suck, it cannot be changed in the short term.
So I know where you are coming from.

But in general, arguing about *formatting* is bike-shedding at its best,
especially in a language where formatting does not matter.

However, we do use textual diff, blame and merge tools--and those do not
understand the tree structure of a Lisp program at all.  Rearranging stuff
especially will (and did) cause diff and patch to mistake the insertion
point for changes.  (It will patch it wrong if applied out of order or when
skipping patches--and will often NOT fail)

So for example it's very difficult to leave off the cosmetic patch and just
apply the non-cosmetic patches that came later.

Furthermore, understand that the package fields (and guix record fields in
general) can refer to previously defined fields--so a package with reordered
fields is NOT necessarily semantically equivalent to the original one.

Try these in guix repl:

(let ((name "OUTER"))
  (package-version
   (package
     (name "INNER")
     (version name)
     (source #f)
     (build-system #f)
     (synopsis #f)
     (description #f)
     (license #f)
     (home-page #f))))

(that gives "INNER")

vs

(let ((name "OUTER"))
  (package-version
   (package
     (version name)
     (name "name")
     (source #f)
     (build-system #f)
     (synopsis #f)
     (description #f)
     (license #f)
     (home-page #f))))

(that gives "OUTER")

That means each cosmetic patch of you required some extra manual review effort
by me in order to make sure that this does not introduce semantic changes.

That said, if people post reformatting patches (especially if part of a patchset
that was presumably already tested by that person) I usually do not say anything
about it because I don't want to cause extra work that is useful to nobody (and
potentially invalidate all the testing done).

FWIW, I do find it strange that Lisp projects, despite using a minimal-syntax
language (mostly in order to conserve its regular tree structure), do not
usually automatically format source code as they check in, but Go projects,
using the prime example of an irregular C-like language, DOES usually use
code formatters automatically when checking in.  That is some strange
reversal of strengths that I wouldn't have expected.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]