4 ms·

You make it sound like a commit is some final immutable set-in-stone thing and so you need staging area. Commits are only "set in stone" after you share (push

• acemarke 10y ago
  You're still missing my point. My preferred workflow is to iteratively put together the pieces I want, and only hit the "commit" button when I'm pretty sure I've got it crafted the way I want. Sure, I _can_ rebase, amend, and rewrite commits after creating them, assuming I haven't pushed them yet, but I'd much rather do it _before_ the commit is created. At first glance, this "gitless" tool doesn't seem to really support that workflow.
  • derefr 10y ago
    Why, though? What's the difference between a staging area that you convert into a commit, and an initially-empty commit that acts as a staging area, that you "commit" by just not modifying it any more, and instead creating a new empty commit (new staging area) to work in? They're bijective mappings of the same data, with the same actions triggered at the same points in a workflow. The only difference is what you label the actions. To go further: how do you feel if you think of all your un-pushed commits as simply "a chain of staging areas"? What if "committing" was something that happened at git-push time, and until then, you just created staging-area after staging-area and populated them with patch-chunks? Because this would also be a bijective mapping, involving the same actions in the same places.
    • lukeschlather 10y ago
      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.
• makomk 10y ago
  Which means that if you amend commits, you need to keep track of whether or not you've shared them with others yet.
  • krupan 10y ago
    Which mercurial does for you (see: phases), but you are right, I forget that git does not help you there.