6 ms·

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 criti

by undata 12y 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.

danielweber 12y ago
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.
- undata 12y ago
  Why would you use a tool you don't understand? What if it breaks?
rst 12y ago
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.
- eropple 12y ago
  "Doctor, it hurts when I do this" does have an answer of its own.
  - Anderkent 12y ago
    Is the answer 'use a better tool'?
  - jsmeaton 12y ago
    > "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.
lliwta 12y ago
> 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.
- undata 12y ago
  Wanting to pull it out separately makes it significant enough. If you want it in both repos, use subtrees.
mindcrime 12y ago
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.

by undata 12y ago

danielweber 12y ago

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.

undata 12y ago
Why would you use a tool you don't understand? What if it breaks?

rst 12y ago

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.

eropple 12y ago
"Doctor, it hurts when I do this" does have an answer of its own.
- Anderkent 12y ago
  Is the answer 'use a better tool'?
- jsmeaton 12y ago
  > "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.

lliwta 12y ago

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

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

mindcrime 12y ago

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.