Probably because Luke isn’t a programmer and many of the people he works with would get confused by actual version control.
This is Luke, he should teach them version control. Perhaps a simple system like svn would be better than git (but it requires a dedicated server...)
The simple functionality alone—diff/merge tools, merge tracking, logs, tagging/branching, retrieving old revisions—is very empowering for any text-based collaboration. Programmers invented it, but that’s no reason nonprogrammers shouldn’t use it.
I haven’t used dropbox beyond a brief trial a year ago, but I seem to remember it has a primitive version tracking system built in. If it does, it’s sure to be much worse than e.g. svn with a good gui like Tortoise. (Those who do not understand, are condemned to reinvent a poor copy...) People who use that, especially, should switch to a real VCS.
Git GUIs are considered harmful, but… they really make sense to non-programmers. This is probably the best way to introduce non-programmers; they can understand an app that does version control, but asking them to understand the terminal environment AND command line git might be too much.
Sounds more like a consideration specific to badly designed git GUIs :-)
I’ve never used a git GUI, only the CLI. I imagine a simple GUI as being built along the lines of “someone doesn’t like the CLI, or maybe someone is using Windows and has no cli, so let’s wrap every cli git command in an exactly equivalent GUI command that just happens to run in a window and not in a terminal.”
Fine, but that problem shouldn’t be somehow specific to the GUI and irrelevant to the CLI. The purpose of having a GUI isn’t to teach people git or hide unfamiliar concepts, it’s to make correct operations more convenient to people who for whatever reason don’t want a CLI in their workflow.
This is Luke, he should teach them version control. Perhaps a simple system like svn would be better than git (but it requires a dedicated server...)
The simple functionality alone—diff/merge tools, merge tracking, logs, tagging/branching, retrieving old revisions—is very empowering for any text-based collaboration. Programmers invented it, but that’s no reason nonprogrammers shouldn’t use it.
I haven’t used dropbox beyond a brief trial a year ago, but I seem to remember it has a primitive version tracking system built in. If it does, it’s sure to be much worse than e.g. svn with a good gui like Tortoise. (Those who do not understand, are condemned to reinvent a poor copy...) People who use that, especially, should switch to a real VCS.
Git GUIs are considered harmful, but… they really make sense to non-programmers. This is probably the best way to introduce non-programmers; they can understand an app that does version control, but asking them to understand the terminal environment AND command line git might be too much.
Why are they considered harmful, more so than any GUI for a complex CLI program is harmful? Are there considerations specific to git here?
Git-specific consideration. GUIs tend to wrap up a bunch of low-level actions and abstract them; you can end up doing strange things.
Sounds more like a consideration specific to badly designed git GUIs :-)
I’ve never used a git GUI, only the CLI. I imagine a simple GUI as being built along the lines of “someone doesn’t like the CLI, or maybe someone is using Windows and has no cli, so let’s wrap every cli git command in an exactly equivalent GUI command that just happens to run in a window and not in a terminal.”
Oh, the problem is that concepts like “squash” and “fast-forward merge” and “remote ref” just don’t make a lot of sense immediately.
Fine, but that problem shouldn’t be somehow specific to the GUI and irrelevant to the CLI. The purpose of having a GUI isn’t to teach people git or hide unfamiliar concepts, it’s to make correct operations more convenient to people who for whatever reason don’t want a CLI in their workflow.