Re: [PATCH] add commit --interactive

I am guilty of introducing "add --interactive" and am somewhat regretting it.

Why?

Because it encourages a wrong workflow, but the word "wrong" needs to be clarified.

The workflow assumed by "add --interactive" (hence by its wrapper, "commit --interactive") goes like this:

 1. You have some large task.  You start hacking and keep hacking
    and hacking.

 2. Your working tree might still be a messy state, but there are
    some good bits in the mess that are worth committing on their
    own, excluding the other changes in the working tree.  This
    could happen for a number of reasons:

    - You might be actually done with the change and your working
      tree is perfect, but the change since the HEAD commit is
      too big to be a single logical change.  You want to split
      the changes into smaller steps.

    - You might be still in the middle of what you initially
      wanted to achieve, but at the same time you found
      something worth changing, which is independently useful
      regardless of what you are doing.  It may be a typo.  It
      may be a bug that might or might not affect what you are
      doing.  But as long as you found it and fixed it, you
      would want to make a separate commit.

 3. So you would fire up "add --interactive", and isolate the
    "good bits" by updating the index selectively to prepare for
    commit.  You would run "diff --cached" to review the change
    you are going to commit makes sense, and then finally make a
    commit.

I am not saying the first two steps are wrong. Everybody does that all the time.

What's wrong is the approach "add --interactive" takes in the last step. The isolation of "good bits" happens in the index, not in the working tree --- which is largely because git is designed to commit the state recorded in the index --- but that encourages the user to commit something that has never been in the working tree, so by definition what is committed in step 3 never could have been even tested. And that is what I feel is very wrong. People in the past claimed that they later would go back to each individual commit and test them, but that is simply hard to believe, because it is tedious in practice.

We should be able to do better than that. Instead of the step 3 in the above, we could have a way to quickly stash the working tree state, reset the working tree to that of the last commit (or whatever commit we want to build a new commit on top of), and selectively apply parts of the the changes we stashed to the working tree. Then we can test the state in the working tree, and run "commit -a" as usual. What's still left in the stashed state can incrementally be trickled in to make further commits.

Probably the operation would go like this. I'll describe them in terms of lower level operations, and leave the scripting to others.

* Stashing the current state

        git commit -a -m 'stashed'
	git tag -f stash
        git reset --hard HEAD^

  After this point, "diff stash^ stash" is the changes yet
  to be applied.

* Switch to the commit you want to apply part of what was
  stashed to.  This part is optional if you are only building on
  top of the current HEAD, but if you have a small but urgent
  bugfix you might want to switch to another branch (say,
  'maint').  There is no magic command needed -- just run

	git checkout maint

  as usual, for example.

* Trickle some of the stashed changes in, perhaps interactively:

	git pick stash

  would probably give an interactive UI similar to "add -i" to
  let you pick and choose from "git show stash" (either per-hunk
  or per-path), but unlike "add -i", which applies the chosen
  change only to the index, it applies the change to the working
  tree and to the index.  As the last step of its operation,
  "git pick" would save the resulting index state as a tree:

	git tag -f pre-fixup `git-write-tree`

* Review and test the change in the working tree.  This does not
  need any special command.  You may also make fix-up in the
  working tree as usual.  Then you would make a commit, perhaps
  using the usual "git commit".

* Then this is the tricky and interesting part.  We need to
  subtract the change we already used to advance HEAD from
  "stashed changes".  I do not think we currently have a single
  command to do this step, but it would probably go like this.

  1. First, we build a tree that is stash^ plus the changes
     we committed right now.

	git read-tree -m -u stash^
	git merge-recursive HEAD^ -- stash^ HEAD
	NEW_TREE=`git write-tree`
        NEW_BASE=`echo stash | git commit-tree $NEW_TREE`

     This would make our working tree and the index match the
     state you would have had, had you started from the original
     state and made only the changes you have committed just
     now.  Note that the resulting tree contains the manual
     fix-ups you made since pre-fixup.

  2. The tree state you would eventually want to have used to be
     in stash but that lacks the manual fix-up you made, which
     is the difference between pre-fixup and HEAD.  So let's
     update the final state with this difference:

	git read-tree -m -u stash
        git merge-recursive pre-fixup -- stash HEAD
	NEW_TREE=`git write-tree`

  3. The strategy is to keep stash pointed at a commit that has
     the tree state of what you eventually would want to have
     (which is now in $NEW_TREE), and represent the changes yet
     to be applied as "diff stash^ stash".  So let's update the
     stash tag:

	NEW_STASH=`echo stash | git commit-tree $NEW_TREE -p $NEW_BASE`
	git tag -f stash $NEW_STASH

* You just finished one step, and still have remainder that can
  be seen from "git show stash".  Go back to "Switch to the
  commit" step (or "Trickle some of the stashed changes" step)
  above and repeat.  The output from "git show stash" will keep
  shrinking, and when it becomes empty you are done.