8 ms·
Git-blame-someone-else – Blame someone else for your bad code
- LinuxBender 11y agoThis is a good example of why git repos should be snapshot and archived to read-only media periodically. I like this! Thank you
- detaro 11y agoIt does a rebase, so everybody that has a copy and pulls will notice.
- LinuxBender 11y agoGood point. Would code review tools catch this? Gerrit, Crucible, et al? More specifically, how obvious would it be and would people question what they see?
- detaro 11y agoTools will probably show that you are trying to merge/push all commits since (and including) the changed one, unless they have something special to detect rebases and display them differently.
- wink 11y agoThis probably could be done using git filter-branch as well. Not rewriting history, I still have this little script called fakecommit[0] lying around I have used in the past to commit stuff under other people's names. [0]: https://github.com/winks/dotfiles/blob/cfd9d994d0bcd7510203a7e2e6be7260b0d699aa/bin/fakecommit https://github.com/winks/dotfiles/blob/cfd9d994d0bcd7510203a...
- andrewstuart2 11y agoAnd this is why I pgp sign all my commits. :-P
- exDM69 11y agoIt's a bit worrying that GitHub will happily associate someone's face on a commit that they didn't write: https://github.com/jayphelps/git-blame-someone-else/commit/e5cfe4bb2190a2ae406d5f0b8f49c32ac0f01cd7 https://github.com/jayphelps/git-blame-someone-else/commit/e... Perhaps GitHub should only do this for signed commits or commits to the author's own repository or something. GitHub also allows you to add anyone to a project without their consent (or has this changed?). This reminds me of the Facebook prank where someone added Mark Zuckerberg to a fake(?) pro-paedophile group.
- andrewstuart2 11y agoAgreed. It should be trivial for them to allow you to paste your pgp public key as you would your ssh public key, then place a nice little "verified" check mark next to commits that can be validated as having been signed with one of your associated private keys.
- mbrock 11y agoThere are so many things that GitHub could easily do, but don't... Makes me wonder what they actually do.
- tinco 11y agoYou mean besides developing and operating one of the best services on the web?
- baku-fr 11y agoWell maintaining software and infrastructure is one thing. But they also seem to lack features compared to the competition. They might want to quickly sort their management issues out and be more agressive feature-wise.
- swsieber 11y agoBest as in market share, but certainly not best by it's own merits. (ie there is better git management software)
- lambda 11y agoShould really use "git filter-branch", not "git rebase -i", for automated history modifications. "git rebase -i" is good for interactive usage, not scripting.
- deleted 11y ago[deleted]
- cevaris 11y agoHey Bob, what is up with the `git push --force master`?
- LinuxBender 11y agoThis was also being discussed here [1] [1] https://news.ycombinator.com/item?id=11049993 https://news.ycombinator.com/item?id=11049993 Apparently it will be obvious to folks that this has occurred.
- manojlds 11y agoUm, mostly no. This can be trivially detected only when you are changing things already pushed. Being a dvcs, you create atleast one commit on your local repo before pushing to a remote. That one (or more) commit can be changed to point at anyone and pushed.
- asabjorn 11y agoMostly yes. You rewrite the whole history from the commit you changed authors on and onwards so git will let you know that you have two conflicting histories that needs to be merged. This is why the author needs to force push to master. The only exception to this is if someone else has not pulled into their private repo any changes at or before the commit you changed.
- manojlds 11y agoWhat I am saying is that this tool can be used exclusively while creating commits. Not for retroactive changes.
- dang 11y agoWe moved the comments here from a later thread that hijacked "Show HN" (https://news.ycombinator.com/item?id=11053078 https://news.ycombinator.com/item?id=11053078). We also rolled back the clock on the current thread so it would go to the same position on the front page. It's still not really a fair swap because the other post has most of the points, but people will probably keep upvoting this one.
- shurcooL 11y ago(When I saw the title, I was wondering if this does something beyond the basic rebase, like trying to brute force a commit such that all following commits are preserved (hash doesn't change), but that's essentially impossible.) I'm tempted to make the observation that there's nothing here you can't already do with a git rebase -i and: GIT_COMMITTER_NAME=a GIT_COMMITTER_EMAIL=a@a.com GIT_COMMITTER_DATE=2006-01-02T15:04:05Z git commit --author='a <a@a.com>' --date 2006-01-02T15:04:05Z But I realize this ability will be novel/surprising to some people, and this is meant to be a joke. I don't do this not because I can't, but because I have no incentive to lie about who wrote/committed certain code.
- infinity0 11y ago> all following commits are preserved (hash doesn't change), but that's essentially impossible. Actually, you only need one brute-force (of the commit that you're changing); subsequent commits only refer to the parent hash, and here we're not changing the commit trees either. SHA1 is already considered broken, so git really should switch to SHA256 soon. This whole "sha1 commit hashes are not for security" argument is mostly naive and bogus. The only way it would be safe, is if (a) everyone set their GPG to default to SHA256 or above (older versions still default to SHA1) and (b) either (b.1) everyone signed every commit this way, or (b.2) everyone signed their tags this way and just before tagging, reviewed their local commits including commits not authored by them up to the previously trusted tag. But if git defaulted to SHA256 or SHA512, then we wouldn't have to reason through the complex scenarios involving (b). Making something "too secure" is a good thing if it simplifies your security analysis and allows you to use your head for other productive things.
- 32bitkid 11y agoHell, I can do _all_ my work as somebody else with "git config user.name" and "git config user.email". If that's really a genuine concern, then a) you are working with a big bag of dicks and b) there are _way_ worse things that person can do with write access to the repository than masquerade as somebody else.
- newday 11y agoAs stated in the project read me, it's just a joke project.
- 32bitkid 11y agoNo, I get it, but even in this thread there is a higher-than-expected amount of hand-wringing.
- logicallee 11y agoI totally agree with 32bitkid's view of the other comments, makes a good point.
- SilasX 11y agoShould probably use this moment to plug my (opposite) project, git-upstage, which lets you claim credit for someone else's work and backdate it so it looks like you did it first: https://github.com/SilasX/git-upstage https://github.com/SilasX/git-upstage
- 0x4a42 11y agoMuch better. Love the hacker's twist. :)
- mjklin 11y ago$ git push SEP-field
- _jomo 11y agoPreviously on HN: https://news.ycombinator.com/item?id=10005577 https://news.ycombinator.com/item?id=10005577
- andrewray 11y agoIt's been my experience, especially in the startup scene where business requirements change often, that `git blame` rarely shows you what you want. Files get renamed, moved, re-indented, etc, frequently. I wrote a tutorial on a more effective (at least for me) solution to find the true author of a change: http://blog.andrewray.me/a-better-git-blame/ http://blog.andrewray.me/a-better-git-blame/
- chx 11y agoI found http://1dan.org/git-blameall/ http://1dan.org/git-blameall/ an incredibly useful tool for similar (not identical) purposes.
- versteegen 11y agoNice tutorial, but aren't you aware that "git blame -w" ignores whitespace changes? git blame also always follows renames. git's rename detection isn't foolproof (if I edit and rename A.cpp to A-star.cpp at the same time as adding a new A.cpp file it won't detect it), however there are two more blame options for that: -C to follow lines copied between files, and -M to follow lines moved within a file. Unfortunately, adding -M and -C will quite badly increases the time to compute the blame. Both take an adjustable parameter (min number of characters to match), but I found I actually had to reduce it to catch all the lines in an example of the A.cpp -> A-star.cpp move I did yesterday.
- sadgit 11y agoI would love to be able to use left and right to skip quickly through revisions when viewing a blame, do you know anything for that?
- versteegen 11y agoThat's something I've wanted for a long time too. tig (a curses-based git interface) fits the bill, though it can be quite confusing (too many keybindings). "tig blame -w <file>" to view a blame (-w to ignore whitespace), and then you can press , on a line to recompute the blame using the parent of that commit, while moving to the ancestor of that line (but tracking the line frequently doesn't work). And < to go back to the previous commit. I remember that tortoisesvn was fairly nice for viewing blames, IIRC you can move through history inside it with some clicking around, and the tortoisegit interface appears to be largely the same: https://tortoisegit.org/docs/tortoisegit/tgit-dug-blame.html https://tortoisegit.org/docs/tortoisegit/tgit-dug-blame.html Windows only however.
- jayphelps 11y agoHere's the tweet: https://twitter.com/_jayphelps/status/695782397439139840 https://twitter.com/_jayphelps/status/695782397439139840
- gcb0 11y agowhat's the point? you just rebased with a incompatible tree. nobody will be able to update that because their trees will say the commit differs. and in the only case this would work, i.e. nobody has that commit yet, you could just have commited as that person. nothing new or interesting. now, github being garbage and not accounting for PGP signatures, now this is something else.