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

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 15, 2013, 15:04 UTC
Message-ID: <CALkWK0kUoW22d67Ufc0i2OTVuRC8G6xGiR4Joz9vLh_4+bkuZQ@mail.gmail.com>
In-Reply-To: <CALkWK0nqrw7DFQSnMvULYjJtBHRnadKWqCLQOAjzJH0o7USo+A@mail.gmail.com>

Ramkumar Ramachandra wrote:

> Okay, so you're proposing a uniform --autostash feature for both merge
> and rebase.  Sorry, I didn't get it last time due to the typos in your
> email; yeah, this is worth investigating.

So, I thought about this and have concluded that pull is the Right place for autostash because of the following reasons:

0. autostash is purely a convenience function that's useful in simple
reduced cases like a dumb 'git pull'; when the script we're
implementing it for doesn't have a ton of command-line options.

1. git stash; git pull; git stash pop; is a very common idiom.  git
stash; git rebase master; git stash pop; is a less common idiom, but I
agree that it is one rebase case where autostash could be useful.
Having git rebase -i show "exec git stash pop" at the end of a
user-editable instruction sheet is less than ideal.  Having git rebase
--onto master HEAD~3 do an autostash _might_ be useful, but I'm not
sure about it.  git stash; git merge feature-branch; git stash pop; is
not a common idiom at all.

2. git-stash.sh is a helper script, in the same spirit as git-pull.sh
and git-rebase.sh.  It is natural and easy to implement autostash for
pull and rebase, but not for a C builtin like merge.  In fact, it's
impossible to implement it for merge unless we make git commit execute
git stash pop (yuck!).

If you want, you can implement a rebase.autostash, but that is not my itch. Considering the gymnastics the implementation would have to do, I'd be against a merge.autostash. So, again: what is your gripe against my pull.autostash implementation, apart from the fact that git status doesn't show stash information? (I _might_ decide to fix this)