SourceTree for Mac 1.9 – Out Now!

By on April 29, 2014

We’re very happy to announce that the next major update to SourceTree for Mac is now available. This release focuses on improved visual design in areas such as the file status and diff views, and a much improved, more streamlined commit experience.


New Commit Experience

We’ve streamlined the commit experience so that it is no longer a separate sheet, but instead it’s built right in to the file status view:

Stage files with checkboxes

You can mark whole files for inclusion in the next commit (stage them in git terms) by checking the boxes in the file list:

[Edit] You can also use the spacebar to toggle the checkboxes for the current selection if you want to stage / unstage many files at once.

If you’re new to SourceTree, our default mode for git is simply for you to check the files you want to commit, which is more approachable to people who don’t understand staging yet. However as soon as you use one of the staging functions, SourceTree will switch to showing the staged and unstaged areas as above, which is what most more advanced Git users will want to see. You can switch back and forth between the simple and advanced modes on the context menu:

Quick access to common file operations

While you can still use the right-click context menu on files to access the full gamut of operations, we’ve also added a quick-access panel for the most commonly used actions, just click the ‘…’ button on the right of a file entry:

The new diff view

The diff view has been given a complete overhaul both visually and functionally. Not only does it look much cleaner, it makes better use of the space, with each hunk hunk of code scrolling independently (rather than everything being one big scrolling area), and controls are locked to the edges of the view for easier access. The functions for manipulating hunks and lines now switch depending on what you have selected; select lines of code to bring up the line buttons, click anywhere outside the code to deselect and bring the hunk buttons back.

Of course you can still stage, unstage and discard from the diff down to a line level:

The new commit pane

Finally when you come to commit, the commit panel simply pops up from the bottom of the file status pane (where you can see any draft message you might have already started to write), either by clicking on it, or using the usual Cmd-Shift-C keyboard shortcut.

As you can see, this is a lot more streamlined, but all the options are still there, and you can drive them with keyboard shortcuts now:

If you change your mind and don’t want to commit immediately, just hit Escape and everything will be saved for when you want to come back and finish it off.

To access the author settings, just click your avatar:

It’s time to upgrade

From now on SourceTree requires Mac OS X 10.7 or higher; 10.6 is no longer supported although you can of course continue to use previous versions of SourceTree on that platform.

There’s more!

There are lots of other refinements we don’t have room for here:

