| 1 |
Patrice Clement posted on Sun, 24 Jan 2016 16:00:31 +0100 as excerpted: |
| 2 |
|
| 3 |
> "Again you should not compress these patches because git does not play |
| 4 |
> well binary files". |
| 5 |
> |
| 6 |
> I'm not sure this statement still holds true with git. Does it? |
| 7 |
|
| 8 |
It does. |
| 9 |
|
| 10 |
Git is designed to be extremely efficient at distributed source version |
| 11 |
control, and works best with text-based sources which it can treat |
| 12 |
"intelligently". Not only does it do its own text compression in the pak |
| 13 |
files, it's relatively dumb in terms of binary differences, being able to |
| 14 |
tell a binary file changed, but effectively considering it a single file |
| 15 |
level change while with text it does line-level tracking. |
| 16 |
|
| 17 |
By compressing a patch or doing a tarball, you're effectively turning it |
| 18 |
into a single blob in terms of tracking, while as the uncompressed text- |
| 19 |
based patch-files, git can not only track the individual files, but |
| 20 |
individual lines within them. While with patch-files losing the |
| 21 |
individual line tracking isn't generally a huge loss (the patches tend to |
| 22 |
be replaced as a whole, without line-level changes within a single |
| 23 |
patch), losing the per-component-patch file tracking is. |
| 24 |
|
| 25 |
-- |
| 26 |
Duncan - List replies preferred. No HTML msgs. |
| 27 |
"Every nonfree program has a lord, a master -- |
| 28 |
and if you use the program, he is your master." Richard Stallman |
Archives