5 ms·

This seems to boil down to a criticism of the staging area, so it is strange its purpose is never clearly explained in the paper. The reason why the staging are

by stiff 13y ago

This seems to boil down to a criticism of the staging area, so it is strange its purpose is never clearly explained in the paper. The reason why the staging area exists, is, I think, that for larger teams working long term on a code-base, it is crucially important for the version control history to be very, very neat, with logically separate changes in separate commits, with very clean commit messages for each change, with the right changes going to the right branch (eg. you don't want to commit a change that can go live immediately to a branch that's going to be released in 3 months) and so on. That's also why git makes rebase such a big deal, I guess Linus spends a lot of time getting people to use the VCS right even after the changes themselves are more or less right, and thanks to rebase and the distributed model he at all is able to do corrections related to version control and branch/release management before changes enter the main repository. People aren't really good in remembering about those things up front, that's why Git introduces the staging area, so that you can work as usual and only after you are finished with whatever was occupying your mind you can consider splitting your work into nice commits, which can be quite a task in itself to do right. If you remove the staging area, and want to incrementally build up a few commits from the changes you made, you end up having to pass in again and again a lot of parameters to the commands executed, first to git diff, then to git commit, and it's easy to do a mistake and diff something other than the changes that will actually be comitted in the end. A lot of people, especially in small teams, use version control very sloppily, and then get confused about conflicts, changes are hard to track down in history etc. Remember that Git was build for maintaining Linux, which has an absolutely huge number of people working in parallel - in this case you really, really have to care about using the VCS tidily, actually understanding its concepts very well, and not just churn away commits, or you will just fail to integrate the changes correctly. So, frankly, while I like the general discussion in this paper and its approach, it seems to me a bit confused with respect to Git, I wonder whether the authors have any experience in doing long-term software development in a team and especially doing software integration and in using a VCS for that purpose. Once you have a few people, or more than one team working on a project, a few testing servers, and a few different release branches, the concepts in Git do make a lot of sense.

haberman 13y ago
Staging seems like a perilous way of creating clean commits. If you make a commit out of only some of the changes in your working tree, the result of a commit will be a filesystem state that never existed in your working directory, and thus was very likely not tested as committed.
- etherealG 13y ago
  if you don't trust yourself to make that judgement, try this workflow: stage, commit, stash now your working copy does match the state you committed, and you can test away to your hearts content. if you find a problem, fix it, and commit --amend. keep this cycle going till you're done. stash pop, carry on working almost every time i see a criticism of git it's about the way you use it not the tool itself.
  - caster_cp 13y ago
    >almost every time i see a criticism of git it's about the way you use it not the tool itself. In my point of view, you cannot separate "the way you use the tool" with the "tool itself". A hammmer is easy and straightforward to use because of its design features. That is what makes the hammer useful. Granted that there are complicated tools, that require a steep learning curve (a pipe organ, for instance), but that should not be the case of git. The whole point is that the tool should make it easy for you to do what you intend to do. That's the whole point of criticizing an application (or tool, as you put it). I am pretty sure that you can make beautiful and exact things with Git, but the fact is that sometimes they are difficult to perform or counter-intuitive, and that's the crux of the criticism. A tool should not be designed only to "allow" people to do certain things. It should also make these things easy and straight forward. It's impressive how (most of the times) our usage of a tool is directly linked to how it was designed. Therefore, design features (like the ones proposed in the article) cannot be distinguished from the "core" of the tool, or the functionalities it allows one to perform. The design, in some sort of way, is the tool. And that's what conditions our usage of it.
    - 13y ago

by stiff 13y ago

haberman 13y ago

Staging seems like a perilous way of creating clean commits. If you make a commit out of only some of the changes in your working tree, the result of a commit will be a filesystem state that never existed in your working directory, and thus was very likely not tested as committed.

etherealG 13y ago
if you don't trust yourself to make that judgement, try this workflow: stage, commit, stash now your working copy does match the state you committed, and you can test away to your hearts content. if you find a problem, fix it, and commit --amend. keep this cycle going till you're done. stash pop, carry on working almost every time i see a criticism of git it's about the way you use it not the tool itself.
- caster_cp 13y ago
  >almost every time i see a criticism of git it's about the way you use it not the tool itself. In my point of view, you cannot separate "the way you use the tool" with the "tool itself". A hammmer is easy and straightforward to use because of its design features. That is what makes the hammer useful. Granted that there are complicated tools, that require a steep learning curve (a pipe organ, for instance), but that should not be the case of git. The whole point is that the tool should make it easy for you to do what you intend to do. That's the whole point of criticizing an application (or tool, as you put it). I am pretty sure that you can make beautiful and exact things with Git, but the fact is that sometimes they are difficult to perform or counter-intuitive, and that's the crux of the criticism. A tool should not be designed only to "allow" people to do certain things. It should also make these things easy and straight forward. It's impressive how (most of the times) our usage of a tool is directly linked to how it was designed. Therefore, design features (like the ones proposed in the article) cannot be distinguished from the "core" of the tool, or the functionalities it allows one to perform. The design, in some sort of way, is the tool. And that's what conditions our usage of it.
  - 13y ago