Still need to be able to "push --force" on the remote repo for this to be useful, right?
Git-blame-someone-else
31–40 of 100 posts
Re: Git-blame-someone-else
#32Stop using git blame to look up who authored code, it's not a useful tool. Use git log -S to search for changes to that line (then repeat with the previous version of that line, until you find the original author), and/or git log -L to track changes to a code block. Don't waste your time with git blame.
how is git log -S more efficient? You have to write whole line, what if line is long? What if you need to look at several lines within some range. git blame is much better than your git log -S
Re: Git-blame-someone-else
#33It’s not just blame. GitHub uses commits to build the contributor list on your repo home page, so you can make it look like it has some famous contributors: https://github.com/jayphelps/git-blame-someone-else/graphs/c...
Oh man. I was thinking they'd probably patch that but ... how could they?
Re: Git-blame-someone-else
#34Stop using git blame to look up who authored code, it's not a useful tool. Use git log -S to search for changes to that line (then repeat with the previous version of that line, until you find the original author), and/or git log -L to track changes to a code block. Don't waste your time with git blame.
it depends on the code base but I get your sentiment
Re: Git-blame-someone-else
#35Earlier quoted context omitted.
I think it's best to migrate to a preferred formatting slowly, versus touching everything at once. I've had open pull requests that I've started over due to aggressive reformatting like that. Between that and breaking tools like 'git blame', it can be painful.
This approach sometimes works for formatting but the issue with ad-hoc approaches is finding ways of enforcing on new commits. This is especially so with a large developer base. Once you move on from just banal issues like whitespace and move your way up to actual structural concepts in the code, ad-hoc starts completely falling apart (at least in my experience.) I once encountered someone who did a giant re-formatti…
That was our problem. We added a git hook to reject new malformed commits. The easier way to not mess more things was to make all the code base compliant.
Re: Git-blame-someone-else
#36Could be good for resume padding. O yea, I wrote 75% of linux...
I've worked with that dev. After 2 weeks on the job, you realize the resume was full of shit, and are actively looking at ways to replace that dev.
Re: Git-blame-someone-else
#37This has saved me so many times. I’m sure I would have lost my job a while ago had I not been able to use this, it’s one of my most actively use tools. I’m sure eventually I’ll be losing my job, but at least this repo has enabled me to keep it a little bit longer.
I'll be keeping an eye on this account. I feel in a few months JB will be promoted to manager.
Re: Git-blame-someone-else
#38Re: the introductory animation, NASA has .gov adresses, it is not a commercial entity. With that said, sign your commits!
Re: Git-blame-someone-else
#39This has saved me so many times. I’m sure I would have lost my job a while ago had I not been able to use this, it’s one of my most actively use tools. I’m sure eventually I’ll be losing my job, but at least this repo has enabled me to keep it a little bit longer.
I'll be keeping an eye on this account. I feel in a few months JB will be promoted to manager.
Now that’s a straight shooter with upper management written all over him.
Re: Git-blame-someone-else
#40Stop using git blame to look up who authored code, it's not a useful tool. Use git log -S to search for changes to that line (then repeat with the previous version of that line, until you find the original author), and/or git log -L to track changes to a code block. Don't waste your time with git blame.
how is git log -S more efficient? You have to write whole line, what if line is long? What if you need to look at several lines within some range. git blame is much better than your git log -S
git blame can't possibly work well in all cases, which is why the author is saying that.
Git doesn't store what actually was changed. Git stores how to reconstruct the new file from the old file in a space efficient way.
This is unrelated to storage of who changed what, only "what is the minimal way to reproduce the end state from the beginning state".
As a result, tools like blame take the two versions and try to figure out what someone actually changed, trying to turn applesauce back into apples.
Whether it gets it right or not has an element of luck to it (the diff algorithms are also often based on finding the minimal sequence of edits.). Whether it happens depends on the algorithm and it's heuristics, and often whether there is a single unique minimal sequences that could produce your end state from your beginning state (if not, it's not actually possible to say what you changed with 100% accuracy)
git log -S instead is saying "give me all the times this line seems to have changed", and then you do the work of figuring out which were real and which are artifacts of the diff algorithm.