Manage stashes similar to commits (feature request)

[rocksolidwebdesign]

Ability to list, apply, pop and drop stashes from a user interface similar to that of the :Gstatus command

[rocksolidwebdesign]

I have started working on this, but I'm not quite sure how you're ultimately routing the output of git status to the window and also how the syntax hilite is happening

I've read through the s:Edit() function but I still don't quite get exactly where or when the git status command itself is being run so I'm not sure how or where to add and or trigger my own desired command which is git stash list.

I can create a :Gstashes command and run it

https://github.com/rocksolidwebdesign/vim-fugitive/commit/eaf8b4b8bd96d16adba10c1623b541448b017c90

but I'm not sure how to

• run the git stash command instead of git somethingelsehere
• redirect that output to the window split generated by s:Edit() or anywhere really for that matter

I bet if you can do that much I can take it the rest of the way.

[tpope]

Basically, you need to make your :Gstashes command edit some made-up path (fugitive:///path/to/repo/.git//stashes would be consistent with the rest of fugitive), and then implement a BufReadCmd to fill in that buffer. You can look at s:BufReadIndex() to see the implementation for :Gstatus. Unfortunately it's a somewhat complicated function, although a lot of it (such as the juggling of $GIT_INDEX_FILE) you can safely ignore. The key part is the invocation of s:ReplaceCmd(), which populates the buffer with the output of a command.

[brainfunked]

I'd really like to be able to use :Gdiff style stash writing to pick and choose specific lines to be stashed. Sometimes git stash --patch simply isn't granular enough.

[glittershark]

This would be super awesome :+1:

[qstrahl]

I would definitely get a lot of use out of this

On 24 November 2014 at 12:49, Griffin Smith [email protected] wrote:

This would be super awesome [image: :+1:]

— Reply to this email directly or view it on GitHub https://github.com/tpope/vim-fugitive/issues/236#issuecomment-64233450.

[omatviiv]

+1 to this feature

[tpope]

This is certainly on the todo list for the new :Gstatus. Displaying a list of stashes and providing maps to pop/apply/drop is relatively straightforward. The annoying part is displaying the stash: as a merge commit, :Gedit stash looks pretty terrible.

[dagadbm]

have you thought about this any more? Tig has a stash menu which is basically similar to the status and on that stash you can drop/apply/clear etc.

Not sure if this is the place but have you also thought about a cz binding for git stash -p ?

[odnoletkov]

FWIW :Gclog -g stash loads all stashes to the quickfix list. You can then browse them and apply using cz<Space>apply<Space><C-R><C-G>

[matochondrion]

FWIW :Glog -g stash loads all stashes to the quickfix list. You can then browse them and apply using cz<Space>apply<Space><C-R><C-G>

Just curious...what would the difference be between cz<Space>apply<Space><C-R><C-G> and cza?

[odnoletkov]

@matochondrion cza always applies topmost stash ('count' stash actually) – and I want to apply currently selected stash

[madhurachanna]

Any update on this feature?

[tpope]

Displaying a list of stashes and providing maps to pop/apply/drop is relatively straightforward.

As hinted at above, the design here is now complicated by the fact we now have stash maps that don't look under the cursor. The obvious path forward is to make them favor the stash under cursor if it's present but fall back to the topmost. But that's a nasty foot-gun waiting to happen: Anyone who gets in the habit of blindly kicking off czp to pop the topmost stash will occasionally screw themselves.

The annoying part is displaying the stash: as a merge commit, :Gedit stash looks pretty terrible.

We now use --first-parent in commit buffers, which is less than ideal, but much better than "terrible" and I would be okay to ship with it.

I guess the path forward would be to start by implementing the stash list only, save the maps for another day. I don't like shipping half a feature, but the alternative is demonstrably eternal stagnation.

[maujim]

But that's a nasty foot-gun waiting to happen: Anyone who gets in the habit of blindly kicking off czp to pop the topmost stash will occasionally screw themselves.

Could there be a warning added for czp in the next release (but no behaviour change) to help prevent this? The behaviour change can then be introduced in a subsequent release.

For the warning, I'm thinking something similar to the warning that was shown when Gbrowse was being deprecated in favour of GBrowse

[tpope]

This isn't a backwards compatibility concern. I want there to be a no-brainer map that pops the topmost stash, as that's what you want to do 99% of the time.

[tpope]

I'm leaning strongly in the direction of overloading the other context sensitive maps: X could be drop, naturally, and we could stick pop on u or something? The tricky part is the documentation.

[EgZvor]

I think pop can be destructive sometimes, but I can't give you an example unfortunately. I remember having a problem with it, probably when there are merge conflicts, it had an effect of drop basically. Since then I started using apply + drop.

Just some info to consider.

[tpope]

git stash pop won't drop the stash if there are merge conflicts.

I do think the operation is a bit too aggressive to trigger on a single key press, and would probably pre-populate the command line instead, like cf does.

[JonasFocke01]

I think consistency is king at this point. X is used on whole files to undo all changes, therefore it feels natural to make it work the same on stashes i think. u for could be the apply, s the apply while keep index, and theyr capital counterparts U and S could serve as a pop. So the user wont have to learn more keys and everything fits tidy together i think. Any thoughts on this?

[jbyler]

Here's another partial solution for anyone looking for a stop-gap. This adds a new binding czl to view the stash in a format that works with vim-fugitive (shortened commit hash first). I prefer this to the quickfix-list version because I can customize the format to include the date and because I'm not in the habit of using the quickfix list.

I recommend using cz<Space>apply<Space><C-R><C-G> to apply a stash, as suggested above by @odnoletkov.

augroup CustomFugitiveMappings
  autocmd!
  autocmd FileType fugitive nmap <buffer> czl :G --paginate stash list '--pretty=format:%h %as %<(10)%gd %<(76,trunc)%s'<cr>
augroup END

[finite-state-machine]

I can see that this feature as discussed would require considerable effort. Perhaps there's some room here for the Pareto Principle (80% of the benefit from 20% of the effort):

Stashes are part of my mental stack, so including the stashes in the status display would be invaluable to me. (Git's status --show-stash option makes me think I'm not alone in this.)

Would it make sense to implement listing stashes on the status page, even if no interactive features were available?

[JonasFocke01]

This alone would be very helpfull for me. Im not using the stash feature alot, so even beeing reminded, that i have undone work to do would make the whole situation way better for me.