Excerpts from Andrew Dunstan's message of vie ene 13 14:29:44 -0300 2012:
> Yeah. Just note this from the docs:
>
> The third syntax ("git merge --abort") can only be run after the
> merge has resulted in conflicts. git merge --abort will abort the
> merge process and try to reconstruct the
> pre-merge state. However, if there were uncommitted changes when the
> merge started (and especially if those changes were further modified
> after the merge was started), git merge
> --abort will in some cases be unable to reconstruct the original
> (pre-merge) changes.
Hm. Whenever I find myself trying to merge something in a tree that
also has uncommitted changes (which is not very often), what I do is
"git stash" to save my work elsewhere and then run the git merge. That
way, if things go wrong (which is also not very often), I can just abort
the merge and pop the patch from the stash, and I'm right back where I
started. Otherwise, I pop my patch from the stash anyway and any merges
are handled by the same merge mechanism, so I can also roll that back if
things don't turn the way I initially wanted.
So while you can certainly screw up and lose work, it's also true that
you have all the tools not to.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support