Desktop: Feature request: Stashing changes when switching branches or "magic stashing"

[lameyer]

Continuation of https://github.com/desktop/desktop/issues/245, where it was decided to not automatically stash changes when switching branches for now.

I find "magic stashing" to be one of the most useful features of the previous desktop app. It enables you to think less about managing git, especially when switching between multiple feature branches. It also makes getting started with git easier and more approachable for a new user.

The option to stash when switching branches would be a good alternative, if "magic stashing" confuses users. I often make changes while testing or debugging that I don't want to commit but that I want to keep when switching to another feature branch. Having to go to the command line for stashing is inconvenient and lowers the usefulness of the Desktop app.

[niik]

Thanks for opening this @lameyer. I'll just note for anyone coming here that a fairly common pattern for people who used the old app on Windows (where we didn't have magic stashing) was to commit everything with a commit summary of wip or something similar and then, when returning to the branch, simply undo the latest change. This flow still works in the new application and may be used as a workaround as this issue is discussed.

Here's a quick demo

[ebrearley]

A temporary wip commit is fine as long as my changes aren't super out there and causing issues with linting and/or tests which can be run from the pre-commit hook (on repo's with this configured).

Thanks for the great tip though!

[beauallison]

+1 with @ebrearley - pre-commit hooks make this difficult and I often resort to stashing through the CLI - would love this functionality returned.

[niik]

A temporary wip commit is fine as long as my changes aren't super out there and causing issues with linting and/or tests which can be run from the pre-commit hook (on repo's with this configured).

I hadn't considered hooks. That's certainly a scenario where that flow breaks down. Thank you @ebrearley and @beauallison for that perspective!

[fallanic]

Totally agree with @lameyer , magic stash and the ability to easily select lines to commit in a file are the two killer features which made me switch from command line to the desktop app.

I also agree about at least making the option available somewhere in the settings, but I still personally think it's better to enable it by default.
Just an idea : if it's confusing some users, why not try adding a small message explaining the magic stash happened, and changes will be "stashed pop" on next checkout of the branch?

The workaround can work in some cases but it's a bit tedious.
Also I was wondering, how long do the "commited just now / Undo" message and button stay for?

Edit : and BTW great job on the beta, the new UI looks pretty cool, and so far it's super stable, not so common for betas 👏

[joshaber]

Thanks for the suggestion!

This idea is interesting for the future, but this is beyond the scope of our current roadmap.

I'm going to add the future-proposal label to this issue and close it out, so that we don't get overwhelmed with our backlog! We'll revisit these as part of our next planning session.

[fallanic]

Well it looks like it is on the roadmap already, first and 3rd bullet Feature completeand Replaces existing Desktop apps :trollface:

Just kidding 🙂 (kind of) but it's too bad the feature was removed, especially if "not many" people where complaining about it (according to https://github.com/desktop/desktop/issues/245 ).

I understand how it could confuse some users without a clear message explaining what just happened, but a handful of people sending emails to support shouldn't outweigh many people who love a feature hence don't contact support.

I hope the feature comes back in the near future, and kudos again on a great beta 👍

[j-f1]

@fallanic It wasn’t removed per se — they removed all of the features by starting over with a completely new codebase.

[fallanic]

I meant "dropped" sorry

[Tywholland]

Just wanted to add that I also really miss this feature, I had been using the old desktop client for so long that I thought this was just how git behaved! I agree this is probably best as a setting too.

If there's a better way to track general interest for a future proposal other than just leaving a comment like this let me know. I didn't see a way to star or +1 it.

[threadhead]

Hate to "me too" this, but I really, really miss this feature. I am typically working on 3-12 branches at any one time and need to quickly switch between. I may switch back to the old Mac version just for this feature alone.

[adamreisnz]

I'd also really like to see this put on the roadmap again. It's what made the previous app great -- being able to switch branches without thinking or worrying about your wip files.

