Commits

You can use Commits to view the commit history of a repository.

Navigate Commits

To open Commits, click Git > Commits.

Commits are listed chronologically. In standard mode, each commit shows:

1. The commit hash, one branch name, one tag name, and +N when there are more names. At the end of the line, HEAD on the checked-out commit, and the bisect state during a bisect.
2. The first line of the commit message.
3. The author, the number of files changed when the list is wide enough, and the commit date, usually shown as a relative time.

The checked-out commit

The commit you have checked out shows HEAD at the end of its first line, and its row has a light blue background. Point to HEAD to see the branch it is on, or that HEAD is detached.

The mark follows HEAD. It moves when you make a commit, switch branches, or check out a commit directly.

During a bisect, the bisect state of a commit is at the end of the line, after HEAD. The bisect color of the row replaces the blue background, and both labels stay. For more information, see Bisect.

Click the Show filters icon to open the filters. Under Branch, click the button and select Current branch to view commits made in the current branch, or All branches to view commits made in all branches in the repository. When the list is not limited to the current branch, a Branch: All branches chip shows above the list.

Commits loads the first 200 commits in the branch or repository. Click Load more to view more commits. When you go to a commit from another place, for example with Show in Commits in Tags, Commits clears the search and filters, and loads more history until it shows that commit.

When a project is shown, Zide reads its first 200 commits in the background, so Commits shows them at once when you open it. Zide then reads the history again and updates the list only if it changed. Your scroll position and selected commit stay. The number of changed files appears on each row shortly after the row, when the panel is wide enough to show it.

In More actions, select Compact Mode under View to show each commit on one line. A check mark shows when it is on.

Click the Graph view icon to show the commit graph. Click it again to show the commits as a list. When a toggle is on, its icon is blue.

The filter and Graph view icons are on the same line as the activity name. More actions also contains Show Filters, and Compact Mode and Graph View under View. In a narrow panel, the Graph view icon disappears first, and these commands stay in More actions.

Branch and tag names

A commit row shows at most one branch name and one tag name. The branch you have checked out is first. When a remote-tracking name, such as origin/main, is on the same commit as its local branch, only the local branch is shown.

Click a commit to open it. The branch and tag names on a commit are labels, so clicking a name in the row also opens the commit.

Right-click a branch name to see its commands:

• Copy Branch Name copies the name.
• Show in Branches opens that branch in Branches.

Right-click a tag name to see its commands:

• Copy Tag Name copies the name.
• Show in Tags opens that tag in Tags.

+N shows how many names do not fit. Point to it to see them. It is a label, so clicking it opens the commit, the same as the rest of the row. The Commit view lists every branch and tag of the commit.

Search commits

To search commits, click the Show filters icon, then type in the Search commits field. Press Ctrl+F to open the filters and move the cursor to the field.

The filter panel holds all the controls that constrain the list. The search field is on the first row. Below it, Search in, Match, Branch, Author, and Date each have a label and a button that shows the value in use. Click a button to change its value. Search in selects where Zide looks for the search text, and Match selects how Zide reads it; see Match the search text and Search changed code.

The line above the list shows the search results and the active filters. Searches include a count of matches. Each filter that is set shows as a chip above the count, for example Search: fix login or Author: Jane Smith. When you browse without a search, the line shows only the chips. With no filters and the current branch selected, the line is hidden. Click a chip to open the filter panel with that control ready: the search text puts the cursor in the field, and the author, the date, and the branch open their pickers. Click the x on a chip to remove that filter.

A search always shows where it looked, because the count depends on it: a Branch chip with the branch name, or All branches. A comparison also names the excluded branch, for example Branch: feature excluding main. The current branch is not a filter, so its chip has no x. When you only browse, the line shows the branch only when it is not the current branch.

When more history is available, click Load more at the end of the list.

During a search, when a chip can be removed, a Clear filters button ends the count line. In a narrow panel it says Clear. When you browse without a search, there is no count line: Clear filters follows the chips when two or more of them can be removed, and a single chip has only its x. It clears the search, the path, the author, and the date, and sets Branch to Current branch. It does not change Search in or Match.

Zide searches the commits that are available on your computer. The search uses your branch selection, your date filters, and your comparison range. Enter part of a commit message, an author name or email address, or at least the first four characters of a commit hash. Results appear in Linear view. Click a commit to open it.

