binutils-gdb

Branch: master

Commit Graph

Author	SHA1	Message	Date
Andrew Burgess	f7f904e4fd	binutils-gdb/git: highlight whitespace errors in source files For a long time I've had this in my ~/.gitconfig: [core] whitespace = space-before-tab,indent-with-non-tab,trailing-space which causes git to show me if I muck up and use spaces instead of tabs, or leave in trailing whitespace. I find this really useful. I recently proposed adding something like this to the .gitattributes files for the GDB sub-directories (gdb, gdbsupport, and gdbserver)[1], however, the question was asked - couldn't this be done at the top level? So, in this commit, I propose to update the top-level .gitattributes file, after this commit, any git diff on a C, C++, Expect, or TCL source file, will highlight the following whitespace errors: (a) Use a space before a tab at the start of a line, (b) Use of spaces where a tab could be used at the start of a line, and (c) Any trailing whitespace. Errors are only highlighted in the diff on new or modified lines, so you don't get spammed for errors on context lines that you haven't modified. The only downside I see to adding this at the top level is if there are any sub-directories that don't follow the tabs/spaces indentation rules very well already, in those directories you'll end up hitting issues any time you edit a line. For GDB we're usually pretty good, so having this highlighting isn't an issue. [1] https://sourceware.org/pipermail/gdb-patches/2022-July/190843.html	4 years ago
Samuel Bronson	a843ea33df	Add a .gitattributes file for use with git-merge-changelog Individual users will still have to: 1. Install git-merge-changelog 2. Set up the merge driver in their git config See gnulib's lib/git-merge-changelog.c [1] for details. For example, I: 1. Patched Debian's gnulib package to build git-merge-changelog, and sent the patch to the Debian maintainer, who then proceeded to not only accept my patch but even write a manpage for git-merge-changelog! (Let's hear it for Ian Beckwith.) So now, I can install it simply by running "apt-get install git-merge-changelog". (Except, of course, that I already have it installed from when I was testing my patch.) 2. Did step (2) from .gitattributes With this patch applied and the above two steps done by whatever means you deem best, you can say goodbye to merge conflicts in ChangeLog files -- at least IF people stop renaming the danged things, anyway. If you don't do step 2, you will continue to suffer from ChangeLog merge conflicts exactly as before, whether or not you did step 1. If you do step 2 but not step 1, git will likely start complaining that it can't find any "git-merge-changelog" to run. [1]: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c [Note: The docs for git-merge-changelog (the comments at the top) say that you need a .gitattributes in every directory. The docs are wrong. Ignore the docs. Well, not the whole docs; just that part. You really only need one at the top level, since .gitattributes uses the same pattern matching rules as .gitignore, which match files in any subdirectory unless you prefix the pattern with a "/", as explained in the gitignore(5) manpage.]	12 years ago

Author

SHA1

Message

Date

Andrew Burgess

f7f904e4fd

binutils-gdb/git: highlight whitespace errors in source files

For a long time I've had this in my ~/.gitconfig:

  [core]
          whitespace = space-before-tab,indent-with-non-tab,trailing-space

which causes git to show me if I muck up and use spaces instead of
tabs, or leave in trailing whitespace.  I find this really useful.

I recently proposed adding something like this to the .gitattributes
files for the GDB sub-directories (gdb, gdbsupport, and gdbserver)[1],
however, the question was asked - couldn't this be done at the top
level?

So, in this commit, I propose to update the top-level .gitattributes
file, after this commit, any git diff on a C, C++, Expect, or TCL
source file, will highlight the following whitespace errors:

  (a) Use a space before a tab at the start of a line,

  (b) Use of spaces where a tab could be used at the start of a line,
  and

  (c) Any trailing whitespace.

Errors are only highlighted in the diff on new or modified lines, so
you don't get spammed for errors on context lines that you haven't
modified.

The only downside I see to adding this at the top level is if there
are any sub-directories that don't follow the tabs/spaces indentation
rules very well already, in those directories you'll end up hitting
issues any time you edit a line.  For GDB we're usually pretty good,
so having this highlighting isn't an issue.

[1] https://sourceware.org/pipermail/gdb-patches/2022-July/190843.html

4 years ago

Samuel Bronson

a843ea33df

Add a .gitattributes file for use with git-merge-changelog

Individual users will still have to:

 1. Install git-merge-changelog

 2. Set up the merge driver in their git config

See gnulib's lib/git-merge-changelog.c [1] for details.

For example, I:

 1. Patched Debian's gnulib package to build git-merge-changelog, and
    sent the patch to the Debian maintainer, who then proceeded to not
    only accept my patch but even write a *manpage* for
    git-merge-changelog! (Let's hear it for Ian Beckwith.)

    So now, I can install it simply by running "apt-get install
    git-merge-changelog".  (Except, of course, that I already have it
    installed from when I was testing my patch.)

 2. Did step (2) from .gitattributes

With this patch applied and the above two steps done by whatever means
you deem best, you can say goodbye to merge conflicts in ChangeLog
files -- at least *IF* people stop renaming the danged things, anyway.

If you don't do step 2, you will continue to suffer from ChangeLog
merge conflicts exactly as before, whether or not you did step 1.

If you do step 2 but not step 1, git will likely start complaining
that it can't find any "git-merge-changelog" to run.

[1]: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c

[Note: The docs for git-merge-changelog (the comments at the top) say
that you need a .gitattributes in every directory.  The docs are wrong.
Ignore the docs.  Well, not the whole docs; just that part.

You really only need one at the top level, since .gitattributes uses
the same pattern matching rules as .gitignore, which match files in
any subdirectory unless you prefix the pattern with a "/", as
explained in the gitignore(5) manpage.]

12 years ago

2 Commits (master)