threads / discuss / 42529

Creating empty commits with --intent-to-add

Subject: Creating empty commits with --intent-to-add

## tl;dr

3 messages between Jun 4, 2016 and Jun 5, 2016.

replies: 2people: 2as markdown or json

Thomas Braun· Jun 4, 2016, 17:54 UTC · lore
Hi,
the following procedure

mkdir test cd test git init echo 1 >file git add --intent-to-add file git commit -m "blurb"

results in a commit. I would have expected that git commit complains, as I have not pased the --allow-empty option.

Is that intended behaviour?
Tested with 2.8.3.windows.1 and 2.1.4 on linux.
Thomas
Duy Nguyen· Jun 5, 2016, 03:15 UTC · re: Thomas Braun · lore

Re: Creating empty commits with --intent-to-add

On Sun, Jun 5, 2016 at 12:54 AM, Thomas Braun <thomas.braun@virtuell-zuhause.de> wrote:

Show 15 quoted lines
> Hi,
>
> the following procedure
>
> mkdir test
> cd test
> git init
> echo 1 >file
> git add --intent-to-add file
> git commit -m "blurb"
>
> results in a commit. I would have expected that git commit complains,
> as I have not pased the --allow-empty option.
>
> Is that intended behaviour?
It's a bug. I'll get to it very soon.
-- 
Duy
Thomas Braun· Jun 5, 2016, 19:02 UTC · re: Duy Nguyen · lore

Re: Creating empty commits with --intent-to-add

Am 05.06.2016 um 05:15 schrieb Duy Nguyen:
Show 19 quoted lines
> On Sun, Jun 5, 2016 at 12:54 AM, Thomas Braun
> <thomas.braun@virtuell-zuhause.de> wrote:
>> Hi,
>>
>> the following procedure
>>
>> mkdir test
>> cd test
>> git init
>> echo 1 >file
>> git add --intent-to-add file
>> git commit -m "blurb"
>>
>> results in a commit. I would have expected that git commit complains,
>> as I have not pased the --allow-empty option.
>>
>> Is that intended behaviour?
> 
> It's a bug. I'll get to it very soon.
Thanks for looking into that!
Encouraged by your statement I've done some bisecting via
#!/bin/sh

git=../git/git ( make -j10 git >/dev/null || exit 125 ) && cd .. && rm -rf test && mkdir test && cd test && $git init && echo 1>file && $git add --intent-to-add file && $git commit -m "blurb" && exit 1

exit 0

and found 3f6d56de (commit: ignore intent-to-add entries instead of refusing, 2012-02-07) as first "bad" commit.

This commit states

################# commit: ignore intent-to-add entries instead of refusing

Originally, "git add -N" was introduced to help users from forgetting to add new files to the index before they ran "git commit -a". As an attempt to help them further so that they do not forget to say "-a", "git commit" to commit the index as-is was taught to error out, reminding the user that they may have forgotten to add the final contents of the paths before running the command.

This turned out to be a false "safety" that is useless. If the user made changes to already tracked paths and paths added with "git add -N", and then ran "git add" to register the final contents of the paths added with "git add -N", "git commit" will happily create a commit out of the index, without including the local changes made to the already tracked paths. It was not a useful "safety" measure to prevent "forgetful" mistakes from happening.

It turns out that this behaviour is not just a useless false "safety", but actively hurts use cases of "git add -N" that were discovered later and have become popular, namely, to tell Git to be aware of these paths added by "git add -N", so that commands like "git status" and "git diff" would include them in their output, even though the user is not interested in including them in the next commit they are going to make.

Fix this ancient UI mistake, and instead make a commit from the index ignoring the paths added by "git add -N" without adding real contents. #################

← back to recent threads