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

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

[Junio C Hamano]

When checkout-cache -a is run, currently it attempts to extract
each existing unmerged stage to the same destination and
complains to what it itself has done.  This is nonsensical.

Presumably, the user is running checkout-cache -a in order to
verify the result of the part that has cleanly been merged.  So
check out only stage 0 entries and give warnings for paths that
are unmerged.

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

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

checkout-cache.c: 431b7032576f40d93a08be801e26f76c168ed57b
--- checkout-cache.c
+++ checkout-cache.c	2005-04-16 22:23:15.000000000 -0700
@@ -121,10 +121,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;
 	}

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

[Junio C Hamano]

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;
 	}