Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming

github.com

Post reply on HN
Print view View original

121–130 of 130 posts

Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming

#121

Post by Lanolderen »

kazinator wrote: post #118
Lanolderen wrote: post #93

Earlier quoted context omitted.

Unless you get lazy like me and start committing only out of shame once the modified file count reaches close to triple digits or prior to doing very sketchy changes.

Is this something you do in a brand new project whose organization, direction and overall requirements are not clear? Or persistently? There is such a concept as a brand new project not requiring version control until it hits a certain stage: you know it when you get there.

Persistently. My solo projects aren't particularly complex though so I haven't really wasted any time by not being able to use git history for debugging. I currently have 38 files modified on my solo work project. If I'm in a team I keep it somewhat tidy but solo I only treat commits as manual save points I use only when my spidey senses tingle or when I'm about to refactor something that works fine as it is. Also when I'm done with a large part of the SW so the next dev at least has some rough timeline for what got added when and how many times it was majorly iterated. It's not a good habit but it has yet to bite me in the ass so I learn.

Edit: A large part of the reason now that I think about it is that I don't work off real tickets but just bugs I notice or things that get mentioned on the current solo work project. In a team I can just dissect the ticket and am forced to do only that ticket on the branch whereas solo I'm just jumping all over the place. Sometimes I'll do thing X partway, start considering options and in the meantime do thing Y so it's a mess but the tasks get done so.. For context the project is 1 year old developed from 0 by me. Essentially an internal log parsing and analysis tool for a couple formats. Nothing particularly complex.

Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming

#122

Post by awesome_dude »

hn_user82179 wrote: post #85
delusional wrote: post #83

Earlier quoted context omitted.

I acknowledge that I have no idea what happened in this situation. Please don't take this as me justifying mean behavior. > Code should be holistically understood and it's your job as a technical leader to know how the parts move That's true when we design something. Once the design is done, and is broken, we have to tear it back apart to understand WHAT is broken. That's when blame is useful. I love using git blame.…

I work at a company with a mess of a monorepo but the git history is a gold mine. It's fascinating digging back into history and reading why certain decisions are made, or random pitfalls the author discovered, or context that was missing. It absolutely feels like a bit of a detective mystery trying to dig back and figure out if some line of code is a bug that was meant to do something else, or is functioning as inte…

