Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 16, 2013, 20:53 UTC
Message-ID: <CALkWK0nVfRETgT9U83Nn0QMg8MvdYWcFLzPELCj=8r6ZrR_KOw@mail.gmail.com>
In-Reply-To: <CABURp0qgxtcf_RCrobWr5Q_yiBraVOMDq9hWHrzP=EbZV46xiQ@mail.gmail.com>

Phil Hord wrote:

Show 6 quoted lines

> If I follow the latter advice about 'rm -rf', who will remember that
> 'rebase' had something stashed, and what will they do with it when
> they do?
>
> What if it is weeks or months later?  I would be surprised to see
> long-forgotten wip show up in my workspace all of a sudden.

Ultimately, I think an ideal implementation requires this entire autostash implementation to reside completely within the $state_dir. The issue of a long-forgotten WIP is then the same issue as a long-forgotten rebase, and a rm -rf $state_dir will get rid of the WIP as well.

The other reason is that it shouldn't interact with the rest of git. This means no touching any refs or reflogs, and this can be problematic if we decide to use the standard git stash. I'm currently working towards seeing if it's possible to get stash to create "named stashes" that we can predictably retrieve later, to avoid rolling our own homegrown stash.

Yes, the problem is much more complex than I initially thought. It was much simpler to implement it for git-pull.sh.