Originally published at: https://boingboing.net/2017/12/18/how-to-fix-common-mistakes-in.html
…
Nice article, but a bit technical for the BB crowd, no? Outside of developers, I don’t think anyone cares. BB does have a high ration of devs in the comment section, but they (we) would normally get this information elsewhere.
…kill
I like it! Thanks! Just started using Git and I’m sure I’ll find this useful.
Actually version control is useful for writing as well, especially if you stick to plain text.
Yes, I use it for writing, but I’m weird that way. It only works if you are using text (or markdown, or html, or latex, etc). But, I would say that track changes in Word or Google Docs is sufficient for most non-technical purposes.
I’m not a developer, and yet it’s useful for me. I sometimes contribute to open source projects, and it’s very easy do make mistakes with git. Also, as I work as scientist/academic teacher, I write in LaTeX and while I’ve not yet tried git for document version control, it could be useful. I think that it could be also useful for some CAD software that stores models in text format, like SolveSpace.
But we still can’t fix Gitmo.
Huh, just saw this and in 15 minutes I am going to co-lead an intro workshop/seminar on using git.
I use GitKraken, it has good branch diagrams which I’ve found are critical to understanding what’s going on.
Git is becoming more common in Windows-land as well. A lot of projects at my Windows-stack centric company are moving to it, now that Microsoft supports it as a first class citizen. TFS/VSTS can host GIT repo’s and supports the GIT proto.
The time I spent writing those 3 sentences was really wasted.
Commonest mistake? Using it…
One small change in in how git’s smudge/clean filters work would actually let it work much better with many document formats. Modern office documents typically store a zip of xml files. Being able to store and diff the underlying xml rather than the zip would be nice, but probably won’t happen. This only isn’t possible because the filters have to map one file to one file, not a file to a directory tree.
The good thing about git is it’s typically very hard to do much more than fuck up your own local copy of a repository. Although when this does happen, it can be quite infuriating.
It doesn’t help that git doesn’t have a middle ground between quick, convenient “do this dangerous thing hundreds of times until the one time you fuck up and accidentally lose hours of work” and inconvenient constant nagging.
Git is really a wonderful RCS but you can tell it was written by and for nerds. Don’t even get me started on its terrible nomenclature and poorly conceived verbs.
I use git all the time for maintaining a repository of md documents. It is really great for this.
While Visual Studio sometimes drives me crazy with its “yeah we use git but we’re going to call things slightly different names and confuse the hell out of you” approach it really is great. And I love how well integrated it is with VSO.
I love this little dig at Windows users on the Git for Windows page:
Git GUI
As Windows users commonly expect graphical user interfaces, Git for Windows also provides the Git GUI, a powerful alternative to Git BASH, offering a graphical version of just about every Git command line function, as well as comprehensive visual diff tools
It’s mostly about getting your own personal workflow done right. I recommend two things to avoid nasty errors: 1. make a local tag and 2. push to a remote before you do anything vaguely dangerous (so you can go back if you need). It’s also easy to create aliases that do this for you automatically.
This is where Mercurial is ahead of the game IMHO.
Git suffers because Linus just needed to bitkeeper replacement, and gave little thought to the UI.
Mercurial has pluggable diff and merge tools which are intended to assist with cases like this.
less characters than the comment