5 ms·

> If you can concurrently build/test and edit, you necessarily have more than one workspace, one of which can take the place of the staging area. This takes a

> If you can concurrently build/test and edit, you necessarily have more than one workspace, one of which can take the place of the staging area. This takes a really narrow view of what software projects can be hosted in git. If you're working on a huge project which must be built (at least for full builds) and tested "in the cloud", which you trigger by pushing to a temporary remote branch, then no, you need not have more than one workspace. If you're a webdev, then yeah, gitless or any other git workflow without the staging area might be useful for you.

prodigal_erik 10y ago
I'm sure that workflow can be made to work, but if I had to answer the question "assume you can't test on your editing box nor edit on your testing box, so how do you get source from your editing box to your testing box?" git would not be anywhere near the top of my list of solutions because it leaves known-bad commits pushed that need to be contained like waste.
- belovedeagle 10y ago
  I think you still don't get this whole "git" thing. Commits are just read-only collections of diff chunks plus metadata, nothing more. It's up to you to define where the boundary is for "bad commits shouldn't be here". Git commits are nothing like SVN or CVS commits (or whatever they're called). Trying to use some other arcane or error-prone mechanism for getting changes onto test machines is exactly what will leak bad code, because inevitably people will end up sending around zips full of code from who-knows-where for who-knows-which-change.
  - prodigal_erik 10y ago
    If you're going to condescend to a stranger, be right. A commit conceptually has a tree of complete blobs that git will diff as needed. git has options that make it more or less sensitive to differences even between unrelated files, so it ignores any delta encoding that may or may not be used in packfiles (and never in loose objects). If you're making an efficiency argument, git doesn't really try to beat the rsync algorithm even if you ignore the metadata. If you're making a "some people know git and nothing else" argument, fix the team, because that's a serious deficiency.
    - belovedeagle 10y ago
      > A commit conceptually has a tree of complete blobs that git will diff as needed You're a bit confused about the difference between "concept" and "implementation". There's multiple ways to conceptualize git, but the one I offered is the one presented by the default porcelain while the one you offered is closer to the implementation. The encoding used for storage is entirely irrelevant to my point. Anyways, my point had nothing to do with efficiency but was related to the topic at hand; that is, whether it it safe to use git to put code on test machines, and indeed whether that's safer than the alternatives. Nothing you said really addresses that point.

prodigal_erik 10y ago

I'm sure that workflow can be made to work, but if I had to answer the question "assume you can't test on your editing box nor edit on your testing box, so how do you get source from your editing box to your testing box?" git would not be anywhere near the top of my list of solutions because it leaves known-bad commits pushed that need to be contained like waste.

belovedeagle 10y ago
I think you still don't get this whole "git" thing. Commits are just read-only collections of diff chunks plus metadata, nothing more. It's up to you to define where the boundary is for "bad commits shouldn't be here". Git commits are nothing like SVN or CVS commits (or whatever they're called). Trying to use some other arcane or error-prone mechanism for getting changes onto test machines is exactly what will leak bad code, because inevitably people will end up sending around zips full of code from who-knows-where for who-knows-which-change.
- prodigal_erik 10y ago
  If you're going to condescend to a stranger, be right. A commit conceptually has a tree of complete blobs that git will diff as needed. git has options that make it more or less sensitive to differences even between unrelated files, so it ignores any delta encoding that may or may not be used in packfiles (and never in loose objects). If you're making an efficiency argument, git doesn't really try to beat the rsync algorithm even if you ignore the metadata. If you're making a "some people know git and nothing else" argument, fix the team, because that's a serious deficiency.
  - belovedeagle 10y ago
    > A commit conceptually has a tree of complete blobs that git will diff as needed You're a bit confused about the difference between "concept" and "implementation". There's multiple ways to conceptualize git, but the one I offered is the one presented by the default porcelain while the one you offered is closer to the implementation. The encoding used for storage is entirely irrelevant to my point. Anyways, my point had nothing to do with efficiency but was related to the topic at hand; that is, whether it it safe to use git to put code on test machines, and indeed whether that's safer than the alternatives. Nothing you said really addresses that point.