Re: git reset --merge misdocumented?

From: Thomas Rast <trast@student.ethz.ch>
Date: Jan 30, 2009, 23:20 UTC
Message-ID: <200901310020.23851.trast@student.ethz.ch>
In-Reply-To: <alpine.DEB.1.00.0901290210540.3586@pacific.mpi-cbg.de>

Johannes Schindelin wrote:

> from the man page I thought that --merge would be just another way to say 
> "git read-tree -u -m".

Isn't that idea from the commit message? I can't find any mention of read-tree in next's idea of the manpage.

> In particular, the man page says _nothing_ about resetting HEAD to 
> something else.

It says

  --merge::
          Resets the index to match the tree recorded by the named commit,
          and updates the files that are different between the named commit
          and the current commit in the working tree.

so while the exact way of "updating" is not specified, it does mention that you can move between commits, and that it will do something with the difference across the move.

The example further down really cleared up the idea for me:

  Undo a merge or pull inside a dirty work tree::
  +
  ------------
  $ git pull                         <1>
  Auto-merging nitfol
  Merge made by recursive.
   nitfol                |   20 +++++----
   ...
  $ git reset --merge ORIG_HEAD      <2>
  ------------

I've never used 'read-tree -u -m' except in voodoo scripting, but I'd have done the same with 'git stash && git reset --hard ORIG_HEAD && git stash pop' before. The original commit message even mentions this equivalence.

So I'm not sure what exactly needs changing there?

-- 
Thomas Rast
trast@{inf,student}.ethz.ch