Problem description

It's common for a large repo to have many branches created by different people. They are often named without any strict convention, so it's hard to remember the required branch name. When I'm checking out a branch, the only way to find the right branch for me now is to look through the whole branch list. If this list was ordered by most recent commits, that could save a lot of time.

Preferred solution

Order the branch list by most recent commit.

Problem description
I don't know about others but in my case very often I have to quickly pull from a remote branch from the list and switch to it. Other clients often ask me if I want to create a local branch of the same name when I double-click on the branch from the remote branches list. Sublime Merge also has double-click for switching between local branches, but no action is specified for when you double-click on a remote branch.

Preferred solution

Display a confirmation modal asking if I want to create a local branch of the same name when I double-click on a branch from remote list

Here's an example of what Sourcetree shows when I double-click on a remote branch from list:

Problem description

In the commit list, there is a dummy commit (see the screenshot below). I've seen other git GUI clients do this as well, but personally I think it's a bit misleading since really you're at the real commit just before it.

Also, I feel like this could be ever-so-slightly related to #8 in some way.

BTW: I'm really liking Sublime Merge so far. I've always been a little disappointed with the git plugins for Sublime Text, so this is a nice surprise!

Preferred solution

It would be great if there was a setting to disable this "phantom" commit from the commit list when there's no changes on your current branch.

Alternatives

Not sure of any alternatives, but I'm open to discussion on this.

Screenshots

Problem description
Sublime Merge doesn't show when tags commits or merges are signed. This is particularly useful to check for unwanted/unauthorized commits.

Preferred solution
Something like github's approach of a verified icon:

https://blog.github.com/2016-04-05-gpg-signature-verification/

Also maybe a filter for verified and unverified tags commits or merges?

Problem description

If a checked out branch is quite old or at least 20 or 30 commits behind the HEAD, it is most likely impossible to see both the "Commit Changes" menu item with the stats of the current changes in the working directory and the branch head commit.

It is easily possible to scroll between them by pressing ctrl+0 and ctrl+1, but

1. as SM is more likely being used via mouse in many situations
2. in order to keep a bird's eye on the working directory stages
3. and visualize the association between the checked out commit and the working changes more clearly

...

Preferred solution

... the "Commit Changes" item in the commit history should be sticky until a user scrolls below the checked out branch.

Screenshots

The screenshot should illustrate how the "Commit Changes" keeps visible while scrolling as long as the checked out branch/commit doesn't move out of the top of the list.

Problem description

I have many branches with the same base commit.
The commit graph takes up a lot of horizontal space, as each branch is indented one level more than the last.

The commandline graph stacks the branches above each other. It does not take up much horizontal space as each branch is only indented one level.

Preferred solution

Could a more compact commit graph be drawn in the commandline style?

Screenshots

The same commits In the Commandline and Sublime Merge:

Problem description

There is no difference how to resize window (maximize it or just pull by window side with cursor) - the result is always the same - too slow and laggy resize

OS: MacOS Mohave 10.14 (18A391)
MacBook Pro 2016 15"
Sublime Merge build 1065

Preferred solution

Smooth window resize

Problem description

