Re: 'git commit' duplicates parents?

From: Linus Torvalds <torvalds@osdl.org>
Date: Jun 20, 2005, 17:44 UTC
Message-ID: <Pine.LNX.4.58.0506201040140.2268@ppc970.osdl.org>
In-Reply-To: <42B6FAE5.6060904@gmail.com>

On Mon, 20 Jun 2005, Dan Holmsand wrote:

Show 6 quoted lines

> 
> Yeah, but that was exactly what I was after...
> 
> As far as I understand it, the git-read-tree -u -m doesn't actually do
> anything when the workspace is dirty - so there's actually no merging 
> going on, right?

No, but you can trivially do so by hand afterwards.

For example, git-read-tree -u -m will complain and say "file xyz is dirty, cannot merge" (or something), and what you might decide to do is just

	git-checkout-cache -f -u xyz
	git resolve $(cat .git/HEAD) $(cat .git/MERGE_HEAD) "..."

and note how you needed to know what the merge head was in order to do this.

[ Side note: I should make "git-resolve-script" run "git-rev-parse" on its
  arguments, so that it would expand HEAD and MERGE_HEAD on its own. Maybe 
  somebody who is interested in this script might want to do that? Hint 
  hint. ]

Note how we could make both of us happy by saving that temporary MERGE_HEAD information somewhere _else_ instead. Maybe the answer is to only use "MERGE_HEAD" for the "merge manually" case, and use something else for the "this was the merge you tried to do last" case?

		Linus