Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx>
> ---
> builtin/add.c | 1 +
> diff-lib.c | 5 +++++
> 2 files changed, 6 insertions(+)
>
> diff --git a/builtin/add.c b/builtin/add.c
> index 3390933..ee370b0 100644
> --- a/builtin/add.c
> +++ b/builtin/add.c
> @@ -63,6 +63,7 @@ static void update_callback(struct diff_queue_struct *q,
> switch (fix_unmerged_status(p, data)) {
> default:
> die(_("unexpected diff status %c"), p->status);
> + case DIFF_STATUS_ADDED:
> case DIFF_STATUS_MODIFIED:
> case DIFF_STATUS_TYPE_CHANGED:
> if (add_file_to_index(&the_index, path, data->flags)) {
Is this related to making "diff-files" show an i-t-a as "new", or
something else?
Ahh, "added" would have never appeared in diff-files output (because
by definition comparing index and working tree for only paths known
to the index would never produce "add"), and the point of this series
is to use that status to signal that the path is marked as i-t-a.
And an i-t-a path is "not yet exist in the index, known to the
system, and exists in the working tree", so catching that new case
here and calling add_file_to_index() would cause such a path to be
truly added to the index (this is "add -u" codepath, right?).
Makes sense.
> diff --git a/diff-lib.c b/diff-lib.c
> index db0e6f8..5f1afa4 100644
> --- a/diff-lib.c
> +++ b/diff-lib.c
> @@ -212,6 +212,11 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
> ce->sha1, !is_null_sha1(ce->sha1),
> ce->name, 0);
> continue;
> + } else if (ce->ce_flags & CE_INTENT_TO_ADD) {
> + diff_addremove(&revs->diffopt, '+', ce->ce_mode,
> + EMPTY_BLOB_SHA1_BIN, 0,
> + ce->name, 0);
> + continue;
> }
>
> changed = match_stat_with_submodule(&revs->diffopt, ce, &st,
And this makes sense, of course.
The way "add -N" entries appear in "git status" has been disturbing
for quite a while to me, too. Thanks for starting to look into it.
--
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