You can find an old commit without loading all of the commits before it.

Match the search text

Match applies to every Search in option:

• Literal text finds the text as you type it. Uppercase and lowercase letters are the same, and characters such as (, ., and * have no special meaning. This is the default.
• All words finds each word of the search text, in any order. Uppercase and lowercase letters are the same. A word can be part of a longer word. In Commit details, each word can match a different part of the commit: ada login finds the commits by Ada that have “login” in the message. In Files: changed lines, all the words must be on the same changed line. Files: text added or removed cannot use All words.
• Regular expression finds text that matches a pattern. Uppercase and lowercase letters must match. To ignore case, start the expression with (?i). In Commit details, the expression is compared with the message, the author name, and the email address, not the hash.

If a regular expression is not correct, the list shows Invalid regular expression and the reason, for example Unclosed group. Correct the expression in the search field to search again.

So far means more history remains to search. Click Load more, at the end of the results, to continue. When the search finishes, the count is the total for your filters.

With All branches, the search includes remote-tracking branches, such as origin/feature, the same as the list.

If Zide cannot tell which branch is current, for example when HEAD is detached, Branch changes to All branches, and the line says so.

A shallow clone has only part of the history. When the repository is a shallow clone, Zide shows a note, because a commit outside the downloaded history cannot appear in the results.

Graph view is not available while a search or an author filter is applied. A graph cannot show the commits that the filter removed. Clear both to use Graph view again.

Search changed code

To find the commits that changed a piece of code, click Show filters, then click the button under Search in:

• Commit details searches commit messages, author names and email addresses, and commit hashes. This is the default.
• Files: changed lines finds the commits that add, remove, or edit a line that contains the text. A moved line is removed in one place and added in another, so it matches. This is like git log -G, but the search text follows Match.
• Files: text added or removed finds the commits where the text appears in a file or disappears from it. Zide counts the matches in the file before and after the commit. An edit that keeps the text, or a line that moves inside the file, does not change the count, so that commit does not match. This is like git log -S, but the search text follows Match.

For example, a commit changes connect("old-server") to connect("new-server"). A search for connect with Files: changed lines finds that commit. With Files: text added or removed, it does not, because connect occurs once before and once after the commit. Use Files: text added or removed to find when the text was first added or when it was deleted.

Files: text added or removed cannot use All words, because separate words have no single count. When one of them is selected, the other is not available, and its line in the list says why.

For the two Files options, a Path field shows below Search in. Type a file or a folder, relative to the repository root, for example src or src/app.js, to search only the changes to it. Leave it empty to search all files. The path can be a file that does not exist now.

The search chip tells which search you used, for example Changed lines: connect with a Path: src chip, or Added or removed: legacyLoad. When Match is not Literal text, the chip says so, for example Search (all words): fix login. Branch, Author, and Date also apply to a code search.

Each result shows the files that matched, below the author. When more than three files matched, a +N label follows; point to it to see the other names. Zide lists up to 20 matching files for a commit. When more matched, the label says or more, for example +17 or more. Click a file name to open the diff of that file in that commit. Click a different part of the row to open the commit. The commit shows all of its changed files, not only the files that matched. Compact rows do not show the files.

Zide compares each commit with its first parent:

• Zide does not search merge commits. It finds the commits that made the change on each branch.
• Zide compares a renamed file with its earlier version, so a rename without other changes does not match. The path applies before Zide finds renames.
• Files: changed lines does not search binary files. Files: text added or removed searches them.
• Zide does not search files larger than 4 MB or very large commits. When this occurs, a note shows above the results: Some very large or binary changes were not searched.
• Regular expressions use the syntax of the Rust regex library. Look-around and backreferences are not available.

A code search is slower than a commit details search. Each part of the search compares up to 2,000 commits. If more history remains, the end of the list shows how far back the search went, for example Searched back to Jan 21, 2024. Click Load more to continue.

To stop a code search, click Stop at the end of the list. The results that Zide found stay. Click Load more to continue from the point where it stopped, also when it found no results yet. If Zide stopped before it compared a commit, there is no point to continue from: click Search again to start again.

Partial and shallow clones

A partial clone, for example one made with --filter=blob:none, does not have all file versions on your computer. Zide downloads the file versions that the search compares, and the end of the list shows Downloading file versions…. Zide downloads only file versions, not more history. If the download fails, the list shows the reason and Retry. If Git is not installed or you must sign in, Zide opens that dialog.

Zide cannot search the code of a clone that leaves out folders, for example one made with --filter=tree:0. The list tells you so.

In a shallow clone, Zide does not search the oldest commit of the clone, because its parent is not on your computer. Zide does not download more history.

Filter by author

To show the commits of one author, click Show filters, then click the button under Author. It shows All authors until you select one. Type in the Search authors field to find an author. Zide searches the authors in the available history, in your current branch, date, and comparison scope. An author does not have to be in the commits that are shown.

Zide shows the name and the email address of each author. Two authors can have the same name. If the names are the same, use the email address to select the correct author.

Click an author to filter the list. The button under Author and an Author chip above the list show the author. To select a different author, click the button again and click another entry. Click All authors, or the x on the chip, to remove the filter.

You can also click an author name in a commit row. Click the same author again to clear the filter.

A result must match the search text and the selected author. When you clear one, the other stays.

Filter by date

To show only the commits of a period, click Show filters, then click the button under Date. It shows Any date until you set a date. Set the After date, the Before date, or both, then click Apply. Click Clear to remove the dates.

When a date is set, you can also click its Date chip above the list. Click the x on the chip to remove the dates.

The date applies to the search as well as to the list, so a search finds only the matching commits of that period.

Clear a search

To remove one filter, click the x on its chip. To clear all of the filters at once, click Clear filters at the end of the count line, or after the chips when you browse without a search.

To clear only the search, click the Clear search icon in the Search commits field, or press Escape in the field. After you clear the search and the author filter, Zide shows the commit list again, at the same position. If the branch selection, the date filters, or the comparison range changed while you searched, Zide loads the list again instead.

Commit actions

Right-click a commit to open its actions. They include Create Branch from Here…, Create Tag Here…, Show in Reflog, Export Patch…, Export Patches from Here…, Amend This Commit…, Create Fixup Commit…, Revert This Commit…, Cherry-Pick This Commit…, Reset to This Commit…, Interactive Rebase from Here…, Checkout (detached HEAD)…, and the Bisect submenu.

These commit actions are also available from More actions in the Commit view. To compare two commits, select Mark for Comparison on the first, then Compare with hash… on the second. You can use either the Commits list or a Commit view for each step within the same Project Tab and repository. Opening the comparison clears the mark.

To cherry-pick several commits, select them first: hold Ctrl (Cmd on macOS) and click each one, or click its checkbox. To select a range, click the first commit and hold Shift while you click the last one. Right-click a selected commit and click Cherry-Pick Selected Commits…. This command is in the Commits list only. See Cherry-Pick Commits.

You can amend only the most recent commit. While a merge, rebase, cherry-pick, revert, or patch series is in progress, you cannot create a branch, amend, revert, cherry-pick, or reset from this menu. While a bisect is in progress, you cannot amend, revert, cherry-pick, reset, or check out from this menu. For bisect instructions, see Find the commit that introduced a bug. For more information about each action, see Commit view. To reorder, combine, or reword commits, see Interactive Rebase. To create a branch, see Create a branch from a commit, tag, or reflog entry.

Before a revert or cherry-pick starts, Zide checks whether the operation could overwrite your changes. If Zide blocks the operation, see A merge, revert, or cherry-pick did not start.

Reset to This Commit… opens the Reset to Commit dialog. Select Mixed, Soft, or Hard, then click Reset. If you select Hard and have uncommitted changes, Zide opens Confirm Hard Reset. Type the confirmation text shown in the dialog and click Hard Reset.

Mode	Effect
Mixed	Keeps your files and resets the index to the selected commit, leaving nothing staged.
Soft	Keeps your files and index. Staged changes are relative to the selected commit; unstaged edits stay unstaged.
Hard	Restores tracked files to the selected commit and discards staged and unstaged changes. Untracked files are kept unless they obstruct restoring tracked files.

The hard reset warning counts tracked files with uncommitted changes and untracked files that the selected commit would overwrite. If Zide cannot read your uncommitted changes, Hard is disabled. Close and reopen the dialog to retry.

Export and apply patches

A patch series is a set of commits saved as mail files by git format-patch. Another person can apply the series to their own repository with Git, and the commits keep their authors and messages.

Export patches

1. In Commits, right-click a commit.
2. Click Export Patch… to export only that commit, or Export Patches from Here… to export that commit and every later commit through the checked-out commit.
3. Check the commits in the dialog. They are listed oldest first.
4. Click Browse… and choose a folder, then click Export.

Git writes one .patch file for each commit. If a file with the same name is already in the folder, Zide asks before it replaces the file. Export Patch… is not available for a merge commit, and a range that contains a merge commit cannot be exported. You cannot export into the repository’s .git folder.

Apply a patch series

1. Click Git > Apply Patch Series….
2. Choose the patch files. You can choose several .patch files, or one mailbox file that holds the whole series. The patches are listed in file name order, or in the order of their [PATCH n/m] numbers.
3. Review the series in the dialog, then click Apply.

To add patches from another folder, click Add Files…. New patches go after the ones already in the list. A file that is already in the list is not added again.

Git adds one commit to the checked-out branch for each patch, with the patch’s author, date, and message. Your hooks and signing settings apply. If a patch does not apply cleanly, Git stops and the patch series shows in the Project Header. Resolve the conflicts, then click Continue. For more information, see Project Tabs.

The dialog has two tabs:

• Patches lists the patches in the order Git applies them, with the subject, author, number of files, and the date in the patch. To change the order, drag a patch by the grip at the left of its row, or click Move up or Move down. Click Remove from list to leave a patch out. With the keyboard, select a patch and press Alt+Up or Alt+Down to move it, or Delete to remove it. A patch usually depends on the patches before it, so check Files Changed after you change the order.
• Files Changed lists every file the whole series changes. Click the list button for repository paths, or the tree button for the files and their folders. Zide remembers your choice. Type in Filter files to show only the files whose paths contain the text.

In tree view, click a folder or press Enter or Space on a focused folder to collapse or expand it. Folders stay open while a filter is active so matching files remain visible.

The status and line counts on each file are the net change: the difference between the checked-out commit and the result of all the patches. A renamed file is one row with its new path; select it to see its former path. Counts of zero are not shown, so a renamed file with no other changes shows only its status. A binary file shows Binary instead of line counts. A file that the series changes and then changes back shows No net change.

Select a file to see which patches change it. Changed by lists each patch with that patch’s own changes to the file. These counts are not added together, because two patches that change the same lines do not change the file by the sum of their counts. Click a patch to show it on the Patches tab.

If a patch does not apply cleanly to the checked-out commit, the net change is not available. The dialog says which patch, and each file shows how many patches change it. Select a file to see which patches they are.

Apply is not available until the repository is ready:

• Check out a branch. The patches cannot be applied to a detached HEAD.
• Commit or unstage any staged changes.
• Commit or stash uncommitted changes in files that the patches change.
• Finish or abort any merge, rebase, or other operation in progress.

Open Staging closes the dialog and shows your changes in Staging. If you fix the problem in another way, for example in a terminal, click Check Again to check the repository again.

If the repository changes after the dialog checked it, Apply does not start, and a message says that the repository changed. Click Review Updated State in the message to check the patches again, then click Apply.

A cover letter from git format-patch has no changes. It stays in the list with Cover letter, not applied, and Git does not apply it. Any other patch without changes stops Apply until you remove it from the list. Zide does not apply a plain diff, or a patch that changes files in the .git folder.

Find the commit that introduced a bug

Bisect finds the first commit that has a bug. You select one commit that has the bug and one older commit that does not. Git checks out commits between them, and you test each one.

Select the commits

1. Right-click an older commit that does not have the bug. Click Bisect, then Select Good Commit.
2. Zide uses the commit you have checked out as the bad commit. To use a different one, right-click that commit, then click Bisect and Select Bad Commit. Zide keeps one commit of each kind until you start, so choosing another one takes the role from the first. Point to the item to see which commit gives it up.

While a bisect or a selection is live, every Commit tab shows a bisect bar under its header. The bar says what that commit is to the search, from This is the commit under test. to Outside the search range., and carries the actions for that commit: Mark as Good, Mark as Bad, and Skip on the commit under test, Show Commit Under Test on the others, and Select or Replace while you are choosing the commits. While Git holds the bisect, the bar also says that amend, revert, cherry-pick, reset, and checkout are unavailable. Start, Cancel, Abort, and Finish stay on the bisect control in the Project Header. With no bisect and nothing selected, bisect is in the Bisect submenu of More actions, as Revert and Reset are.

Selecting the first commit opens the Bisect tab. Return to Commits to choose or replace either end of the search. In Commits, a state label at the end of each row identifies the Good and Bad commits. A colored line at the left shows the search range. Commits outside the range have no line, and their messages are dimmed. A Commit tab shows the same state in its BISECT banner. The Branch or Worktree control in the Project Header becomes the bisect control. It shows Bisect: Setup until both commits pass validation, then Bisect: Ready.

You can select the commits in either order. A bisect searches in one direction, so the good commit must be in the bad commit’s history. The menu disables a role that this direction does not allow:

• A commit that no later commit comes after cannot be the good commit. The last commit on your only branch is an example.
• After you select one commit, the other role is disabled on a commit that would invert the pair.

If the commit you have checked out cannot be the bad commit, the control asks you to select one.

You do not have to select both commits. The one you leave out is selected for you: the commit you have checked out becomes the bad commit, and the most recent tag in its history, or a commit further back, becomes the good commit. The control names both commits, and you can replace either one before you start.

Check the good commit before you start. A bisect trusts it, so if the bug also exists there, the search ends on the wrong commit and reports no error.

To clear the selection, click the bisect control, then Cancel Bisect. The commits are not affected: nothing is checked out and the branch does not change. Zide also clears the selection when you close Zide.

Start and test

Save your files before you start.

1. Click Start in the bisect control. Git checks out a commit to test. The control shows its hash.
2. Test the version that Git checked out.
3. Click Good if the bug does not exist, or Bad if it exists. To skip a commit that you cannot test, click the bisect control, then click Skip.
4. Repeat steps 2 and 3 until the control shows a result.

If a checkout could overwrite your changes, Zide shows Cannot Bisect. See A merge, revert, or cherry-pick did not start.

Click the bisect control to see the commit under test and, when available, the estimated number of tests remaining. Under Commit under test, the menu holds the commit and what you can do to it: Mark as Good, Mark as Bad, Skip, and Show in Commits. Show Bisect and Abort Bisect… follow. To see the good and bad commits the search has reached, look at the colored line in Commits or open the Bisect tab.

Click Show Bisect to open the Bisect tab, which holds the range, every decision as a commit with its verdict, and the result with what it means. Zide brings it forward when you start a bisect and again when the search finds an answer.

In Commits, each marked row names its state: Good, Bad, Skipped, Testing, First Bad, or Possible First Bad. The state label and row color show its part in the search. Commit hashes keep their usual graph colors.

The line at the left of each row shows the search. It is green where the bisect has settled that the bug does not exist, red where it has settled that the bug exists, and blue for the commits that could still be the first bad one. As you test, the green and red ends grow toward each other. A dimmed message means Git will not test that commit, either because it is outside the range or because the search has passed it.

The bisect control and a Commit tab use the same icons. You can also mark the commit under test from its Bisect submenu.

If the next test commit is not checked out, the control shows Bisect: Blocked. Resolve any checkout problem, then click Retry Checkout.

Finish the bisect

When Git finds the first bad commit, the control shows Bisect: Found. Click the control, then the commit hash to open its details. Click Finish Bisect to return to the starting branch or commit. The search markers disappear from Commits, and the result stays in the Bisect tab. Click Close inside that tab to discard the result and close the view.

If skipped commits prevent a single result, the control shows Bisect: Inconclusive. Its menu lists up to 50 possible first bad commits and shows how many more are not listed. Commits flags each commit in the list. Click Finish Bisect to return to the starting branch or commit.

To end an unfinished bisect, click the bisect control, then click Abort Bisect…. Click Abort Bisect in the confirmation dialog. Zide returns to the starting branch or commit and discards the bisect decisions.

A bisect that you start in a terminal also shows in Zide. If it has no good or bad commit yet, select the missing commits from the Bisect submenu. You can continue an unfinished bisect after you restart Zide. Each worktree has its own bisect.

Assist with This

Right-click a commit and point to Assist with This. In the Commit view, you can also right-click the content header or an ordinary background area, or click More actions.

Under Zide Assist, click Add to Conversation to attach the commit to a Zide Assist tab. You can also drag the commit into a Zide Assist tab. For more information, see Attach items to a message.

Under Ask Zide, click Open Ask Zide. Zide opens the commit in the Commit view with an Ask Zide panel beside it. In the panel, click Summarize Changes or Review Commit. See Ask Zide beside a tab.