Everyone else only had to update, commit, update, commit, update, commit… Git dumps the burden of understanding complex version control on everyone – while making the maintainer’s job easier. In the traditional open source project, only one person had to deal with the complexities of branches and merges: the maintainer. Burden of VCS maintainance pushed to contributors Several ways a committer can irrevocably destroy the contents of a repository: You can make any changes you like, and you can always get it back”. The fundamental promise of any version control system is this: “Once you put your precious source code in here, it’s safe.
Someone could quite conceivably write an improved interface (easygit is a start) that hides unhelpful complexity such as the index and the local repository.
“Git is good” is true if speaking of architecture – but false of user interface. It’s simply the result of ignoring the needs of normal users, and confusing architecture with interface. Interestingly, I don’t think this trade-off is inherent in Git’s design. Git is a 4 handle, dual boiler espresso machine – when all they need is instant. But the majority of Git users are not in this situation: they simply write code, often on a single branch for months at a time. Most of the power of Git is aimed squarely at maintainers of codebases: people who have to merge contributions from a wide number of different sources, or who have to ensure a number of parallel development efforts result in a single, coherent, stable release. Keep using Git, and more concepts will occasionally drop out of the sky: refs, tags, the reflog, fast-forward commits, detached head state (!), remote branches, tracking, namespaces 5. Remember the complicated information model in step 1? It keeps growing, like a cancer. Translation: git-rebase – Sequentially regenerate a series of commits so they can be applied directly to the head node 4. Git-rebase – Forward-port local commits to the updated upstream head Here’s a description for humans: git-push – Upload changes from your local repository into a remote repository Git-push – Update remote refs along with associated objects They describe the commands from the perspective of a computer scientist, not a user. The man pages are one almighty “fuck you”. It combines email reading with patch applying, and thus uses a different patch syntax (specifically, one with email headers at the top). The most spectacular example of this is the command “git am”, which as far as I can tell, is something Linus hacked up and forced into the main codebase to solve a problem he was having one night. The various options of “git reset” do completely different things. Specifying filenames completely changes the semantics of some commands (“git commit” ignores local, unstaged changes in foo.txt “git commit foo.txt” doesn’t). But the shortcut for “git branch” combined with “git checkout”? “git checkout -b”. Some “shortcuts” are graced with top level commands: “git pull” is exactly equivalent to “git fetch” followed by “git merge”. The command line syntax is completely arbitrary and inconsistent. Now Git: you have files, a working tree, an index, a local repository, a remote repository, remotes (pointers to remote repositories), commits, treeishes (pointers to commits), branches, a stash… and you need to know all of it. In fact, branches are tags, and files you already know about, so you really need to learn three new things. That’s pretty much everything you need to know. As a point of reference, consider Subversion: you have files, a working directory, a repository, versions, branches, and tags.
The information model is complicated – and you need to know all of it. What a pity that it’s so hard to learn, has such an unpleasant command line interface, and treats its users with such utter contempt. It has a powerful distributed model which allows advanced users to do tricky things with branches, and rewriting history. Git is the source code version control system that is rapidly becoming the standard for open source projects.
0 kommentar(er)
