Skip to Content.
Sympa Menu

sm-commit - Re: [SM-Commit] GIT changes to master grimoire by Thomas Orgis (e29981cde83e143459e19efbdce706851a8b0cbe)

sm-commit AT lists.ibiblio.org

Subject: Source Mage code commit list

List archive

Chronological Thread  
  • From: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • To: sm-commit AT lists.ibiblio.org
  • Subject: Re: [SM-Commit] GIT changes to master grimoire by Thomas Orgis (e29981cde83e143459e19efbdce706851a8b0cbe)
  • Date: Mon, 26 Mar 2007 17:31:04 -0500

On Mar 26, Thomas Orgis [thomas-forum AT orgis.org] wrote:
> Am Mon, 26 Mar 2007 15:58:44 -0500
> > > +# That is ugly, but we need to ensure minimal accounts that usually are
> > copied
> > > +# from iso. At least in theory (for chroots), we should create
> > everything via spells.
> > > +# Root account is always needed, bin user/group is provided by iso and
> > an unknown
> > > +# number of spells need it. Perhaps one should make a
> > smgl-system-accounts spell and
> > > +# remove all create_(account|group) from here?
> >
> > Thomas can you *please* fix your editor so that at least when you work on
> > SMGL things it uses a proper 80 column break? It's bad enough when mails
> > and commit messages are wrapping, but I really don't like to see comments
> > and spell code overly wide and wrapping, it makes it hard for others to
> > manage.
>
> Oh, the legacy of the punch cards!

You can call it what you like, a lot of us maintain terminals of
non-infinite width so we can have more of them on the screen, and nowhere
is "as wide as anyone can get away with" the standard. 80 is the standard
size so that's what's sane to use to play well with others.

> I agree that there is one too long line in INSTALL:
>
> # number of spells need it. Perhaps one should make a smgl-system-accounts
> spell and
>
> That's 84 chars. Sorry, that one slipped through. I made sure the others
> are <=80 and they indeed are.

Maybe this is an imperial vs metric issue but no, at least 3 of those lines
are > 80. 'from iso' is 85. 'Root account' is 81. 'That is ugly' ends up
wrapping in the commitdiff because of the + delimeter at the beginning but
those kinds of things happen sometimes no matter what best intentions.

> Same in HISTORY. Still, your mail reply greatly messed up with the
> quoting when breaking the lines but only putting one ">" in there.

I quoted it that way on purpose so you can see what the rest of us have to
try to see. It's really annoying to be editing a file or reading a commit
and see all these wrapped lines everywhere, and sometimes data is even
lost. Yeah vim is smart enough to color it all correctly but 'git show'
isn't necessarily even smart enough to wrap it:

+# That is ugly, but we need to ensure minimal accounts that usually are
copied
+# from iso. At least in theory (for chroots), we should create everything
via s
+# Root account is always needed, bin user/group is provided by iso and an
unkno
+# number of spells need it. Perhaps one should make a smgl-system-accounts
spel
+# remove all create_(account|group) from here?

> Does the 80char rule also apply for the commit comment? I guess so, since it
goes
> out to a mailing list (with a stupid...

Well, it's definitely good manners. Keep in mind an extra tab gets
prepended to the commit message from what you see in your editor.

> Well, I'll wrap that, too in future. But for sure I won't "fix" my editor to
do that
> automatically, since that can _break_ badly (not just the lines;-) when
programming
> (even bash).

I don't know what editor you use but it's not usually hard to make it
enforce standard widths at least via visual cues without mandating them in
places they'd break anything.

> Please don't be offensed when I express my disliking for the 80char issue,
> I will obey the rules as good as I can, but I won't tell you I'm glad being
> forced into the punch card legacy;-)
> So please, just make it clear: Lines up to 80 characters in spell files
> _and_
git
> comments (I hope exceptions in spell files are allowed where breaking a long
> command line would only complicate things or is not easily possible)?

Nobody expects you to adhere to formatting that breaks code, of course.
But other than that it's just a matter of etiquette and not making it hard
for other people that have to review your code or make their own
modifications later.

Attachment: pgpXMx4zudf7M.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page