Details
-
Suggestion
-
Resolution: Unresolved
-
None
-
None
Description
I have a nice feature in mind to speed up the work and make commits faster and of better quality.
So I'm working on projects and do different edits to different files. Then I'd like to commit these changes in small isolated commits that do changes to different parts of the application. Some of it described in this article https://about.gitlab.com/blog/2018/06/07/keeping-git-commit-history-clean/: https://i.imgur.com/egkbdkA.png:
I would like to make atomic commits in which project builds. So if I edit 2 classes and second class uses changes in class #1, but class #1 doesn't use changes in any other classes, I'd like to first commit class #1 and then class #2. Or maybe both of them at the same time if they're a part of the same part of the application.
The thing is that testing if project builds and works as intended only with these small changes is challenging and error prone: it requires time, many manual atomic actions and requires one to do everything exactly right and in the exact order. One bad mistake and you lost all of your uncommited changes.
So what can I do right now to see if everything works after I change only class1 that doesn't use changes in other classes? Suppose I have a working tree with unstaged changes. So I stage class1. Then I commit it. Then I stash everything else, as described in this answer https://stackoverflow.com/a/34681302/6693304:
If it builds and works, good. What if it doesn't? I have to amend commit, reset to head to it shows the staged changes from the amended commit and pop the stash. Then I add something else to the staging area, commit staged changes(class1 and some other changes I added after applying the stash). Then I stash all unstaged and untracked files again and test if it works again.
That's a lot of work just to test if it builds and works.
I made a sketch of how it would look like with the Stashing area in Sourcetree:
Not the minus signs next to plus signs.
After removing files from the working tree to the stashing area(files wouldn't be in the working tree and you could test your project with only the changes in the working tree), the interface would look like this:
It would be as easy as moving them from unstaged to staged with git add, except the command would be something like git add --stash fileName.
It would be as easy as clicking on the minus sign in the Sourcetree, just as easy as to click on the plus sign to add to the staged area.
And it would be possible to do all that with hunks as well: stash hunks, unstash hunks. This isn't possible now, you can only apply the whole stash.
I think this would allow us to make commits of better quality and much faster than it is possible right now with all the manual work required.
What do you guys think?