Merge and Rebase

Piazza @724

This is a rewrite of an answer I wrote for Piazza @724. A plain text version is reproduced here (with typos reproduced verbatim).

Unsurprising Predicament

Another day of cs400 submit causing mayhem with its reckless git pull --no-edit, creating ugly commit histories *with* its already heinous commit messages.

Git makes branching cheap, but that does not mean branching is always the good idea -- or even make it the right one, so to speak.

Two strategies for combining diverging histories, labeled old for upstream history and new for local history. On the left, the rebase strategy is employed to replay the new commits on top of the old ones; the combined history is clean and linear. On the left, the merge strategy is employed to create a merge commit, one whose parent points to both HEAD of local history and HEAD of remote history.

Merge

The ugly right half of the diagram above.

The good thing about this strategy is that it preserves the commit metadata, most prominently the commit hash, of both HEADs, new (the submit commit) and old (the NEW#2 commit). The question now is who in the world it preserves the old HEAD for, and the answer is absolutely no one, other than the short life span it existed *exclusively* on the author's local repository.
The commit graph is nonlinear, though one may rightfully argue is necessary due of the distributed nature of Git as a version control system. The catch, again, is that this is not always desirable. Particularly when Git is used to track the development history authored by a single person merging is almost always undesirable.
It is, admittedly, harder to mess up a merge than a rebase. But I say this is just the reluctance to assume adequate responsibility to learn to do things the right way. (In other words, skill issue; it's about time people learn to use git reset --hard ORIG_HEAD and git log --oneline --graph.)

Rebase

The based left half of the diagram above. (Pun intended.)

The bad thing is that commit metadata is rewritten on the side that gets rebased. In the example, this means if the HEAD of the new history NEW#2 were pushed elsewhere, it would not be happy to see that this new history contradicts its knowledge of the old NEW#2 (With Git jargon this is to say that such a push is non-fast-forwardable. pushing this rebased history. This, as I have discussed, is an unrealistic scenario; local development stays local, and there should absolutely be zero harm in discarding something that is *in nature* a work-in-progress.
The commit graph is linear. A boring linked list; but that's what technology *should* be. This point should be self-explanatory.
Rebasing *is* harder. But if you do it right, it can be as simple as git rebase origin/master (or whatever they call the default branch these days). With git-pull(1), it can look like git pull --rebase origin master, which looks like a lot to type, but you'd have to do the same to with --no-ff to merge anyways (if we can all stop ignoring that the devious cs400 init tramples over your user config and forcifully sets pull.rebase to true).

Scope of this discussion

Note that I am not talking about merge/rebase workflow in a *collaborative* environment; that opens a whole wormhole of problems, ones that are oftentimes overwhelmingly social. I only focus on Git when used by one person.