|
|
|
|
|
|
by mechanical_fish
5848 days ago
|
|
|
Do not underestimate the potential usefulness of a git utility that lets people do a couple of basic operations on a git repo while teaching them nothing. I know lots and lots of people who have no desire to learn version control but who need to interact with a VCS. But I think I understand where you're coming from. My take is that all of these supposedly-simpler interfaces are nowhere near radical enough. If you try to make git easier by deleting half the feature set you end up with Emasculated Git. It's still obviously git, but it isn't git, so (e.g.) you ask your friend how to use git and they tell you ten things, half of which you can't do because the tool doesn't support them. Or you consult a git book and it seems both familiar and unfamiliar. What I wish someone would try is designing a tool that has, say, 5% of Git's features, and a different name, but uses Git's protocols to interact with Git repos. The user presses a button to download a project from a URL. They tinker. Occasionally they press a button which saves a milestone copy of their directory tree. They can optionally give milestones names. With another button, they can send their milestones to a server in the cloud. They can also browse the cloud looking for other people's milestones and fetch those. They can see the diffs between two milestones. And there probably needs to be a tool to help merge a set of changes into a directory, which can then be saved as yet another milestone. Think: "what would Git look like if Apple designed it?" The result is probably not a tool that a hacker would use directly. But I would hand it to all my non-hacker colleagues in the hope of capturing their work in a repo which I could then pull, sort out, and merge into the main tree. And it would let them browse the history and pull stuff out of it without having to bother someone like me. |
|
|
For subversion, changesapp or cornerstone might appeal to you.
DVCS has high intrinsic complexity, though i agree that simplifying assumptions could reduce git's apparent complexity