In GitHub Desktop there was no concept of staging files like there is in Sublime Merge and honestly I’m not finding it helpful 90% of the time. Can I disable this interactive staging process in Sublime Merge so it behaves more like GitHub Desktop?
Interactive staging
facelessuser
#2
This was probably one of the things that got on my nerves about GitHub Desktop. I much prefer explicitly staging a new file, or the ability to avoid staging a change in a specific file that is not relevant for my current commit. I guess I may have found the GitHub “auto-staging” less annoying if there had been an easy way to explicitly un-stage a file.
Obviously, there are fans of GitHub Desktop, so I get that some people might desire the more, stripped down approach of GitHub Desktop. It omits a number of features in favor of ease of use, which makes sense as it easier to pick up for inexperienced git users, but still provides common functionality for experienced users. Advanced users can always go to the command line or use something else if their needs require it.
On the other hand, I’ve tried some git tools that I found were overly complicated in their interface.
For me, I think Sublime Merge strikes a good balance offering the advanced functionality while keeping things pretty easy.
I’m not sure if the Sublime team would entertain the idea of introducing an auto-staging mode for Merge, but you could create an issue here: https://github.com/sublimehq/sublime_merge. This is probably the more appropriate way to make a suggestion for a feature.
Personally, I like the way Merge handles staging, but I get that everyone has different wants/needs.
3 Likes
jps
#3
Sublime Merge tries hard to keep the same workflow and terminology as Git itself. Git has a notion of staging files, therefore Sublime Merge does to.
While there are advantages to trying to present a different workflow to Git (such as removing the notion of staging), I think in the long term it doesn’t do anyone any favors, as users end up learning the UI, rather than learning core Git concepts. I think that if a users mental model of how Git works differs from how Git actually works, then when they step outside of the common stage/commit/review/push commands, e.g., needing to reset a branch, they’ll quickly run into difficulty.
8 Likes
tajmone
#5
In GitHub Desktop there was no concept of staging files like there is in Sublime Merge
I haven’t used GitHub Desktop, so I’m curious about this and not quite sure how it works. How would you handle hunks in GitHub Desktop? is it possible, for example, to only commit part of the changes?
@jps,
Sublime Merge tries hard to keep the same workflow and terminology as Git itself. Git has a notion of staging files, therefore Sublime Merge does to.
While there are advantages to trying to present a different workflow to Git (such as removing the notion of staging), I think in the long term it doesn’t do anyone any favors, as users end up learning the UI, rather than learning core Git concepts.
While this makes sense and might hold true for many SM users, I don’t see why what @genericptr is asking for shouldn’t be achievable via SM packages. I think that in this respect there a general expectation that SM (being the sibling of ST) will eventually open up to a wide variety of user customizations, just like with ST.
I haven’t really understood what is the roadmap for SM regarding extensibility. Will SM eventually become highly customizable via packages? or will extensibility be limited to look and feel theming and some basic Git setting, keybindings, etc.?
I admit that I was holding some rather high expections in terms of how customizable SM was going to be — expectations which haven’t been so far met, but being SM still in its early infancy I thought it might be just an issue of priorities. But from reading the above reply I’m not getting an impression that similar things will be achievable via customization, it sounds more like a rigid frameset is being established for SM behavior.
0 Likes
facelessuser
#6
Yeah, you can selectively unstage hunks, or maybe tell it to not stage those hunks when you hit the commit button. I don’t know if it actually stages until you hit commit. I think it just visuallizes all changes that aren’t ignored, and then stages and commits them when you commit, but I could be wrong. As far as unstaging hunks, I think in GitHub Desktop you had to un-select the lines in the gutter.
Assuming they implement a plugin system, it may very well be possible. I would be really surprised if the extensible features available to the plugin system allows changes to the GUI. But this specific case, a plugin could possibly just auto stage everything, including untracked files that are not ignored. I don’t think it would allow you to remove the unstage buttons, just automate the staging.
I have to be honest though, when it comes to a SM plugin system, keybindings for special commands and such is probably all I need. I don’t think I personally really need anything above and beyond that like I do in my editor, maybe I just haven’t considered the possibilities outside of the box I use SM in 
.
0 Likes
genericptr
#7
I guess I’m not a very advanced user because I’ve never used hunks before and I even got away without staging until now. Maybe GitHub Desktop decided to only implement the features that 90% of users use and left out the more advanced ones. Sublime Merge for example included squishing commits (a feature I really wanted) that GitHub Desktop didn’t even have at all.
0 Likes
srbs
#8
The roadmap has plugin support listed, just not very high (at the time). The question still remains on how flexible and what integration points will exist.
Now that ST 3.2 is out and the issues that came from it are (hopefully) mostly fixed, I’m hoping the Sublime Merge API can get some attention along with other issues SM has.
1 Like
tajmone
#9
I have to be honest though, when it comes to a SM plugin system, keybindings for special commands and such is probably all I need. I don’t think I personally really need anything above and beyond that like I do in my editor, maybe I just haven’t considered the possibilities outside of the box I use SM in
For example, I encountered some problems working with ISO-88591-1 files, where Git doesn’t seem to have explicit settings for this encondig.
So, it would be nice if custom SM extensions could be used to implement some custom chores before and after trying to commit, or other operations.
Git already offers advanced options and settings to allow custom scripts to be run before or after certain operations — and similar tasks could be automated directly in ST anyhow. But chances are that SM extensions could be more practical to use, especially on Windows, without affecting a repository settings (not even locally).
Other applications might envolve automating interactions with GitHub API and other tools. Again, SM could provide a more user-friendly experience here, and in case of collaborative projects end users would only have to install a given package to replicate the same workflow regardless of the OS.
The roadmap 3 has plugin support listed, just not very high (at the time). The question still remains on how flexible and what integration points will exist.
Thanks for the Roadmap link! (wasn’t aware of it)
Regarding SM extensibility, I was hoping that Sublime HQ was going to surprise me again with new creative approaches — after all, what they did with ST is quite impressive in terms of how extensibility was conceived in a flexible manner. But I agree, it’s not a simple issue like for ST.
User definable macros could be a good place to start, to allow opening a Git shell and running a series of commands using parameters subistutions in the macros, so that common operations could be handled via reusable macros.
As for Git Flow Integration, this is an example of something that should implementable via custom packages, for there are alternative workflows to Git Flow — not everybody in the Git community agrees with the Git Flow filosophy, but indeed the whole idea of having some established work scheme is valid, and there are different solutions to this common need.
I’m not sure if it’s even doable, but if SM was to expose an API that allows implementing Git Flow as a package it would be really good. I guess this would require some thorough thinking through, but again … if the Sublime HQ team can’t do it, who can? 
Maybe GitHub Desktop decided to only implement the features that 90% of users use and left out the more advanced ones. Sublime Merge for example included squishing commits (a feature I really wanted) that GitHub Desktop didn’t even have at all.
I remember using the first version of GitHub Desktop, which was later rewritten from scratch (and I haven’t used the newer one). From what I remember, it’s an excellent tool, but (as you said) it was conceived to cover the most common uses that the majority of GitHub users would expect to use — for everything else, there’s the command line Git interface.
I guess I’m not a very advanced user because I’ve never used hunks before and I even got away without staging until now.
I personally use file and hunk staging a lot, especially during the pre-commit work phases. For example, let’s say I have a script that automates modifying/creating many project files (e.g. produce HTML docs), and I want to run a test-execution of the script and be able to quickly discard it. If I stage my manually edited files before running the script, I’ll then be able to quickly discard all the files created by the script via SM interface, because changed and staged files are handled separately in the interface, so using the dicard all button in the working area is safe.
Hunks are quite useful, and I like the way SM allows you to keep track of them and control their staging. I use that a lot when I need to quickly revert code/documentation changes that I decide to discard. Knowing that this feature is there in SM, and quick to access, influences the way I work on code, because I always edit knowing that SM will show me a nice diff of the document before and after my changes, and provide a quick way to rollback single chunks of edited code/text. Hunk staging allows a further layer of “undoability”, because you can then compare the current edits with both the original code/text AND the staged changes.
Ultimately, these are all features that can be exploited to improve your local workflow and be more productive.
0 Likes
srbs
#10
This is kind of supported through branch/commit menus & git aliases as seen here. It’s not ideal by any means, but it is a viable workaround for most cases (since you can’t use the command palette to handle choosing a branch/tag/etc).
Git Flow is already supported, starting with the command Git Flow: Initialize & has support for common operations.
0 Likes