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

Git Blame-Someone-Else

github.com

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Git Blame-Someone-Else

#61

Post by hinkley »

inlined wrote: post #31
Znafon wrote: post #8

Earlier quoted context omitted.

You would already get a conflict as the history of the repo changed and signing all commits as some drawbacks as Torvalds explained here: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t... I'm not sure it's better.

I think Torvald’s stance is reasonable when considering a customer’s safety as guaranteed by an organization. E.g. this build is signed as safe. Commit signatures are useful in large organizations designed to worry about insider threats. If code that is reckless or malicious is found in a build, you want repudiation of the author. Lack of commit signatures allows a malicious actor to cover their tracks. And also, we…

How would merges work there?

I've had a coworker, "Tom", who was terrible with three way merges (why is it the people awful at merges want to do the most merges by insisting on feature branches for their code?)

I'm still not sure what he was doing but some of his merges ended up with the wrong name next to code. We started figuring this out about him when "George" was getting dressed down for a bug he introduced.

Two things drew me into this. First, I was getting tired of things being blamed on George. Everybody in this group had issues, nobody should have been pointing fingers at anybody else, especially this guy or his partner in crime, Tom. But equally important to me at that moment was that I was the primary on that code review, so now it's on me too.

A lot of code I look at becomes a bit of a blur, but I remembered this block of code particularly well, because it was the sort of tricky code that George sometimes cocks up but bless him if he didn't get it right on the first try. Only the code we were upset about wasn't the code I reviewed. His name was on it. The commit sequence lined up. What the hell.

An excruciatingly long git bisect later (git bisect is not built for some things, this included) and I track it down to a bad three way merge by Tom. He ended up with some bastardized version of left and right that had its own set of bugs, and George's name on the commit. I hadn't known you could do that with Git. It was quite upsetting.

Re: Git Blame-Someone-Else

#62

Post by jimktrains2 »

gus_massa wrote: post #55
mh8h wrote: post #47

Earlier quoted context omitted.

That's because you are not supposed to rebase other people's code on top of a changed base. That can effectively modify the behaviour of their code change. So it's good that the resulting commit won't be signed anymore. And if you are rebasing your own code, then you can sign it again.

What about cherrypicking bug fixes to old versions?

Cherry picking creates a new commit.

Re: Git Blame-Someone-Else

#64

Post by tomcatfish »

hinkley wrote: post #61
inlined wrote: post #31

Earlier quoted context omitted.

I think Torvald’s stance is reasonable when considering a customer’s safety as guaranteed by an organization. E.g. this build is signed as safe. Commit signatures are useful in large organizations designed to worry about insider threats. If code that is reckless or malicious is found in a build, you want repudiation of the author. Lack of commit signatures allows a malicious actor to cover their tracks. And also, we…

How would merges work there? I've had a coworker, "Tom", who was terrible with three way merges (why is it the people awful at merges want to do the most merges by insisting on feature branches for their code?) I'm still not sure what he was doing but some of his merges ended up with the wrong name next to code. We started figuring this out about him when "George" was getting dressed down for a bug he introduced. Two…

Do you have any more information of any kind on this (like info you have run into since then)? This sounds very interesting and it also sounds like something I should be aware is possible to do (especially on accident).

Re: Git Blame-Someone-Else

#65

Post by gus_massa »

jimktrains2 wrote: post #62
gus_massa wrote: post #55

Earlier quoted context omitted.

What about cherrypicking bug fixes to old versions?

Cherry picking creates a new commit.

The cherry picked comment usually has the same author and date that the original commit. (Note that rebasing also creates a new commit.)

One of the latest commits backported to Linux 4.9.something https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

Cherrypicked from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

Note that the changes are identical, just add ` &&ret` twice, but the line numbers have changed. Also, the cherrypicked version has an additional `Signed-off-by: `.

Re: Git Blame-Someone-Else

#66

Post by emmelaich »

tsm wrote: post #32
emmelaich wrote: post #28

Earlier quoted context omitted.

A branch is just a series of commits; if any one of the commits has a different hash (as this hack will do) then the commit and all following commits will have a different hash. Including the id of the branch (the HEAD).

It's simpler than that: a branch is just a pointer to one specific commit (with a specific SHA)

True, but it's both.

Just as a link in a linked list is often the list and the node in the list.

Re: Git Blame-Someone-Else

#67

Post by Aperocky »

jimktrains2 wrote: post #17
warpech wrote: post #10

What is more, you can: 1. clone https://github.com/torvalds/linux into /linux" rel="nofollow">https://github.com/ /linux . 2. push a fake "torvalds" commit into your repo. 3. check the SHA of the the commit that you made. 4. the commit will be visible at the original repo URL with your SHA ( " rel="nofollow">https://github.com/torvalds/linux/commit/ ), with no indication whatsoever that this is coming from a differen…

I've never really understood Torvalds' reason for not cryptographiclly signing commits. > Btw, there's a final reason, and probably the really real one. Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less. It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need _one_ signature to make all the commits reachable…

Oh, I've had that at one of the place I used to work at. The git commit tree is signed, and once a team member left no one can create branches any more because all of his commits are now insecure.

Yeah that was fun.

Re: Git Blame-Someone-Else

#68

Post by brantonb »

eljimmy wrote: post #33

I really dislike the term chosen for this feature. “Blame”, assumes the code is broken or written improperly in some way. Most of the time I use it I’m just trying to find out who wrote it so I can find the original commit to understand it in more context. Should have named it “git who”

Xcode 10 changed their per-line annotation feature from Blame to Authors.

Re: Git Blame-Someone-Else

#69

Post by y4mi »

orf wrote: post #48
SilasX wrote: post #45

Earlier quoted context omitted.

GP isn't saying GitHub should copy the entire repo, only that there should be some indication that the code you're looking at isn't the repo owner's (despite being committed in their name and on a repo they "control"). I don't see what optimization requires that. They already keep track of e.g. me pushing up someone else's commit after a rebase -- it indicates that I pushed but the commit originally came from someone…

> I don't see what optimization requires that. From a single commit ID you cannot tell which repo it came from. A "repo" is just a tree of commits.

github doesnt use plain bare repositories for their repo hosting, so they can do whatever they deem useful :)

if they did you'd be spot on though

Post reply on HN