I really like the Merge Resolution view and behavior (with it's 3/4 solution of swapping merged with base) and would like to use it even with files that aren't in the git repo and/or being merged. As the product has Merge in the name and can do diffs and merge resolution, I would have expected the option to take 3 arbitrary files and open a 3(+) way merge on them. EG I have a file in a current repo; I want to specify another file that is the common base and a third file that will be the staged changes and these are all separate.

In some cases I have a repo that has some files where a base version is not in the history at all and I have another change I'd like to merge in, from the other repo that does have the base in the history and some changes not reflected in this repo. I would like to select the three related files that I have on the file system (probably not all checked into the same repo) and view their diverged differences for manual merging.

Preferred solution

This may not be simple because you're likely relying on git's diff based storage, but like: Merge[Tool] filename.ext filename.base.ext filename.remote.ext filename.ext
Where those are the backup, base, remote and local. I'd be using the same backup and local as in this case I want to make the result saved as a staged change to the local file in the repo. The base is something not tracked that was a specific older version perhaps older than the history of my repo, and the remote is some updates I want to bring in from an outside change to this base file, but I'm expecting, even without conflicts, that I have to manually review everything.

I would normally think the simplest way for me to do it is to check out from somewhere the base version and copy the file to filename.base.ext, check out the changes from elsewhere I want to bring in and copy them to filename.new.ext then open a 3-way merge with filename.ext filename.base.ext and filename.new.ext, or as shown in the prior paragraph. Because, to be honest, the alternative – committing the base in a branch, updating that with a commit of the existing version and then changing that to the new version to view it – provides me only one 2 way diff at a time. Without a forced merge conflict, I'm not going to see how both versions differ from the base and how to merge their intents together as clearly.

Alternatives

The current work around is to do:

• git checkout -b base
• cp file.base.ext file.ext
• git commit
• git checkout -b orig
• git checkout -b new
• cp file.new.ext file.ext
• git commit
• git checkout orig
• git revert HEAD
• git commit
• sublime-merge merge new

Now you can finally open a merge resolutions view for each conflicted file, assuming there are conflicts. If there aren't you're out of luck, which may not have been the result you actually wanted to review.

This process could be automated with generated temporary files if need be…

Screenshots

None available.

Problem description

I use conditional includes to separate my personal projects from work for my employer. Because of this, my .gitconfig doesn't directly contain a [user] section; it's included dynamically based on the folder I'm working in:

In .gitconfig

[includeIf "gitdir:Work/"]
    path = .gitconfig-work
[includeIf "gitdir:Personal/"]
    path = .gitconfig-personal

.gitconfig-work

[user]
    name = Mark Bell
    email = [MY WORK EMAIL]

.gitconfig-personal

[user]
    name = Mark Bell
    email = [MY PERSONAL EMAIL]

However, this results in Sublime Merge asking me to enter my name and email address when I commit to any repository, presumably because it can't find them in .gitconfig and isn't parsing the conditionals.

As a result, I can't currently use SM at all, unless I re-specify my credentials for every repository I work on and persist them to the settings for the individual working copy.

Preferred solution

Sublime Merge should be able to figure out that the current repository is using conditionally included user info. I realise mine is a fairly niche use case, but it would be great to get support for this, as it is an established Git feature.

Problem description

Many Git GUI clients offer dedicated shortcut key bindings for most often used Push/Pull operations, but currently in Sublime Merge the fastest way you can do this now is to press Cmd+P, type push, hit Enter then press Enter again.

Preferred solution

It'd be great if there was an option to bind dedicated key combination to trigger Fetch/Push/Pull immediately. Personally I think Cmd+Shift+F (Fetch), Cmd+Shift+P (Push), Cmd+Shift+L (Pull) are keys that are easy to remember. (I'm coming from Sourcetree)

Alternatives

I noticed others in the forums have suggested keys like Cmd+ArrowUp, Cmd+ArrowDown for Push/Pull respectively.

Additionally, it would be great if there was some sort of way to easily access User Key binding preferences through app itself. Sublime Text provides an option like that but currently the configurable items in user preferences is very very limited in Sublime Merge.

Problem description

Currently you can only see how many commits a branch is ahead/behind of its tracking branch if you check it out and look at the branch name box in the middle of the toolbar.

Preferred solution

Display the number of commits each local branch is ahead/behind of its tracking branch in the Location Bar sidebar.

Alternatives

Several ways this could be displayed; see attached screenshot for how Fork does it as an example of prior art (mac OS app).

Screenshots

Version info

• OS: macOS 10.14
• Build: 1066

Description

The "Open in Editor" command from the context menu when clicking on a file at a particular revision (e.g. when browsing the file tree) opens that file at the current work space version. This has two problems:

