I think it is pretty much what stash does, but it creates a named shelved change set that stays locally and that can be viewd from a list. You can create as many as you need and you can unshelve the entire change set, destroying it or not, or only part of it, even only one change from a method.
https://www.jetbrains.com/help/idea/2016.2/shelving-changes.html https://www.jetbrains.com/help/idea/2016.2/unshelving-changes.html This video shows how version control works on Intellij all around, the specific part on a very simple usage of the shelve feature can be seen at 8:00. https://www.youtube.com/watch?v=_YW8-9oLgO0 On Mon, Oct 3, 2016 at 10:51 AM, Nicolas Passerini <npasser...@gmail.com> wrote: > No I do not know it, how does it work? > > On Mon, Oct 3, 2016 at 3:43 PM, Vitor Medina Cruz <vitormc...@gmail.com> > wrote: > >> Yes, I agree on the case of fake commit, I prefer your usage of git. In >> the case of stash, I prefer Intellij shelve feature, do you know it? I >> think it helps me organize better than the stash, I use it all the time. >> >> On Mon, Oct 3, 2016 at 10:35 AM, Nicolas Passerini <npasser...@gmail.com> >> wrote: >> >>> >>> >>> On Mon, Oct 3, 2016 at 2:19 PM, Vitor Medina Cruz <vitormc...@gmail.com> >>> wrote: >>> >>>> My two cents: having different images for branches is a good >>>> workaround, but I will have to manually control those images, while git >>>> abstracts this a little since I have a way to tell it to stash and bring >>>> back work in progress. Depending on the project, I think loading a new >>>> image with a fresh HEAD would require a lot of time to bring all >>>> dependencies and compile, while just getting changes made at certain point >>>> from an image and stash them would be much faster, am I wrong? >>>> >>>> >>> Just one comment: the proposal is not to have an image for each branch, >>> you can switch branches using Iceberg. What Iceberg does support not >>> currently is just the "stash" command. >>> >>> Yet it could be slower to create a clean image with your changes, there >>> are ways to make it faster. Also git stash has its own problems, personally >>> I am not a fun of that feature, and I've seen lots of time people messing >>> with it and loosing changes. Moreover, I do not see that saving a "fake" >>> commit to later delete it as a "best practice", but more as a workaround >>> because you do not have a better tool. >>> >>> For all this grounds is that we do not see it as a priority, because we >>> think that there are other tools that can replace it (yet we would like to >>> listen to other opinions) . >>> >> >> >
