Re: [PATCH 2/2] reset: support "--mixed --intent-to-add" mode

On Tue, Feb 04, 2014 at 02:25:25PM -0800, Junio C Hamano wrote:

Junio C Hamano [off-list ref] writes:

quoted

While I do not have any problem with adding an optional "keep lost
paths as intent-to-add entries" feature, I am not sure why this has
to be so different from the usual add-cache-entry codepath.  The
if/elseif chain you are touching inside this loop does:

 - If the tree you are resetting to has something at the path
   (which is different from the current index, obviously), create
   a cache entry to represent that state from the tree and stuff
   it in the index;

 - Otherwise, the tree you are resetting to does not have that
   path.  We used to say "remove it from the index", but now we have
   an option to instead add it as an intent-to-add entry.

So, why doesn't the new codepath do exactly the same thing as the
first branch of the if/else chain and call add_cache_entry but with
a ce marked with CE_INTENT_TO_ADD?  That would parallel what happens
in "git add -N" better, I would think, no?

In other words, something along this line, perhaps?

<snip>

Yes. But you need something like this on top to actually set
CE_INTENT_TO_ADD

-- 8< --

diff --git a/read-cache.c b/read-cache.c
index 325d193..87f1367 100644
--- a/read-cache.c
+++ b/read-cache.c

@@ -585,6 +585,7 @@ void mark_intent_to_add(struct cache_entry *ce)
 	if (write_sha1_file("", 0, blob_type, sha1))
 		die("cannot create an empty blob in the object database");
 	hashcpy(ce->sha1, sha1);
+	ce->ce_flags |= CE_INTENT_TO_ADD;
 }
 
 int add_to_index(struct index_state *istate, const char *path, struct stat *st, int flags)
-- 8< --