(Resend) [PATCH] checkout-cache -a should not extract unmerged stages

From: Junio C Hamano <junkio@cox.net>
Date: Apr 17, 2005, 22:00 UTC
Message-ID: <7vis2lvzbl.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7vy8bi0y2k.fsf@assigned-by-dhcp.cox.net>

Linus,

    do you have any particular reason you did not want the patch
to skip unmerged ones when "checkout-cache -a" is done, and if
so could you let me know?

Here is what happens before the patch:

    $ ls -al
    total 16
    drwxrwsr-x  3 junio src 4096 Apr 17 14:30 ./
    drwxrwsr-x  8 junio src 4096 Apr 17 14:17 ../
    drwxr-sr-x  3 junio src 4096 Apr 17 14:30 .git/
    -rw-rw-r--  1 junio src   29 Apr 17 14:30 SS
    $ show-files --stage
    100644 9e26851b98ab7dd3a3b9653a2efb9b4de0465310 0 SS
    100644 e14bafaadce6c34768ba2ff8b3c6419e8839e7d2 1 TT
    100644 99ef1b30fc6d6ea186d6eac62619e1afd65ad64e 2 TT
    100644 033b9385f7a29882a6b4b34f67b20e2304d3489d 3 TT
    $ ../++linus/checkout-cache -a
    checkout-cache: SS already exists
    checkout-cache: TT already exists
    checkout-cache: TT already exists
    $ ls -al
    total 20
    drwxrwsr-x  3 junio src 4096 Apr 17 14:31 ./
    drwxrwsr-x  8 junio src 4096 Apr 17 14:17 ../
    drwxr-sr-x  3 junio src 4096 Apr 17 14:30 .git/
    -rw-rw-r--  1 junio src   29 Apr 17 14:30 SS
    -rw-rw-r--  1 junio src  363 Apr 17 14:31 TT

See those two warning for TT? It has extracted stage 1 and complaining about what it has done when it goes on to extract stage 2 and 3.

At this point what is in TT is from the stage 1.

This behaviour is somewhat defensible, in that you are giving the user a ready access to the "original" (from stage 1), and he can continue cat-file blob other stages to decide what to do. But I think that the way the user wants to resolve the unmerged state is not our business and it is not particulary useful for the plumbing layer to assume that he would always need stage 1 contents to arrive the merged result (e.g. sdiff between stage 2 and stage 3 would not require stage 1).

With the patch, you get this:

    $ checkout-cache -a
    checkout-cache: SS already exists
    checkout-cache: needs merge TT
    $ ls -al
    total 16
    drwxrwsr-x  3 junio src 4096 Apr 17 14:32 ./
    drwxrwsr-x  8 junio src 4096 Apr 17 14:17 ../
    drwxr-sr-x  3 junio src 4096 Apr 17 14:30 .git/
    -rw-rw-r--  1 junio src   29 Apr 17 14:30 SS

I think it is consistent with this behaviour you already have merged:

    $ ../++linus/checkout-cache SS TT
    checkout-cache: SS already exists
    checkout-cache: TT is unmerged.
    $ ls -al
    total 16
    drwxrwsr-x  3 junio src 4096 Apr 17 14:32 ./
    drwxrwsr-x  8 junio src 4096 Apr 17 14:17 ../
    drwxr-sr-x  3 junio src 4096 Apr 17 14:30 .git/
    -rw-rw-r--  1 junio src   29 Apr 17 14:30 SS

Attached is a re-diff with an updated message.

I could also send you a patch that implements an alternative strategy. With or without "-a", checkout of unmerged files can result in something like this:

    $ checkout-cache -a
    checkout-cache: SS already exists
    checkout-cache: storing stage 1 for TT in TT~1~
    checkout-cache: storing stage 2 for TT in TT~2~
    checkout-cache: storing stage 3 for TT in TT~3~
    $ ls -al
    total 28
    drwxrwsr-x  3 junio src 4096 Apr 17 14:55 ./
    drwxrwsr-x  8 junio src 4096 Apr 17 14:17 ../
    drwxr-sr-x  3 junio src 4096 Apr 17 14:30 .git/
    -rw-rw-r--  1 junio src   29 Apr 17 14:30 SS
    -rw-rw-r--  1 junio src  363 Apr 17 14:55 TT~1
    -rw-rw-r--  1 junio src  363 Apr 17 14:55 TT~2
    -rw-rw-r--  1 junio src  363 Apr 17 14:55 TT~3

Maybe these two behaviours can be controlled with another option (say, -m).

Petr, do you think this alternative behaviour would be useful for Cogito when it starts using "read-tree -m"?

---------------------------------------------------------------- When checkout-cache -a is run, currently it attempts to extract all existing unmerged stages to the same destination and complains to what it itself has done for the first stage when it tries to extract the later stages. This is nonsensical. Just report the unmerged state and let the user sort the mess out using "show-files --unmerged" and "cat-file blob".

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 checkout-cache.c |   11 +++++++++++
 1 files changed, 11 insertions(+)

--- ++linus/checkout-cache.c 2005-04-17 13:57:04.000000000 -0700 +++ ++junio/checkout-cache.c 2005-04-17 14:35:11.000000000 -0700

@@ -137,10 +137,21 @@
 
 static int checkout_all(void)
 {
+	struct cache_entry *unmerge_skipping = NULL;
 	int i;
 
 	for (i = 0; i < active_nr ; i++) {
 		struct cache_entry *ce = active_cache[i];
+		if (ce_stage(ce)) {
+			if (!unmerge_skipping ||
+			    strcmp(unmerge_skipping->name, ce->name))
+				fprintf(stderr,
+					"checkout-cache: needs merge %s\n",
+					ce->name);
+			unmerge_skipping = ce;
+			continue;
+		}
+		unmerge_skipping = NULL;
 		if (checkout_entry(ce) < 0)
 			return -1;
 	}