Some problems for git beginners

Some problems for git beginners

[ZhangJinbao]

Hello! Sorry to bother you in your busy schedule.

As a git beginner, I have a few simple questions to ask you

First, how to implement the algorithm when there is file renaming in Git directory?

By comparing the SHA1 value of the file, and then calling the GIT MV command?

Second, how to implement the algorithm when there is file movement in Git directory?

How is the tree object updated?

Third, when a commit event occurs, the current blob file stores the full amount of data, while the previous version stores the incremental data

But I didn't find out how to (local git database) when I actually used it.

When git clone is used, the results are close to the conclusion

These are not found in the book, so I have to bother you.

I hope you can help me solve my confusion when you are free

thank you very much indeed

Re: Some problems for git beginners

[Bagas Sanjaya]

On 09/10/21 14.43, ZhangJinbao wrote:

> Third, when a commit event occurs, the current blob file stores the full amount of data, while the previous version stores the incremental data
> 

When you `git commit`, Git will initially write objects related to the 
commit (blob, tree, and commit) as loose objects. Some point on the 
time, Git will repack many loose objects into one big packfile and write 
the corresponding pack index. Delta compression is applied when writing 
the packfile.

-- 
An old man doll... just what I always wanted! - Clara

Re: Some problems for git beginners

[Philip Oakley]

On 09/10/2021 10:12, Bagas Sanjaya wrote:
> On 09/10/21 14.43, ZhangJinbao wrote:
>
>> Third, when a commit event occurs, the current blob file stores the
>> full amount of data, while the previous version stores the
>> incremental data
>>
>
> When you `git commit`, Git will initially write objects related to the
> commit (blob, tree, and commit) as loose objects. Some point on the
> time, Git will repack many loose objects into one big packfile and
> write the corresponding pack index. Delta compression is applied when
> writing the packfile.
>
Git is multi-layered, and multi-faceted. So often the impression given
isn't the same as what happens internally.

All commits are full snapshots, even if git (normally) shows only the
changes for previous diffs.

But then git will, at a convenient point 'pack' all those snapshots
(fairly efficiently) so that the local git storage of the whole
repository, with full history, (typically) is no bigger than the checked
out files. The packing is part of that layering.

There are similar facet/layer effects from the Staging area ("index") /
Object store viewpoints.

The https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
is worth a read, along with other descriptions.

Philip

Re: Some problems for git beginners

[Philip Oakley]

Please don't drop the list...

On 11/10/2021 04:00, ZhangJinbao wrote:
>
>
>> 2021年10月9日 下午6:32，Philip Oakley <philipoakley@iee.email
>> <mailto:philipoakley@iee.email>> 写道：
>>
>> On 09/10/2021 10:12, Bagas Sanjaya wrote:
>>> On 09/10/21 14.43, ZhangJinbao wrote:
>>>
>>>> Third, when a commit event occurs, the current blob file stores the
>>>> full amount of data, while the previous version stores the
>>>> incremental data
>>>>
>>>
>>> When you `git commit`, Git will initially write objects related to the
>>> commit (blob, tree, and commit) as loose objects. Some point on the
>>> time, Git will repack many loose objects into one big packfile and
>>> write the corresponding pack index. Delta compression is applied when
>>> writing the packfile.
>>>
>> Git is multi-layered, and multi-faceted. So often the impression given
>> isn't the same as what happens internally.
>>
>> All commits are full snapshots, even if git (normally) shows only the
>> changes for previous diffs.
>>
>> But then git will, at a convenient point 'pack' all those snapshots
>> (fairly efficiently) so that the local git storage of the whole
>> repository, with full history, (typically) is no bigger than the checked
>> out files. The packing is part of that layering.
>>
>> There are similar facet/layer effects from the Staging area ("index") /
>> Object store viewpoints.
>>
>> The
>> https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
>> <https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain>
>> is worth a read, along with other descriptions.
>>
>> Philip
>>
>
> I'm very glad to hear from you
>
> After further study and practice in recent days, there are still
> several questions to confirm
>
> As the article says: 
> What is also interesting is that the second version of the file is the
> one that is stored intact, whereas the original version is stored as a
> delta — this is because you’re most likely to need faster access to
> the most recent version of the file.
>
> Practice has proved that:
> Using the repo.rb(22KB) file, you can store the original version as a
> delta. But using the test.txt(22B) file, you cannot store the original
> version as a delta. 
> Does this algorithm depend on the size of the file? If so, what is the
> file size boundary?
>
> ——————————————————————————————————————————————————————————
> zhangjinbao@Jinbao test % ls   
> repo.rb
> zhangjinbao@Jinbao test % echo "version 1" > test.txt
> zhangjinbao@Jinbao test % git add .
> zhangjinbao@Jinbao test % git commit -m "Create test.txt"
> [master b4a4c9d] Create test.txt
>  1 file changed, 1 insertion(+)
>  create mode 100644 test.txt
> zhangjinbao@Jinbao test % echo "# version 2" >> test.txt 
> zhangjinbao@Jinbao test % git commit -am "modify test.txt"
> [master c454823] modify test.txt
>  1 file changed, 1 insertion(+)
> zhangjinbao@Jinbao test % git gc
> ...
> zhangjinbao@Jinbao test % git verify-pack -v
> .git/objects/pack/pack-17ceeb7d325a4eb7dab3f6f04dda67daa7515feb.idx 
> c45482367fb06750398339597be1c0679af8ee9a commit 226 157 12
> b4a4c9de03421e9e49eaae3c67cf43c699eb5b98 commit 226 157 169
> bcb782fa38f8b016b263a129d3960f409f285215 commit 231 161 326
> 228b55de49116a358ec7c15ccb291678a014fcc8 commit 175 124 487
> b042a60ef7dff760008df33cee372b945b6e884e blob   22054 5799 611
> d25a248172e09b2ef61bcf45b5ec29435da23241 blob   22 26 6410
> aef683d9d2619240c4fa1dcb5a04ea8cbe1de89a tree   71 79 6436
> fdd7ee840023b632768fdcdc08a3465a0c4d46ed tree   71 78 6515
> 83baae61804e65cc73a7201a7252750c76066a30 blob   10 19 6593
> a1ca41f02e3519c32aafb8f4d4d9f465c8ce587a tree   35 46 6612
> 38feecbdf638935287fd920e8f2d694aa8c28d9f tree   35 46 6658
> 033b4468fa6b2a9547a70d88d1bbe8bf3f9ed0d5 blob   9 20 6704 1
> b042a60ef7dff760008df33cee372b945b6e884e
> 非 delta：11 个对象
> 链长 = 1: 1 对象
> .git/objects/pack/pack-17ceeb7d325a4eb7dab3f6f04dda67daa7515feb.pack: ok
> zhangjinbao@Jinbao test % 
>
> --zhangjinbao

The packing is a heuristic, which is explained in narrative (story) form
here: https://git-scm.com/docs/pack-heuristics
--
Philip