4

I'm puzzled to see a merge commit in the git log by my colleague Alice, and Bob assures me that it was indeed him who did the merge. I see no other merge commit by Bob, so it looks as if Alice somehow managed to take over Bob's commit.

Alice did indeed also commit something, but her commit activity came likely after Bob's. Alice is using git exclusively through Visual Studio's git ui.

I know that locally commits can be rewritten through rebase operations, but it's my understanding that this isn't normally done for commits that are already pushed. I would assume that a graphical git ui doesn't do anything out of the ordinary.

So why do I see Alice as the author and committer in the git log? What could possibly have happened to cause this?

EDIT: Other commits have sensible authors, so this isn't simply the wrong username being configured.

John
  • 6,693
  • 3
  • 51
  • 90
  • Well the thing is, a merge commit consists of two parents, Bob and Alice. So, without having any other information, I might expect to see one, or both, of these authors in the merge commit. – Tim Biegeleisen May 29 '19 at 14:20
  • @TimBiegeleisen But the merge itself should have a commit author also. Why should that not be the one who created the merge commit? (I don't think merge commits *consist* of parents, they *have* parents, which are different commits.) – John May 29 '19 at 14:21
  • I don't know the logic which Git is using internally to decide which author to display, but [here](https://stackoverflow.com/questions/9447371/override-author-on-git-merge) is a reference for how to change the author name. – Tim Biegeleisen May 29 '19 at 14:23
  • Did you set git config --global? – Avijit Majhi May 29 '19 at 14:36
  • @AvijitMajhi Yes and other commits have the correct authors in both Bob's and Alice's case. – John May 29 '19 at 14:47
  • try `git blame -w file.cpp` assuming that problem was caused by white characters. – Marek R May 29 '19 at 14:51
  • Also I've noticed that some UIs are confusing [committer and author](https://stackoverflow.com/a/18754896/1387438). – Marek R May 29 '19 at 14:56
  • 1
    First: I would double-check that Bob performed a "true merge" and not - by accident - a fast-forward merge. If that is followed by a true merge from Alice everyone talks about "that merge" not about the same thing. Other possibility: Alice did something like `git commit --amend --reset-author`. – A.H. May 30 '19 at 09:08

1 Answers1

1

Every commit object carries both fields, author and committer. You can inspect the raw commit object using the command-line git cat-file -p operation. For instance:

$ git cat-file -p 83232e38648b51abbcbdb56c94632b6906cc85a6 | sed 's/@/ /'
tree 894962f72d565687c409f018060fdefa20e5f3fe
parent aa8c8d914e4ae709e4fd025f359594f62653d9e5
author Junio C Hamano <gitster pobox.com> 1556175832 +0900
committer Junio C Hamano <gitster pobox.com> 1556178085 +0900

The seventh batch

Signed-off-by: Junio C Hamano <gitster pobox.com>

Once a commit is made, it cannot be changed: the hash ID of the commit, in this case 83232e38648b51abbcbdb56c94632b6906cc85a6, is a cryptographic checksum of the contents of the commit. If I took this text, changed the names, and made a new commit from the result, I'd get a different commit hash ID.

Now, I could do that, and having done that, I could then copy all the immediate downstream commits—all the children of 83232e38648b51abbcbdb56c94632b6906cc85a6—to new and different commits that have my new commit as their parent(s). Then I'd have to copy those commits' children, and their children's children, and so on, all in an effort to make you believe that my copy of 83232e38648b51abbcbdb56c94632b6906cc85a6 is the copy you should use. If there are any signed commits, or signed annotated tags, in this copied chain, I'd be unable to sign them properly unless I had Junio Hamano's signing key. So you might be able to tell that I did this—and even if there aren't any signing keys, you'd probably still be able to tell, because the Git repository I offered to you, with these copied replacements, would not match the copy you'd picked up earlier, with the originals in it.

So, the fact that the merge has Alice's name on it—assuming your GUI is not lying to you—means that the merge has Alice's name on it. That doesn't mean that Alice actually made it, as Bob could have set his Git up to claim to be Alice for the duration of Bob making the merge. If you want to verify who made the commit, you'll need some kind of digital signature as well, either on the commits, or on annotated tags. (Signing each commit is a big pain, which is why the Git developers only sign their annotated tags.)

Why and how this happened is not something we can guess. It's up to you whether to believe Bob when he says that he did not do it as a prank. You'll have to observe it actually happening and investigate from there.

torek
  • 448,244
  • 59
  • 642
  • 775
  • "Every commit object carries both fields" - what fields? – Matt Arnold Apr 28 '21 at 08:37
  • 1
    @MattArnold: "author and committer": it's a reply to this sentence fragment in the original post, *So why do I see Alice as the author and committer in the git log?* – torek Apr 28 '21 at 09:00