Casey McGinty [off-list ref] writes:
Is there any feature in git to perform and auto stash apply/pop when
trying to do a merge/rebase in a dirty working dir? This would save
some keystrokes from time-to-time, and make it easier for new users
unfamiliar with git.
I agree with the keystrokes part, but not with the fact that it would
make it easier in general. In the sequence
git stash
git merge
git stash pop
conflicts can occur in 2 distinct places. One can easily forsee this
senario occuring:
git stash
git merge
# fix conflicts
# git commit
# forget to do the action needed to get the "git stash pop"
and voila, you've just lost data.
Actually, what I'd like to see would be this feature, but limited to
the case where the merge is a fast-forward, because then, only the
last action of the sequence could possibly leave conflict, so Git
could finish with a message like "please fix conflicts and continue
working". Actually, this is not far from what "git checout -m" is
doing.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
On Tue, Nov 9, 2010 at 2:49 AM, Matthieu Moy
[off-list ref] wrote:
Casey McGinty [off-list ref] writes:
quoted
Is there any feature in git to perform and auto stash apply/pop when
trying to do a merge/rebase in a dirty working dir? This would save
some keystrokes from time-to-time, and make it easier for new users
unfamiliar with git.
I agree with the keystrokes part, but not with the fact that it would
make it easier in general. In the sequence
git stash
git merge
git stash pop
conflicts can occur in 2 distinct places. [...]
Correct me if I'm wrong, but I think git will only stop you from
performing a merge if it would involve touching any of your dirty files,
so in the case of merge, I agree with Matthieu that temporarily stashing
your changes would probably just increase the risk of confusing the
user.
However, in the case of rebase, git will not let you rebase if *any*
file is dirty. So, in this case of rebase, there are often cases where
git prevents a rebase that could have been a stash + rebase + stash pop
without any conflicts in the pop step.
I know that the fact that 'git rebase' (usually in the form of a
'git pull' configured for rebase on the current branch) forces the user
to temporarily stash his changes has been somewhat annoying to some of
my colleagues.
I actually implemented support for stashing changes using 'stash create'
and 'stash apply', but only for non-interactive rebase. The implentation
supports a '--stash' argument and a 'rebase.stash' configuration. I am
currently working on refactoring git-rebase.sh and
git-rebase--interactive.sh, but once that's done, I will post an updated
version of the 'git rebase --stash' patch(es).
I later found out that this seems to have been attempted at least twice
before. The first time by Junio in 6c9ad16 (rebase: allow starting from
a dirty tree., 2007-07-09). This was later reverted. I think it was
reverted because the stashing was not optional.
Some months later, Simon Sasburg sent some patches on the same subject,
see http://thread.gmane.org/gmane.comp.version-control.git/63007/. These
patches don't see to have been accepted, but I'm not sure why.