• if the file doesn't exist anymore, nothing happens, without feedback
• right clicking on the file at commit X, and selecting "Open in Editor" from that context, suggests it will open that file at commit X.

Additionally, being able to open a file from a previous commit would be a very welcome and powerful feature.

Steps to reproduce

Steps to reproduce the behavior:

1. Open repository ...
2. Select a previous commit
3. Right-click on a file diff in the right pane

Expected behavior

Open the file at that specific revision

Screenshots

Version info

• OS: Windows 10, Ubuntu 16.04
• Build: Dev 1064, 1062

Description

Navigating a diff hunk that is larger than the visible screen space with keyboard keys (arrows, PageUp/Down, Home/End) does not keep the cursor in view. The cursor merely disappears off the screen. Navigating with Tab across hunks does scroll as expected.

Steps to reproduce

Steps to reproduce the behaviour:

1. Open repository and select any commit that has a large diff hunk.
2. Click inside the hunk.
3. Move the cursor down line by line until it goes past the end of the screen.

Expected behaviour

The viewport of the diff hunk (or of the whole screen) should scroll to keep the cursor in view in order to provide a more complete keyboard-only interface.

Problem description

Currently when resolving a merge conflict I have to do the following:

1. Click Resolve for a file
2. Resolve conflicts in the file
3. Click Save
4. Click Stage
5. Click Resolve for the next file

The last three steps are extra button clicking for little reason (particularly since I can review the diff of the file in the merge pane).

Preferred solution

Ideally, when clicking Save in a merge conflict, I would like it to save my conflict resolution, stage the file, and automatically open the merge pane for the next conflicted file.

Alternatives

If the "one step at a time" workflow is important for some people, this could be opt-in either through a preference, "options" dropdown (e.g. similar to the one used for pull/push buttons in the toolbar), make a separate button for "Save and resolve next", or I'm sure there are other creative ways to approach the UX that would allow flexibility while still reducing the number of unnecessary steps for most uses.

Version info

• OS: macOS 10.13.6
• Build: 1062

Description

The default sidebar ("Location Bar") size is far too small for me (branch names tend to be prefixed with shared things like "feature", making it difficult to tell them apart in the default sidebar width). I resize the sidebar for my open windows when I launch the app, but if I quit and relaunch the sidebars revert to their original width.

Steps to reproduce

Steps to reproduce the behavior:

1. Open a repo window
2. Open the Location Bar, if necessary
3. Resize the Location Bar wider by clicking and dragging where it meets the rest of the window
4. Quit Sublime Merge
5. Launch Sublime Merge; note that the window reopens at the same size and position, but the Location Bar is using the default width

Expected behavior

The sidebar should remember its width between launches.

Problem description

The commit message area and the staged files area are closely related concepts, they go together (IMO) in the stage->commit workflow. But, SublimeMerge keeps the working directory list in between.

Preferred solution

A setting that makes SM show the staged files list before the working directory file list.

Alternatives

I considered having a dedicated window to craft the commit message with an easy way of review the staging area while typing, but it felt a bit against the "Sublime way" of doing using interfaces (almost no modal windows), and I guess having a separate view (not a window) it would be too much work.

Screenshots

This is the original view. I have highlighted the pertinent areas: in red, the ones relevant for crafting a commit message; and in blue, the current working directory:

This is the proposal (with said setting enabled). Now the UI relevant to write a commit message is all grouped together:

There isn't a dedicated "view" for the staging area in SublimeMerge, and that's fine! Now, while I'm mostly comfortable with the Git command line interface, the main reason I like "porcelain" interfaces for Git is to be able to "prepare" a commit, that is, I pick the files/hunks I want to commit, stage them, then write a good commit message for what I'm about to commit. Problem is, sometimes I don't stage everything, so in those cases I now have, the commit text area, a listing of workdir files that I'm currently not interested in, and then the staged files listing, the ones I'm interested in. Sometimes re-reading what's staged allows me to write more useful/detail commit messages, that's why it would be really helpful (well, in my case) to have them all grouped together.

