Hacker News Reader

Hacker News

Comment by weavejester | Hacker News Reader

Parent Full thread

weavejester

"Do we need to understand the implementation of block allocation, snapshots, atomic writes, etc. to save files?"

No, but consider what you need to know about file systems to use them. At the barest minimum, you need to know that:

* Data is stored in files

* Files have names

* Files are contained in directories

* Directories have names

* Directories can contain directories

If you had no understanding of what a file or a directory was, I'd imagine you'd find the behaviour of "grep" or "cat" completely unintuitive.

You don't need to know how Git stores data internally, but you do need to have a basic understanding of its design, just as you need a basic understanding of a filesystem in order to use it.

View on HN

I expect to need exactly the same level of knowledge to work with a DVCS, because I'm editing files. SVN was very close to providing that in many ways and it worked. I don't want to know about a staging area unless I explicitly use it, for example. I don't want to know about the design or patch handling, unless I explicitly request or apply a patch. Merging is merging - it's good couple of levels of abstraction above patches.

Basically - I want my DVCS to require as much knowledge as cp, diff, patch. I could live with them, if I had to (see - `quilt`). Now a DVCS should be easier to use, not harder. Otherwise, what's the point?

People use DVCS for its features and capabilities. Because it can do more things not because it is easier to use. In the case of git the 'simple' workflow runs into some troubles because git is designed to accommodate much more complex workflows and as a result some of the core concepts have been tweaked in what people consider to be 'unintuitive' ways.

People choose vi/emacs over notepad/ed/pico for many of the same reasons and people complain about many of the same things (it's unintuitive, complicated, confusing, and so on...)

The reason why this is important is that dvcs-es are very different from editors. If I don't like emacs, I'll use vi, gedit, ed, ... - we'll get the same file and the same result, it's only the method that's different.

If you use git however, I have a choice of a) git b) hg-git c) not working with your code.

Surely the same argument applies to SVN as well? Whichever VCS you use, you're going to force contributors to adapt to a particular version control philosophy.

"I expect to need exactly the same level of knowledge to work with a DVCS, because I'm editing files."

From Git's point of view, you're not editing files; you're creating patches.

Git is fundamentally a tool for constructing, sharing and storing patches. You may disagree that this is the best way to approach version control, but if you accept this philosophy, then Git is remarkably simple and logical.

Personally, I feel that treating a version control system like a filesystem is the wrong approach. I'm primarily interested in managing changes to the code, not in tracking chronological changes in individual files.

Reply on news.ycombinator.com