Comment by viraptor | Hacker News Reader

Comment by viraptor | Hacker News Reader

Parent Full thread

I see this mentioned so many times:

"Git seems unintuitive because you don't have a good grasp of what it does behind the scenes"

but I fail to see why this is true. Do we need to understand the implementation of block allocation, snapshots, atomic writes, etc. to save files? Do we need to know the ip checksumming algorithm to connect to use internet? Do we need to understand congestion control algorithms to browse websites? {and many other examples}

No - we don't and many of us do not know those things. Then why are we expected to know the internals of git to use it? (use - not modify, analyse, edit without an interface, etc.) Why can't we get a tool which gets an address and makes the file appear on the local storage? (or any equivalent to VCS workflow)

"Designing a patch database" - No, I want to use a VCS, not design it. If it works on pixie dust, I'm ok with that. It's just a tool. It's supposed to help me do the real work, not give more stuff to think about on every step. Why is "you don't understand how it works" an acceptable answer here? Where's the iphone of VCS-es?

"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.

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