4 ms·

The basics (stage, commit, merge, branch, push, pull, log, diff, bisect) aren’t confusing. (The rest isn’t that confusing either, but…) If you prefer GUIs, feel

The basics (stage, commit, merge, branch, push, pull, log, diff, bisect) aren’t confusing. (The rest isn’t that confusing either, but…) If you prefer GUIs, feel free to use them, but that’s certainly not everyone.

recursive 10y ago
I was at least a little confused by stage for a while. I still think the distinction between stage and commit is unnecessary at best.
- nolemurs 10y ago
  If you don't have `stage` how are you going to generate a commit which has only some of the changes you've done (potentially including partial commits from files)? `stage` is unnecessary if you have a really simple workflow, but it provides a lot of flexibility at very little cognitive cost.
  - recursive 10y ago
    By specifying the parts you want to include when you commit. I think it's unnecessary for any reasonable work flow, and doesn't manage to break even on its benefit vs. cognitive cost.
    - nolemurs 10y ago
      So you want a long command line argument were you tag specific line numbers and have to get it all right at once? That sounds terrible to me. Being able to add bits and pieces to your staging area and then once you've got it all ready commit is pretty useful. I guess I just don't see the cognitive cost as being particularly high. It's a pretty simple model.
      - krupan 10y ago
        You can add bits and pieces to commits directly with commit --amend. The index is really not needed.
      - recursive 10y ago
        I really would prefer not to even use a CLI for this operation, since I think it's not well suited to the kind of interaction commits entail. A "staging area" is a useful concept, but it's not one that needs to exist outside the UI of whatever tool you're using to generate the commit.
  - lobster_johnson 10y ago
    "git add -p" generally negates the need for incremental staging, unless you have made two unrelated changes to the same diff hunks that need to be untangled.
- tsm 10y ago
  I had a recent epiphany about staging, which is that it really starts making sense if you stage as you go. Let's say you want to write small feature X, and it truly makes sense for X to be a single commit. But doing X involves changing around both Y and Z. Git makes the following workflow easy: * Fiddle around until you get Y working how you want it * Stage it * Fiddle around trying to get Z to work. Try something experimental. Nope, that's not you want it. `git checkout .` Try again. You don't have to worry about only blasting away the failed Z attempt while preserving Y—since Y is staged, it's easy to keep around.
  - komali2 10y ago
    Technically the same metaphor can be used for "commit" if we assume you stage the one thing and commit that one thing. Now look through the same workflow again but replace "stage" with "stage it and commit it."
    - agentgt 10y ago
      You can also use shelve in mercurial. I have never needed to use it on git though because of staging/cheap branches.
  - krupan 10y ago
    But why stage when you can just commit? You can use rebase -i to modify that commit later if you need.
    - minitech 10y ago
      You might not want to commit all of your changes at once.
      - krupan 10y ago
        commit can be followed by a file name. Or there is commit --interactive or commit --patch to choose what to commit (or git add versions of those).
Certhas 10y ago
I disagree, the basics are confusing, because there is too much state. I think gitless (http://gitless.com/#vs http://gitless.com/#vs) shows how a less confusing version looks.
- minitech 10y ago
  State in the form of staged changes is a huge convenience to me (e.g. with git add -p), but to each their own.
- swift 10y ago
  Reminds me of hg patch queues, which I've always found to be drastically more error prone than git's staging feature when trying to commit some but not all of the changes you've made, but I haven't tried gitless and it may do it better.

recursive 10y ago

I was at least a little confused by stage for a while. I still think the distinction between stage and commit is unnecessary at best.

nolemurs 10y ago
If you don't have `stage` how are you going to generate a commit which has only some of the changes you've done (potentially including partial commits from files)? `stage` is unnecessary if you have a really simple workflow, but it provides a lot of flexibility at very little cognitive cost.
- recursive 10y ago
  By specifying the parts you want to include when you commit. I think it's unnecessary for any reasonable work flow, and doesn't manage to break even on its benefit vs. cognitive cost.
  - nolemurs 10y ago
    So you want a long command line argument were you tag specific line numbers and have to get it all right at once? That sounds terrible to me. Being able to add bits and pieces to your staging area and then once you've got it all ready commit is pretty useful. I guess I just don't see the cognitive cost as being particularly high. It's a pretty simple model.
    - krupan 10y ago
      You can add bits and pieces to commits directly with commit --amend. The index is really not needed.
    - recursive 10y ago
      I really would prefer not to even use a CLI for this operation, since I think it's not well suited to the kind of interaction commits entail. A "staging area" is a useful concept, but it's not one that needs to exist outside the UI of whatever tool you're using to generate the commit.
- lobster_johnson 10y ago
  "git add -p" generally negates the need for incremental staging, unless you have made two unrelated changes to the same diff hunks that need to be untangled.
tsm 10y ago
I had a recent epiphany about staging, which is that it really starts making sense if you stage as you go. Let's say you want to write small feature X, and it truly makes sense for X to be a single commit. But doing X involves changing around both Y and Z. Git makes the following workflow easy: * Fiddle around until you get Y working how you want it * Stage it * Fiddle around trying to get Z to work. Try something experimental. Nope, that's not you want it. `git checkout .` Try again. You don't have to worry about only blasting away the failed Z attempt while preserving Y—since Y is staged, it's easy to keep around.
- komali2 10y ago
  Technically the same metaphor can be used for "commit" if we assume you stage the one thing and commit that one thing. Now look through the same workflow again but replace "stage" with "stage it and commit it."
  - agentgt 10y ago
    You can also use shelve in mercurial. I have never needed to use it on git though because of staging/cheap branches.
- krupan 10y ago
  But why stage when you can just commit? You can use rebase -i to modify that commit later if you need.
  - minitech 10y ago
    You might not want to commit all of your changes at once.
    - krupan 10y ago
      commit can be followed by a file name. Or there is commit --interactive or commit --patch to choose what to commit (or git add versions of those).

Certhas 10y ago

I disagree, the basics are confusing, because there is too much state. I think gitless (http://gitless.com/#vs http://gitless.com/#vs) shows how a less confusing version looks.

minitech 10y ago
State in the form of staged changes is a huge convenience to me (e.g. with git add -p), but to each their own.
swift 10y ago
Reminds me of hg patch queues, which I've always found to be drastically more error prone than git's staging feature when trying to commit some but not all of the changes you've made, but I haven't tried gitless and it may do it better.