> Ofc as my org has gotten bigger, we've lost a lot of the discipline around writing good commit messages so now it's just a mess of large code-changes with 1-line "bugfix" explainations :(

I have a battle at the moment to try and get the team I am in (5 devs) to take their git commit messages and history seriously, but the "TL" has said that he "doesn't care that much about commits/history/etc"

That bit us right on the ass when debugging someone elses branch recently, because the state needed to fix was across three seemingly unconnected commits, so a checkout of one commit + fix then needed to be tested across two other commits.

Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming

#123

Post by TZubiri »

lionkor wrote: post #92
TZubiri wrote: post #66

Earlier quoted context omitted.

No. You are thinking of git bisect

No, bisect is not blame but for commits. Blame shows you which COMMIT is to blame. That's my point.

True

Git log gives the author (et al) given a commit.

Git blame gives the commit given the line and file.

Worth noting that annotate and praise were added to address the semantics, regardless of whether they were the original intent or not

Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming

#124

Post by jeff_carr »

weebst wrote: post #28
mmcclimon wrote: post #11

> You can invoke git-who as git who by setting up an alias in your global Git config This works even without the alias, by the way: by default `git whatever` will search your path for `git-whatever` and execute it.

Wow! I had no idea. Will need to update the README. Thanks for the tip!

Yes, that is awesome. I wonder if "go" works like that also?

Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming

#125

Post by Minor49er »

ge96 wrote: post #115
Minor49er wrote: post #52

Earlier quoted context omitted.

> Subversion docs are clear that it's a snarky name and that 'svn praise' and 'svn annotate' are neutral synonyms. A few years ago, some Atlassian developer changed "Blame" in the BitBucket UI to "Annotate". I remember a lot of people being frustrated because they couldn't find "blame" anywhere and the change was never officially announced. It just happened one day Someone opened a ticket with BitBucket about it whic…

I'm not in disagreement about being able to tell who wrote some piece of code, I like gitlens in my vscode for ex. The feelings hurt thing is real, unfortunately for myself I am that person that gets butthurt but it's a phrasing thing, "why did you do this?" vs. something more neutral sounding like "hey this has this side effect are you aware". Anyway unfortunately in my case too we're not allowed to write tests so i…

I'm curious if you have experienced people asking something as blunt and short-sighted as "why did you do this?" as the result of a blame. The blame should reveareveal the PR or commit that a change came from which should answer that question already

You should also write tests. They ensure that your code works as intended. Some teammates might not understand that untested code can cause more development time since broken features will have to be fixed in production, so highlighting bugs that have to be fixed as well as writing tests thst cover as many cases as possible should shine some light for those still not understanding their value

Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming

#126

Post by ge96 »

Minor49er wrote: post #125
ge96 wrote: post #115

Earlier quoted context omitted.

I'm not in disagreement about being able to tell who wrote some piece of code, I like gitlens in my vscode for ex. The feelings hurt thing is real, unfortunately for myself I am that person that gets butthurt but it's a phrasing thing, "why did you do this?" vs. something more neutral sounding like "hey this has this side effect are you aware". Anyway unfortunately in my case too we're not allowed to write tests so i…

I'm curious if you have experienced people asking something as blunt and short-sighted as "why did you do this?" as the result of a blame. The blame should reveareveal the PR or commit that a change came from which should answer that question already You should also write tests. They ensure that your code works as intended. Some teammates might not understand that untested code can cause more development time since b…

That's the thing, I used to think tests are annoying but now I'm advocating for em, maybe a sign of growing up ha. Unfortunately not my call. Yeah it's just tone, tone changes the outcome of some conversation. Puts person on defensive, stops thinking, that kind of thing.

Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming

#127

Post by Minor49er »

ge96 wrote: post #126
Minor49er wrote: post #125

Earlier quoted context omitted.

I'm curious if you have experienced people asking something as blunt and short-sighted as "why did you do this?" as the result of a blame. The blame should reveareveal the PR or commit that a change came from which should answer that question already You should also write tests. They ensure that your code works as intended. Some teammates might not understand that untested code can cause more development time since b…

That's the thing, I used to think tests are annoying but now I'm advocating for em, maybe a sign of growing up ha. Unfortunately not my call. Yeah it's just tone, tone changes the outcome of some conversation. Puts person on defensive, stops thinking, that kind of thing.

I mean, I get it. Priorities can also affect things. I'm in a similar situation at work where the manager is pushing to get a project out as fast as possible at the expense of testing and even basic planning. It's only serving to make things much worse because all of the short sighted decisions are causing all kinds of new problems that could have been avoided entirely

Sometimes it's easier to adopt better practices when moving to another team or project altogether

Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming

#128

Post by funcDropShadow »

ants_everywhere wrote: post #40
lionkor wrote: post #10

By the way, git blaming is really misunderstood by a lot of people; its NOT about who did it, its about which commit is to blame -- that's different.

I'm pretty sure it's about who wrote the code. 'git blame' is named after the subversion and CVS blame features that do the same thing. Subversion docs are clear that it's a snarky name and that 'svn praise' and 'svn annotate' are neutral synonyms. Perhaps someone familiar with CVS can comment on its history there since it seems to be the first source control to add it. EDIT: and one of the main reasons it's a useful…

Yes, the history of the name is as you write. But the value of the command lies in finding the commits, and, especially, in finding which lines changed together.

Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming

#129

Post by follower »

mckn1ght wrote: post #20
rav wrote: post #18

Earlier quoted context omitted.

On a small team I usually already know who wrote the code I'm reading, but it's nice to see if a block of code is all from the same point in time, or if some of the lines are the result of later bugfixing. It's also useful to find the associated pull request for a block of code, to see what issues were considered in code review, to know whether something that seems odd was discussed or glossed over when the code was…

I find the GitHub blame view indispensable for this kind of code archeology, as they also give you an easy way to traverse the history of lines of code. In blame, you can go back to the previous revision that changed the line and see the blame for that, and on and on. I really want to find or build a tool that can automatically traverse history this way, like git-evolve-log.

"Cregit" tool might be of interest to you, it generates token-based (rather than line-based) git "blame" annotation views: https://github.com/cregit/cregit

Example output based on Linux kernel @ "Cregit-Linux: how code gets into the kernel": https://cregit.linuxsources.org/

I learned of Cregit recently--just submitted it to HN after seeing multiple recent HN comments discussing issues related to line-based "blame" annotation granularity:

"Cregit-Linux: how code gets into the kernel": https://news.ycombinator.com/item?id=43451654

Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming

#130

Post by follower »

gwbas1c wrote: post #74
lionkor wrote: post #10

By the way, git blaming is really misunderstood by a lot of people; its NOT about who did it, its about which commit is to blame -- that's different.

BTW, one of the more frustrating things about "git blame" comes about when cleaning up an old codebase: In my current job I had to move a lot of files, combine repos, reformat code, ect, ect. "git blame" and similar tools often always show my name, even though I didn't write the code.

"Cregit" tool might be of interest to you, it generates token-based (rather than line-based) git "blame" annotation views: https://github.com/cregit/cregit

Example output based on Linux kernel @ "Cregit-Linux: how code gets into the kernel": https://cregit.linuxsources.org/

I learned of Cregit recently--just submitted it to HN after seeing multiple recent HN comments discussing issues related to line-based "blame" annotation granularity:

"Cregit-Linux: how code gets into the kernel": https://news.ycombinator.com/item?id=43451654

Of course, in your situation I guess such a tool would only help if other people use it. :D

Post reply on HN