{"thread":{"id":"52117","subject":".git/binary","startedAt":"2019-10-25T08:58:37Z","lastAt":"2019-10-25T21:33:23Z","messageCount":8,"participants":["без имени","Philip Oakley","Pratyush Yadav"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"384848","messageId":"22757761571993594@vla1-d97dbca235a9.qloud-c.yandex.net","threadId":"52117","inReplyTo":null,"subject":".git/binary","fromName":"без имени","fromEmail":"mykaralw@yandex.ru","sentAt":"2019-10-25T08:53:14Z","receivedAt":"2019-10-25T08:58:37Z","isPatch":false,"sender":{"key":"mykaralw@yandex.ru","avatar":null},"body":"Is it possible to add a `.git/binary` configuration file like` .gitignore` to the `git` system with a list of files stored in a single (current) state.\n\n-- \nzvezdochiot\n\n"},{"id":"384869","messageId":"b9e29a2f-494b-eebc-a3ee-2a2ed4967d7e@iee.email","threadId":"52117","inReplyTo":"22757761571993594@vla1-d97dbca235a9.qloud-c.yandex.net","subject":"Re: .git/binary","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2019-10-25T15:10:36Z","receivedAt":"2019-10-25T15:10:39Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi zvezdochiot,\nOn 25/10/2019 09:53, без имени wrote:\n> Is it possible to add a `.git/binary` configuration file like` .gitignore` to the `git` system with a list of files stored in a single (current) state.\n>\nHave you looked at the `git help attributes`?\nIn particular the example\n\n*.jpg\t\t-text\n\nWhere the '-text' says no end of lines for conversion (i.e. binary!)\n\n\nOr were you thinking of some other meaning for \"files stored in a single (current) state\"?\n\n-- \nPhilip\n\n"},{"id":"384874","messageId":"24796381572021130@iva7-56e9317134d0.qloud-c.yandex.net","threadId":"52117","inReplyTo":"b9e29a2f-494b-eebc-a3ee-2a2ed4967d7e@iee.email","subject":"Re: .git/binary","fromName":"без имени","fromEmail":"mykaralw@yandex.ru","sentAt":"2019-10-25T16:32:10Z","receivedAt":"2019-10-25T16:38:33Z","isPatch":false,"sender":{"key":"mykaralw@yandex.ru","avatar":null},"body":"> Or were you thinking of some other meaning for \"files stored in a single (current) state\"?\n\nIt means that new versions of files located in `.git / binary` will completely replace old versions in history, and therefore will be in a single (current) state in history. What used to be another version of this file should be ignored (very useful for PNG, JPEG, PDF).\n\n-- \nТерритория без имени\n\n"},{"id":"384880","messageId":"20191025180533.ed6du6weja2wfx6c@yadavpratyush.com","threadId":"52117","inReplyTo":"24796381572021130@iva7-56e9317134d0.qloud-c.yandex.net","subject":"Re: .git/binary","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2019-10-25T18:05:33Z","receivedAt":"2019-10-25T18:06:50Z","isPatch":false,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"On 25/10/19 07:32PM, без имени wrote:\n> > Or were you thinking of some other meaning for \"files stored in a single (current) state\"?\n> \n> It means that new versions of files located in `.git / binary` will completely replace old versions in history, and therefore will be in a single (current) state in history. What used to be another version of this file should be ignored (very useful for PNG, JPEG, PDF).\n \nSomething like this might have trouble working with checkouts of past \ncommits, which is a major reason (at least for me) for using a version \ncontrol system.\n\nSay you have two files marked as \"binary\" A.png and B.png at commit X. \nSome part of your code references those files. Now let's say you make a \nnew commit Y where you remove A.png. You also remove all references to \nA.png in your code since you don't need it anymore. In your suggested \nsystem, we drop A.png.\n\nNow if you checkout the commit X, A.png does not exist. This means your \ncode won't compile or work properly, defeating the purpose of version \ncontrol.\n\nYou can argue that \"how about we keep deleted files in history, but for \nthe files that are modified, we don't keep their history, just the \nlatest version?\".\n\nFor that argument, consider the following: say you have a commit X which \nhas A.png. A.png has the dimensions 200x200. You make a new commit Y \nwhere you make A.png larger, say 400x400.\n\nNow if you checkout X, A.png is still 400x400 since we didn't track its \nhistory. And so, the behaviour of your software at that point might also \nchange, defeating the purpose of version control.\n\nSo instead, I'd point you to git-lfs [0]. I haven't personally used the \ntool ever, but it _might_ help in your use case.\n\n[0] https://git-lfs.github.com/\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"384881","messageId":"26026581572028020@vla4-9d01d86ae0b7.qloud-c.yandex.net","threadId":"52117","inReplyTo":"20191025180533.ed6du6weja2wfx6c@yadavpratyush.com","subject":"Re: .git/binary","fromName":"без имени","fromEmail":"mykaralw@yandex.ru","sentAt":"2019-10-25T18:27:00Z","receivedAt":"2019-10-25T18:27:39Z","isPatch":false,"sender":{"key":"mykaralw@yandex.ru","avatar":null},"body":"> Something like this might have trouble working with checkouts of past\n> commits\n\nThis is a conscious step that is taken exactly there and only where there is a need for it. For example, `doc/*.png, doc/*.jpg, doc/*.pdf`.\n\n-- \nzvezdochiot\n"},{"id":"384883","messageId":"24145781572028812@sas2-1c82b59a1818.qloud-c.yandex.net","threadId":"52117","inReplyTo":"20191025180533.ed6du6weja2wfx6c@yadavpratyush.com","subject":"Re: .git/binary","fromName":"без имени","fromEmail":"mykaralw@yandex.ru","sentAt":"2019-10-25T18:40:12Z","receivedAt":"2019-10-25T18:46:56Z","isPatch":false,"sender":{"key":"mykaralw@yandex.ru","avatar":null},"body":"> Something like this might have trouble working with checkouts of past\n> commits, which is a major reason (at least for me) for using a version\n> control system.\n\nGood. If such a mechanism seems too problematic for you, then suggest another mechanism for resetting the history of a specific file. Alternatives are even more problematic. If the file placed in the list I proposed will go into the git history only as a link without checking and calculating the amounts, then isolating the file included in the history will change all the amounts.\n\n-- \nzvezdochiot\n\n"},{"id":"384884","messageId":"5f558e34-bdb2-6656-d2ca-42a2d7cb8874@iee.email","threadId":"52117","inReplyTo":"24796381572021130@iva7-56e9317134d0.qloud-c.yandex.net","subject":"Re: .git/binary","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2019-10-25T20:59:24Z","receivedAt":"2019-10-25T20:59:28Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 25/10/2019 17:32, без имени wrote:\n>> Or were you thinking of some other meaning for \"files stored in a single (current) state\"?\n> It means that new versions of files located in `.git / binary` will completely replace old versions in history, and therefore will be in a single (current) state in history. What used to be another version of this file should be ignored (very useful for PNG, JPEG, PDF).\n>\n\"completely replace old versions in history\" : but why?\n- Is it a space (size on disc, or memory) problem/limitation\n- A confidentiality problem?\n- A 'must use latest procedure' (always checkout latest instructions) \nproblem?\n- A synchronisation problem (no adequate diff) needing single line of \ndevelopment? (there was a discussion at Git Merge in February about this \nfor modified Audio-Visual (AV) files in Games development\n\n“Git for games: current problems and solutions” presentation by John\nAustin at Git Merge 2019:\n   https://www.youtube.com/watch?v=K3zOhU3NdWA&list=PL0lo9MOBetEFqBue4vNcTEnkBjgIQU1Q3&index=8&t=0s\n\n- Something else?\n\n\nThe main advantage of Git is that it distributes control from some central 'manager' to the individual and does that by taking snapshots and exchanging verification stamps, so the idea of deleting history feels somehow 'wrong', hence the need to understand\n\n-- \nPhilip\n\n"},{"id":"384888","messageId":"25196441572039199@iva5-58d151f416d2.qloud-c.yandex.net","threadId":"52117","inReplyTo":"5f558e34-bdb2-6656-d2ca-42a2d7cb8874@iee.email","subject":"Re: .git/binary","fromName":"без имени","fromEmail":"mykaralw@yandex.ru","sentAt":"2019-10-25T21:33:19Z","receivedAt":"2019-10-25T21:33:23Z","isPatch":false,"sender":{"key":"mykaralw@yandex.ru","avatar":null},"body":"> The main advantage of Git is that it distributes control from some central 'manager' to the individual and does that by taking snapshots and exchanging verification stamps, so the idea of deleting history feels somehow 'wrong', hence the need to understand\n\nI perfectly understand that by removing information about the file and its changes from the history, I will “delete” it completely. Git needs changes to work. That means you will need an additional utility file, for example, `.gitshadow`, containing the sum of the files in the list. And this service file will already be reflected in the history. Moreover, it must be to process in a special way.\nWhat is this \"all\" for?\nToo much that is in `git` is completely useless to anyone. This mechanism (if it is implemented) will not be needed by everyone, but those who need it will be very gracious for freeing useless the mountains of  trash.\n\n-- \nzvezdochiot\n\n"}]}