{"thread":{"id":"50937","subject":"feature request: .blameignore","startedAt":"2019-04-15T21:02:35Z","lastAt":"2019-04-16T16:33:55Z","messageCount":5,"participants":["Christian González","Thomas Gummerer","Barret Rhoden"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"373906","messageId":"130b0ffd-ed84-59ea-751b-cc59241cab1f@nerdocs.at","threadId":"50937","inReplyTo":null,"subject":"feature request: .blameignore","fromName":"Christian González","fromEmail":"christian.gonzalez@nerdocs.at","sentAt":"2019-04-15T20:55:47Z","receivedAt":"2019-04-15T21:02:35Z","isPatch":false,"sender":{"key":"christian.gonzalez@nerdocs.at","avatar":"https://gravatar.com/avatar/c5ffe8c814658cda6427878811aaaf438b5ae6271415957e64334d5f14ae0f0b?d=mp&s=160"},"body":"Hello git community,\n\nI'm completely new here, and maybe my request is dumb, has already a\nbetter solution, or I did not fully understand git. Please tell my if\nso. I stumbled upon this idea while following the django developers\nmailing list, people there discussing whether nor not to adopt *black*\n(https://github.com/ambv/black, a python code formatting tool) as\nenhancement in the development cycle. One of the main arguments against\nblack was that it changes git history by masking git blame. Whenever a\ngit commit with only a black formatting change is committed, you can't\neasily see using git blame WHO did actially write a line of code\n*before* that commit. It is possible to look further manually, and they\nsaid there are tools like git-hyper-blame that circumvent that problem,\nbut I always asked myself since I use git, why isn't there a simple\npossibility how I can e.g. fix a whitespace code \"error\", or do a code\nreformatting WITHOUT taking away the original author's credits for that\nline.\n\nI know, there are some counter arguments about that:  e.g. whitespace\nchanges could lead to programming errors too, even to compiler errors,\ndepending on the language, and how the compiler engine treats whitespace.\n\nI don't suggest git to ignore whitespace (or whatever) changes in the\nblame history automatically.\n\nWhat I suggest is: let git accept a file like .blameignore,\n.gitblameignore, .gitblame etc., you name it.\nIn my simply suggest, I would see that file as one-hash-per-line that is\nignored by git blame. And for the sake of convenience, add a git option\nto add that hash automatically:\n\n    git commit -m \"fix whitespace\" --blame-ignore\n\nThis would add this commit's hash to the .gitblameignore (or whatever) file:\n\n4070ddcdd3d3cc45ec7952e1b37ab374aed9083c # fix whitespace\n\nand a \"git blame any_file.txt\" would ignore this one commit and show the\nlast commit's author of changed lines.\n\nEven better would it be to allow chunks to be excluded, because bad\ncommit habits of whitespace AND real code changes at the same time are\nnot possible to undo later - except there would be a .gitblameignore file.\n\nIt would even be possible to incorporate this into tht .gitignore file,\nwith a section, or a certain prefix...\n\nIMHO, this would allow better per-project maintainance of blame history\nwhich could be changed later in time and  re-fixed if done wrong - all\nwithin git history itself.\n\nI'd love to hear what you think about that.\n\nYours,\n\nChristian\n\n\n\n-- \nDr. Christian González\nhttps://nerdocs.at\n+43 (0) 650 7644477 \n\n"},{"id":"373911","messageId":"20190415211519.GG1704@hank.intra.tgummerer.com","threadId":"50937","inReplyTo":"130b0ffd-ed84-59ea-751b-cc59241cab1f@nerdocs.at","subject":"Re: feature request: .blameignore","fromName":"Thomas Gummerer","fromEmail":"t.gummerer@gmail.com","sentAt":"2019-04-15T21:15:19Z","receivedAt":"2019-04-15T21:15:24Z","isPatch":false,"sender":{"key":"t.gummerer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/191004?v=4"},"body":"On 04/15, Christian González wrote:\n> Hello git community,\n> \n> I'm completely new here, and maybe my request is dumb, has already a\n> better solution, or I did not fully understand git. Please tell my if\n> so. I stumbled upon this idea while following the django developers\n> mailing list, people there discussing whether nor not to adopt *black*\n> (https://github.com/ambv/black, a python code formatting tool) as\n> enhancement in the development cycle. One of the main arguments against\n> black was that it changes git history by masking git blame. Whenever a\n> git commit with only a black formatting change is committed, you can't\n> easily see using git blame WHO did actially write a line of code\n> *before* that commit. It is possible to look further manually, and they\n> said there are tools like git-hyper-blame that circumvent that problem,\n> but I always asked myself since I use git, why isn't there a simple\n> possibility how I can e.g. fix a whitespace code \"error\", or do a code\n> reformatting WITHOUT taking away the original author's credits for that\n> line.\n> \n> I know, there are some counter arguments about that:  e.g. whitespace\n> changes could lead to programming errors too, even to compiler errors,\n> depending on the language, and how the compiler engine treats whitespace.\n> \n> I don't suggest git to ignore whitespace (or whatever) changes in the\n> blame history automatically.\n> \n> What I suggest is: let git accept a file like .blameignore,\n> .gitblameignore, .gitblame etc., you name it.\n> In my simply suggest, I would see that file as one-hash-per-line that is\n> ignored by git blame. And for the sake of convenience, add a git option\n> to add that hash automatically:\n\nThis sounds roughly like what Barret Rhoden (added to Cc) has been\nworking on.  I haven't followed that patch series in detail, but you\ncan have a look at it atthe latest iteration at\nhttps://public-inbox.org/git/20190410162409.117264-1-brho@google.com/.\n\n>     git commit -m \"fix whitespace\" --blame-ignore\n> \n> This would add this commit's hash to the .gitblameignore (or whatever) file:\n> \n> 4070ddcdd3d3cc45ec7952e1b37ab374aed9083c # fix whitespace\n> \n> and a \"git blame any_file.txt\" would ignore this one commit and show the\n> last commit's author of changed lines.\n> \n> Even better would it be to allow chunks to be excluded, because bad\n> commit habits of whitespace AND real code changes at the same time are\n> not possible to undo later - except there would be a .gitblameignore file.\n> \n> It would even be possible to incorporate this into tht .gitignore file,\n> with a section, or a certain prefix...\n> \n> IMHO, this would allow better per-project maintainance of blame history\n> which could be changed later in time and  re-fixed if done wrong - all\n> within git history itself.\n> \n> I'd love to hear what you think about that.\n> \n> Yours,\n> \n> Christian\n> \n> \n> \n> -- \n> Dr. Christian González\n> https://nerdocs.at\n> +43 (0) 650 7644477 \n> \n\n[-- Error: unable to create PGP subprocess! --]\n\n"},{"id":"373917","messageId":"5df051ce-007c-cc12-6f02-345b33480c0a@nerdocs.at","threadId":"50937","inReplyTo":"20190415211519.GG1704@hank.intra.tgummerer.com","subject":"Re: feature request: .blameignore","fromName":"Christian González","fromEmail":"christian.gonzalez@nerdocs.at","sentAt":"2019-04-15T21:56:50Z","receivedAt":"2019-04-15T21:57:00Z","isPatch":false,"sender":{"key":"christian.gonzalez@nerdocs.at","avatar":"https://gravatar.com/avatar/c5ffe8c814658cda6427878811aaaf438b5ae6271415957e64334d5f14ae0f0b?d=mp&s=160"},"body":"Am 15.04.19 um 23:15 schrieb Thomas Gummerer:\n> This sounds roughly like what Barret Rhoden (added to Cc) has been\n> working on.  I haven't followed that patch series in detail, but you\n> can have a look at it atthe latest iteration at\n> https://public-inbox.org/git/20190410162409.117264-1-brho@google.com/.\n\nAs far as I can see this is an \"automagic\" way of creating those \"blame\nskips\" - which can be easier in some way, but until it works \"perfect\"\nIt is prone to produce problems IMHO.\n\nThe git history is a \"document\" that _has_ not to be changed by design.\nSo if this \"heuristic\" produces a wrong result, it's kind of\nunpredictable what was wrong.\n\nI think it would be MUCH easier to mark chunks or whole commits as  \"not\nimportant\" explicitly - by using a file.\n\nLook at .gitignore: git isn't trying to heuristically determine which\nfiles should be ignored when committing. This is done explicitly in a\n.gitignore file.\n\nFor blames this could be done too.\n\nHeuristics could lead to other kind of problems too, as the engine does\nnot know anything about the project. Maybe there will be a programming\nlanguage in near future where trailing whitespaces matter (bah, please\nnot). But the project should decide, not git itself.\n\nSo IMHO project specific .*ignore files are the better way of handling\nthis than doing the skipping on heuristics alone - which could be\nhelpful though when *creating* that files, even during the commit\nprocess... like\n\n    git ccheckut\n    git: 'ccheckut' is not a git command. See 'git --help'.\n\n    The most similar command is\n    checkout\n\nMaybe a lazy:\n\n    git commit -a -m \"big, clunky, fixes everything and the rest\"\n\ncould produce a message like:\n\n    There are whitespace changes in files <file_a>, <file_b> ... -\n    git automatically marked them as not important\n    commits. They are ignored when using git-blame.\n\nChristian\n\n--\n\nDr. Christian González\nhttps://nerdocs.at\n\n"},{"id":"373976","messageId":"7cb3e28d-2f4a-9fa8-d3c5-3b9184e53149@google.com","threadId":"50937","inReplyTo":"5df051ce-007c-cc12-6f02-345b33480c0a@nerdocs.at","subject":"Re: feature request: .blameignore","fromName":"Barret Rhoden","fromEmail":"brho@google.com","sentAt":"2019-04-16T14:52:15Z","receivedAt":"2019-04-16T14:52:21Z","isPatch":false,"sender":{"key":"brho@google.com","avatar":null},"body":"Hi -\n\nOn 4/15/19 5:56 PM, Christian González wrote:\n> Am 15.04.19 um 23:15 schrieb Thomas Gummerer:\n>> This sounds roughly like what Barret Rhoden (added to Cc) has been\n>> working on.  I haven't followed that patch series in detail, but you\n>> can have a look at it atthe latest iteration at\n>> https://public-inbox.org/git/20190410162409.117264-1-brho@google.com/.\n> \n> As far as I can see this is an \"automagic\" way of creating those \"blame\n> skips\" - which can be easier in some way, but until it works \"perfect\"\n> It is prone to produce problems IMHO.\n> \n> The git history is a \"document\" that _has_ not to be changed by design.\n> So if this \"heuristic\" produces a wrong result, it's kind of\n> unpredictable what was wrong.\n> \n> I think it would be MUCH easier to mark chunks or whole commits as  \"not\n> important\" explicitly - by using a file.\n\nI think there's a slight misunderstanding.  In the patchset that Michael \nand I are working on, the user specifies whole commits explicitly.  This \nis usually done with a file, but can also be done from the command line \nfor \"one-off\" ignored commits.  That sounds like what you want.\n\nThe heuristics come in when we try to pass blame for specific *lines* \nthat an ignored commit touched.  We pass the blame to the parent commit, \nbut we also want to match the lines to a specific line in the parent \ncommit.  That way we can find the 'right' ancestor commmit.  We're not \nable to always identify the 'right' commit, hence the heuristics.\n\nBarret\n\n"},{"id":"373981","messageId":"48c54a71-ea00-82be-0844-9e1c76308e1e@nerdocs.at","threadId":"50937","inReplyTo":"7cb3e28d-2f4a-9fa8-d3c5-3b9184e53149@google.com","subject":"Re: feature request: .blameignore","fromName":"Christian González","fromEmail":"christian.gonzalez@nerdocs.at","sentAt":"2019-04-16T16:33:45Z","receivedAt":"2019-04-16T16:33:55Z","isPatch":false,"sender":{"key":"christian.gonzalez@nerdocs.at","avatar":"https://gravatar.com/avatar/c5ffe8c814658cda6427878811aaaf438b5ae6271415957e64334d5f14ae0f0b?d=mp&s=160"},"body":"\n> I think there's a slight misunderstanding.  In the patchset that\n> Michael and I are working on, the user specifies whole commits\n> explicitly.  This is usually done with a file, but can also be done\n> from the command line for \"one-off\" ignored commits.  That sounds like\n> what you want.\n>\n> The heuristics come in when we try to pass blame for specific *lines*\n> that an ignored commit touched.  We pass the blame to the parent\n> commit, but we also want to match the lines to a specific line in the\n> parent commit.  That way we can find the 'right' ancestor commmit. \n> We're not able to always identify the 'right' commit, hence the\n> heuristics.\n>\nOh - that's something different, yes - thank you for clarifying!\nMisunderstanding on my side, yes. This is a really great feature! Is\nthere a vague time schedule for a release? Still this year?\n\nThanks!\n\nChristian\n\n"}]}