git add - adds files to git repository objects tree - though it shouldn't

[SetTrend]

When files are supposed to be added to the repository's git index, the current git version also adds them to the git repository's objects tree:

git.add.adds.objects.to.git.database.mp4

To my knowledge, this is not an intended behaviour and unnecessarily bloats the objects tree.

For technical details see here ...

• ✅ I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using?

• Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.33.0.windows.2
cpu: x86_64
built from commit: 8735530946cced809cc6cc4c2ca3b078cdb3dfc8
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.19042.1165]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: VisualStudioCode
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: ExternalOpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: CRLFAlways
Bash Terminal Option: ConHost
Git Pull Behavior Option: Merge
Use Credential Manager: Core
Performance Tweaks FSCache: Enabled
Enable Symlinks: Enabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Enabled

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

PowerShell 7.1.4

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

> git init
> 'Test' | Out-File Test.txt
> git add .

• What did you expect to occur after running these commands?

The Test.txt file should have been added to the index, but not to the object tree.

git commit is supposed to add objects to the git objects tree. git add is supposed to only add objects to the index file.

• What actually happened instead?

After hitting git add . the Test.txt file was already added to the git objects tree without cause.

[dscho]

Git's index is a light-weight data structure that contains nothing more than:

• file name (relative to the project's top-level directory)
• file mode
• SHA of the contents

In other words, the Git index does not even contain the contents. It only has the SHA, or "object name", of the contents. And the only way to get to those contents is, you guessed it, by looking up that key in the object database.

In yet other words, what you report as a "shouldn't" is a "but it's by design, actually" instead.

[SetTrend]

Did this behaviour by any chance change in the past year? I've been teaching git a couple of months ago to another group of programmers, and I can't remember having seen objects added to the objects tree when we used git add back then.

[dscho]

No, this has been the case from before the first Git commit was created and the index was still called "dircache".

[dscho]

Note: there is one way that git add does not modify the object database: when the contents had already been added previously (or when the file is empty, as the empty blob is hardcoded and usually not added as an explicit database entry).

[SetTrend]

Note: there is one way that git add does not modify the object database: when the contents had already been added previously (or when the file is empty, as the empty blob is hardcoded and usually not added as an explicit database entry).

Good catch! This sounds like a good reason for what I had been observing back those days. 👍

[PhilipOakley]

As far as I understand, it hasn't changed.

Obviously(?) the 2-char sub-directory name can vary as it is the first two characters of the [SHA1] object hash, so as more objects are added the more sub-dirs you may have.

However Git can also store the objects in the pack file(s) so you may those instead. If a file is larger than a certain size then Git will automatically send the object straight into the pack [many reasons].

It's most likely that you just hadn't immediately noticed the particular details of the internal format, which can be a [backward compatible] moving target..

[dscho]

If a file is larger than a certain size then Git will automatically send the object straight into the pack

You mean that 512MB threshold? I doubt that @SetTrend added such a file and therefore missed that the odb was changed (unless he overrode core.bigFileThreshold?

[PhilipOakley]

You mean that 512MB threshold?

Yes, the BigFileThreshold (and any other implementation detail that I might have forgotten or not known about ;-).

Though I was tending toward a descriptive response. It's easy for the 'curse of knowledge' to creep in to a lot of Git discussions because of the ratchet effect between the concepts and their implementation.

As noted, we humans often get mental models that turn out to be 'surprised' by later observations, and we can't quite put our finger on where/when we (or the world) went wrong (one of those engineering niche areas we tend not to like looking into).

"The Index" is one of those concept/implementation conundrums, along with the object store / repository conundrum.