If I remember correctly there is/was some preliminary work (at most 'pu'
stages) about adding --dirty option to git-merge, git-pull and git-rebase.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git


-

[ message continues ]

Hi,


There was, but AFAICT these are dead now.

The consense was that you are much better off committing first, then 
pulling.  And if the work you are doing really is not committable, but you 
_have_ to pull _now_, you use stash.  Although you are quite likely to 
revert the pull when it succeeds, and _then_ unstash.

Ciao,
Dscho

-

[ message continues ]

Sorry but I don't really understand why one should "revert the pull" ? Could
elaborate for a newbie ? :)

- Aghiles.
-

[ message continues ]

Hi,


Yes, no problem.

A pull is just a fetch and a merge.  And a merge is a commit with more 
than one parent.  So you can use the command "git reset --hard HEAD^" to 
undo a merge, just as you can undo any other commit.

NOTE: if you pushed that commit (merge or not), do _not_ use reset.  This 
effectively rewrites history, and _will_ upset people pulling from you.  
If you really have to undo a commit you already published, use "git revert 
<commit>".

Hth,
Dscho

-

[ message continues ]

*DANGER*

A pull is usually just a fetch and a merge, but sometimes it can
fast forward.  ORIG_HEAD, not HEAD^, points at the previous HEAD
location in both cases.

-

[ message continues ]

Hi,


Oops. Right.

Thanks,
Dscho

-

[ message continues ]