We hope you like the new version of SourceTree as much as we do!



  • numpty
    Posted April 29, 2014 at 9:29 am | Permalink

    Looks like some really nice updates there, downloading it now!

  • Oli Mortimer
    Posted April 29, 2014 at 9:36 am | Permalink

    Great update. Unfortunately the ‘…’ menu is broken, and you can’t see the first ‘Stage File’ option

    • Anonymous
      Posted April 29, 2014 at 9:39 am | Permalink

      Hmm, I can’t reproduce this here, please can you raise a bug a with more details about your setup?

    • ceiroa
      Posted May 6, 2014 at 8:00 am | Permalink

      Reverted back to 1.8.1. I appreciate the effort but the new UI did not work for me. Staging area was not clearly defined, and I could not see path to files. I’d be happy to get bug fixes, but I’d prefer to keep the UI the way it is. “If it ain’t broken, don’t fix it.”

  • Posted April 29, 2014 at 11:32 am | Permalink

    The visual lightening is nice… SourceTree is beginning to look more and more like a native Mac app 🙂

    I have a few observations about usability regressions:

    – Cmd-Shift-L is no longer bound to Pull. Is that by design, for some reason?

    – I miss being able to drag files between the staging area and the working copy. The checkboxes are not used properly for this UI; they create a “shooting fish in a barrel” situation whereby the click targets move and disappear in response to engaging what should be a toggle button.

    – Why did the commit details and the file listing have switched places? Now the full commit message is farther away from its one-line summary (in the table view), needing more eye movement to read a series of commits.

    • Posted April 29, 2014 at 12:11 pm | Permalink

      In regard to the latter, I just noticed that the old arrangement persists in the “Search View”. I suppose this is an oversight? (However, I prefer this old view over the new.)

    • Posted April 30, 2014 at 12:28 am | Permalink

      Hey Ben,

      Sorry about the Cmd-Shift-L shortcut – I had scoured the shortcuts to make sure I wasn’t overriding any other shortcut, but not carefully enough. This shortcut will return in 1.9.1.


      • Grant Holle
        Posted April 30, 2014 at 11:03 am | Permalink

        Yay! Thank you!

  • Posted April 29, 2014 at 11:57 am | Permalink

    I appreciate the great product and I purchased it when it was still a paid tool. However the new file status view is not an improvement over being able to choose between the multi-paned or flat view. i can understand wanting to add the checkboxes but was getting rid of some great file management functionality really warranted?

    As soon as I updated to v1.9 I needed to copy some files within the repo and rather than a simple multi-paned experience viewing “All Files”, I was forced to scroll forever. I tried using the search filter but that just made it more obviously deficient over how well executed it used to be.

    😉 Also sad that Mercurial Queues didn’t make it in to this version.

    • Posted April 30, 2014 at 12:31 am | Permalink

      Hey Stephen,

      Coincidentally I responded on the Mercurial Queues issue yesterday as I was the developer who implemented interactive rebase in SourceTree originally. I’ve assigned it to 2.0 for review, but it may be a 2.1 feature eventually. Nevertheless, we have our eyes on it 🙂


  • Pulkit Singhal
    Posted April 29, 2014 at 12:06 pm | Permalink

    Visually, I like the slick smooth new look but functionally I’m having a hard time adapting to it. Is it possible to go back to the old view?

  • Anonymous
    Posted April 29, 2014 at 1:35 pm | Permalink

    Click, click, click, click.. Checkboxes suck. Please make it stop!

    In the WC view, I have to check individual checkboxes to select files for commit. I used to be able to select an entire range of files with a click, shift-click combination anywhere in the listing, but now I have to target a tiny checkbox for each and every file. This is a big step backwards in usability.

    Also, unless I can adjust the UI font size for the file listing, it is too small. The loss of vertical space due to separator lines is a drag too. Actually, the separator lines between each file cause an unfortunate visual disconnect when grouping by sorted path.

    • Posted April 29, 2014 at 1:48 pm | Permalink

      I agree with and support all of these criticisms.

    • Anonymous
      Posted April 29, 2014 at 2:05 pm | Permalink

      Adding to what I’ve already said. The fact that file listing is essentially one big column, making each file and its path just one long string, makes it very difficult to actually scan the listing for individual file names.

      Please at least bring back separate columns for status, filename and path (in that order).

      • Posted September 3, 2014 at 11:42 am | Permalink

        Just wanted to add up regarding complaining. It’s not complaining, it’s giving feedback. And getting feedback is great for any type of project. It’s up to owners what to do with it, but they should be thankful for any type of it.

    • Posted April 29, 2014 at 7:33 pm | Permalink

      I concur with @disqus505:disqus and @zygoat:disqus. These changes needs to get reverted or better adjusted.

    • Posted April 29, 2014 at 8:41 pm | Permalink

      I am in the same camp. You can right-click and select ‘add to index’ but the flow it just much worse. Finding things is a lot harder. Not having a split panes for staged/unstaged is really annoying when trying to see what you have already added.

      I can understand trying to make it easier for new developers but it would be nice to have an option to re-enable the previous UI.

      I’m not a great fan of the new commit window either, but I think with a split view it would be ok.

      The improvements to the diff view are nice though.

      For now I’m going to do the same and switch back to the 1.8 series and see if anything happens in future updates.

    • Anonymous
      Posted April 30, 2014 at 1:33 am | Permalink

      You don’t have to click every checkbox, once you’ve multi-selected, Space will toggle all the checkboxes for the current selection. Thanks for the feedback on the font size & style, we’ll consider it.

      • tres
        Posted April 30, 2014 at 1:38 am | Permalink

        I really like the Sourcetree, many great features, good concept, however I will revert to 1.8.1 and wait for the checkbox-less UI.

        @stevestreeting:disqus I know how to use checkboxes I just don’t want to use them, this one is definitely not for me.

      • Anonymous
        Posted April 30, 2014 at 4:45 am | Permalink

        Unfortunatelly this is still worse than the previous options, not to mention lack of sorting by name/path is a big pita…
        what was so wrong with cmd+click to select?!

        • Anonymous
          Posted April 30, 2014 at 4:51 am | Permalink

          Cmd-Click still works to multi-select. Hitting the spacebar after that does the same as drag/dropping that multi-selection to the other view. Sorting is now in the same drop-down as the filter FYI.

          • Anonymous
            Posted April 30, 2014 at 4:59 am | Permalink

            Hm, it still *feels* weird. I’m having and Idea why – spacing. Previously the list was waaay more compact so visually I had more items visible (even without getting rid of the staging area) and not there is more whitespace (also, more white alltogeter, see my other comment) which causes the sesnation of awkardness. For the moment I’m back on 1.8.1 (hard to find btw!) as using it doesn’t seem so weird.

          • Kalle Rainio
            Posted May 5, 2014 at 12:02 pm | Permalink

            I agree. I loved the old interface because it was so compact.

            I’m a programmer. I love my iPhone. But I don’t want mix the two. Right now it seems like this version of SourceTree was designed to be used with a touch screen.

            And the way SourceTree used to show the list of files: with the path on a separate column, sorted by status, path and then filename. I never really understood how awesome it was until it was gone.

            I reverted back to 1.8.1 immediately.

          • windows_user
            Posted May 1, 2014 at 5:34 am | Permalink

            You forgot to take into account that Mac users hate to touch their keyboard. 100% Mouse FTW!

          • Posted May 2, 2014 at 1:08 pm | Permalink

            Bullshit 🙂 Keyboard FTW. Way faster then the mouse!

      • Anonymous
        Posted April 30, 2014 at 6:50 am | Permalink

        Actually, this does not work correctly for me. If I select a range of say 4 files, then press the spacebar, only 3 of the four are selected. The last one selected in the range is never checked. This appears to be a small bug. Regardless, I still really dislike checkboxes and the loss of drag and drop for staging.

        • N1ghtm4r3z
          Posted August 23, 2014 at 5:02 am | Permalink

          Just updated to version on windows and I went digging in the options to enable drag and drop for staging files… now I read this is a feature???? Ugh, why do product owners never take into account “don’t fix what aint broken”, it was a good feature and I’m doubting to leave the auto update on if more of this mess is coming to the next version… fix this plz

      • iHate iOS7
        Posted May 28, 2014 at 1:47 am | Permalink

        Why should I have to use a key when I already have the checkboxes under my cursor? And where does it say I can use space? Nowhere. This is a hidden function = bad UX.

        • Davis Hernandez Guido
          Posted August 20, 2014 at 12:02 pm | Permalink

          they are not real checkboxes, they are working more like buttons… checkbox should just show that you selected that file, then when you hit the move to staging all that is selected should move… but now is like a buttons and status of Im or Im not in staging… that makes it hard to use… and confuse. At leas that is how I feel, seems to work like if they are touchscreen!

          (sorry for the necro, I tough I was in the win threat, just notice this is for the mac version and they just did the same on the windows version)

    • Nathan Gray
      Posted May 2, 2014 at 10:02 am | Permalink

      Sorry to hijack your comment, but I thought it worth mentioning that Steve has posted a response to the flood of comments on 1.9:

      He also shared this link for those who want to vote on UX improvements or follow their progress:

    • --marc
      Posted May 5, 2014 at 8:29 pm | Permalink

      I agree with bringing back the treeview as soon as possible.

      The “spacebar toggle” (instead click) may be “quick” for some set of actions; however, the reference to “quick” misses a fundamental issue that the treeview is much better matched to human information processing psychology.

      The treeview allows for the “chunking” of information in a hierarchical presentation and manipulation form. For more background on the psychology of “chunking” information, one can start with “Chunking_(psychology)” and “The_Magical_Number_Seven,_Plus_or_Minus_Two” in the Wikipedia)

      I have reverted to 1.8.1 pending resolution of the missing treeview.

      • Светлана Окунева
        Posted May 12, 2014 at 1:26 am | Permalink

        I’m waiting for the treeview too.

      • Posted May 29, 2014 at 11:12 am | Permalink

        I’m about to do the same. Once you have trees why would you ever ever go back to flat? Unless you only have a few file. I have more than a few files. Also, there are too many cases in the new version where I need to go to my mouse to switch window or confirm something. I’m programming, I don’t want to touch my mouse unless I need to. Also, why doesn’t page up and down work for the source change view, this was true in the old version as well. I. Don’t. Under. Stand.

      • AR3MY
        Posted June 19, 2014 at 7:51 am | Permalink

        Thanks a lot for this link to previous version, i do update innocently, and i start a devil day with sourcetree…

    • Anonymous
      Posted May 7, 2014 at 3:22 am | Permalink

      Here’s another vote for bringing back the tree view. I actually just started using SourceTree (long time Tower user), just to check it out after hearing about this update. It doesn’t disappoint, but tree view is something I’ve turned everything (menu options, preferences, the web) upside down for.

    • will
      Posted May 12, 2014 at 6:56 am | Permalink

      I with disqus505 on this. I have really tried to get used to the new UI, but I find it so jarring compared to 1.8.1 that I am now going back.

  • Paula Wing
    Posted April 29, 2014 at 1:57 pm | Permalink

    Some improvements look good – however I am upset that you have taken away staging and working copy from the file view. As others have commented, I used the drag & drop to staging and the right-click for commit all the time. You’ve made a simple workflow more complex for me 🙁

    • Anonymous
      Posted April 30, 2014 at 1:47 am | Permalink

      The staging and working copy view are still there; instead of drag/drop you can just press the spacebar to toggle, that’s even faster.

      • Anonymous
        Posted April 30, 2014 at 3:20 am | Permalink

        That’s not “even faster” if you’re trying to stage/un-stage folders of many files or sub folders since there doesn’t seem to be a folder view anymore? And if your file paths are relatively long you can’t actually see the full text string for the file path so you end up having to check each file individually before staging/un-staging.

        Both those processes where “grab+drag+drop” before…

        Also, it seems to be hanging for me on visualising the staged/un-staged files when using the “Use Staging Area” (likely a bug)

      • Rick Wong
        Posted April 30, 2014 at 6:46 am | Permalink

        Try unstaging a newly added file with spacebar. It doesn’t un-add it.
        Also I keep getting menu popups that are too small for their content.

        The UI change wouldn’t have been so disruptive if everything just worked.

        • Anonymous
          Posted April 30, 2014 at 6:50 am | Permalink

          There’s an issue with moved files that we know of, but added files work fine for me when staging/unstaging with space. The popover sizing is being looked at, it only affects non-Retina machines and although we tested on non-Retina secondary displays it appears this one sneaked through for machines whose only display is non-retina.

        • windows_user
          Posted May 1, 2014 at 5:37 am | Permalink

          “…if everything just worked.”

          There’s the Mac user we all know and love!

      • Paul
        Posted May 6, 2014 at 3:34 am | Permalink

        Please consider listening to user feedback on this one. You say you want to make the best possible product – take this feedback productively and consider bringing back drag and drop – I agree drag and drop was better. This is a step backwards I’m afraid. The best thing to do here is to take it on the chin and put it back to how it was. The product was better before.

  • Martin Zůbek
    Posted April 29, 2014 at 2:13 pm | Permalink

    Looks great. I only wish Windows version also got so much attention and care. SourceTree is awesome piece of software, and IMO it deserves a little bit more visual touches (at least on Windows).

    • Posted April 30, 2014 at 12:26 am | Permalink

      Hey Martin,

      The Windows version gets just as much time devoted to it. Because Mac is further ahead in terms of the functionality it had a little more breathing room for UI updates like this. The Windows version is having the same changes made to it and will be available in the near future.


  • Guillaume
    Posted April 29, 2014 at 3:31 pm | Permalink

    I have always used and praised Sourcetree since I started using Git. I’m also all for changes when it’s for good. But this is the first time that I think a Sourcetree update is a step in the wrong direction.

    “Stage files with checkboxes”: how on earth is this a better UI/UX than what we had before? It feels weird and non natural, I think it is a bad UX practice to move things around between 2 areas with checkboxes, I don’t think I’ve ever seen that anywhere.

    I was drag and dropping files from the working copy to the staging area all the time, SUPER easy and useful. At least give us the possibility of choosing between the new and the ‘old’ working copy / staging area UI?

    Also, the new UI for hunks makes it less readable, it was easier to visualize hunks with clearly defined blocks.

    • Anonymous
      Posted April 30, 2014 at 1:36 am | Permalink

      You’ll probably find that using the spacebar to stage/unstage is even faster than drag/drop.

      • Anonymous
        Posted April 30, 2014 at 4:47 am | Permalink

        No it’s not… some may find it easier but don’t assume that because some find it useful imediatelly everyone will

      • Snark
        Posted April 30, 2014 at 8:02 am | Permalink

        It’s not fast and I’ll tell you why: now I have to carefully select all of a subfolder’s content on a flat list. Before I just could Drag & Drop the easy to target root node (aka folder).

        • windows_user
          Posted May 1, 2014 at 5:36 am | Permalink

          Tree view and drag’n’drop are two different features.

      • Jose Ramon Cano Yribarren
        Posted May 2, 2014 at 1:42 am | Permalink

        If you want to stage 1 or 2 files is great. But if you want to stage, let’s say, 50 files, you don’t select them pressing Shift+down 50 times and then space, you use your mouse. And if you have your hand in the mouse, it’s faster to drag and drop than pressing space (or, if not faster, much much more natural than doing part of the job with the mouse and part with the keyboard).

      • kavehv
        Posted May 5, 2014 at 9:57 am | Permalink

        I get the feeling you guys only work in smaller repos if this is the case.

      • N1ghtm4r3z
        Posted August 23, 2014 at 5:08 am | Permalink

        Why the hell would you throw away a feature because you personally think spacebar/checkboxes are faster??? Please don’t destroy developer’s productivity because you have a grudge against drag and drop … nevertheless, those features can perfectly co-exist so why would you remove it anyway?

        • Anonymous
          Posted August 26, 2014 at 1:46 am | Permalink

          Please check the latest version, you can still drag-drop if you use the ‘spit view staging’ view mode.

  • waffletower
    Posted April 29, 2014 at 4:14 pm | Permalink

    The main reason I use Sourcetree is to get greater context and control over commits. The new changes made in 1.9 to staging were unusually disruptive to my workflow. Staged files were no where to be seen after staging them. Having to hunt for the “Use the staging area” preference to simulate the workflow I was used to was annoying. But I have to say, despite this, the checkboxes might actually be an improvement. I will weigh in again later. As annoyed that I was that Sourcetree changed dramatically while I was trying to get work done, this change might be for the better.

  • JBC
    Posted April 29, 2014 at 5:36 pm | Permalink

    What the h*** did you do??? How can I stage an entire directory? Do I have to click every freakin’ checkbox for every freakin’ file in every freakin’ subdirectory? Are you insane?

    • Posted April 29, 2014 at 5:40 pm | Permalink

      It seems that you can click the checkbox beside the label “Unstaged files” and it will stage everything. Strange but true. In the case of these headings, it seems that the meaning of “Staged files” and “Unstaged files” is not actually associated with the checkbox that sits beside them—another example of poorly-conceived UX.

      • JBC
        Posted April 29, 2014 at 7:07 pm | Permalink

        Thanks, Ben. That’s handy if I want to stage everything, but it doesn’t help me if I want to stage just one subdirectory. I used to be able to drag and drop a folder and everything under that folder would be staged. I can’t do that anymore. I’m checking in WordPress themes with a hundred or more files in the theme’s directory. I can no longer install a few themes and then commit each one individually. SourceTree suddenly made my workflow SUCK. I will now use the Git plugin in NetBeans whenever I possibly can. And everyone within earshot will know why.

        • Anonymous
          Posted April 30, 2014 at 1:37 am | Permalink

          The spacebar also stages / unstages the current selection.

        • Anonymous
          Posted April 30, 2014 at 3:24 am | Permalink

          I have the exact same issue. Updated this morning and went to try rearrange some file structures I’ve been meaning to do and 1.9 is completely useless for deep file structures with hundreds of files to change.

          I quite literally sat there for an hour thinking that there must be a better way, and then almost another hour trying to work with it but gave up as it’s just too error prone (yes I can press space to stage/un-stage files selected, but that doesn’t help much here)

          Just rolled back to 1.8.1, did the same task in 5 minutes. I’ll hold off updating until they fix the UX in this area.

  • kavehv
    Posted April 29, 2014 at 8:18 pm | Permalink

    I’m going to add my voice to the chorus here. The new file picker, while pretty, is functionally awful compared to the file picker it replaced. It was a bad decision to simply do away with the free and column views without replacing them with similar functionality. Please bring this back.

  • ken
    Posted April 29, 2014 at 10:57 pm | Permalink

    Please restore tree view style. It was very useful!

    • Requin
      Posted April 30, 2014 at 2:05 am | Permalink

      Switched back to the previous version when I’ve realized there is no tree view…

  • William RS.
    Posted April 29, 2014 at 11:59 pm | Permalink

    Very pretty, but please bring back the tree view! I had to switch git clients after updating.

    I work on projects with many files and having them all listed in a flat view (instead of a tree view where I can expand and collapse directories) is untenable for me. I do appreciate the updates! But half my projects can’t use your lovely client right now.

  • Snark
    Posted April 30, 2014 at 12:15 am | Permalink

    I agree on

    – no easy subfolder check-in
    – no easy select + drag & drop staging
    – no easy scanning of file and folder names

    Also this is the kind of mess that you get when you try to solve a problem with custom UI. The native OS X list view did a much better job.

    It looks less cluttered, but the advanced workflow feels worse.

    “You can switch back and forth between the simple and advanced modes on the context menu:”

    It would be helpful if this image would show the click target. Even better: don’t show the optional context menu but the real menu or pref window. Bonus point if it had the correct OS X menu item capitalization. 😉

  • Gautam
    Posted April 30, 2014 at 12:51 am | Permalink

    So, SourceTree now lacks the tree-view for files? How am I supposed to just select one folder, or a subfolder? No way I am going through (sometimes) 1000 files to look for just the files in the folder I want.

    • Posted May 1, 2014 at 6:34 pm | Permalink

      I think they’re trying to encourage using Finder for that given that there’s a very prominent “Open In Finder” option in the title bar, and also in the main File Status UI when there aren’t any changes.

      It does seem that finding files in SourceTree when you need to, for stuff like viewing history or ignoring/removing from version control, just got more awkward with that change, though.

      • Anonymous
        Posted May 2, 2014 at 2:20 am | Permalink

        We’re listening to feedback on the tree view, but you should know that Cmd-F to search files got better in 1.9. Instead of just filtering the current list (usually Pending Files), once it runs out of matches it’ll flip to searching for all files. So if anything finding clean files to view history or remove from version control should be better now because you don’t have to mess with the filter any more to quickly locate an unmodified file.

  • xes
    Posted April 30, 2014 at 1:04 am | Permalink

    how can I hide the file path and show only the file names? Like it was before

  • Nathan Holmberg
    Posted April 30, 2014 at 1:04 am | Permalink

    As others have noted, the changes to workflow may work for some people but are fundamentally broken for those who deal with a large number of files. While I don’t mean to sound harsh, how much user testing was done to verify this really is a better, rather than just better-looking update?

    Thanks to the (admittedly slick) auto-update process I can no longer use this product. Is there anywhere where it is possible to download older versions or do I need to find an alternative?

  • Pete
    Posted April 30, 2014 at 2:00 am | Permalink

    The staging area – please consider bringing-back the old system back with split panes!
    The file paths are very difficult to scan – please consider bringing-back the separate columns for status, file name, and path.
    IMO, the commit description should be above the list of files – for some reason, it is difficult to read when below the list of files. Maybe that is just me, however. 🙂

    When will you add support for showing diffs of Mac/iOS .strings files?

    Luckily, I decided to try-out 1.9 in a VM – I’m sticking with 1.8 for now (which I love!).

    • Posted April 30, 2014 at 10:46 am | Permalink

      Exactly—the split-pane view provided a visual reference point for assessing the volume of files (if any) that were staged or not. With the fish-in-a-barrel design now introduced, there is no longer any fixed reference point, since the location of the split is indeterminate (or non-existent).

      Further testament to this design flaw is that at a glance it is impossible to tell whether ALL files are staged or NO files are staged. Unless you look at that damn parade of checkboxes, I guess.

  • Posted April 30, 2014 at 2:34 am | Permalink

    1) The new staging approach uses space smarter. Now staged and unstaged files are using all available vertical space that is good. UX is different and needs some time to get used. I think it is not better or worse, it’s just different.

    2) Committing needs less clicks that is always good.

    3) 1.9 works a lot faster. Special thanks for this.

    I like this release. I needed 3 minutes to get used to it. Thanks a lot! 🙂

  • Ray Beyer
    Posted April 30, 2014 at 2:40 am | Permalink

    I’m not sure about the checkboxes, but the first impression is fine for me. Got to get used to it.

    I do like the quick-access to the common file operations. But: is “discard” the same as “reset”? I guess it is. But why a different name then?

    • Anonymous
      Posted April 30, 2014 at 5:58 am | Permalink

      Yes, we’d always used ‘Discard’ on the diff pane so we’re using it in the popover too, it means either Reset or Revert depending which dvcs you’re using.

  • Anonymous
    Posted April 30, 2014 at 3:08 am | Permalink

    Wow, this is a big step back in productive user workflow 🙁

    What happened to folder view? Who decided check boxes or right clicking to then select an option was faster than drag dropping?

    If I have a folder of files with a deep structure that I want to commit, I now have to shift select all of those items in one giant flat list, being careful that i’ve not accidentally scrolled too far? That’s a big increase in manual steps prone to errors. In the old folder view with drag drop that was one motion – grab that folder, drag and drop to check in area, done.

    If I want to add specific sub folders in that deep folder structure I’m now pretty screwed as I can’t expand the path window wide enough to see the full path to identify said files.

    Having separate panels for staged and un-staged with file structure was one of the best features in SourceTree as it visually allowed you to see what was going in quickly and efficiently without seeing just a sea of incomplete text file paths. Whoever decided to get rid of that needs to have a serious think about never doing UX design again…

    Does anyone know if there is a way to roll back? This update is going to cost me a lot in wasted time.

    • Posted April 30, 2014 at 11:19 am | Permalink

      Thanks for digging out the link; I am reverting back to 1.8.1 now too so that I can get work done without losing my mind.

      • csolallo
        Posted April 30, 2014 at 11:40 pm | Permalink

        Agreed. Thanks for finding the link. I’ve rolled back to 1.8.1 as well.

    • Steve Powell
      Posted May 1, 2014 at 3:24 am | Permalink

      OK; reverting to 1.8.1. Sorry SteveStreeting, but I couldn’t understand the new interface at all for ten minutes, then when I understood it I couldn’t understand why you had done it. You have produced a GUI interface that commits many basic user interface errors: mis-labelled checkboxes, items/options that appear and disappear, and move about; relocation of function to be distant from the focus; … others have pointed them out. Thanks for an hours’ amusement, but I’m reverting and may not upgrade again. Shame–the product was brilliant.

    • Chris
      Posted May 1, 2014 at 11:07 pm | Permalink

      +1 for reverting to 1.8.1. I also tried to work with the multi-select/space but it was buggy (would not consistently select/deselect and move the correct entries). Having the filename/entire path in the same list is much more difficult to work with.

    • Anonymous
      Posted May 2, 2014 at 12:49 am | Permalink

      Thank you so much for that link. This is completely broken for me. The visuals do not match what is actually checked into BitBucket, I get surprises when I look at the actual commit from BitBucket. It’s one thing to change the UI, I don’t like it at all, but I presume I’ll get used to it. But this is broken, utterly broken on my mac. I can’t imagine what they thought they were doing.

    • Kirill Muzykov
      Posted May 5, 2014 at 8:11 am | Permalink

      Thanks a lot for this link! Spent 2 days to use new UI, but it simply awful!

    • Baastax
      Posted August 25, 2014 at 3:39 am | Permalink

      Yeah, our whole team went back to old version after this update. The new GUI just doesn’t make any sense.

  • Dan Brown
    Posted April 30, 2014 at 4:07 am | Permalink

    I like having a single list for both staged and unstaged files But the division between them needs to be far more obvious.

    I can ignore the checkboxes easily enough as I stage by hunk anyway as I review the diff. However the stage/discard hunk buttons have been moved from conveniently near the file list to the far right of the screen which is plain annoying and neither a usability or speed improvement.

    But the real dealbreaker is the loss of the directory tree. The new file list may be fine for a few files at a time but for lots it is unusable. I frequently switch from pending to all to locate a specific file to check a log or whatever I need to do. Being able to collapse the tree and get to the right directory in a few clicks is perfect for that. Scrolling through a few thousand files looking it up alphabetically is a terrible replacement.

    So, I’ve gone back to 1.8.1.

    • windows_user
      Posted May 1, 2014 at 5:38 am | Permalink

      Instead of scrolling, type the first part of the filename in that search box. It filters very quickly.

  • aro
    Posted April 30, 2014 at 5:35 am | Permalink

    the new commit stage / workflow is everything else but useful. Two column diff preview and file listing can’t be resized. How do I know which file is the right one? Please bring back the dual pane für working dir/ commit stage !!!

    • Anonymous
      Posted April 30, 2014 at 5:57 am | Permalink

      I’m not sure what you mean, the file list and diff are still in 2 separate columns just like before, and you can grab the split in the middle to resize the two – please see the first screenshot in the blog for example. Unless you mean something else?

  • jrittle
    Posted April 30, 2014 at 5:46 am | Permalink

    Two questions – Are there any plans to update SourceTree to include some form of ‘auto-pull’ for remote servers? (or is this possible now?)

    Also, is there a place to see the upcoming/planned updates for SourceTree?

    • Anonymous
      Posted April 30, 2014 at 5:55 am | Permalink

      We already auto-fetch if you’re on git, the default is every 10 minutes. We don’t auto-pull though because that would change your working copy and that’s usually not what you want happening without your say-so.

      • jrittle
        Posted April 30, 2014 at 6:15 am | Permalink

        I completely understand that most projects wouldn’t want this happening automatically. However, I do think there are plenty of solid use-cases out there that would validate this as an option.
        It would be great if there was at least the option to ‘turn on’ auto-pulls for various remotes. Personally, we have several projects that would find this extremely useful.
        Thank you for your quick reply!

  • Anonymous
    Posted April 30, 2014 at 7:03 am | Permalink

    Why is SourceTree sometimes trying to be clever by pre-selecting my files? I have a hg repo that when I open it, ST has already pre-selected my added and modified files. This forces me to first unselect everything then use the now sub-par UI to reselect what I want.

    • Anonymous
      Posted April 30, 2014 at 7:10 am | Permalink

      We pre-select on the same basis that the old commit sheet used to pre-select in hg. That means all pending files except untracked.

      • Anonymous
        Posted April 30, 2014 at 7:26 am | Permalink

        Except that since my Hg workflow was always “Commit Selected” from the working copy, I never had to deal with the old commit sheet other than make my comments.

        ST has been an amazing product pretty much since day one, but 1.9.0 has really been a disheartening release.

  • Gabriele
    Posted April 30, 2014 at 8:12 am | Permalink

    Please give us the option to switch back to the old view, this checkbox thing is really annoying.

    • Glyn Normington
      Posted May 1, 2014 at 2:58 am | Permalink

      I couldn’t agree more. I have recommended SourceTree to friends and colleagues for years and used to pay for it. But 1.9.0 is a retrograde step for usability and if I eventually need to “upgrade” to it, I’ll be doing my staging on the command line so I don’t get a headache.

  • Clay
    Posted April 30, 2014 at 11:11 am | Permalink

    I appreciate the work to improve the software, but I much prefer the tree view and staging pane that I could drag files to. It’s easier and more logical than the new way with the spacebar shortcut. Will you please bring it back? Maybe if enough people ask!

    • Clay
      Posted April 30, 2014 at 11:27 am | Permalink

      I used Time Machine to restore the previous version which seems to have worked. Posting this in case anyone else liked the previous version better and is wondering if they can go back.

  • waffletower
    Posted April 30, 2014 at 12:08 pm | Permalink

    I will eventually get used to the new placement of hunk buttons, though I have accidentally chosen the wrong hunk more than once. While Jonny Ive may not approve, it may help to draw an additional dark line between hunks to make clear as to which hunk the buttons are associated with. In a long list of hunks there isn’t a visual cue to differentiate. Coupled with the fact that the hunk buttons used to be placed at the bottom of a hunk and now they have been moved to the top, the relearning required is significant and confusing to long standing users. But either 1.8 or 1.9 are so much better than Tower for this particular feature.

    • Posted April 30, 2014 at 12:14 pm | Permalink

      The hunk buttons being moved to the top are indeed another usability regression.

      If I am assessing a hunk for staging or reversion, I’m going to read through the diff first, which might require some vertical scrolling. I’ll then be at the bottom, ready to make my decision. With 1.9, I am now forced to scroll back up to the top in order to find the buttons.

      As you also alluded, the visual separation between hunks is now more subtle now than before, making the the task more difficult.

      The result of this change is increased work and cognitive load for the user, with no added benefit.

      • Fabian Lange
        Posted April 30, 2014 at 12:53 pm | Permalink

        completely agree, why on earth would an action you would take after reading multiple lines of text be positioned at the top of that text? Thats not a matter of taste or design, its completely broken.

        • windows_user
          Posted May 1, 2014 at 5:46 am | Permalink

          Do you guys use your mouse as an aid to track words as you read? No reason you can’t leave your mouse at the top of the interface.

      • Feng-Shui
        Posted May 1, 2014 at 4:03 am | Permalink

        “I’m going to read through the diff first, which might require some vertical scrolling. I’ll then be at the bottom, ready to make my decision.” Yes.

  • Fabian Lange
    Posted April 30, 2014 at 12:22 pm | Permalink

    I want to support all the concerns regarding the commit/stage view. It was the best feature for me in sourcetree. By far! I could easily stage many files, unstage hunks, stage other hunks, stage whole directories, ignore other files etc, all nice.
    Now the whole experience is gone, the checkboxes are clunky, and contrary to what you claim, the spacebar does not work for me. The visual style makes it much harder to figure out which files there are. Are you using java? you cannot be serious by showing the full path length? Full workspace package pathes break the stage view and even the diff view because such long pathnames just do not work.
    I cannot believe that you claim all you Atlassian Devs are using it. The commit pane is such a bit step backwards that I cannot try the other nice additions.

  • Nathan Gray
    Posted April 30, 2014 at 1:51 pm | Permalink

    Having used SourceTree for several years now and submitted several feature requests and bug reports I’ve got a lot of respect for the way this team accepts and acts on community feedback. I’m optimistic that the checkbox UI will quickly go the way of Clippy and Qwikster, so I’m trying to be restrained and constructive in my reaction to this change. But it’s tough when a UI that was maybe a bit rough around the edges but fundamentally sound gets replaced by one that’s such a step backwards.

    – Toggling a checkbox should NEVER cause the checkbox itself to jump to a different location! Isn’t this interface design 101?

    – The new UI completely falls over when you have more than a few dozen files changed, because the staged/unstaged files are all in one giant list. Stage a few lines from a file. Oops, didn’t mean to stage that line? Have fun scrolling the giant list to find the staged version of the file! Want to jump back and forth to see what’s staged vs. unstaged? Scroll like the wind, bro.

    – Having separate columns for the filename, path, and status made it easy to visually isolate the item you were interested in, and sorting was a no-brainer. Now it’s messier to find the filename and sorting is mixed with filtering in an awkward textual drop-down.

    – Minor nitpick: The inline commit message is nice, but the commit message is the “title” of the commit. It should go above the contents of the commit, not below it. Same in the timeline view — it’s weird that the metadata appears below the changed file list.

    – Finally, a missed opportunity: If you’re redesigning the commit UI please make it freaking drop-dead stupid obvious WHAT BRANCH you’re committing to! My daily “company git guy” support load would drop dramatically if you did this…

    Back to 1.8 for me. 🙁

  • Ion
    Posted April 30, 2014 at 6:25 pm | Permalink

    Bring back tree view!

  • Alex Hunsley
    Posted May 1, 2014 at 1:37 am | Permalink

    This update is a nightmare. No staged files view? No file tree view? Hunks all together etc? Please fix this insanity.

  • Thomas Hempel
    Posted May 1, 2014 at 2:05 am | Permalink

    Is this a joke? Alright, this must be a joke.

    Nobody can seriously think that this is a good idea. I mean come on, I have to deal with more than one changed file per commit on a daily basis. This interface is a total nightmare.

    To move 20 files from one folder to another one, I now have to click 40 checkboxes? Are you kidding me?

    Come on guys. Please, please, please with sugar on top. Give us back the old interface. It was perfectly fine for the job!

    I don’t want to go back to Tower again. :-/

  • Anonymous
    Posted May 1, 2014 at 2:27 am | Permalink

    Rather than reply to every comment here I thought I’d respond here at the top level. Firstly, apologies to people who don’t like the changes in this update. We always knew it might be controversial with some people, although we genuinely felt that after doing user tests and using it ourselves internally for many weeks that after an adjustment period, it felt better. I hope you give it some time, try the alternate approaches, but if you still feel strongly, the previous version is still available here:

    We’re making some small refinements and fixes for 1.9.1, and we’ll be reviewing all the feedback for future updates. Changes to a core UI component which hasn’t altered much in over 2 years is always going to be tough, but there were definitely things to address when it came to new users (particularly those new to git). We thought we’d got the balance right between making it easier for new users while retaining the preferences of more advanced users – which includes us! – but your feedback is useful in gauging the success of that in the ‘real world’ of course. Thanks for your feedback, and for your patience; we all want to make SourceTree the best tool for everyone.

    • Anonymous
      Posted May 1, 2014 at 7:27 am | Permalink

      I’m having a hard time buying the argument that much of this was to make it easier for new users. For one glaring example, you’ve made file viewing/management a totally foreign experience. I can only comment on the OSX version, but the new version of ST displays and manages files like no other OSX application that I know of, including the most familiar of all, “Finder”. How is this easier for *any* user?

      Perhaps using yourselves as beta testers is just too small a sample group. Do you never work with large, deep file hierarchies with hundreds or even thousands of files? Does nobody work on laptops with limited vertical space? Does everyone really like checkboxing files and having the files “jump” to a new location?

      I think this blog post has received more comments than any other on ST. Considering that most of them are unsupportive, along with most of the related comments in your Twitter feed, you should consider that your team made some mistakes with this UI/UX overhaul.

      Unfortunately, it seems your message is that we should try to get used to it, because we’re not going back. That’s really too bad. If ST was a paid product, I would be voting with my wallet.

      • Anonymous
        Posted May 1, 2014 at 7:39 am | Permalink

        I’m simply asking that you give it a chance; we have been using it internally for a while (across the company). But I’m definitely *not* saying that it’s ‘take it or leave it’, we’re definitely listening to the feedback. The major issues are being catalogued, and we’ll be looking at all of these once we’ve had time to reflect:

    • barduck
      Posted May 1, 2014 at 7:41 am | Permalink

      I understand that people tend to resist change and rather stick to what they know and use to.

      But the complaints about this update go way beyond just generally being uncomfortable with getting use to a new UI and modified workflow. There is functionality that people were using and was just removed (tree view, separate paths). The new UI is inferior in any possible way, staged view was a clear way to see your changes in a glance, checkboxes are not and this is very non standard UI on the Mac.

      I simply don’t understand what problem you were trying to solve by this. Just the fact that it “hasn’t altered much in 2 years”? Why fix it if it wasn’t broken? I am sorry to say but your reply sounds like trying to defend the decisions in this release no matter what and an attempt to pin the complaints about this release on the “people don’t like change” argument.

      I know that SourceTree is free and I am grateful for that, you can’t complain about something given to you at no cost. Still, this is something my work was dependant on and I will not be migrating to 1.9 in its current state. I’d rather pay for better alternative.

      • Anonymous
        Posted May 1, 2014 at 7:46 am | Permalink

        We genuinely had feedback that ST was difficult for people new to git. It wasn’t ‘broken’, at least for people who knew how git worked, but the intention was to smooth the on-ramp for people who didn’t. Some designs mooted were more radical than this one, and we tried to hit the middle ground; feedback from user tests at both ends of the spectrum suggested we had, along with internal dogfooding; but you can never tell for sure until you open it up wider. We’re listening to the feedback.

        • barduck
          Posted May 1, 2014 at 8:02 am | Permalink

          I am all for clean and effective UI but people who are new to git are better served by helping them understand how git works, not abstracting it from them. This goes directly against what git stands for.

          Also, people who don’t like the extra flexibility and functionality of git have the alternative of using Mercurial, which ST also support and has simpler workflow.

          Those of us who chose and like git because of these differences from hg now feel kinda cheated by ST trying to forcing us back to a dumbed down experience.

  • Alexander Obuhovich
    Posted May 1, 2014 at 8:01 am | Permalink

    I want to see files grouped by folder (like in previous versions of SourceTree). Can I enable that mode back?

    Also drag-n-drop mode for Staging was more intuitive IMO.

  • Errortype520
    Posted May 1, 2014 at 8:23 am | Permalink

    I don’t like the new checkboxes, I will revert back to 1.8.1 for now.

  • Jim Renkel
    Posted May 1, 2014 at 9:19 am | Permalink

    I generally agree with the other opinions expressed here that the new UI is a step backward, at least for experienced users. And I understand the point about trying to make it easier for new users with small projects.

    But new users with small projects eventually become experienced users with large projects. Then they too will face the same issues with this that we already do.

    I guess the real problem I’m having with all of this is that SourceTree now seems committed to this new user interface. I can, and will, stay on 1.8.1 to keep the old UI, but if, say, some great new feature is added to git, will it also be supported in the old UI or only the new UI?

    I think we all, unfortunately, know the answer to that one.

  • Brian Westphal
    Posted May 1, 2014 at 10:13 am | Permalink

    I’ve tried using 1.9, and I just can’t do it. The tree view made it so easy to find a file. There isn’t a single complete path in this 1.9 file list because my paths are too long. So it’s very difficult to find what I’m looking for.

    The fact that a file jumps around when it is clicked and causes the others files to move up or down is not the way things are done on the Mac.

    I also agree that the hunks in the diff view are not properly separated and the unstage hunk button was much more convenient at the bottom of the hunk.

    I must switch back to 1.8.1 now. I’ll continue to watch new updates to 1.9, but if the tree view doesn’t come back, then I will have to find another git client. That’s unfortunate because SourceTree was a killer app before this change.

  • Anonymous
    Posted May 1, 2014 at 11:11 am | Permalink

    I’d just like to express my gratitude for the ease with which those of us who struggled to find something of value in the new 1.9 interface can revert back to 1.8.1. I mean it and no sarcasm intended — locking me into 1.9 would have driven me to one of the many alternatives, and I really like SourceTree.

    I have to say that suggesting that I might like 1.9 once I’ve used it for a while is a lot like suggesting that eventually I’ll get used to a new pair of ill-fitting shoes — I might adjust, yes, but they still won’t ever fit, and I’d rather not voluntarily put myself through the unnecessary pain of ‘adjusting’.

    I would guess that most of us use a git interface like SourceTree because we prefer a graphical UI to the command line and use SourceTree instead of SmartGit or Tower or even GitHub because we prefer it’s interface. Radical changes to that interface aren’t merely ‘controversial’ but can be a real deal breaker in the implicit, and somewhat binding, contract between developer and current loyal users.

    So thank you for making it possible to keep using SourceTree 1.8.1, although by making it an essentially dead fork I suspect I won’t be able to stick with it. I hope that the profoundly negative feedback from current users carries extra weight in the internal arguments that will ensue about what to do to ‘fix’ the UI in subsequent releases.

  • Anonymous
    Posted May 1, 2014 at 11:23 am | Permalink

    These changes are terrible. Thank you at least for making your auto updater leave the old version in the trash, I’ve restored it and disabled updates. May have to look for a different git gui now.

  • Anonymous
    Posted May 1, 2014 at 11:43 am | Permalink

    Excellent work.

    This new UI is much improved because it allows more of my teams to work with Git, coming from a variety of backgrounds and disciplines. The older UI was a bit too complicated for many people and onboarding team members was often slow.

    I am happy that your team still includes great options to ‘nerd-out’ against the actual commands, jump to the shell and let more advanced users do what they do best.

    Please keep making these simplification improvements to allow more people to centralize around this tool.

  • Julian
    Posted May 1, 2014 at 1:39 pm | Permalink

    Big QQ. No more 10.6 support 🙁
    The post-Steve OS X versions suck hard, so I’m still on 10.6.8 and do not see a single damn reason to “upgrade”.
    Why is SourceTree dependent of 10.7+ all of a sudden?

    • Posted May 1, 2014 at 1:49 pm | Permalink

      Come on, Julian. That’s a straw man and an unreasonable appeal to emotion. Supporting and testing against OS versions that are three years out of date is a considerable burden even for actively-funded software. And SourceTree is a free product, no less. You can’t reasonably expect ongoing and cutting-edge support, especially in new versions of products, and especially as time moves on.

      • Julian
        Posted May 2, 2014 at 4:27 am | Permalink

        They (and quite a few other devs with Mac/Win Software) are still supporting Windows 7 which came out roughly two years earlier than this version of OS X. For some strange reason, time runs faster in the Apple world? Sorry, but I call BS argument for that.

        Seriously, I think that’s doable without too much hassle as long as you don’t have an unreasonable urge to instantly try out freshly released UI components from the newer versions just for fun or because they look cool to you.

        And of course there’s nothing to “expect” from a free product, still it would be quite nice.

        • Anonymous
          Posted May 2, 2014 at 6:26 am | Permalink

          2 primary reasons for dropping 10.6 support:
          * Localisation: supporting more languages is disproportionately hard without Auto Layout support which was introduced in 10.7
          * ARC is not fully supported in 10.6

          There are other things too but those are the major ones. Localisation got better in 10.8 too but we’ve compromised and kept 10.7 in.

          Apple had been telling us at every WWDC that we should support the ‘current – 1’ versions of OS X. I think that’s a bit extreme which is why we’ve supported 10.6 for so long, but this is the expectation they set. The drawbacks for keeping 10.6 now outweigh the positives and the percentage of users on 10.6 is so tiny it doesn’t justify itself any more, sorry.

    • Anonymous
      Posted May 1, 2014 at 8:18 pm | Permalink

      Julian, I was a 10.6.8 holdout until just a few weeks ago, but found that there were too many of my apps that I could no longer upgrade, and new apps that I could not have. Fortunately, with the addition of some apps, namely TotalSpaces and HyperDock, Mavericks (10.9.2) is working out really well for me. The upgrade process was smooth, the new OS features are nice, and I’ve noticed no significant hit in performance.

      • Julian
        Posted May 2, 2014 at 4:34 am | Permalink

        I’ve had 10.7 and 10.8 on machines I don’t use for active work and have 10.9 on my mini server currently. It’s not like I just clicked around for a few minutes on a demo device in a store, I did try to adjust those with settings and 3rd party software in an attempt to get my muscle-memory based workflow with much gesture and key combo usage back working – with no satisfying success since there always was something important missing. And then there’s the fugly “design” with baby blue buttons and (really, a great advancement! bravo!) all-greyish icons in Finder and elsewhere so you can no longer quickly distinguish the different entries. Finder sidebar custom ordering? Nope.
        I could go on and on with that if I wanted to write more…

  • Anonymous
    Posted May 1, 2014 at 2:16 pm | Permalink

    Hi, – Feed back. The entire reason I use SourceTree, and have been heavily recommending it to people for years… is that it looks like a file browser, has a nice tree view and Mac style column view. The new GUI is unusable to visual thinkers. It is as bad as green command line where we have to parse text. Something a lot of programmers really gravitate to. But not so much none programmers. Theres no use of color or visual indicators to break up paths etc.

  • Jerry
    Posted May 1, 2014 at 6:22 pm | Permalink

    The diff summary seems to be gone from the diff view (“Modified file, 18 lines added”, etc). I found that hugely helpful. I’m reverting to 1.8 until it returns. I’m not a fan of the new checkboxes either. Overall, 1.9 seems to be a huge step backwards.

  • Disgruntled Java Developer
    Posted May 1, 2014 at 10:01 pm | Permalink

    Ugh… the new staging/commit workflow is completely unusable for me on my project that has really long path names and really long filenames.

    I will be downgrading to 1.8 and hoping you read all this feedback and change it so I don’t have to search for a new git client…

  • Christian Kipke
    Posted May 2, 2014 at 1:00 am | Permalink

    Hey guys… I like your app. BUT the latest update is not for me. Maybe it’s faster and all those advantages are great… But maybe you should had roll it out as some 2.beta or something. I often need to sort inside my uncommitted changes but now I am lost. I can sort by checkboxes but how can I change the sort direction?

    Will use 1.8.1.

  • Jose Ramon Cano Yribarren
    Posted May 2, 2014 at 1:30 am | Permalink

    What the…? The thing I liked the most about SourceTREE was the TREE!. Before update, if I wanted to stash a folder, I just drag-drop the folder to stash. It was brilliant! Now, if there are 10 thousands files, sub-folders, sub-folders, etc I have to select them all??? Sure, I can select the firs file, scroll 5 minutes to carefully find the last one, press shift to select them all and then press space bar, double checking that I am only selecting that folder, but this is a pain in the ass. Looks like you are going backwards with sourcetree.
    1.9 looks beautiful, but it’s so upset you “killed” that tree that I’m going back to 1.8. Maybe you can consider combining the checkmarks with the tree, or at least give the option to use it, before people start getting angry and grab their torches and pitchforks
    Do not kill more trees! 😉

  • phelgo
    Posted May 2, 2014 at 2:31 am | Permalink

    Please bring back the drag and drop functionality. Thanks (:

  • Posted May 2, 2014 at 3:00 am | Permalink

    Why the hell did you remove the pull shortcut?

  • jf
    Posted May 2, 2014 at 4:41 am | Permalink

    I miss the tree view. Why did you remove it?

  • Anonymous
    Posted May 2, 2014 at 7:07 am | Permalink

    This morning I was still using 1.8. Cloned a repo, bookmark created. Then installed 1.9, cloned another repo, no bookmark appeared. Tried again, didn’t work. Restarted the software, no. Reinstalled it, still the bookmark didn’t appear. Trying to find version 1.8 to download and install it back.

    • Anonymous
      Posted May 2, 2014 at 9:01 am | Permalink

      We haven’t experienced this with 1.9 and after doing a few tests here, cloning created bookmarks just like before. Please open a but report at with more details so we can investigate.

  • Anonymous
    Posted May 2, 2014 at 4:25 pm | Permalink

    The tree view was one of my #1 reasons for using SourceTree. I have been eagerly awaiting having the tree view in the Windows version as well…

    Please bring back the tree view. Until then I am staying on the previous version.

  • Kraig McConaghy
    Posted May 3, 2014 at 1:28 pm | Permalink

    I know some people are missing the tree view in the staging area but I miss the split between filename and path. Most of the time I know exactly what file it is based on the name and don’t need the path (since most file names in repos are unique). Its so cluttered now with the path. Or at least make path a toggle. I also don’t like the checkboxes but I but they don’t bother me that much. Other then that I like the new look and it will fit nicely with the rumored OSX 10.10.

  • Jeremiah Small
    Posted May 4, 2014 at 2:39 am | Permalink

    Back to 1.8.1 for me, I’m afraid. The two deal breakers for me? Missing tree view. Missing staging pane.

  • Harp
    Posted May 5, 2014 at 3:14 am | Permalink

    First time I’ve had to revert to a previous version of this software. Love Sourcetree, love the company, but hate this update. I don’t understand why the functionality of file browsing has been hamstrung. It is so hard to see when you are trying to commit files. All you see is a big long list of files. no hierarchal view based on file structure. I don’t understand why you would get rid of this?? I have work to do and this just screwed up my whole workflow. Can’t even look at any other features with the elimination of the tree and column view. There is no organization of files visually. sure I can look at the path of 100 files and determine which folders I need to select and then select all the files in that group… but that is way harder than selecting a folder and dragging it.

    • Carlos
      Posted May 5, 2014 at 9:04 pm | Permalink

      But just think how happy you’ll be when working with the iOS version that will be exactly the same. No difficult context switch for users to make. All praise the rise of mobile devices.

  • ort11
    Posted May 5, 2014 at 8:04 am | Permalink

    Yes please return the last UI (or at least the ability to use the last UI). Need staged files / vs changed files as before when merging in untracked branches and needed to see local changed files only.

  • Anonymous
    Posted May 5, 2014 at 12:14 pm | Permalink

    How do I get the old staging area back? It was much easier to understand and visualized the commandline better. It made teaching the staging area to the rest of my team much easier.

  • Jeremy
    Posted May 5, 2014 at 3:02 pm | Permalink

    Having lots of problems with 1.9.1, and logging in to just brings me recursively back to a log-in page, so…

    Truncating the first part of filenames in the files list by full path makes it unreadable, e.g.:

    “…Example Assets/Shaders/Vegetation.mat”

    “…le Assets/Shaders/VertexAnimation.mat”


    I click the checkbox next to “Staged files” or “Unstaged files” (which I
    assume means “stage/unstage all files”) I get a spinning icon as though
    Sourcetree is doing something, but it spins forever.

    I have to quit Sourcetree to recover.

    After restarting Sourcetree the files are in fact properly staged/unstaged.

    The diff pane forces its width to be the width of the entire path to the file.

    If the selected file has a long path name, the files pane on the left becomes super narrow.

    diff pane appears to take precendence, preventing me from resizing the
    files pane to be bigger (it lets me make the file pane smaller, but not

    Redefining the typical meaning of a checkbox in the case of staging/unstaging files is unintuitive.

    if ever, does toggling a checkbox mean “perform this action
    immediately”, normally it just toggles the selection of an item in a
    standard UI.

    Selecting multiple files in the
    file list, then right clicking and selecting “Add to index” (or “Unstage
    from index”) sometimes has no effect.

    I expect it to add/remove these files to/from staging.

    Sometimes this command actually works, but not every time.

    a single file in the file list, then right clicking and selecting “Add
    to index” (or “Unstage from index”) sometimes causes EVERY file to be
    added to/removed from staging.

    Doesn’t happen every time.

    When scrolling down the file list of my working copy, the “Staged files” scroll out of view.

    This makes it hard to manage my commits when I can’t visually track which files are in staging.

    is also sometimes confusing when I scroll down and add a file to
    staging, because the file just disappears from view with no other
    feedback about what just happened.

    I think I’ll
    stop there for now. I was excited for these changes but I tend to agree
    the the other users here, the new design is worse than the old one.
    Thankfully I can downgrade.

  • Jeremy
    Posted May 5, 2014 at 3:25 pm | Permalink

    Actually it’s not all bad, the new quick find feature is pretty great!

  • Carlos
    Posted May 5, 2014 at 9:01 pm | Permalink

    Welcome to SourceTree for iOS folks. I think that pretty much explains the new interface. A colossal mistake and crappy release.

  • Paul
    Posted May 6, 2014 at 3:31 am | Permalink

    Sorry to say, but I agree with all the criticisms of this update. Please revert back to how it was – checkboxes are horrible, the staging area shouldn’t be hidden, and we want tree view back. Please listen to the criticisms.

  • Pascal Welsch
    Posted May 6, 2014 at 4:04 am | Permalink

    I don’t like it …

  • Anonymous
    Posted May 6, 2014 at 7:41 am | Permalink

    The working copy view is awful. The quick commit on the bottom is awful. I will stay on 1.8 for now.

  • Anonymous
    Posted May 6, 2014 at 7:57 am | Permalink

    First sourcetree update that required me to go to the command line to figure out what was staged.

  • Al
    Posted May 6, 2014 at 8:07 am | Permalink

    Hey guys and girls. Terrible update. I thought I just committed 6 files and it took all of my changes in my workspace and committed them. It’s a good thing I had a backup copy of my 3 days worth of changes! Now I’m afraid of committing 6 files. I don’t get it. I had/have 30 something changes in my working copy and I only wanted to commit 6 and it took them all. AND there we only 6 boxes checked AND they were new files as well. Not a good user experience. It’s non intuitive

    • Anonymous
      Posted May 6, 2014 at 8:20 am | Permalink

      Really sorry you’re having issues here. We’re listening to UX feedback but we can’t reproduce any incorrect commits like you describe here; I’m assuming you’re not using staging (or are using hg) therefore are looking to commit just the checked files. I’ve run through a bunch of tests with many files (modified, added and untracked) and have checked just some of these boxes, and every time the commit only takes the checked files with it.

      If you’re able to reproduce this on a test repo so we can take a look at it that would be appreciated. Please log a bug here if you can reproduce:

      • Al
        Posted May 6, 2014 at 9:48 am | Permalink

        Well I’m using BitBucket and committing what i always do. I checked 6 files (all PNG files) and at bottom of ST I added my commit text. Then I noticed my entire “Modified files..” UI was completely blank. I don’t know what triggered it. I was clicking the checkbox at the top a few times (on and off). Today after backing out all of the changes I started slowly and tried a few. But I suspect when in the modified files view I clicked – un-clicked the “Unstaged files” box a few times. I didn’t realize until today that it said “Unstaged files”. (Which looks like it epxands AFTER adding files for a proper commit later). I assumed it was just to globally check all of the files. The interface goes too fast. You click and un-click it assumes you want to stage files. They it starts “twirling….” like it’s in progress but it doesn’t stop and you had just un-clicked quickly. A little confusing right now. You should have had a feature to enable – disable the checkbox feature. I suspect it’s too late. I tried locating 1.8 but it’s gone. You still have it anywhere? I’m on Mac!

      • Al
        Posted May 6, 2014 at 10:16 am | Permalink

        Well I’m not sure what triggered it.

        I was in the untracked view and I did a few clicks of the ”
        Unstaged button” But it was in succession. Quickly clicking it.
        I then checked 6 files and did a commit. I know it was 6 in the “untracked” area because I constantly look. When I went back to my modified view all of my files were gone. And sure enough they were all on their way to BitBucket. I did not pay attention to the wording of “Unstage files”. I assumed, wrongly; that it was just to highlight all of the files (for a mass commit ). But after committing 6 files, I noticed that the “un-staged files” dropped down and was waiting for me to commit them. Didn’t realize that. I almost always work out of the modified or untracked. Never use any of the others except maybe as a curious look once in a while.

        When you click-un-click multiple times it looks like it’s assuming that you’re staging though I un-clicked quickly. Then the interface just “swirls” or looks like it’s in progress, when it’s not.

        On Mac.

      • Al
        Posted May 6, 2014 at 10:48 am | Permalink

        The other problem Steve is that “Staged drop down” never updates.
        So add a new file to index. Go to modified. You see one file in “Staged”. Then add 5 modified files to staging. Doesn’t update.
        Go back to untracked and then back to modified and now I see the correct number of files waiting for the commit

      • Dan Brown
        Posted May 7, 2014 at 5:03 am | Permalink

        I’ve had this several times in the year I’ve been using SourceTree and Git.

        I will stage some files but leave some unstaged. Commit, then find out that the staged files remained where they were and all the unstaged ones have been commited instead. Luckily I’ve caught it before pushing most of the time.

        It is due to having a folder in the unstaged files selected when clicking Commit. This seems to be a feature and sets the ‘commit mode’ dropdown in the commit dialog. However it is not consistent across folders as some with unstaged files cause it to happen but other don’t. Extremely annoying when it happens though.

      • Al
        Posted August 1, 2014 at 4:57 am | Permalink

        Works well now,

  • Anonymous
    Posted May 6, 2014 at 8:16 am | Permalink

    “We hope you like the new version of SourceTree as much as we do!”

    Sadly, no.

    I think it’s mostly been said, but the random moving checkbox dance really deserves special mention.

    Please put the crayons away, revert the staging pane and give us back the tool that we can actually use. I will happily pay money for a version based on 1.8.

  • mars
    Posted May 6, 2014 at 1:45 pm | Permalink

    buggy UI, worst update ever

  • mars
    Posted May 6, 2014 at 1:47 pm | Permalink

    why is “commit” greyed out and I have to UNCHECK-> CHECK-> click on branch -> click back to “working copy” to make this fking button clickable

  • mars
    Posted May 6, 2014 at 1:49 pm | Permalink

    I really don’t want to spam this but this update has been throwing bugs like 20 times a day.

  • badupdate
    Posted May 6, 2014 at 5:29 pm | Permalink

    this update makes me go back to command line git…..

  • Chris Byers
    Posted May 6, 2014 at 8:49 pm | Permalink

    I’m not usually big on change, but this new layout I could get used to, if the app worked at all. I now have crashed 5 times trying to simply stage my files. After the first crash, I opened it again and it had EVERYTHING selected for the staged area, so I lost about an hour of work staging one file at a time (I like to review the code very meticulously). Then I clicked the “Staged Files” checkbox thinking “Oh you must click this to uncheck it which will stop showing me staged files” WRONG, that unstages everything, brilliant UI design there guys. When I select “Pending”, I just want to see pending unstaged files that I didn’t click “Add to Index” an hour ago, but it’s just completely screwed up right now…I don’t want to see staged files at the top of the list either, don’t want to see them at all frankly in the same list. Why is that useful?

    Please provide a link to go back to a working version if that’s possible. Also, I don’t like the new diff on the right side, difficult to see where one stage hunk ends and the next begins. It was quite clear before. Although I do like the multi file selection. Another bug though is if I don’t wait for the right side to show up completely and right click on the left pane, the menu to Add to Index just does nothing.

  • Aaron
    Posted May 7, 2014 at 8:01 am | Permalink

    I’m adding my name to the list of users who have reverted to 1.8.1. The new UI is a big step backwards in functionality and usability.

    Committing directories is grossly inefficient without the Tree View.

    Filenames are no longer scannable.

    Files are accidentally staged because the list changes when clicking a checkbox.

    How in the world is checking “Unstaged files” to stage all files in the working copy considered a usability enhancement? This exemplifies bad UI design.

    I have recommended SourceTree to clients and colleagues and am now recommending that they stay with 1.8.1 or downgrade until Atlassian rectifies these blunders. I hope that I can continue to use SourceTree. It was truly a great product until the 1.9/1.9.1 release.

  • Posted May 7, 2014 at 8:30 am | Permalink

    Hate to jump on the bandwagon, but this update is just terrible. Is it pretty? Sure. Did it make me have to second guess what I committed and check it from the CLI? Yeap. I reverted back to 1.8.1 thanks to fellow commenters. Doing everything from the CLI is more productive than using 1.9 (which is what I ended up doing before finding the link for 1.8.1). Just trying to run a git log on something was impossible (seriously, I couldn’t even find a place to find the freaking files). It’s just bad.

  • applejack42
    Posted May 8, 2014 at 12:42 am | Permalink

    Removing the separate staging panel is a horrible idea. It was much clearer what has been staged and subsequently committed when it was in a separate panel. The enlarged padding also makes the interface take up too much space.

    I’ve reverted back to 1.8.1 for the time being.

  • Anonymous
    Posted May 8, 2014 at 2:10 am | Permalink

    So again, too many comments to reply to each individual but having reviewed the feedback, here’s what we’ll be doing over the next few weeks:

    * Adding an option to switch to a tree view

    * Adding the option to use a discrete split panel for staging instead of a fluid headered list (this will likely be mandatory for the tree view anyway)

    * Adding the option to use separate columns for filename & path in the flat view instead of one combined filename

    Thanks for all the feedback. While most commenters here won’t believe me, many people do like the new style but we acknowledge that a lot of existing users think we went too far and preferred the old approaches, so we’ll be bringing many of them back as view options. If you’re hating 1.9 in the mean time, you can still use 1.8 from here: – keep an eye on the updates to see when your preferred option returns.

    • barduck
      Posted May 8, 2014 at 3:21 am | Permalink

      Excellent news! Thank you very much for actually listening to user feedback.

      I can only image the arguments storm on your design meetings discussing these changes…

    • Anonymous
      Posted May 8, 2014 at 3:23 am | Permalink

      Wow, that is awesome. Thanks for listening to the feedback and for giving a clear outline of the actions you will take. SourceTree is close to gaining a new fan (haven’t been using it long enough yet 😉

    • Jordi Puigdellívol
      Posted May 8, 2014 at 8:39 am | Permalink


    • Joe
      Posted May 12, 2014 at 10:39 am | Permalink

      Thanks for listening! Looking forward to the tree view’s return, so I can go back to only complaining about the lack of it on Windows.

    • Jasmine
      Posted May 12, 2014 at 3:04 pm | Permalink

      Thank you for listening to us and bringing back the ability to work with the tree view :o)

    • Anonymous
      Posted May 13, 2014 at 2:50 am | Permalink

      The visual style I actually really like, it’s the lost functionality that has burned me.

      Massively impressed at how much you guys are reacting to our (admittedly over zealous) feedback!

      *thumbs up*

    • Paul
      Posted May 13, 2014 at 12:59 pm | Permalink

      So this is how to do things right. You’re listening to your users and you’re turning a negative into a positive. This is the kind of thing you do when you’re serious about wanting to make the best possible product.

      Just one question – will you consider bringing back drag and drop to stage/unstage files? I really miss that feature.


      • Anonymous
        Posted May 14, 2014 at 1:34 am | Permalink

        Yes, this is part of the option to use a discrete split panel for staging instead of the ‘fluid with headers’ mode; drag & drop will work in this mode. I’m working on it right now in fact 😉

        • Paul
          Posted May 14, 2014 at 2:03 am | Permalink

          Awesome! 😀

    • Stacy
      Posted May 13, 2014 at 3:32 pm | Permalink

      Yes, thanks for taking our feedback to heart! I do like the way commits work now, but I absolutely depend on the tree view because of similarly- and identically-named files in repositories located on rather long paths. I cannot work with the current view, so I’ll revert, but I do like the other changes.

    • Aaron
      Posted May 14, 2014 at 5:55 pm | Permalink

      Hurray! I only wish I saw this comment sooner.

    • Alexander Salnikov
      Posted May 23, 2014 at 4:43 am | Permalink

      Thanks for listening to our feedback.

      You’re on the right track, but for now I’ve reverted to 1.8.1.

    • Zaky Z
      Posted May 25, 2014 at 9:57 am | Permalink

      Just to add another voice – really missing the drag and drop here. The long file names are painful to the eyes as well. Thanks for reacting to feedback this way!

  • Adam
    Posted May 8, 2014 at 3:13 am | Permalink

    The new interface is really a step back. You keep scrolling up and down, more if you double click on the file xcode opens, if you double click on the check box then surprise, the next file gets added as well. Please roll it back ASAP. It’s extremely annoying, and slow to scroll. The previous interface was snappy, this one feels like it’s a html based.

  • Rob Gilbert
    Posted May 8, 2014 at 8:53 pm | Permalink

    Steve, as a developer myself, I understand that users are always going to be resistant to change – especially when it comes to UI. However I must say that I initially chose SourceTree (over Tower and others) based on the UI. It even dragged me away from the shell (which is how I only ever used git before Sourcetree)! Now with these changes I have to consider what my options are – of course I’ll give it a shot, but reverting to 1.8 is tempting.

    Another (even more trivial) criticism – the working copy view (which I spend a lot of the day staring at) seems sterile and hard to look at with the new fonts. When I look at the screen I wonder why I’m not looking at the output of “git status” in the terminal.

    One thing that I DO like about the new interface however is the staging process and commit message being in the same window (I always thought the second commit pane/sheet was unnecessary).

    Thanks for your hard work.

  • Pedro Hull
    Posted May 9, 2014 at 11:18 am | Permalink

    checkboxes? what’s it guys? i used to stage folders automatically, now i have to click thousands of times? veeery bad.

    at least i saw the edit: “[Edit] You can also use the spacebar to toggle the checkboxes for the current selection if you want to stage / unstage many files at once.”

    didn’t like this new stage way. still prefer the older. treeview, please!!!!! =////

  • disqus42
    Posted May 9, 2014 at 2:28 pm | Permalink

    Where did the Draft Commit Message feature go? I used this all the time.

    I am also going back to 1.8 for now.

    • Anonymous
      Posted May 12, 2014 at 2:23 am | Permalink

      Draft commit is still there – you just have to click on the commit pane, type a message, then press escape. Your message will be saved using the same mechanism as draft commit always did – there wasn’t any need for a separate feature for this any more.

  • Long Nguyen Tien
    Posted May 10, 2014 at 3:32 am | Permalink

    Where is my treeview?

  • Mike M
    Posted May 10, 2014 at 1:08 pm | Permalink

    I’ve had multiple commits in latest Mac version stall. For example, commit dialog just shows:

    git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree commit -q -F /var/folders/wc/c_n4qtqn36x45w9gh2y516mm0000gn/T/SourceTreeTemp.TXwh9l -a

    I have to kill ST and then start the commit. I’ve *never* had this issue before.

  • Anonymous
    Posted May 13, 2014 at 1:24 am | Permalink

    how can i see files in tree view now?

    • me
      Posted May 13, 2014 at 1:28 am | Permalink

      i rolled back

  • Anonymous
    Posted May 13, 2014 at 9:52 am | Permalink

    Dear god! You guys to borked the working copy view.

    It is almost unusable for large code bases. Not only is the UI awful, but it seems to be a lot more glitchy and slower.

  • Josh Freeman
    Posted May 14, 2014 at 3:05 am | Permalink

    I love the new updates, i know there are a few issues but for me they super minor, for example multiple file commits, i can just select a bunch and hit spacebar, and they staged. I find it super nice and better than before, I also like how commit is now in the app and not a popup, also makes it a lot nicer.

    Keep up the great work!

  • Anonymous
    Posted May 14, 2014 at 3:40 am | Permalink

    New commit experience: When you try to Stage lines and the button turns into Stage hunk right under your mouse, this is VERY VERY FSCKING FRUSTRATING.

    It’s about time you fix this pointless polling which resets all the selection I made. Be polite to your users!

    • Anonymous
      Posted May 14, 2014 at 3:52 am | Permalink

      We’re not polling, it’s an OS file event that triggers a refresh (you can disable auto-refresh); but yes, we should try to maintain the hunk selection in this case anyway. Will look at it when we review the new diff again soon.

  • ctismer
    Posted May 16, 2014 at 7:11 pm | Permalink

    SourceTree has been great on OS/X.

    Now, this version is gone and has the same UI as windows 🙁

    Where are the nice tree views gone?

    This is a major step backwards, INHO.

    cheers – Chris

  • Laurie
    Posted May 21, 2014 at 3:19 am | Permalink

    Use case: moved a folder full of files – initially recognised as deletions and additions AND you edited a few code files elsewhere (interspersed throughout the list now).

    In the past, not a problem, but I now have to click all of them individually so I can commit the moved files apart from the edited codes files. I used to use shift and cmd clicking to select ranges and individual files that could be then dragged into the staging area. Please bring this back. My finger can’t take that much clicking! I really like that sourcetree is actively developed, but this makes it much less usable.

  • cosmolux
    Posted May 22, 2014 at 1:46 pm | Permalink

    I’m fine with the new UI in general, but I have had to downgrade to 1.8.1 for a specific use case: Viewing the revision log for an arbitrary folder that does not contain pending changes. My text editor only supports logs for files, and I want to use a GUI. Is there a way to do this without using the missing tree view?

  • iHate iOS7
    Posted May 28, 2014 at 1:47 am | Permalink

    Eagerly awaiting 1.9.3 with hope that they’ve reverted many of the UI changes back to 1.8.

  • Richard
    Posted May 29, 2014 at 3:51 am | Permalink

    I still wish Sourcetree would remember it’s sidebar width

  • Martin
    Posted May 30, 2014 at 2:38 am | Permalink

    1.9.x only works with very small projects. Anyone working in a larger code base, with more than a few modifications per commit, will benefit from upgrading back to 1.8.1 (…).

  • whatthe?
    Posted June 19, 2014 at 7:33 pm | Permalink

    I agree with disqus505, click click click, just terrible. am trying to go back a version

  • Kayateia
    Posted July 6, 2014 at 9:34 pm | Permalink

    No good on the dropping 10.6 support. =_= Some of us can’t move up due to Apple’s gutting of Rosetta. (You guys probably want to update your download buttons to say 10.7 anyhow, as the ones on the main site still say 10.6.)

    • Anonymous
      Posted July 8, 2014 at 7:27 am | Permalink

      You can continue to use 1.8.x on 10.6 but Apple are making it increasingly impossible to support this version while using the latest dev tools, sorry. In fact, Apple tell developers to support ‘latest -1’, we go beyond that but can’t maintain old version support forever. If you’re on 10.6 you won’t be prompted to auto-update from 1.8, the update system is aware that you can’t update to 1.9+.

      All of our download buttons are updated except for the sidebar on the blog, which we’re working on.

  • Posted October 29, 2014 at 1:46 pm | Permalink

    Direct download link if you find this page looking for a way to revert from 2.0 =>

  • Laszlo Heredy
    Posted October 30, 2014 at 9:21 am | Permalink

    DO NOT DOWNLOAD! SourceTree has made development a nightmare.

    It is FAR better to delete my SmartGIT config files every 30 days than to deal with SourceTree’s destructive nonsense.

    Cherry picking? forget it.

    Forgot to change branches BEFORE you did your work? Or god forbid you worked on two separate issues without a care in the world? Well you’ll be working double time now. Unless… Best solution: STOP, download SmartGIT, HAMMERTIME. Otherwise, best solution SourceTree has is for you to manually copy all files you worked on to the desktop or something, and throw away all your working copy, then make branches one by one and commit each.

    Every merge ends up in endless “conflict resolution” when there are no conflicts. To SourceTree, a conflict is when the SAME FILE has been worked on. Edit line 1 and try to merge line 1020. Conflict. Then you know what else? Before you address the conflict, SourceTree puts in some nice non-compilable text
    And leaves it like that!!!!! HAHAHAHA

    Seriously! THIS WILL BE IN YOUR FILE!!

    Do NOT use this program. Please, please, do NOT.

    More keeps coming
    If you make enough changes… say you search/replace something with 100 occurrences. SourceTree will just give up and see your commit as ONE CHUNK — THE WHOLE FILE!!! YEAH!!!! Amazing. So amazing.

    Please do not touch this program. It's pretty and it will get you fired. Hit on the boss' secretary instead. At least you have a chance there. Use SmartGIT and continue to love programming.

    Feedback, complaining? I've faithfully fed back to Atlassian about scores of items, especially JIRA. Mobile JIRA.. oh god don't get me started. You can't even see linked issues in the mobile version, let alone edit comments. Then worse, their fancypants javascript makes it impossible to highlight text, and their Desktop Version cripples even the most capable mobile browser by scaling their useless floating menu bar OVER everything else, so you can't magnify 2x without covering your entire screen in five buttons. Horrifying. My company uses JIRA so there's no escaping this, unfortunately. However with SourceTree I have a choice thank all that is good, and I can't believe I've suffered through SourceTree as much as I have before running back to the plain-Jane SmartGIT that just works. GIT is BEAUTIFUL if you let it. SourceTree will kill your soul.

    This is more of an honest warning cry from behind enemy lines. It's a trap, do not seek passage. Retreat, fall back, go around.

  • El Presidente
    Posted December 9, 2014 at 3:24 pm | Permalink

    More checkbox BS in ST (2.0.3). Use checkboxes to check several untracked files. Then click on “Add”. Guess what? Only the one highlighted file is added. Checkboxes mean f*** all in this case. It’s highlighted files that are affected by the Add operation, not checkboxes. So WTF are checkboxes for? Oh yeah, commits, because according to end user feedback people found highlighting files in ST pre 1.9 confusing. Just one more inconsistency in SourceTree’s makeover for people that were never meant to be developers in the first place.