Now, I'm being nagged by a popup and have to go to the CLI and type commands, which takes me out of my work flow and unnecessarily wastes time.

The wip commit, while maybe a good work around for some cases, is like others pointed out a problem if:

• you are using deploy hooks,
• others rely on a stable branch to work on,
• you want a clean commit history.

[PascalPixel]

@joshaber This is the reason I use Github Desktop, I was surprised today that it's not in the new version (or any other way to stash)

[danyriv]

How many voted does this request need to make it to the roadmap? I really, really miss this feature. It definitely slows down the dev process when having to do fake commits to switch between branches.

[shamimmirzai]

Please add auto-stash. I've moved back to the old github desktop now. Well and truly, auto-stash was the killer feature that we loved about github desktop - please add it.

[PascalPixel]

• Right now there is a popup saying 'stash changes first'
• In the Tower git client, this same popup offers options:
  
  
  
  • Stash changes now (input title)
  
  
  • don't stash (moving the changes to the other branch)
  
  

This approach notifies the user that they are committing an act of treason against Git, yet offers a way out that isn't so blocking as it is now..

[fregante]

@Superpencil yeah explicit options are even better:

• stash
• keep
• discard (I do this a lot)

[Mlocik97-issues]

I really need this feature so much... I am considering to download gitkraken

[Xotabu4]

Miss auto-stash so much. This simplifies teaching new guys how to work with git.

[northamerican]

When creating a new branch from master, GitHub Desktop also used to switch and 'carry over' your unstaged changes to the new branch. This and the auto-stashing paradigm it had were killer features. It's pretty much _the_ use case for git stashing, all automated.

[fregante]

@northamerican the first feature you describe is still there, the changes are always carried over when switching, except when they conflict.

[northamerican]

@bfred-it ah i see! it's equally brilliant. saves a stage, stash, checkout, stash apply all in one go.

[shoes22]

+1 for re-implementing magic stashing, or at the very least an option pop-up with the feature. My entire team has been using the old Github Desktop program for Mac, and we have become quite reliant on the feature in our workflow. It's not feasible to integrate the new version of Github Desktop into our current set-up without it.

[kparkov]

I am currently doing a programming course, and trying to avoid making it a git course. The only client easy enough to use to keep git out of focus is GD. However, as each student have a branch that they can use for saving their exercise solutions, it becomes very awkward when they have made changes while on master, and cannot switch to their own branch. The commit/undo routine is just weird when trying to keep it simple. Magic stashing would be a great relief here.

[fsaenger]

Really need this feature! (Stashing in general would be awesome)

I constantly switch back to SourceTree, while I'd prefer to stay in GD's clean interface.

[callumlocke]

I'm confused by the team's position on this. What does it mean to label it as future-proposal and then close the issue without putting it on the roadmap? If it's a "maybe one day but not now" situation, how long should we wait before requesting it again?

FWIW this feature represented 50% of the value of GitHub Desktop for me (the other 50% being the ability to deselect lines when committing).

[adamreisnz]

I feel the same way, this issue is generating quite a large interest from many people, and I feel such issues warrant to be kept open and brought forward on the roadmap to improve visibility and status on them.

I get it that the team doesn't want to get overwhelmed with issues, but it's easy to forget and ignore issues once they've been closed and I think it makes more sense to keep at least high value future proposals open, to avoid confusion in the community, as closing issues that are being considered is not common practice on Github (ironic, no? 😄 )

Speaking of the roadmap, I am aware that there are bi-annual meetings of the team to discuss this roadmap. Is there a way for the community to excert any influence on this, or does the team pick whatever interests it?

I think that for example code highlighting in the diff (which has been a main focus of the last few updates it seems) is just a gimmick compared to this must-have and often requested feature, so not sure how that got prioritised so highly on the roadmap.

[fregante]

it's easy to forget and ignore issues once they've been closed

They use the future-proposal label exactly for that. Closed but not forgotten.

[adamreisnz]

