26 ms·

My commit workflow goes like this: I run git diff, look at the first file that has changed, and then if it looks good, I add that file. At this point I may noti

My commit workflow goes like this: I run git diff, look at the first file that has changed, and then if it looks good, I add that file. At this point I may notice a stray print() statement or something, and delete it, then hit add. I rinse and repeat until I've read everything that I'm about to commit and verified it's what I want. I've been using mercurial for a couple months for work, and I miss the git staging area workflow. I dislike just assuming all the modifications I've made are good to go, I think the focus git's staging area steers you toward is really valuable.

bendbro 10y ago
Did you reply to the wrong comment? Your comment seems off topic relative to the parent. Regardless, your workflow of 'git diff' on staging with 'add's functions the same as 'git diff HEAD~' on a commit with 'commit --amend's
- lukeschlather 10y ago
  I think you (and the parent) are totally misunderstanding what I and probably most other people use git's staging area for if you think that git diff HEAD~ does the same thing. To illustrate a little more explicitly, a typical workflow goes like this: git diff git add file1 git diff git add file2 git diff ... git commit Now yes, you could replace `git add fileX` with `git commit --amend fileX` but I don't see that as a better interface. There are lots of circumstances where I rewrite history, but if there's a workflow that doesn't involve rewriting history, I'll take that one please.
  - tene 10y ago
    To make this point a little more directly, and in a similar way to what the article talks about, using "git commit" for this is using the same command for two different things, and makes it easier to make mistakes. Treating the staging area differently from commits means that you'll never accidentally alter a commit that has already been pushed, or accidentally add changes to a commit that you didn't intend them to be in. Yes, you can implement this workflow with commit --amend, but it's nice to have support from the tools to distinguish between "possibly-incomplete changes that I've signed off on as part of preparing a larger change set" and "completed, approved changes that may have been pushed to other people". Yes, you can implement this by committing each change and then later rebasing them, but that's even worse from a perspective of the tools supporting the workflow directly.
    - bendbro 10y ago
      I absolutely agree with you. There is good reason to differentiate staging from commits, I was just curious why he seemed to think it couldn't be done.
  - bendbro 10y ago
    I am imagining treating the last commit as your staging area. Am I missing something that makes that impossible? Specifically, what is the operation that you can't map from staging to a final commit?
    - acemarke 10y ago
      Unstaging, maybe? I use SourceTree, so I don't have to remember the specifics of staging-related commands vs commit-related commands. It's just right-click > "Stage / Unstage File", click "Stage / Unstage Hunk" or shift-click "Stage/Unstage Lines". Undoing part of a commit to be the equivalent of an "Unstage" action is feasible, I'm sure, but I couldn't tell you off the top of my head exactly what that command would be. So overall, part of it is that it's a mental model, part of it is that the concept is built right into Git.
krupan 10y ago
Mercurial patch queues are very similar to the index: http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues/ http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercu...

bendbro 10y ago

Did you reply to the wrong comment? Your comment seems off topic relative to the parent. Regardless, your workflow of 'git diff' on staging with 'add's functions the same as 'git diff HEAD~' on a commit with 'commit --amend's

lukeschlather 10y ago
I think you (and the parent) are totally misunderstanding what I and probably most other people use git's staging area for if you think that git diff HEAD~ does the same thing. To illustrate a little more explicitly, a typical workflow goes like this: git diff git add file1 git diff git add file2 git diff ... git commit Now yes, you could replace `git add fileX` with `git commit --amend fileX` but I don't see that as a better interface. There are lots of circumstances where I rewrite history, but if there's a workflow that doesn't involve rewriting history, I'll take that one please.
- tene 10y ago
  To make this point a little more directly, and in a similar way to what the article talks about, using "git commit" for this is using the same command for two different things, and makes it easier to make mistakes. Treating the staging area differently from commits means that you'll never accidentally alter a commit that has already been pushed, or accidentally add changes to a commit that you didn't intend them to be in. Yes, you can implement this workflow with commit --amend, but it's nice to have support from the tools to distinguish between "possibly-incomplete changes that I've signed off on as part of preparing a larger change set" and "completed, approved changes that may have been pushed to other people". Yes, you can implement this by committing each change and then later rebasing them, but that's even worse from a perspective of the tools supporting the workflow directly.
  - bendbro 10y ago
    I absolutely agree with you. There is good reason to differentiate staging from commits, I was just curious why he seemed to think it couldn't be done.
- bendbro 10y ago
  I am imagining treating the last commit as your staging area. Am I missing something that makes that impossible? Specifically, what is the operation that you can't map from staging to a final commit?
  - acemarke 10y ago
    Unstaging, maybe? I use SourceTree, so I don't have to remember the specifics of staging-related commands vs commit-related commands. It's just right-click > "Stage / Unstage File", click "Stage / Unstage Hunk" or shift-click "Stage/Unstage Lines". Undoing part of a commit to be the equivalent of an "Unstage" action is feasible, I'm sure, but I couldn't tell you off the top of my head exactly what that command would be. So overall, part of it is that it's a mental model, part of it is that the concept is built right into Git.

krupan 10y ago

Mercurial patch queues are very similar to the index: http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues/ http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercu...