CODEWITHSUNDEEP
github
Laird Nelson
Laird Nelson

Reputation: 16238

If squashing never alters committers, why does Github's squash-and-merge button update the committer?

In the spirit of testing the "there are no dumb questions" theory, why does Github's squash-and-merge strategy update the committer after merging a pull request?

That is, suppose I author a pull request in my fork of a project. Suppose it has two commits in it. Suppose I ask the project maintainer to now merge my pull request to master of the upstream project.

Suppose she chooses the squash-and-merge strategy so that there will be one commit at the end.

Suppose further that the merge can be accomplished via a fast-forward, i.e. as simple as possible a case as I can think of. (Fast-forward merges should just update the branch pointer, which seems to me like it would leave the commit completely unchanged.)

Why is it, then, that the latest commit on master after the squash and merge operation features me as the author (I understand that part) but the maintainer as the committer? Isn't that an alteration of a commit, and doesn't squashing and fast-forward merging ensure that commits are not altered?

Is Github silently doing the equivalent of something like git amend under the covers?

Upvotes: 1

Views: 207

Answers (1)

VonC
VonC

Reputation: 1327174

Isn't that an alteration of a commit

More than an alteration: a creation of a new commit, which reflect the changes of your two commits.
And your two commits are no longer referenced by the main repo: it references only the squashed commit.

That new commit has still you as an author, but is committed by the maintainer.

Upvotes: 1

Related Questions