Commit Log

[JosephTLyons]

The user should have access to the history of commits.

• Each commit in the history view shows the commit message, author(s), and time.
• Clicking a commit would open the diff in a multi buffer, similar to the project diff.
• Allow the commit list to be searched.

Additionally, we want a commit graph. I'm not sure where design will land on this, but it might be implemented directly here, or it could be in its own view. Writing it down here as a future note for us to make a decision on.

Related:

• Implement file history viewing, including local and Git. #16827

[coolemur]

Gitlense has nice UI.

On leftside list of commits on right side diff of selected commit.
Also, would be nice to have a quick way to checkout selected commit from history (for debugging purposes) - double click on commit in history could check out that commit.

[keybits]

Similarly it would be worth taking insipiration form Sublime Merge.

The commits view is very intuitive and powerful.

[WoodyWoodsta]

My biggest ask - and I ask with my whole heart... That if and when Zed implements this that the graph view is beautiful. IMO, nothing beats Gitkraken's graph view for being able to easily visualise branches and where they go.

Some of the things Gitkraken's view gets right:

• Separated information in columns: branches, graph, commit, sha, date
• Column alignment
• Straight branch lines (not weird angled lines)
• Proper and generous horizontal spread of commits belonging to each branch in the graph view
• Similar colours based on proximity of branches from one another

---

It seems like every other source control solution resorts to something that looks like the below, and it significantly reduces the clarity and how quickly you can understand a graph in a more complex project.

[kozel-sd]

So many options for the commit list view... My favorite is how it's made in Git Extensions - it derives branches from branch lines instead of commits, which makes the view cleaner in most cases (at least for me 😃):

(note the line to the selected commit).
Everything else, even the Gitkraken's approach, makes me sad.

Is it a good idea to define an API for obtaining Git log info, drawing primitives into the view box and interacting with it, provide a default implementation, and allow users to replace it? Maybe by adding an entry in Settings with the path to a shared library that implements the desired view 🤔

[jmoore34]

I think it would be perfectly acceptable to start with something basic and then iterate on it later