Uploaded image for project: 'Sourcetree For Mac'
  1. Sourcetree For Mac
  2. SRCTREE-7340

Stashed area in Sourcetree

    XMLWordPrintable

Details

    • Suggestion
    • Resolution: Unresolved
    • None
    • Git
    • None
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

    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? 

      Attachments

        Activity

          People

            Unassigned Unassigned
            59dcd2521832 Sergei Kulagin
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated: