Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes:
> @@ -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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html