I'm aware of the label, but closed issues don't encourage much community interaction, and when new people arrive at this repo looking for issues like these they will tend to look into open issues rather than closed ones, assuming they'd be sitting in the backlog as they haven't been completed yet. Hence the frequent duplicates issues that appear as well, not just for this feature but also for example for organising repo's by org.

[j-f1]

I think that for example code highlighting in the diff (which has been a main focus of the last few updates it seems) is just a gimmick compared to this must-have and often requested feature, so not sure how that got prioritised so highly on the roadmap.

Most of the languages have added to the syntax highlighter by users.

[shiftkey]

Hey all, just wanted to add some context from our side about "magic stashing" and why we haven't prioritised it yet.

With the Desktop Electron work, we've taken time reflect on features in the classic apps that were problematic and see whether we can achieve the same result differently. The Sync button is a great example of that. You can read about the different direction we took it in.

The reasons for this change were lessons we learned from the classic apps:

• "Sync" introduced new terminology to hide away the underlying work that we did to update a repository, which confused some users
• when "Sync" failed, people like to Google for this word which didn't lead them to good support resources
• over time "Sync" accrued a lot of additional maintenance work to try and handle various corner cases

There is a request to bring this back, which we will follow up with separately, but for now we're really happy with how the new contextual button turned out - it's closer to that balance between familiar Git concepts and being intuitive to users not familiar with Git (even if it's no longer a one-click experience).

Magic stashing is a similar feature to the Sync button in many ways, but we didn't really address the details in the same way in the original issue #245.

We didn't put "magic stashing" on our roadmap for 1.0 because of our focus on implementing the baseline for both macOS and Windows - and it wasn't implemented on Windows. We also didn't talk about the underlying implementation of "magic stashing" and the problems as we saw it.

I went digging through the history to find the various ways the original "magic stashing" implementation has affected users. Here's a non-exhaustive list:

• "Magic stashing didn't restore uncommitted changes after syncing"
• "Magic stashing can fail to restore changes with no indication that they still exist"
• "Magic stashing may delete ignored files"
• "Magic stashing fails if untracked files conflict"
• "Magic stashing information will be lost if a repository moves on disk"

So while we know this is a beloved feature for many, we have some reservations about revisiting this in it's current form:

• we always strive to preserve your repository data - you're trusting us with your work, and that's a big responsibility. Features like this that touch working directory changes can be risky if not thought through and battle-tested.
• this feature often required human support help to recover from - if we revisit this, the experience needs to be approachable by user who aren't necessarily familiar with Git concepts when things fail.
• starting fresh with a new "magic stashing" implementation would mean revisiting all these corner cases again.

We'll talk more as a team this week about this and other proposals as part of our roadmapping session and report back soon!

[callumlocke]

Thanks @shiftkey for explaining. I can see the issues with restoring it exactly as it was.

Personally I would be happy with doing a wip commit and then doing "Undo" later, which would achieve the same thing as magic stashing but more consciously, less magic, which is good.

But that's not feasible if you have a pre-commit hook that rejects your commit due to broken code (which is frequently the case with a WIP) or some kind of post-commit deploy/reporting hook (also not desirable for a WIP).

I guess this could all be solved if it was possible to do a --no-verify commit from within the app. This could be as simple as a checkbox labelled "Skip hooks" next to the Commit button.

Adding a "Skip hooks" checkbox would have other benefits too, like when using line selection to do a series of partial commits, you often don't want to run slow hooks on every commit.

[paulbruneau]

I didn't know about this new version until I changed jobs and downloaded the new version last week. The old version said "I'm up to date" all along and never told me it was going to go away so I was living in stupid bliss. (How should I have heard about this new version?)

This week I have been kind of hating the new version because it didn't have the animated branch view that I loved and just today I learned it doesn't have Magic Stash (WTF?) so I found the old version on the web (223) and I'm just going to pretend the new version doesn't exist.

Sorry to be that old cranky guy who hates the new thing (I've been on the other side of that many times) but I feel good that at least I'm letting you know why I won't be using the new version until I'm forced to by some reason.

[j-f1]

Have you seen @shiftkey’s comment above about why we haven’t brought back magic stashing? Also, check out #1634 for our issue tracking a history graph.

How should I have heard about this new version?

Once we release 1.1, we’re going to add a popup banner in the old app indicating that it’s deprecated and that you should update to this version.

[paulbruneau]

Hi, thank you, I did see the post with reasons, but those reasons didn’t lessen my desire to keep using something I have found to be so useful over the last several years.

[shiftkey]

@paulbruneau thanks for the feedback

The old version said "I'm up to date" all along and never told me it was going to go away so I was living in stupid bliss. (How should I have heard about this new version?)

We haven't forgotten this - we're tracking it in #2146.

[adamreisnz]

@paulbruneau I've been in exactly the same spot as you, and at first I uninstalled the new version and went back to using the old one as well. But then I came back to it and got used to it, now I wouldn't want to switch back.

I can highly recommend you give it a try for a week or so. It's a lot faster and works more efficiently, in particular switching branches and pushing/pulling is a lot quicker.

The lack of magic stashing was a bit of a pain, but it's not the end of the world not having it, as my console is always open anyway.

[jmonrove]

I have been using the new version for about a month or so and I find myself manually stashing stuff. I tried to live without it, but couldn't. I think about moving to the old app daily.

[AshleyB-Tapjoy]

Having to constantly go back to the command-line to stash my changes when switching branches is quite frustrating. I frequently have to switch between our master branch and my working branches so I can compare the way the code executes. I almost never want changes in one branch to be applied to my other branches. The Magic Stash feature really helped streamline this workflow for me.

@joshaber @shiftkey: I understand there were specific use-cases where Magic Stash proved to be problematic. Wouldn't turning it into an option in the settings satisfy both groups of users? It seems like a lot of users were reliant on it, and it's frustrating there is no plan to bring it back.

If you can't give us Magic Stash - can you at least give us a UI-based stash option? I feel like that's the bare minimum feature support that is required. It is really weird that I have to constantly use a CLI to make your GUI application work.

[bschaeublin]

@joshaber @shiftkey:
Sorry, for the bump, but all referenced issues lead to this ticket. And this one is closed, but no offical statement for any future plans - the feature is missing in the actual roadmap too.

In my opinion a "manual" stash option should necessarily be provided by github desktop.

It is a pleasure to work with GD but I have to switch to sourcetree for stashing changes, when gd can not accomplish the situation with 'Magic Stash'. This and the lack of providing an actual "git-flow" interface leads me to always to make use of the fallback.

[adamreisnz]

Having a manual stash option (even in the warning dialog that appears when trying to switch branches) would be neat. It seems like a decent compromise between no stashing and magic stashing.

Currently, in our work flow, the two things I most frequently need to switch back to command line for are usually stashing and cherry picking. If they could be incorporated in the UI that'd be great.

[pingchen114]

This is really not cool to remove the stash feature like that. If I want to use this desktop client, then it should at least fulfill my basic requirements. And by dropping this feature completely, it literally forcing me to use CLI or other client to access GitHub. Maybe you can at least add a manual stash feature for this GitHub client.

[shiftkey]

@bschaeublin @adamreisnz @pingchen114 apologies for missing the pings on this.

And this one is closed, but no offical statement for any future plans - the feature is missing in the actual roadmap too.

We're only planning the roadmap for the next six months, and that roadmap is just things that the core team is working on. The priority for this feature hasn't changed, and my concerns about the implementation still stand.

I also believe that any stash feature needs to rely on conflict resolution for when stashes can't be applied cleanly. We've prioritized some work around this for upcoming releases as part of tackling merge conflicts in the app, so this will help with any potential stash feature.

If someone wants to see this feature in the app sooner than that, I'd like them to get involved and champion this feature.

What sort of things am I looking for?

• Sell everyone on the vision of how this feature would work - pictures, workflows, details, etc
• Explain how it'll address the problems you're facing - help us to understand the pain
• Hack something into the app to experiment.

We're around for giving feedback and even code reviews if someone makes some progress, but we're bandwidth-limited at the moment with picking up more work.

[Onikoroshi]

I'm not sure about "championing" this feature, but I can definitely add my voice to the chorus of those clamoring for the "old feature" back. I confess I don't understand enough about Git to really follow your problems with this feature. That's one of the reasons I use the Github Desktop app - so that I don't have to muck about with complex issues and can use my time on my own code challenges. So, I can't help much with your first and last bullet points. However, I believe your second bullet point has been well answered, and I'll add a summary of my experience to the pile. My app(s) tend to have several active branches at once. A production branch where we deal with urgent issues, a hotfix branch where we work on resolving semi-urgent issues, and one or more feature branches where we develop features. In the course of a day, I tend to swap between those active branches quite frequently. The old functionality was very helpful in that any changes I made to one branch did not follow me to another - we want to keep the code on the separate branches separate until we're ready to merge. Now, when I swap branches, it tries to add the changes I've made to the new branches - the exact opposite of what I want! If the "work in progress" workaround is to do a temporary commit before I switch, then that needs to be explicitly mentioned somewhere so that I don't forget to do so, and thereby mess up one of my other branches when it attempts to apply those changes. It just seems like it would be much easier to apply those unapplied changes to a branch I've been working on then to attempt to apply them to a new branch that I haven't been working on. Again, I don't really understand how all this works, so I'm sure at least some of that is way off base, but that's the workflow I have had, the workflow that the old GitHub Desktop app supported, and the workflow that the new GitHub Desktop does not support. So, that's my pain, and how this feature - even as it existed before - would help alleviate that. If I had the time and know-how to further "champion" this feature, I certainly would.

Thank you for the otherwise fantastic application, and I do hope this feature will show up in the near future!

[paulbruneau]

^^^this person is the champion we need. @Onikoroshi You know you can still use the old version, right?

And to github, this whole issue is full of champions. And the people who made Magic Stash originally are all champions. Why do you pretend you need a champion?

[Onikoroshi]

@paulbruneau : I may indeed switch back to the old version if I can't get used to the new workflow. I'm hoping that won't be necessary, though. :/

[agarny]

I use the old GitHub Desktop pretty much every day, which means that I have seen the availability of version 224. It works fine for my needs, except that I find it very slow to refresh. So, today, I thought I would give the new GitHub Desktop another go since it had been months since I had last tried it. Well... still no magic stashing, so... back to the old GitHub Desktop. Frustrating to say the least! :(

@joshaber, any chance of ever seeing magic stashing in the new version? I mean, if you guys want people like me to move to the new version, then you might want to make sure that it has the features the old one has... no?...

[shacker]

I'm not really interested in "magic stashing" but would very much like to have a manual stashing feature, similar to the one in SourceTree (I switched from SourceTree to Github Desktop because it's leaner/faster, but manual stashing is essential workflow).

[iAmWillShepherd]

@shacker Would you mind creating a separate issue for manual stashing?

[adamreisnz]

@shacker please link to it here when you do, so I can upvote it there too! 👍

[shacker]

@adamreisnz @iAmWillShepherd Feature request created:

https://github.com/desktop/desktop/issues/4793

[emurgittroyd]

Would really like to see magic stashing as well. This has been a daily annoyance for me since upgrading my desktop app.

[barbara-sfx]

I just installed the new version and will not use it again until auto-stashing is restored. Besides that, when I edit a bunch of files in a branch, then switch to master, those same files are still shown as uncommitted files. This makes it way too easy to accidentally commit files to master before they are ready. I can't imagine why this feature was removed. Was it not working properly before? I didn't even have to learn what stashing was until I updated to the new version.

[AirborneEagle]

We can discuss "Magic Stashing" (I am totally for it).
but I see absolutely no reason why there is no way to stash at all! Regardless of other problems it may cause the wip workaround is just sloppy in my opinion, and not in line with best practices. teaches bad habits.

[pandaiolo]

Not allowing this at least as an option makes no sense, switching back to old GD... Is this thing so difficult to implement that you chose to drop an existing feature while you are thinking about it?

[barbara-sfx]

Can anyone name one mainstream desktop app that forces you to go to the command line to perform a common, simple operation? I don't think so.

Also, Mac users love the feature, Windows users never had it, so the solution is to take it away from everyone? Really?

If there are issues related to magic stashing, as listed above, wouldn't those same issues surface if someone used the command line to stash? I mean, aren't these git issues, not desktop app issues? If stash would throw an error if run at the command line, then magic stashing could do the same thing: display the error and tell the user the stashing failed and they need to deal with it.

And if those issues are corner cases, as you say, well there are always going to be corner cases. Right now you have many people just not using the new app as opposed to a few corner cases. I really think you made the wrong call here.

Anyway, IMHO, the minimal flow should be:

• I try to change branches
• Modal popup - You have uncommitted changes. Stash changes?

Buttons: Stash (default button implemented if you hit Return; stashes and switches to selected branch); Cancel: Returns you to the app.

Even better flow: Add checkbox Do not ask again
i.e. make "Always stash when switching branches" an option you can set in preferences.

If you think this is even better:

Modal popup: You have uncommitted changes. What do you want to do?
Buttons: Stash (as above); Carry over [new, undesirable behavior that applies uncommitted changes to the target branch]; Cancel

I would still want to see option in preferences if you feel people are likely to always choose one or the other.

[adamreisnz]

@shiftkey any update on magic or manual stashing (#2304)?

Counting just these two issues, it seems that more than 100 votes have been cast to get some form of stashing into the app. Are you taking this into account in your roadmap planning? It seems this is by far the most widely requested feature, which judging by the comments is still holding back many users from adopting the new version.

[tylerweitzman]

Same +1

[wazawoo]

+1. I will not use the new app or use any other app unless this feature appears in them. This was my first git client (before even learning command line git), and it was just perfectly natural that switching branches would save your progress on the branch you were on before, and you could switch back to it later and all the work in progress would be there. When I had to use Windows at work, I started out using git in the command line, and was constantly annoyed with how you would have to stash before switching branches. What if I forget that I had work in progress stashed on that branch? You have to manage it manually. So I thought, if I get a GUI client, maybe it will have the neat branch switching behavior. Turns out, no. No such (magic stashing) solution exists on Windows (that I have found). I found the next best thing on GitKraken, with stashing in the app, and a visual indication of when you have stashed work on a branch. This is still not ideal, but it works. But when I tried the updated GitHub Desktop, it didn't have magic stashing, and didn't have any way to switch branches with work in progress without leaving the app to stash with the command line. Maybe I was just spoiled when magic stashing was around, but it was such an awesome git experience, and I will never work on Mac without it.

[billygriffin]

Thanks for the feedback folks, and I absolutely appreciate the desire to have nicer handling of stashing in the app. We're evaluating all of these issues designated as future-proposal here (https://github.com/desktop/desktop/issues/5398) and it should be more obvious what we are and are not working on (and how we decide) in the next few months. In addition, we hope that process will unlock the potential of the Desktop open source community to contribute some of these more useful features. I apologize for the delay in responding and appreciate that this is important.

[a0930119952]

從 Windows 10 的郵件傳送

寄件者: Billy Griffin
傳送時間: 2018年9月1日 上午 08:51
主旨: Re: [desktop/desktop] Feature request: Stashing changes whenswitching branches or "magic stashing" (#1633)

Thanks for the feedback folks, and I absolutely appreciate the desire to have nicer handling of stashing in the app. We're evaluating all of these here (#5398) and it should be more obvious what we are and are not working on (and how we decide) in the next few months. In addition, we hope that process will unlock the potential of the Desktop open source community to contribute some of these more useful features. I apologize for the delay in responding and appreciate that this is important.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[barbara-sfx]

Not that anyone probably cares, but because the old version of the desktop software stopped working today, I had to find an alternative. I found a different free app that - SURPRISE! - has both Stash and Pop icons right there on the toolbar along with Push and Pull. What a concept. I'm breathing a sigh of relief.

[billygriffin]

Thanks for letting us know @barbara-sfx, and I hope it works well for your needs. We’re planning to work on this - I drew up a new issue today in #6107 to tee that up and get any feedback on what problems we’re solving before we kick off the work.

[barbara-sfx]

I'm glad to hear that you are planning to put it back on the roadmap sooner rather than later.

[agarny]

@barbara-sfx: not sure I understand your message. For one, the old GitHub Desktop application still works fine. Second, you mention a different app and praise it (why not, indeed), but don't even mention its name... or is that just you being sarcastic?

[barbara-sfx]

Well the old version isn't working for me, for whatever reason. You are lucky it's still working for you! Maybe it's an OS thing.

I don't think it's appropriate to name a competitor here. I just searched around and tried a couple that I found and picked one I liked. If this feature request gets addressed, I could see myself coming back at some point.

[agarny]

Well the old version isn't working for me, for whatever reason. You are lucky it's still working for you! Maybe it's an OS thing.

FWIW, I am using the old GitHub Desktop application on macOS.

[nitinsingh-cb]

Why not have an option of custom action where you can apply any git command to a selected set of lines? You can then chose to discard, save, compare, edit or whatever. You only need to know the correct git command :)

[pomplesiegel]

I really miss the stashing behavior as well! I thought I was going crazy recollecting how the software previously behaved.

[GriffinSauce]

I too would love to have this feature back, maybe as an option. It was a massive speed boost compared to more "raw" git interactions.

On the other hand I understand the hesitation noted, it would definitely help to make it more visible (like the contextual button instead of sync).

[billygriffin]

Hi folks! We're looking at this in #6107 - we're referencing all the feedback here as well, just for context, but just wanted to let y'all know where that work is happening. It is prioritized on our roadmap so it's definitely something we're working on in the next couple months.

[Thaina]

+1 for this. This is very common scenario for switching branch. Why this was closed?

[adamreisnz]

Because it has been implemented? :)

On Fri, 5 Jun 2020, 17:26 Thaina Yu, [e-mail] wrote:

+1 for this. This is very common scenario for switching branch. Why this
was closed?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/desktop/desktop/issues/1633#issuecomment-639267068,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADXYQQ46CJI4ED2K7RZNATRVB6ZFANCNFSM4DL7DBYA
.

[Thaina]

@adamreisnz Really? I may not updated things for too long just try to use it and still don't work in my machine

[adamreisnz]

Just make sure you're using the latest client

On Fri, 5 Jun 2020, 17:51 Thaina Yu, [e-mail] wrote:

@adamreisnz https://github.com/adamreisnz Really? I may not updated
things for too long just try to use it and still don't work in my machine

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/desktop/desktop/issues/1633#issuecomment-639273969,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADXYQTUJL5VWEFBXDSYHCLRVCBVLANCNFSM4DL7DBYA
.

[shamimmirzai]

The option to auto-stash is present in the new client which is great, but it doesn't auto-restore when I switch back to that branch, which the old client does.

[adamreisnz]

It's probably better this way, so you have more control over it. It's just
one click away now anyway.

On Fri, 5 Jun 2020 at 19:29, Shamim Mirzai [e-mail] wrote:

The option to auto-stash is present in the new client which is great, but
it doesn't auto-restore when I switch back to that branch, which the old
client does.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/desktop/desktop/issues/1633#issuecomment-639308959,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADXYQUEWL6JGSDK5F23RFDRVCNFDANCNFSM4DL7DBYA
.