Re: git-name-rev off-by-one bug

From: Linus Torvalds <torvalds@osdl.org>
Date: Nov 30, 2005, 01:51 UTC
Message-ID: <Pine.LNX.4.64.0511291742000.3135@g5.osdl.org>
In-Reply-To: <20051130001503.28498.qmail@science.horizon.com>

On Tue, 29 Nov 2005, linux@horizon.com wrote:

Show 7 quoted lines

>
> You seem to be saying that producing a merge with conflict markers is
> what you (almost) always want, so it's the default.  No objections.
> 
> But why collapse the index and only keep stage2?  Why not leave all
> stages in the index *and* the merge-with-conflict-markers in the working
> directory?

That may actually work really well. It would also avoid one bug that we have right now: if you fix things up by hand, but forget to explicitly do a "git-update-index filename" or "git commit filename", a plain regular "git commit" will happily commit all the changes _except_ for the ones you have merged manually. It's happened once to me.

If we left things in the index in an unmerged state, we'd be guaranteed to either _fail_ that git commit unless somebody has done the git-update-index (or names the files specifically on the commit command line, which will do it for you).

So I think I agree.

Junio?

The problem (I think) was that "git-diff-file" did bad things with unmerged entries. That's what the comment in git-merge-one-file implies. But otherwise this should just make it so..

Do you want to test this out?

		Linus

---

diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index c3eca8b..739a072 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-file.sh
@@ -79,11 +79,7 @@ case "${1:-.}${2:-.}${3:-.}" in
 		;;
 	esac
 
-	# We reset the index to the first branch, making
-	# git-diff-file useful
-	git-update-index --add --cacheinfo "$6" "$2" "$4"
-		git-checkout-index -u -f -- "$4" &&
-		merge "$4" "$orig" "$src2"
+	merge "$4" "$orig" "$src2"
 	ret=$?
 	rm -f -- "$orig" "$src2"