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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 6, 2014, 00:43 UTC
Message-ID: <xmqq1tzh135x.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAPc5daXvBPTVCUv=qO++kiOMQck1daTc_rmhpWrDk-KbTuvZOQ@mail.gmail.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 8 quoted lines

> On Wed, Feb 5, 2014 at 3:48 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>> No no. I found that duplicate, but I did not suggest removing it
>> because it is needed there..
>
> Hmph, if that is the case, we probably should make it the
> responsibility of the calling side to actually mark ce->flags with the
> bit (which would also mean the function must be renamed to make it
> clear that it does not mark).

After looking at the codepath that uses the record_intent_to_add() before this patch, I am coming to the conclusion that it is the right thing to do after all. The code appears in this section:

	if (!intent_only) {
		if (index_path(ce->sha1, path, st, HASH_WRITE_OBJECT))
			return error("unable to index file %s", path);
	} else
		record_intent_to_add(ce);

which tells (at least) me: "We are not adding the contents of this path, so we do not run index_path(); instead we call this helper function to set the object name in ce to represent an intent-to-add entry".

So I'll rename it to set_object_name_for_intent_to_add_entry() or something, restore that flag manipulation back to the caller, and add another to the new caller, and requeue.