Logical Reverse Chronological Order: Interpreting Git's Rebase's git log History

This article explores how chronological order and logical order can be used to understand default ordering of git log's history upon a singular git rebase operation.

Table of Contents

1. Chronological Order
2. Logical Order
3. Rebase
4. Interpreting Git Log
5. Git Rebase Merge Commands
6. Conclusion

Chronological Order

Chronological order refers to the order of commits based on their timestamps.

This reflects when the commits are made, regardless of their logical relationships.

For example, say we have the following chronologically ascending commits from top to bottom, earliest/oldest to latest/newest/recent :

A: Jan 1, 1pm
B: Jan 2, 1pm
C: Jan 3, 1pm
X: Jan 3, 2pm
Y: Jan 4, 2pm
D: Jan 4, 3pm

Corresponding chronological graph, left to right:

A - B - C - X - Y - D

Back to Top

Logical Order

Logical order refers to the parent-child relationships between commits in git, regardless of chronological order.

It represents the commit graph, where each commit logically follows its parent, regardless of the timestamp.

In the example, say feature branch was created after commit B and has logical commits C and D (after B), while X and Y follow logically after B on main:

A - B - X - Y
      \
       - C - D

The common, or base, ancestor is B.

Rebase

Upon a git rebase, which here includes the typical merging in a single operation, and not a separate rebase then merge commit (say M), we get this logical order:

A - B - X - Y - C' - D'

The apostrophes for C', D' indicate distinct rebased versions of the commits, with different hashes created during the rebase because their parent commit changed to Y.

Commits C' and D', together in that order, are appended at main's tip, after Y - which is now the new base, regardless of the timestamps that determine the chronological order.

The tip is the "end" of the history, currently with D.

Back to Top

Interpreting Git Log

By default, git log shows logical order in reverse chronological order, or logical reverse chronological order:

D' - C' - Y - X - B - A

Commit D appears at the top.

This means:

• Commits are displayed starting from the chronologically most recent commit from the logical graph
  • This refers to the tip being the starting point, D, which happens to be so since it is chronologically the last/most recent commit
• Timestamps do not determine position (not inconsistent with being chronological, as that's covered above)
  • Once the logical graph is constructed, the order of commits in the log is based on parent-child relationships, not the timestamps. This means commits may appear in a sequence (logical order) that doesn’t align with their actual time of creation.

This default behavior reflects how git manages the commit graph internally.

A side note, I'd say that the git documentation simplifies this too much when it refers to this as "reverse chronological order". Maybe this can lead to some confusion as to how that's consistent with being chronological when it's not timestamps per-se that determine the chronological-ness of the order. 🤔

This would be reverse chronological order in the strict sense, which is not what we see from git log:

D' - Y - X - C' - B - A

Back to Top

Git Rebase Merge Commands

This is the typical sequence for the 'singular' step rebase and merge that doesn't create a separate merge commit.

# Ensure you're on the feature branch
git checkout feature

# make commits on feature (and someone else does so on main)

# Rebase feature branch onto main
# Probably need to pull latest for main
git checkout main
git pull
git checkout feature
git rebase main

# Switch to main branch
git checkout main

# Fast-forward main to include the rebased feature branch
git merge --ff-only feature

# Push the updated main branch to the remote
git push origin main

The key is the git merge --ff-only command, as compared to the --no-ff option for the separate rebase and merge commit.

Back to Top

Key Points to Remember

• git log shows commits in logical reverse chronological order by default.
• Rebase rewrites commit history: Commits from the source branch are applied first, followed by the rebased commits, regardless of their timestamps.
• Timestamps do not influence the logical structure of the commit graph.

Conclusion

Understanding the distinction between logical and chronological order in Git can be useful for interpreting git log, especially after git rebase operations.

The git log commit history primarily reflects the logical structure of the commit graph. After a rebase, commits from the source (e.g., feature) are incorporated at the tip of the destination branch (e.g., main), regardless of their original timestamps.

Timestamps play a secondary role and may not align with the logical order of the commits, particularly after a rebase, where the logical graph takes precedence over chronological order.

By keeping these concepts in mind, you can more effectively navigate and analyze your Git history during development.
Back to Top