# [PATCH] Correct spelling of 'REUC' extension

2 messages from 2010-02-02 to 2010-02-02. Participants: Shawn O. Pearce, Junio C Hamano.
Thread: https://gitlist.dev/t/22489

## Shawn O. Pearce, 2010-02-02 15:33

Subject: [PATCH] Correct spelling of 'REUC' extension
Message-ID: <20100202153328.GB9687@spearce.org>
URL: https://gitlist.dev/e/20100202153328.GB9687%40spearce.org

```
The new dircache extension CACHE_EXT_RESOLVE_UNDO, whose value is
0x52455543, is actually the ASCII sequence 'REUC', not the ASCII
sequence 'REUN'.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---

 I missed the patch that added this to C Git, so I got a bit
 surprised when an unresolved index started crashing inside of JGit.

 JGit is trying to do the right thing by ignoring the extension,
 since its name is all uppercase, but its still getting confused
 and barfing at the end of the file.  While trying to track it down
 I started scratching my head wondering what this 'REUC' extension
 was, and where it came from... only to find out its not actually
 documented in the sources, because the comment is wrong.

 read-cache.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/read-cache.c b/read-cache.c
index 309b77a..f1f789b 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -26,7 +26,7 @@ static struct cache_entry *refresh_cache_entry(struct cache_entry *ce, int reall
 
 #define CACHE_EXT(s) ( (s[0]<<24)|(s[1]<<16)|(s[2]<<8)|(s[3]) )
 #define CACHE_EXT_TREE 0x54524545	/* "TREE" */
-#define CACHE_EXT_RESOLVE_UNDO 0x52455543 /* "REUN" */
+#define CACHE_EXT_RESOLVE_UNDO 0x52455543 /* "REUC" */
 
 struct index_state the_index;
 
-- 
1.7.0.rc0.170.g7207c

-- 
Shawn.

```

## Junio C Hamano, 2010-02-02 18:13

Subject: Re: [PATCH] Correct spelling of 'REUC' extension
Message-ID: <7vpr4n5wwa.fsf@alter.siamese.dyndns.org>
URL: https://gitlist.dev/e/7vpr4n5wwa.fsf%40alter.siamese.dyndns.org
In-Reply-To: <20100202153328.GB9687@spearce.org>

```
"Shawn O. Pearce" <spearce@spearce.org> writes:

> The new dircache extension CACHE_EXT_RESOLVE_UNDO, whose value is
> 0x52455543, is actually the ASCII sequence 'REUC', not the ASCII
> sequence 'REUN'.

Thanks; applied.

It was originally meant to be "resolve undo conflicts" but the symbolic
name got too long with the last word.

```
