101–110 of 362 posts
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
Looks great! Is there any roadmap somewhere so we know what to expect in the future?
Looks great! I was using Fork before, but prefer the clean UI of Sublime Merge so far. Here's how to create a shortcut to the smerge command (Mac), which I didn't see documented anywhere: ln -s "/Applications/Sublime Merge.app/Contents/SharedSupport/bin/smerge" /usr/local/bin/smerge
"Conflicts are presented with a 3-pane view. On the left are your changes and on the right are theirs. In the center pane is the resolved text" They are missing a pane then. A 3-way merge involves your changes, others changes, a common ancestor, and the resolved text. kdiff3, Beyond Compare, and very recent versions of emacs are the only tools that I've seen that present this properly.
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
"Conflicts are presented with a 3-pane view. On the left are your changes and on the right are theirs. In the center pane is the resolved text" They are missing a pane then. A 3-way merge involves your changes, others changes, a common ancestor, and the resolved text. kdiff3, Beyond Compare, and very recent versions of emacs are the only tools that I've seen that present this properly.
Earlier quoted context omitted.
It'd be nice if there was a command line option for this actually. I have my machine setup almost entirely automated, but this is one of the manual steps I have to do.
As far as I know, it used to be just a matter of writing the plaintext license into the appropriate file: https://forum.sublimetext.com/t/license-installation-silentl...
"Conflicts are presented with a 3-pane view. On the left are your changes and on the right are theirs. In the center pane is the resolved text" They are missing a pane then. A 3-way merge involves your changes, others changes, a common ancestor, and the resolved text. kdiff3, Beyond Compare, and very recent versions of emacs are the only tools that I've seen that present this properly.
That's true, but is it important to have all those things visible when you're resolving a conflict? The design of a UI should be driven by what the user needs to see, not the data that's being used. Most apps have absolutely loads of invisible data in the background making things work; that doesn't mean they need to be front and centre in the UI.
In my experience of resolving conflicts I can't remember a time when I've needed to refer to the common ancestor, so do I really want to give it screen space?
Hi Jon, On windows it treats .gitignore patterns as case-sensitive which differs from how git itself behaves.
Looks great! I was using Fork before, but prefer the clean UI of Sublime Merge so far. Here's how to create a shortcut to the smerge command (Mac), which I didn't see documented anywhere: ln -s "/Applications/Sublime Merge.app/Contents/SharedSupport/bin/smerge" /usr/local/bin/smerge
You could cut out the middleman by adding "/Applications/Sublime Merge.app/Contents/SharedSupport/bin" to your PATH.