Arguably, I could "fix" this by having a tidier repo (like not having a dirty working copy) because if every change is staged, then the working directory list would be empty, but I wonder if that's always the case with everyone...

Sorry for the long text!

I help to find bugs and improve software with one condition only: it should be free software. Let it has some ad and annoying alerts but the general features such as theming MUST be available. I just will not use it with light theme. I sure you would have much more profit if SM would have the same payments/donation system as ST had and has now.

Summarizing, I forced to say I will wait until you change your decision about it.

Excuse my impudence and good luck. )

Problem description

The "Edit - Copy" (and Cut / Paste as well) menu item (on macOS) is currently enabled (but doesn't seem to do anything) when a commit is selected.

Preferred solution

It would be nice, if this copied the commit hash of the selected commit to the clipboard, as that is often used by other git-related tools (e.g. command-line client).

Alternatives

Just disable the menu-items / short-cut when no text field is active.

Screenshots

Problem description

A common option in most diff tools is the ability to hide/ignore space related difference.

Preferred solution

It would be good to have this in the preference option, but also the ability to toggle it on a file by file basis.
Also it would be great in the list of file modified in a commit if we could have an indicator that changes are space only (similar to the one for renaming).

Alternatives

An extra option that would clearly put sublime merge on top of any other diff tool is the same concept but apply to comments, since SublimeMerge support syntax highlighting:

• ability to hide any change inside a comment
• quick toggle mode
• indicator in the list of modified files.

And other diff display option would include:

• control how many "context" line are displayed for each diff (unomidifed line before and after a change)
• Option to show whole file
• Hide only trailing space/empty
• Quick navigation between changes

Screenshots

Here is an ugly mockup using icons bar from GitExtension diff:

Problem description

Not exist a possibility of collapsing these areas.

Preferred solution

Version info

• OS: Linux (4.18.8, Arch current)
• Build: 1060

Description

When editing a commit message, with gpg signing enable, the edited commit is not signed.

Steps to reproduce

Steps to reproduce the behavior:

1. Enable GPG signing in your gitconfig
2. Create a repository, create a file in the repository, commit it
3. git log --show-signature to verify commit was signed
4. Edit the commit message (right-click commit in Sublime Merge, Edit Commit -> Edit Commit Message)
5. git log --show-signature and see an unsigned commit

Expected behavior

I would expect editing the message to behave identically to git commit --amend -m "new message", which does re-sign the commit.

Problem description

One of the features I miss from Git Tower is that it automatically ran git fetch at intervals. This ensured that my tags, remote branches, and so forth were up to date, and reduced the likelihood of me wasting time trying to commit stuff to a branch that has changed upstream.

Preferred solution

I would love if Sublime Merge periodically fetched repos for open windows, without needing me to explicitly initiate a fetch.

Alternatives

There are a lot of ways to approach this. At a low level, there could be a mechanism for automatically running commands when a window is opened or focused (maybe with a minimum amount of time since the last time the command automatically ran, in case users are swapping between windows regularly). There could be a mechanism for automatically running commands on a strict time interval. Either mechanism could be specific to fetching, and controlled via preferences. Etc.

Basically, all I care about as a user is that my sidebar stays up to date without needing me to babysit it, and the software isn't constantly pinging the server with fetch requests. :-)

SM 1063

The keyword commit: and the hash itself should be highlighted to give user feedback about correct spelling.

Example Sublime Merge Search.sublime-syntax

%YAML 1.2
---
scope: source.sublime-merge.search
contexts:
  main:
    - match: '"'
      scope: punctuation.definition.string.begin.search
      push: double_quoted_string

    - match: '\b(and|or|not)\b'
      scope: keyword.operator.logical.search

    - match: '\b(author:|path:|file:|line:|from:|min-parents:|max-parents:|commit:)'
      scope: keyword.search

    - match: '\b-?[0-9]+\b'
      scope: constant.numeric.integer.search

    - match: '\b[a-f0-9]{2,21}\b'
      scope: constant.numeric.hex.search

    - match: '\('
      scope: punctuation.section.brackets.begin.search
    - match: '\)'
      scope: punctuation.section.brackets.end.search

  double_quoted_string:
    - meta_scope: string.quoted.double.search
    - match: '\\.'
      scope: constant.character.escape.search
    - match: '"'
      scope: punctuation.definition.string.end.search
      pop: true

Version info

• OS: Mac
• Build: 1064

Description

When the built-in upgrader is used to update Sublime Merge, the Sublime Merge.app that results does not have a valid signature. This appears to be because the non-executable files in the app do not have the proper extended attributes set on them to utilize the _CodeSignature/ folder.

This doesn't have the effect of making the application unusable since the quarantine extended attribute is no longer present.

This is likely a result of the copy that happens before the diff is applied by the up executable.

Originally reported at https://forum.sublimetext.com/t/invalid-code-signature-after-self-update-on-macos/39387.

Steps to reproduce

Steps to reproduce the behavior:

1. Update Sublime Merge to a newer version

Expected behavior

The .app should continue to have a valid signature after the upgrade.

Problem description

Not a big deal and super low priority, but maybe you could adjust the way renames are coloured.

Just moved a file from a folder "Setup" to "Namespaced".
The 'e' and 'p' characters are not coloured. I understand why it diffs like that.

Preferred solution

• Maybe colour the full folder name if a file is moved to a new folder, but partially colour if a folder is renamed.

Alternatives

• Maybe split by path separator and apply colour to the full folder if more than 50% of the characters change and it is not all prefixed or suffixed.

Screenshots

There are probably plenty of complications, but just wanted to notify you when I saw this:

Problem description

Clicking a commit shows the files changed by the commit, but there is no way to tell if a file is newly added vs modified.

Preferred solution

Any indication to tell apart, New, Moved, Modified, Deleted, Moved & Modified.

Problem description

The hazard buttons are a very good alternative for modal dialogs asking for dangerous actions to be really performed. While "Abort merge", "Stage All" and others follow this functionality the "Discard All" button shows a modal dialog asking for the files to be deleted or not.

Is there any certain reason to not make it a normal hazard button?

Preferred solution

The "Discard All" button in the commit dialog should work like the other hazard buttons. Clicking once turns it into red while clicking a second time performs the action.

Version info

• OS: Win7 x64
• Build: 1062

Description

If files are using LF as the line ending on Windows, they are forced converted to use CRLF after resolving conflicts. This makes the whole file different.

Steps to reproduce

Example repo: reproduce.zip

Steps to reproduce the behavior:

1. Open repository
2. Merge branch mom into branch master.
3. Resolve the conflict and then merge.
4. The file line ending is changed from LF to CRLF.

Expected behavior

File line endings should not be changed.

Screenshots

Problem description

When I am working on a feature branch, sometimes I get a little carried away and begin working on something that needs to be isolated from the rest of the pack, but only realize it too late. Right now stashing just stashes the entire set of unstaged or indexed files.

Preferred solution

An ability to selectively stash hunks or whole files to be applied to another branch later.

Alternatives

Ability to break out individual files into a new branch.

Version info

• OS: macOS 10.13.6
• Build: 1065

Description

Unable to authenticate for github.com in Sublime Merge with GitHub Two-factor authentication.

Steps to reproduce

Steps to reproduce the behavior:

1. Enable GitHub Two-factor authentication (my authenticator application is 1Password)
2. Clone a new repository
3. An "Authentication Required" popup opens asking for authentication for github.com with "Username" and "Password" input boxes
4. Enter GitHub username and password

Expected behavior

As GitHub Two-factor authentication is enabled, a second popup should be asking for an authentication code (second authentication factor). As a comparison, I am providing screenshots showing the authentication flow from GitHub Desktop and Sublime Merge.

GitHub Desktop

Sublime Merge

Problem description

Sublime Merge should display ref lists using a nested folder representation. This is a common feature in most git clients and lots of users leverage it to keep large lists of refs organized.

Git itself has semi-formal support for "path-like" ref names using / as a path separator. If you have a "foo/bar" branch git will prevent you from creating a "foo" branch, since "foo" can't be both a ref and a "directory" of other refs.

Preferred solution

• Lists of ref names should be displayed using a nested folder representation.
• This would include at least the sidebar lists:
  • Branches
  • Remote Branches
  • Tags
• For example, if there are four ref names: foo/bar/alpha, foo/bar/beta, foo/gamma, and buzz/lightyear they should be displayed like:
  • foo
    • bar
      • alpha
      • beta
    • gamma
  • buzz
    • lightyear
• In this example the foo, bar, and buzz rows should have disclosure triangles that can be expanded or collapsed.

Alternatives

Using search to filter the list of branches might be considered an alternative to hierarchical organization of refs. I feel that both are highly valuable for different use cases and neither approach is 100% sufficient.

Screenshots

Branch list in SourceTree:

Branch list in Git Tower:

Problem description

The current SM displays image diff as binary contents.
It would be good even if it simply shows the before/after images.
Here's Github's example: https://git.io/fApgi

Preferred solution

The basic 2-up mode is enough I guess.

Screenshots

Problem description

Regularly you get to merge file with space conflict (trailing spaces removed, tab/space conversion) and most of the time, the "correct" file is always the same.

Preferred solution

Add a button to solve all space conflict using a given file.

Alternatives

In the same idea, give the possibility to fix all remaining conflict using one file or the other: sometimes you know that contribution from one files can be totally ignored.

A nice UX improvement would be to get an indicator of the number of remaining conflict and how many are space related, both in before and during the merge.

Version info

• OS: Windows 10
• Build: 1065

Description

If you have submodules at detached heads they show up as unstaged files. This happens even if there are no changes locally in the submodule (see the screenshots below).

Steps to reproduce

1. Have one or more submodules in detached HEAD states in a repo
2. Open Sublime Merge for that repo
3. Notice the submodules are marked as unstaged changes
4. Make a change in one of the submodules
5. Notice (in Sublime Merge) those changes do not show up (<< this could be a separate issue)

Expected behavior

If there are no changes to the submodule, and the submodule is in a detached HEAD state, it shouldn't necessarily show up as unstaged changes. I would expect there might be some indication that the submodules are in detached HEAD states, but not as unstaged changes, especially when there were no changes. Also, I'd expect there to be some indication of modified files in a submodule if there were changes.

Screenshots

No changes in submodules, just detached HEAD states

This shows the status of the repo: $ git status

This shows the corresponding view in Sublime Merge

With changes in submodules and detached HEAD states

This shows the status of the repo: $ git status

This shows the corresponding view in Sublime Merge - note the first submodule is the one with changes

Problem description

In some situations it is helpful to be able to pick only parts of an existing commit to be applied to another branch, maybe as hotfix, maybe to split a commit which was judged too sophisticated at some point. SM supports cherry-picking the whole commit only at the moment.

Preferred solution

The command should work like staging files. Means select single folders, files, hunks or lines to cherry pick.

The hunk header of a committed file currently just shows the "hunk history" button. Maybe the hunk header could be turned into a toolbar containing things like

• Cherry-Pick Hunk
• etc.

Selecting single lines within the hunk should then change the buttons to

• Cherry-Pick Lines
• etc.

The commands should be able to be bound to user defined keys as well.

Feature suggestion

Current version lacks built-in support for GitFlow branching model commands.

Preferred solution

Add support for GitFlow commands to the GUI. SourceTree's approach to this feature is nice and could provide a good reference.

Other
Love the early version, can't wait to see what will become of it.

Problem description

There is no diff/merge tool with proper syntax highlighting like SublimeMerge, but it can only works in a git environment. There is a lot of non-git cases where diff/merge is required
The name SublimeMerge put emphasis on Merge not Git, so allow the tools to be used in situation where there is no git repository.

Preferred solution

Support a simple command-line option like : "smerge base mine others".
This would make it easy to call SublimeMerge from other revision control tools.

Alternatives

And an even greater upgrade would be to allow diff/merge directly on two directories,

Version info

• OS: Windows 10
• Build: 1062

Description

When pre-commit hook fails, the commit message is discarded and the commit message box is empty.

Steps to reproduce

Steps to reproduce the behavior:

1. Open any repository
2. Ensure that pre-commit hook fails(e.g. by returning 1)
3. Stage files and write a commit message
4. Click on commit

Expected behavior

Commit message remains in the commit message box.

Version info

• OS: Windows 7 64-bit
• Build: 1062

Description

When attempting to open a worktree (which has a .git file with "gitdir: " syntax), Sublime Merge complains that it "doesn't look like a git repository."

Steps to reproduce

Steps to reproduce the behavior:

1. Create a bare repository, and then create a worktree based on that bare repository.
2. Open Sublime Merge and attempt to open the worktree.
   The error will appear.

Expected behavior

I expect Sublime Merge to open the repository and operate on it as if the directory referenced by "gitdir:" is the real .git directory and the worktree directory is the working copy location.

Bitbucket, as well as other hosting services I’m sure, sends a response text on git push that includes the url for making a pull request. If I do git push in iTerm2 it parses the link and I can cmd+click it to make a PR. It’d be awesome if Sublime Merge did the same on messages received so when I pull up the server response I can just click the link. Bonus points for some even nicer ui

Version info

• OS: Windows 10
• Build: 1062

Description

As the title already says, the clean_working_dir alias git clean -f removes all untracked files located in the top-level of the working directory. If a file is located in any sub directory it remains there.

Steps to reproduce

Steps to reproduce the behavior:

1. Open a repository
2. Add a dummy file in a new sub directory newsub/subsub/foo.json
3. Run "Delete All Untracked Files..." from command palette

Expected behavior

No more unchanged files should remain in the working directory.

Looks like git clean -d -f is required to do that.

Problem description

For some repos, I am the only developer.
In this case, I don't need to see the author, and I don't really care about the time of commits.
Just the modified file count and commit message on the left, and branch names on the right would be great.

Preferred solution

Option to hide the second line, Author and Time from the commit graph and reduce the vertical space.

Screenshots

One commit per line, similar to gitx:

Problem description

If a bug was found being introduced by a commit, it might be useful to be able to revert the causing file, hunk or even just a single line of code. This can be required as a temporary solution until a better fix is available or to remove a regression. It would at least help complete all functions like (stage/stash/revert/...) supporting all kinds of operation in the same way.

Preferred solution

The command should work like staging files. Means select single folders, files, hunks or lines to revert.

The hunk header of a committed file currently just shows the "hunk history" button. Maybe the hunk header could be turned into a toolbar containing things like

• Revert Hunk
• etc.

Selecting single lines within the hunk should then change the buttons to

• Revert Lines
• etc.

The commands should be able to be bound to user defined keys as well.

Such a toolbar could make use of glyphs/icons instead of text to keep the button size as compact as possible. A description of the action can be displayed as tooltip if the button is hovered. The buttons might be hidden in the same way as the current "hunk history" button.

Problem description

I recently purchased Sublime Merge. It works really well, but one feature that would be very useful to me is to checkout a previous version of a folder or single file into the working directory.

Preferred solution

Some method of selecting a specific folder or file and checkout into the working directory. The git command would be something like this

git checkout COMMIT -- foo.txt

Problem description

git reflog provides valuable information about the repository's history and provides an important means to recover from mistakes or see how the repository got to its current state. It would be of great benefit to have this information presented in a manner that clearly identifies checkouts, vs merges, vs pulls, etc. and provides the ability to act on them or to drill into details.

Preferred solution

Executing the command (either via command palette or a direct link in the sidebar at the level of BRANCHES, REMOTES, etc) would list the reflog history similar to how commits are listed when selecting a branch. Selecting an entry in the reflog would show the changeset details in the right-most pane. Context menus on the reflog entries would show any commands that are appropriate and available.

Alternatives

It is currently possible to add a custom command to the palette whose output is visible by clicking the icon in the left of the info bar. This output is plaintext which makes it more difficult to parse visually and is not interactive at all.

Screenshots

Here is an example of how this feature is presented in Tower:

(source: https://www.git-tower.com/help/mac/commit-history/reflog)

Problem description

A common activity I do is exploring what commits are in a particular branch. Be it the currently checked out branch, an arbitrary branch or tag.

I'm on a large team who makes a lot of remote branches including many experimental ones that never get pulled into master. Having everything in the mix makes it extremely difficult to see what commits are in what branch.

Preferred solution

If there was a way to limit the commit branch view. I'm imagining a set of "always on top" options at the top of the commit view.

Options to convey how the list view will be filtered:

• Checked out branch
• Branch
• Tag

Whatever makes sense really, but at least the currently checked out branch.

Screenshots

Version info

• OS: Mac OS X 10.13.6
• Build: 1058

Description

In the conflict resolution view (3/4 way merge) you can easily leave the view without saving anything.
Also after saving you can easily undo what you did by re-entering it clicking on resolve RIGHT BESIDE stage.

Steps to reproduce

Steps to reproduce the behavior:

1. Click resolve to open a 3 way view, start making changes.
2. Try to find some text or a reference in the file, press command-F
3. Anything you do here will not only not find text, but also exit you back to the in-progress merge view, but without any of the changes made so far.

Expected behavior

Would have liked an incremental search. Command-F should work. / is a kludge if you must, but it's not there at all so…

Another fun thing is to press Command-P. That list comes out of nowhere with no anchor like it would have in the previous window state.

Version info

• OS: Windows 10
• Build: 1062

Description

When the window size is not wide enough to display the submodule changes the horizontal scrollbar is always visible and with no transparency effect contrary to a standard file where it is only appears on mouse hover and even in this case there is some transaparency effect to let the text readable

Steps to reproduce

• Open a repository with sub-modules
• Click on a commit where submodule version is changed
• resize window to make the horizontal scrollbar appears.

Expected behavior

The scroollbar should behave the same as for a standard file: auto-hide and transparency effect

Screenshots

Version info

• OS: macOS 10.13.6
• Build: 1062

Description

Git specifies the core.excludesFile setting, with the following description from the git-config manpage:

Specifies the pathname to the file that contains patterns to describe paths that are not meant to be tracked, in addition to .gitignore (per-directory) and .git/info/exclude. Defaults to $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/ignore is used instead. See gitignore(5).

However, it appears that Sublime Merge is looking for a different path, or ignoring this altogether. Considering that many development environments include compiled files inside the repo, this can mean that Sublime Merge is effectively unusable for even simple repos (e.g. python produces pyc files, mypy creates a large .mypy_cache folder in the repo root, C object files, etc).

Steps to reproduce

Steps to reproduce the behavior:

1. Open repository ...
2. Have a global exclude file with patterns to exclude files
3. See unstaged files that should be ignored by the global excludes

Expected behavior

The global excludes file should be used for also ignoring files to be staged.

Problem description

When committing it's hard to glance which files have been staged. This is true especially when you have a decent number of changes and you are trying to split it off into smaller commits.

Preferred solution

I would love if Sublime Merge provided a view similar to the following found in products such as Sourcetree:

Benefits:

• easy to view which files are staged or not
• view is compact
• allows to stage particular lines hence file shows up in two places: staged and unstaged
• allows intuitive keyboard navigation to move between files, and familiar select all files via cmd+a feature as well