Re: 'git commit' duplicates parents?

From: Dan Holmsand <holmsand@gmail.com>
Date: Jun 20, 2005, 17:20 UTC
Message-ID: <42B6FAE5.6060904@gmail.com>
In-Reply-To: <Pine.LNX.4.58.0506200808090.2268@ppc970.osdl.org>

Linus Torvalds wrote:

Show 14 quoted lines

> 
> On Mon, 20 Jun 2005, Dan Holmsand wrote:
> 
>>git-resolve-script still seems a bit too eager to write MERGE_HEAD and 
>>ORIG_HEAD - they only make sense if there's actually been any merging 
>>done, don't they?
>>
>>Patch below shows what I mean.
> 
> 
> I considered this, but decided that MERGE_HEAD is potentially very useful
> for some of the other failure exits. There's a few "exit 1"'s in there,
> for example when the "git-read-tree -m"  fails because of a dirty
> workspace.

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?

If you react to the dirty-workspace-warnings in such a failed merge by "git commit-ing" (and not noting the MERGE_HEAD warning, which has been known to happen), you'll end up with an unwanted parent in the commit.

Or am I just being stupid :-?

/dan