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) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html