Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: [PATCH] gdb, gdbserver, gdbsupport: fix leading space vs tabs issues
Date: Mon, 14 Sep 2020 12:13:09 -0400	[thread overview]
Message-ID: <7174ea3f-ea3d-dad9-ab63-df7586ae0f9e@polymtl.ca> (raw)

Many spots incorrectly use only spaces for indentation (for example,
there are a lot of spots in ada-lang.c).  I've always found it awkward
when I needed to edit one of these spots: do I keep the original wrong
indentation, or do I fix it?  What if the lines around it are also
wrong, do I fix them too?  I probably don't want to fix them in the same
patch, to avoid adding noise to my patch.

So I propose to fix as much as possible once and for all (hopefully).

One typical counter argument for this is that it makes code archeology
more difficult, because git-blame will show this commit as the last
change for these lines.  My counter counter argument is: when
git-blaming, you often need to do "blame the file at the parent commit"
anyway, to go past some other refactor that touched the line you are
interested in, but is not the change you are looking for.  So you
already need a somewhat efficient way to do this.

Using some interactive tool, rather than plain git-blame, makes this
trivial.  For example, I use "tig blame <file>", where going back past
the commit that changed the currently selected line is one keystroke.
It looks like Magit in Emacs does it too (though I've never used it).
Web viewers of Github and Gitlab do it too.  My point is that it won't
really make archeology more difficult.

The other typical counter argument is that it will cause conflicts with
existing patches.  That's true... but it's a one time cost, and those
are not conflicts that are difficult to resolve.  I have also tried "git
rebase --ignore-whitespace", it seems to work well.  Although that will
re-introduce the faulty indentation, so one needs to take care of fixing
the indentation in the patch after that (which is easy).

The patch is too big to send through the list, so I have uploaded it on
the users/simark/fix-leading-whitespace branch:

https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/simark/fix-leading-whitespace

Simon


             reply	other threads:[~2020-09-14 16:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-14 16:13 Simon Marchi [this message]
2020-09-14 16:25 ` Christian Biesinger
2020-09-14 17:06   ` Simon Marchi
2020-10-26 16:29 ` Simon Marchi
2020-11-02 15:30   ` Simon Marchi via Gdb-patches

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7174ea3f-ea3d-dad9-ab63-df7586ae0f9e@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox