From: "Christian González" <email@example.com>
Subject: feature request: .blameignore
Date: Mon, 15 Apr 2019 22:55:47 +0200 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 2610 bytes --]
Hello git community,
I'm completely new here, and maybe my request is dumb, has already a
better solution, or I did not fully understand git. Please tell my if
so. I stumbled upon this idea while following the django developers
mailing list, people there discussing whether nor not to adopt *black*
(https://github.com/ambv/black, a python code formatting tool) as
enhancement in the development cycle. One of the main arguments against
black was that it changes git history by masking git blame. Whenever a
git commit with only a black formatting change is committed, you can't
easily see using git blame WHO did actially write a line of code
*before* that commit. It is possible to look further manually, and they
said there are tools like git-hyper-blame that circumvent that problem,
but I always asked myself since I use git, why isn't there a simple
possibility how I can e.g. fix a whitespace code "error", or do a code
reformatting WITHOUT taking away the original author's credits for that
I know, there are some counter arguments about that: e.g. whitespace
changes could lead to programming errors too, even to compiler errors,
depending on the language, and how the compiler engine treats whitespace.
I don't suggest git to ignore whitespace (or whatever) changes in the
blame history automatically.
What I suggest is: let git accept a file like .blameignore,
.gitblameignore, .gitblame etc., you name it.
In my simply suggest, I would see that file as one-hash-per-line that is
ignored by git blame. And for the sake of convenience, add a git option
to add that hash automatically:
git commit -m "fix whitespace" --blame-ignore
This would add this commit's hash to the .gitblameignore (or whatever) file:
4070ddcdd3d3cc45ec7952e1b37ab374aed9083c # fix whitespace
and a "git blame any_file.txt" would ignore this one commit and show the
last commit's author of changed lines.
Even better would it be to allow chunks to be excluded, because bad
commit habits of whitespace AND real code changes at the same time are
not possible to undo later - except there would be a .gitblameignore file.
It would even be possible to incorporate this into tht .gitignore file,
with a section, or a certain prefix...
IMHO, this would allow better per-project maintainance of blame history
which could be changed later in time and re-fixed if done wrong - all
within git history itself.
I'd love to hear what you think about that.
Dr. Christian González
+43 (0) 650 7644477
[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 16605 bytes --]
next reply other threads:[~2019-04-15 21:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-15 20:55 Christian González [this message]
2019-04-15 21:15 ` Thomas Gummerer
2019-04-15 21:56 ` Christian González
2019-04-16 14:52 ` Barret Rhoden
2019-04-16 16:33 ` Christian González
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:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.
Code repositories for project(s) associated with this inbox:
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).