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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 4, 2014, 19:09 UTC
Message-ID: <xmqqvbwu8zjx.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1391480409-25727-2-git-send-email-pclouds@gmail.com>

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:

Show 10 quoted lines

> @@ -128,13 +129,20 @@ static void update_index_from_diff(struct diff_queue_struct *q,
>  				    one->path);
>  			add_cache_entry(ce, ADD_CACHE_OK_TO_ADD |
>  				ADD_CACHE_OK_TO_REPLACE);
> +		} else if (*intent_to_add) {
> +			int pos = cache_name_pos(one->path, strlen(one->path));
> +			if (pos < 0)
> +				die(_("%s does not exist in index"),
> +				    one->path);
> +			set_intent_to_add(&the_index, active_cache[pos]);

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?