git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Thomas Gummerer <t.gummerer@gmail.com>
To: "Christian González" <christian.gonzalez@nerdocs.at>
Cc: git@vger.kernel.org, Barret Rhoden <brho@google.com>
Subject: Re: feature request: .blameignore
Date: Mon, 15 Apr 2019 22:15:19 +0100	[thread overview]
Message-ID: <20190415211519.GG1704@hank.intra.tgummerer.com> (raw)
In-Reply-To: <130b0ffd-ed84-59ea-751b-cc59241cab1f@nerdocs.at>

On 04/15, Christian González wrote:
> 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
> line.
> 
> 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:

This sounds roughly like what Barret Rhoden (added to Cc) has been
working on.  I haven't followed that patch series in detail, but you
can have a look at it atthe latest iteration at
https://public-inbox.org/git/20190410162409.117264-1-brho@google.com/.

>     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.
> 
> Yours,
> 
> Christian
> 
> 
> 
> -- 
> Dr. Christian González
> https://nerdocs.at
> +43 (0) 650 7644477 
> 

[-- Error: unable to create PGP subprocess! --]


  reply	other threads:[~2019-04-15 21:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-15 20:55 feature request: .blameignore Christian González
2019-04-15 21:15 ` Thomas Gummerer [this message]
2019-04-15 21:56   ` Christian González
2019-04-16 14:52     ` Barret Rhoden
2019-04-16 16:33       ` Christian González

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

  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 \
    --in-reply-to=20190415211519.GG1704@hank.intra.tgummerer.com \
    --to=t.gummerer@gmail.com \
    --cc=brho@google.com \
    --cc=christian.gonzalez@nerdocs.at \
    --cc=git@vger.kernel.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).