Re: erratic behavior commit --allow-empty

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Angelo Borsotti <angelo.borsotti@xxxxxxxxx> writes:

> I think that you would agree with me that this is not a nice
> behaviour.

This is fundamentally how Git works. You probably didn't notice it, but
if you do

echo 'some content' > file1.txt
git add file1.txt
git commit -m "file1"

echo 'some content' > file2.txt
git add file2.txt
git commit -m "file2"

Then the second commit does not "create" a new blob object for
file2.txt, because it has the same content as an existing one. But the
point is: you really don't care, or indeed, you care about sharing the
blob objects to save disk space.

> How could a user ever use a command that is not predictable?

It is predictible: give it twice the same inputs in the same conditions,
and it will yield the same output.

You still didn't tell us where the problem was. You are unhappy with
having twice the same sha1 for the same object, but what concrete bad
consequence does this have? (except for saving bandwidth in addition to
disk space when trying to push your commit)

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]