Live data from Hacker News

Show HN: Sublime Merge – A Git client from the makers of Sublime Text

sublimemerge.com

241–250 of 362 posts

Re: Show HN: Sublime Merge – A Git client from the makers of Sublime Text

#241
post #231
post #2

Hi HN - Jon Skinner here, I made Sublime Text and Sublime Merge, alongside the rest of the Sublime HQ programming team - Will, Dylan and Benjamin. Let me know if you have any questions! Edit: there's also the announcement blog post, at https://www.sublimetext.com/blog/articles/sublime-merge

Jon, if you're looking for ideas what to work on next, please consider creating an email client. With fast UI & search, tree view for emails, proper support of plain text emails etc.

That's definitely a brilliant idea. I wish Jon like this one.

Re: Show HN: Sublime Merge – A Git client from the makers of Sublime Text

#242
post #228

I use SourceTree almost solely for its "Split View Staging" feature, where a line or hunk can be moved between the two states and the entire bit you're about to commit can be viewed independently of other working copy changes. Fits my mental model so well , but is apparently considered too complicated for most other git clients such as GitHub Desktop and Tower. From the animation, Sublime Merge seems to have Staged/U…

I've been pretty happy with SourceTree, despite a few minor annoyances. What missing features are you thinking of?

Re: Show HN: Sublime Merge – A Git client from the makers of Sublime Text

#243

Earlier quoted context omitted.

Presumably as time goes on it will become more and more integrated with Sublime Text, which is arguably a "very good editor". Or is that not what you mean?

Then it would presumably have been a feature of Sublime Text, rather than a standalone application?

Well, when I say "integrated with ST", I mean they will be integrated with each other.

That way, I can be a power user of Sublime Merge while only using ST occasionally (because I'm more of a vim user), or vice versa (because I'm more of a magit user). Or you can be a power user of both.

I think it makes sense in this case to have two applications. I personally am an avid user of ST, but I generally prefer the command line for git. However, there are some things that it's nice to have a GUI for when git'ing, so this is ideal for me.

Re: Show HN: Sublime Merge – A Git client from the makers of Sublime Text

#245
This looks pretty good! Maybe this is a good time to air some complaints about all of these Git UIs.

The approach of every single Git app that I've encountered is to present the history as the entry point to working with a project. Maybe I'm a weirdo, but that's not how I primarily work with git, and while having such a history view is critical, I'd like a tool that actually doesn't do that as its main mode of operation.

Instead, I'd like a tool that has a file-oriented approach. Which is to say that it should show uncommitted changes as a file tree browser that either shows the entire tree (with icons, colours or whatever to indicate what is changed) or the subset which has changed. This should be a tree browser where you can click on a single file to view its diff.

The other thing that these Git apps do badly is diff display. Sublime Merge can be forgiven for doing a simple colourized vertical view in its first public release, but other tools can't. The best diff browser I've seen is Eclipse (which I haven't used in a decade, but still miss at times), which coincidentally implements the same UI metaphor. Take a look at this screenshot:

https://i.ytimg.com/vi/-Jdu__jEnFw/maxresdefault.jpg

Note the left pane, which is the file tree. It's only showing changes.

Note the top right panel, which shows a semantic change tree of your file. If Eclipse understands the structure of your file, then it can show the changes by class, method and so on. It's really nice.

Thirdly, note the diff view, which is a side-by-side view which is visually really good at correlating blocks of changes. Many side-by-side differs will keep the two views vertically synchronized by inserting blank space. Not Eclipse! There's no blank space; instead, Eclipse uses the Bezier lines to indicate which block on the left side corresponds to the block on the right side, and these lines are updated as you scroll. Here's a video from someone using the UI:

https://youtu.be/KfeqnernMmE?t=807

Eclipse isn't/wasn't a beautiful app, but it nails the diff view.

The important thing is that you don't get the entire project diff in a single view, which is what Sublime Merge does if you go into either the "unstaged files" panel or a commit, but you get a concise file overview, and only see the diff for one file at a time. Doing it the way I describe above doesn't preclude being able to see the diff for a whole tree in a single pane, but it shouldn't be the default.

Re: Show HN: Sublime Merge – A Git client from the makers of Sublime Text

#246

I've been using Tower but I may switch to this since Tower switched to a subscription model and I'm a fan of Sublime Text.

I feel the same. This is a better fit for me anyway. Tower seems to have doubled down on the "non-developer" type. I am perfectly happy to use git on CLI, but a visual interface for selective staging and merge conflicts makes things easier. This seems to really fit the workflow for keyboard power users (cmd+p menu, etc)

Re: Show HN: Sublime Merge – A Git client from the makers of Sublime Text

#247
post #231
post #2

Hi HN - Jon Skinner here, I made Sublime Text and Sublime Merge, alongside the rest of the Sublime HQ programming team - Will, Dylan and Benjamin. Let me know if you have any questions! Edit: there's also the announcement blog post, at https://www.sublimetext.com/blog/articles/sublime-merge

Jon, if you're looking for ideas what to work on next, please consider creating an email client. With fast UI & search, tree view for emails, proper support of plain text emails etc.

This is one of those things that I didn't know I needed. An email client made for power users with the speed, simplicity and flexibility of Sublime Text (and now Merge) would be the end of all of my email woes. I would pay a lot of money for this.

Re: Show HN: Sublime Merge – A Git client from the makers of Sublime Text

#248

Earlier quoted context omitted.

Alas, one of our key principles is to not hide or rename anything in Git, so your knowledge from using Git on the command line transfers to and from Sublime Merge.

Fair enough, maybe think of this as an optional feature for the future :) you must be really good with git but most people need to google how to do something everytime they want to do something more complicated then a merge

Personally, I believe letting every UI or toolchain compatible with git settle on their own phraseology for identical operations will lead to more issues than we currently have. Git is definitely complex, flags unclear, and commands awkward from time to time. Now, imagine trying to figure out the meaning of commands when they don't even translate equivalently across tooling? Sounds like a nightmare to me. I appreciate the effort to stay consistent with git itself.

Re: Show HN: Sublime Merge – A Git client from the makers of Sublime Text

#250
post #13

Earlier quoted context omitted.

Well, for one, GitKraken is Electron while the Sublime tools are native C++. So I’d expect faster performance.

I remember something about Sublime being written in Python? Also I'm more curious about the feature set. The performance argument can be made again for Sublime vs VSCode. Doesn't matter to me because I've switched from Sublime to VSCode a long time ago. I care about features the most, not if the app will open in 0.5s or 3s

> I remember something about Sublime being written in Python?

SublimeText is written in C++ with the "Skia Graphics Library" for the UI.

It exposes an Python API to extend the functionality via 3rd-party packages.

> I care about features the most, not if the app will open in 0.5s or 3s

Opening is not the only performance gain you will get for using a software written with native libraries.

You get faster overall operations in comparison with a program like GitKraken that needs to allocate several chunks of memory to execute simple tasks. It always baffles me when people use the startup time of a program as a mean to explain why they prefer using it over others. Electron-based applications are —overall— not performant. It's impossible to get good performance out of Electron because it sits on top of a web browser that is known to hug significant amount of memory from your entire system.

Post reply on HN