[arghwhat]

All but the first commit has parents. All commits point to the state of the file tree at that point.

A "merge commit" is nothing more than a commit claiming any number of parents greater than one. It is still its own file tree reference that decides how the tree looks, and nothing dictates that it should be related to the parents.

[tsimionescu]

If that were true, then git log -p would have worked. The reality is that merge commits are treated differently from other commits by many parts of git. Saying that they are "just a commit with multiple parents" gives people the wrong impression.

Git is more than the data structure backing it. And many parts of git make all sorts of assumptions that treat things that are more or less identical in the data model as actually being different. Tags are not the same thing as branches, for example, even though they are stored in virtually the same way.

[arghwhat]

Well, yes - git log does have special handling of commits with multiple parents because everything it shows is a special cased lie. Why? Because commits do not contain diffs or patches, but are instead full snapshots of the repository as a whole at a point in time.

git log -p is a convenience tool that tries to show code progression, and so it comes up with these simple diffs. Showing a graph of N-way conflict resolutions would not help the user trying to get an overview. Other tools exist to track the origin of a particular change, such as git blame.

It is important to understand what a git commit actually is exactly because of the caveats of such convenience interpretations. Otherwise you'd have no idea where a conflict resolution is stored, and you'll run into the surprises mentioned here.

In my opinion, git also becomes a lot easier to work with once you understand the low-level details, as you realize which high-level tools are similar, compatible, or fit or unfit for a a specific purpose.

[tsimionescu]

What git log shows is not "a lie", it is a part of its data model. Git is all of its commands, not just the low level details. Commits are both snapshots of the entire repo, and diffs, and delta compressions - none of these is "a lie".

[arghwhat]

> Commits are both snapshots of the entire repo, and diffs, and delta compressions - none of these is "a lie".

Commits are never diffs. Commits are snapshots, and sometimes git computes a diff between two commits. Commits are also never delta compressions, but can be stored within a delta-compressed packfile.

Whether you like it or not, git is primarily its low level details. The porcelain stacked on top changes, and differs depending on the user's client (e.g., a GUI using libgit2). However, that "git log -p" is "part of git" that git log -p is not trying to convince you that commits are diffs and show you a true chronicle. It instead assumes that you know what commits are, and that you are asking for an easy to read overview of what has been going on.

Accepting that commits are always solely snapshots will make the issues you run into when working with the porcelain easier to understand, especially when exposed to more than one client.

(Knowing about packfiles and delta compression can also be useful when looking into performance/resource utilization.)

[arghwhat]

*However, that "git log -p" is "part of git" does not change that git log -p is...

[kccqzy]

You are right that conceptually this is okay. But it is a UI problem that commands the author tried didn't manage to show the difference between the merge commit against any of its parents.

[robin_reala]

Technically you can have multiple first-commits in a Git repository. For example, Linux had 4 initial commits in 2017: https://www.destroyallsoftware.com/blog/2017/the-biggest-and...

[arghwhat]

Indeed, through commits with multiple parents (merges), you can end up having multiple orphan commits (initial commits).

Multiple initial commits are a bit rarer, usually stemming from merging in entirely different git repos with their own separate history as part of consolidation.