Git development
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Kalle Olavi Niemitalo <kon@iki.fi>
Cc: git@vger.kernel.org, gitster@pobox.com, spearce@spearce.org
Subject: [PATCH 1/2] Move MERGE_RR from .git/rr-cache/ into .git/
Date: Sat, 12 Jul 2008 15:56:19 +0100 (BST)	[thread overview]
Message-ID: <alpine.DEB.1.00.0807121553120.8950@racer> (raw)
In-Reply-To: <87skufmjg4.fsf@Astalo.kon.iki.fi>


If you want to reuse the rerere cache in another repository, and set
a symbolic link to it, you do not want to have the two repositories
interfer with each other by accessing the _same_ MERGE_RR.

For example, if you use contrib/git-new-workdir to set up a second
working directory, and you have a conflict in one working directory,
but commit in the other working directory first, the wrong "resolution"
will be recorded.

The easy solution is to move MERGE_RR out of the rr-cache/ directory,
which also corresponds with the notion that rr-cache/ contains cached
resolutions, not some intermediate temporary states.

Noticed by Kalle Olavi Niemitalo.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	Shawn, I Cc:ed you because of 2/2.

	On Sat, 12 Jul 2008, Kalle Olavi Niemitalo wrote:

	> I don't see any way to modify the symlinks made by 
	> git-new-workdir so that new SHA-1 directories in .git/rr-cache
	> would be shared but .git/rr-cache/MERGE_RR would not.  On IRC, 
	> "gitte" suggested changing Git to use $GIT_DIR/MERGE_RR instead of 
	> $GIT_DIR/rr-cache/MERGE_RR.

	"gitte" actually expected that a patch would not be that hard.

	> I suppose compatibility with people's existing repositories 
	> would require the modified Git to keep reading 
	> $GIT_DIR/rr-cache/MERGE_RR too, so that Git could be painlessly 
	> upgraded during a merge, but it is not obvious to me how lock files 
	> should then work.

	"rerere" is not perfect.  Thus, I suspect that we can just leave 
	an existing MERGE_RR alone, and the user just has to record the 
	resolution another time.  Too bad.

 branch.c          |    2 +-
 builtin-rerere.c  |    2 +-
 t/t4200-rerere.sh |    6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/branch.c b/branch.c
index 56e9492..b1e59f2 100644
--- a/branch.c
+++ b/branch.c
@@ -166,7 +166,7 @@ void create_branch(const char *head,
 void remove_branch_state(void)
 {
 	unlink(git_path("MERGE_HEAD"));
-	unlink(git_path("rr-cache/MERGE_RR"));
+	unlink(git_path("MERGE_RR"));
 	unlink(git_path("MERGE_MSG"));
 	unlink(git_path("SQUASH_MSG"));
 }
diff --git a/builtin-rerere.c b/builtin-rerere.c
index 69c3a52..1db2e0c 100644
--- a/builtin-rerere.c
+++ b/builtin-rerere.c
@@ -429,7 +429,7 @@ static int setup_rerere(struct path_list *merge_rr)
 	if (!is_rerere_enabled())
 		return -1;
 
-	merge_rr_path = xstrdup(git_path("rr-cache/MERGE_RR"));
+	merge_rr_path = xstrdup(git_path("MERGE_RR"));
 	fd = hold_lock_file_for_update(&write_lock, merge_rr_path, 1);
 	read_rr(merge_rr);
 	return fd;
diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
index cf10557..b5a4202 100755
--- a/t/t4200-rerere.sh
+++ b/t/t4200-rerere.sh
@@ -57,7 +57,7 @@ test_expect_success 'conflicting merge' '
 	! git merge first
 '
 
-sha1=$(sed -e 's/	.*//' .git/rr-cache/MERGE_RR)
+sha1=$(sed -e 's/	.*//' .git/MERGE_RR)
 rr=.git/rr-cache/$sha1
 test_expect_success 'recorded preimage' "grep ^=======$ $rr/preimage"
 
@@ -143,7 +143,7 @@ test_expect_success 'rerere kicked in' "! grep ^=======$ a1"
 test_expect_success 'rerere prefers first change' 'test_cmp a1 expect'
 
 rm $rr/postimage
-echo "$sha1	a1" | perl -pe 'y/\012/\000/' > .git/rr-cache/MERGE_RR
+echo "$sha1	a1" | perl -pe 'y/\012/\000/' > .git/MERGE_RR
 
 test_expect_success 'rerere clear' 'git rerere clear'
 
@@ -190,7 +190,7 @@ test_expect_success 'file2 added differently in two branches' '
 	git add file2 &&
 	git commit -m version2 &&
 	! git merge fourth &&
-	sha1=$(sed -e "s/	.*//" .git/rr-cache/MERGE_RR) &&
+	sha1=$(sed -e "s/	.*//" .git/MERGE_RR) &&
 	rr=.git/rr-cache/$sha1 &&
 	echo Cello > file2 &&
 	git add file2 &&
-- 
1.5.6.2.511.ge432a

  reply	other threads:[~2008-07-12 14:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-12 11:27 git-new-workdir should not share .git/rr-cache/MERGE_RR Kalle Olavi Niemitalo
2008-07-12 14:56 ` Johannes Schindelin [this message]
2008-07-12 14:56   ` [PATCH 2/2 (for GIT-GUI)] git-gui: MERGE_RR lives in .git/ directly with newer Git versions Johannes Schindelin
2008-07-13  1:16     ` Shawn O. Pearce
2008-07-13  8:58       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.1.00.0807121553120.8950@racer \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=kon@iki.fi \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox