Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: // comments and \ Date: Fri, 04 Dec 2015 09:36:57 -0800 Organization: None to speak of Lines: 70 Message-ID: References: <1by4dedxvd.fsf@pfeifferfamily.net> <874mg2dwm9.fsf@bsb.me.uk> <1btwo2dw6b.fsf@pfeifferfamily.net> <1bh9k2dtri.fsf@pfeifferfamily.net> <56617a2a.5013750@news.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="8436"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/6A3YpWnmxZq5gicERXKs0" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:VMsmX7EY4F3zFQfMBaYZC5Nr9Oo= sha1:NNuiHM2MnFy8QgFw8Uhk3Q4HiTE= Xref: csiph.com comp.lang.c:77838 raltbos@xs4all.nl (Richard Bos) writes: > David Brown wrote: >> The other thing about svn is that it is that it works nicely and >> conveniently with a range of files - in particular, binary files are not >> an issue. git is great for pure programming source code - but less >> great for storing entire projects that may contain documentation in >> binary formats, CAD designs, and all sorts of other files. > > Wha... hold on, doesn't git know that we live in an interactive world > now? Graphics files have been an integral, unmissable part of > programming for, well, decades! And help files... OK, it's an open > source project, its main users don't know what the words "help file", > "manual" or "documentation" mean, but still, for those of us who have to > face _real_, non-geek, users, it'd be nice if it handled them. If it > handles only source code and not help files, I guarantee you that the > two _will_ get out of sync, which already happens far too often. For most simple operations, git handles binary files the same way it handles text files. You can add a binary file to a git repo, modify it, check in a new version, retreive old versions, etc. But there are some problems. If you commit a large text file, change a few lines, then commit the updated version, git will store the two versions reasonably efficiently; it doesn't store the entire duplicated content of both versions. Small changes in binary files tend to be more difficult to isolate. If, for example, you commit a large image file, tweak it to darken it a little bit, then commit the updated version, git will probably have to store both versions in their entirety, since it won't be able to figure out a compact way to represent the differences. If you commit a lot of different versions of the file, you're effectively going to have a full copies of each version. And since git is a distributed system, all those copies are going to be stored on your local system. There are some add-ons that try to deal with this kind of thing (Google "git large file storage" for example). For text files, git makes it reasonably easy to merge two different versions into a new one. If the changes are isolated within the file, git does a good job of merging them automatically; if they're not, it marks the conflicts and lets you resolve them manually. None of that is likely to be possible for binary files. (If you can generate the binary files from an editable text file, that solves problem, but that's not always possible.) [...] > Explain to me again how version control, _particularly_ git, is useful > for a stand-alone programmer who has the discipline to make backups? > I'm especially interested in a justification for either installing a > whole new server, or trusting my (possibly proprietary, certainly > personally written) code to another server in either "The Cloud" or the > USA. You don't have to set up a server. The repo, including all the history, is stored under a single ".git" directory; you can make backups of that if you like. Git *organizes* your backups, and lets you view your project's history. For example, you can check out an older version of your project, take a look at it, and then check out the current version again, and it's likely to be *much* easier (and more space-efficient) than retrieving the old version from a backup. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"