I actually think "silently ignore intent-to-add" was a mistake.
We used to error out at write-tree time, which I think is the
right behaviour--"I know I want to have this path, but I cannot
yet decide with what content" is what the user is telling us when
she says "add -N", so until that indecision is resolved, we
shouldn't write out a tree object out of the index.
On Wed, Mar 16, 2016 at 2:05 PM, Jeff King <peff@xxxxxxxx> wrote:
> On Wed, Mar 16, 2016 at 05:02:45AM -0700, Josh Triplett wrote:
>
>> On Tue, Mar 15, 2016 at 09:51:35PM -0700, Junio C Hamano wrote:
>> > Josh Triplett <josh@xxxxxxxxxxxxxxxx> writes:
>> >
>> > > As far as I can tell, if I run "git add -N" on a file, and then commit
>> > > without adding the file contents, it gets committed as an empty file.
>> >
>> > Is that true? Git once worked like that in earlier days, but I
>> > think write-tree (hence commit) would simply ignore intent-to-add
>> > entries from its resulting tree.
>>
>> Git 2.7.0 does appear to commit an empty file if I commit after git add
>> -N.
>
> I don't think this is the case:
>
> git init
> echo content >file
> git add -N file
> git commit -m "empty?"
>
> git ls-tree HEAD
> git status
>
> shows that we committed an empty tree. So I see two obvious
> possibilities for improvement:
>
> 1. This commit should have failed without --allow-if-empty. We need to
> be more careful about intent-to-add entries when figuring out if
> the commit would be empty or not
>
> 2. I'm not sure if "silently ignore intent-to-add" is the best policy.
> At least a warning ("hey, what did you want to do with these
> entries") seems merited, if not aborting the commit entirely. I
> hesitate on the latter only because perhaps that would mess up
> somebody's legitimate workflow.
>
> -Peff
--
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