Hacker News new | ask | show | jobs
by undata 4333 days ago
These are extremely superficial reasons to criticize git, leading me to believe that the author knows very little about git internals. I'll take the first critique and leave the second to someone else...

You can't pull a portion of the repo because the current state of the repo is built from the tree of commit diffs... This and the fact that git itself is a hash database leads to very efficient use of space. If you want a single folder within a repo, why isn't that folder its own repo?

Between that, the passive aggressive ;-) and the unfortunate advocacy of SVN... ugh.

4 comments

leading me to believe that the author knows very little about git internals

Needing to know about the internals of git is a flaw of git, not a feature.

Why would you use a tool you don't understand? What if it breaks?
You can't pull a portion of the repo because the current state of the repo is built from the tree of commit diffs... This and the fact that git itself is a hash database leads to very efficient use of space.

Sure, but knowing that is essentially irrelevant if your workflow involves a need to check out a partial tree, and Git makes it (hard|impossible|unwieldy|whatever) to do that.

If you want a single folder within a repo, why isn't that folder its own repo?

Because needless proliferation of tiny repos is a problem in its own right?

and the unfortunate advocacy of SVN... ugh.

There's nothing unfortunate about advocating SVN, if SVN is a better fit for your workflow - and by extension, presumably, someone else's workflow which happens to mirror yours.

He's saying that "pulling a portion of the repo" is one of his use cases, and not being able to do that gets in his way.

Pointing out technical reasons why git doesn't do the job he wants doesn't make it useful for him, it just points out why the problem is hard to fix.

"Doctor, it hurts when I do this" does have an answer of its own.
> "Doctor, it hurts when I do this"

.. though it never used to.

I don't agree with the criticism of the article (though there are plenty of UX reasons to be critical), but this is hardly a punching yourself in the face kind of behaviour.

Is the answer 'use a better tool'?
> These are extremely superficial reasons to criticize git

They are use cases which matter to the author. That's basically the opposite of superficial.

> If you want a single folder within a repo, why isn't that folder its own repo?

The author addresses this -- because the folder is not significant enough to warrant the overhead of placing it in a separate repo.

Wanting to pull it out separately makes it significant enough. If you want it in both repos, use subtrees.