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

31–40 of 69 posts

Re: Git Blame-Someone-Else

#31

Post by inlined »

Znafon wrote: post #8
mohsen0 wrote: post #3

And that is why signing commits should be enforced.

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 should accept that we don’t treat all authors with the same scrutiny. Veterans’ code gets scrutinized less, so let’s actually trust that they’re the real author before signing a tag with their code.

Re: Git Blame-Someone-Else

#32

Post by tsm »

emmelaich wrote: post #28
argd678 wrote: post #27

Earlier quoted context omitted.

How do they know which branch in my fork is mine vs upstream? Or in the case where I modify a forked branch?

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)

Re: Git Blame-Someone-Else

#33

Post by eljimmy »

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”

Re: Git Blame-Someone-Else

#34

Post by panda88888 »

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”

Or “git credit”

Re: Git Blame-Someone-Else

#35

Post by [deleted] »

panda88888 wrote: post #34
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”

Or “git credit”

[deleted]

Re: Git Blame-Someone-Else

#36

Post by gus_massa »

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…

Cryptographically signing the commits makes rebasing impossible (or at least more difficult).

In some cases the rebase is very clean, and none of the modified files had changed by other commits. I guess in this case, git can have a rule to keep a "link" to the old commit and accept the old signature as a signature of the new commit.

In some cases there are trivial changes, like indentation because someone else added an `if` around the code you are modifying. Sometimes part of the problem has been fixed. Sometimes one of the functions you use has an additional parameter. Sometimes the code has been moved to another file. In this cases it is difficult to automatically detect if the new rebased commit is equal enough to the old commit to accept the new signature.

We can go into the big rebase/merge debate. Linus is in the rebase camp.

Re: Git Blame-Someone-Else

#37

Post by thwarted »

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”

You can always use "git annotate" or alias git commands in your gitconfig.

Re: Git Blame-Someone-Else

#38

Post by Znafon »

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…

This makes sense,all organizations are different and it is true that all changes to the kernel tree are publicly ACK-ed before geetting committed.

Maybe we could make a note of the public key that pushed each commit to the repo so we get the best of both ways, each commit is associated to a user from it's public key, not just the Author field and tags are signed by GPG.

Re: Git Blame-Someone-Else

#39

Post by ajross »

argd678 wrote: post #27
smitop wrote: post #22

Earlier quoted context omitted.

> the repo "network" This is actually an optimization done by GitHub. It would take up a lot of space if GitHub copied the entire repo every time someone forked it, so they keep all the commits in the original repo. As a side effect, commits in forks are accessible from the original repo since commits from both repos are stored in the same place.

How do they know which branch in my fork is mine vs upstream? Or in the case where I modify a forked branch?

It's sort of the reverse: they can't know, from a bare commit ID, what repo it "belongs" to without searching backward from every tag or branch in the repo. (Even that question is malformed: repos have histories and may have contained commits in the past that are no longer ancestors of existing branches or tags).

So they just fake it: they look in their database to find any commit with that SHA and put it up. And that database happens (for obvious performance reasons) to be shared between a repo and its forks.

Post reply on HN