31–40 of 130 posts
I like it. A problem I had right away is some people commit using two different emails. Like one from home computer and one from work computer. Would be nice to be able to define them as the same thing.
Cool, but how do I increase the number of rows? Is it always just the top ten?
Earlier quoted context omitted.
I have seen `git blame` used to blame specific people. I've seen it work. Some of those people deserved some blame. The manpage explains what the command does. How and why it's used is up to the user.
Alternatively git praise https://github.com/ansman/git-praise
Followed the link, and the README said: > This requires that you have Go, Ruby, and the rake Ruby gem installed. That doesn't cut it for me. git - once built - depends on C libraries and Perl. If you want to add something onto git (that is not specifically targeting Go, or Ruby etc.) - it should not IMNSHO depend on other things. That doesn't mean you can't write your tool in some modern fashionable language, but eve…
These are all build dependencies. You don't need any of these just to run git who. The language could be clearer; I'll update it.
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.
Isn't that what git bisect is for?
Don't tell the higher ups about this stack ranking tool.
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.
Isn't this sort of an inconsequential point? The commit still has one and only one author and that's almost certainly what I'm looking for so I know who to go ask questions about their code. I also use it to find the commit but less frequently.
And the committer and author don’t even need to be the same!
But the point, as I read it, is: what matters is the context, i.e. if a line is faulty, how did things look like when it wasn’t faulty? The commit’s content is more often more important than the committer, although the committer is useful because you can ask them if they’re still around.
Cool stuff. I like using Git via the CLI, but when it comes to blame, I simply use the preview UI of the VSCode GitLens extension. It takes half a second to launch it from the command palette and inspect the blame.
I have some VS Code extension (errr... not sure which) that faintly inlines the git blame result on each line of code you're working on. I find it kind of handy.
I uninstalled it, I seem to recall it impacting the speed of VS Code a good bit.
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.
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.
'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 feature is it tells you who to talk to to understand a piece of code, or to coordinate a roll back, or to do any other sort of communication. It probably matters more in a big company where code is changing frequently and you're unlikely to know everyone and what they're working on.