#Gitx bug list how to#
#Gitx bug list update#
#Gitx bug list code#
#Gitx bug list mac#

Along with the lack of state saving in the split views, resizing a commit view oddly scrolls the entire view down as you drag. I'm not sure what is 'broken' with the email-style multipane view of commits. Same for the unresizable list of commit messages and the commit view taking over your entire screen, losing any context in the process. GItUp's map is essentially 'mystery meat navigation' in the absence of context - it's really hard to understand why it's designed like this at all.

#Gitx bug list mac#

I had used it when it was new, and just tried using it again - unfortunately like every other Mac Git client I try, I keep on coming back to (ancient, essentially unmaintained) GitX, along with the command line and Emacs’ Magit for some special cases such as interactive rebase. So it’s easy to switch Macs and leave some changes stranded.Īpple File System (APFS) BBEdit Bug Design Git Git Tower GitUp Mac Mac App macOS 10.13 High Sierra Unicode

#Gitx bug list update#

Update (): One annoyance I’ve found is that you cannot see from the Commit view, which is where I live, whether there are changes that you need to push or pull. BBEdit offers two separate commands: the log view shows commit messages but doesn’t directly let you view the previous versions, and the command for comparing with previous versions doesn’t let you view the commit messages. Tower and Xcode want you to navigate to the file first you can’t just drag and drop it from elsewhere. Tower, Xcode, and BBEdit can all do this, though each introduces more friction than I would prefer. The biggest shortcoming of GitUp is that there’s no way to view the history of a particular file. I’m not sure whether this is a GitUp bug, though, because I sometimes see the same thing in Finder since updating to High Sierra. The layout of the panes and the text rendering sometimes get messed up on non-Retina displays. The | true is necessary because otherwise GitUp will complain about the exit status. There’s no built-in support for using BBEdit as a diff tool, but it can use the one from your git configuration, and you can set BBEdit using these commands: git config '/usr/local/bin/bbdiff -wait -resume $LOCAL $REMOTE | true' Pressing D in Quick View opens the external diff tool, but in Map View you have to press I to see the diffs D instead modifies the repository, swapping the current commit with its parent (Move Down). The Quick View unfortunately does not remember the split view state. I don’t think I was even aware of the Quick View until I read the documentation because it’s not mentioned in the menu bar. Unfortunately, the width is not resizable, and sometimes it’s necessary to Tab before you can press the Spacebar to switch to the Quick View that shows the commit details. The “Browse Head Ancestors…” command shows a more traditional list of recent commits so that you can see multiple commit messages at once. You don’t have to browse using the Map View. Will prevent problems like this in the future. Perhaps entering: git config -global core.precomposeUnicode true GitUp ( again) helped me fix the inconsistencies between my repository and working copy, where the git command-line tool and Tower were not showing an accurate view.

Switching to APFS, with its native normalization, confused Git due to some files I had with Unicode names.

#Gitx bug list code#

It helped me find some “missing” code that (I think due to a migration from a previous version control system) was hidden on one of my tags and not visible on the master branch. It also shows which part of each line changed. In particular, the Diff View is much faster to load than Tower’s, and you can easily see diffs for multiple files simultaneously, rather than having to select one after the other or click an Expand All button.

I like that it’s really fast and avoids animations that would get in the way.

#Gitx bug list how to#

The user interface is non-standard-and to me not very self-explanatory-but it is actually very functional once you know how to use it. I’m not sure whether this is due to improvements in the app itself or simply my better understanding from reading the documentation and listening to this podcast. I’ve recently rediscovered GitUp, and I like it much better now than the first time around.