1. clone https://github.com/torvalds/linux into https://github.com/<YOURNAME>/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 (https://github.com/torvalds/linux/commit/<SHA>), with no indication whatsoever that this is coming from a different repo

I have reported this problem to GitHub a while ago and they replied to me that this is a well known feature of 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.

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 else.

(You might argue that determining what refs contain a commit is potentially expensive, perhaps, but GitHub already does this, so I'd argue that it's not that expensive.)

if they did you'd be spot on though

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.

Including the id of the branch (the HEAD).

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

> 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 from that one be effectively covered by that one. So signing each commit is simply missing the point.

http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...

At the very least I don't think it's "totally stupid", even if I know it's not a panacea for all ills.

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.

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: `.

Yeah that was fun.

True, so it is just a joke.

    git filter-branch --env-filter '
    old_email=megatron@example.com
    new_email=redacted
    if [ "$GIT_COMMITTER_EMAIL" = "$old_email" ] ; then
        export GIT_COMMITTER_EMAIL="$new_email"
    fi
    if [ "$GIT_AUTHOR_EMAIL" = "$old_email" ] ; then
        export GIT_AUTHOR_EMAIL="$new_email"
    fi
    ' -- --all

git filter-branch is perfect for this kind of wholesale revision. filter-branch is essential for tasks like: open-sourcing repos that need some kind of cleanup, massaging repos generated by a VCS migration tool, etc. For example, years ago I participated in the move of a large CVS repo to git; there was significant filter-branch post-processing required to create an acceptable baseline)

  git filter-branch --env-filter " \
    export GIT_AUTHOR_NAME=Dade\ Murphy \
           GIT_AUTHOR_EMAIL=zer0cool@example.com \
           GIT_COMMITTER_NAME=Dade\ Murphy \
           GIT_COMMITTER_EMAIL=zer0cool@example.com"

https://stackoverflow.com/questions/750172/how-to-change-the...

I did it as a learning exercise, and if anyone's interested I documented the source in a lot of detail to show everything I learned along the way.[1]

[1] https://github.com/JacobEvelyn/git-self-blame/blob/master/gi...

I'm not sure it's better.

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.

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.

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.

https://github.com/SilasX/git-upstage

(Inspired by the time someone typo'd "unstage" to "upstage" and I guessed what a git-upstage command would be.)

I was disappointed that git didn't have it, so I created myself one. I'm glad git has trivial support for aliases.

[1] https://compbio.soe.ucsc.edu/cvsdoc/cvs-manual/cvs_74.html

Also, as already noted, this overwrites all the history after the commit, making it useless.

Then people said it's a joke...

I know I will get downvoted for this comment, but How did this make to the first page of HN?

Sounds fair.