Re: An alternate model for preparing partial commits

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

I've always said that I am not in favor of any form of partial commits, exactly for the reason Robert states, namely that you are not committing what you had in your work tree as a whole. I said so back when the only form of partial commits were "git commit [-o] this-file". I said it again even when I introduced "add -i", that the interface goes backwards and does not fix the issues associated with partial commits.

But I agree with you that calling the index half-baked is missing the point. The index is merely the lowest level of facility to stage what is to be committed, and there is no half nor full bakedness to it. The way the current Porcelain layer uses it however could be improved and Robert is allowed to call _that_ half-baked when he is in a foul mood (even then I would rather prefer people to be civil on this list).

So I would welcome constructive proposals to make things better.

But before going into the discussion, to be fair, I would mention that people who are used to partial commits (perhaps inherited from their CVS/SVN habit) defend the practice by saying that they will want to make commit series first (with unproven separation between commit boundaries that is inherent to the practice of making partial commits) and it is not problem for them that their commits are not tested at commit time, because they will test each step afterwards after they are done committing. They can fix things up later with "rebase -i" if they find glitches.

The defense makes sense from the workflow point of view, in that batching things up tends to make people more productive. You think of the logical separation first and make commits without having to wait for each step to build and test (otherwise your train of thought would be interrupted), and then you test the final resulting sequence as a separate phase. Although I imagine I would personally not be able to work that way comfortably, I consider this a personal preference issue, and if some people are more productive to work that way, it is fine to support the workflow.

But that is not a reason not to support other workflows.

I would actually go the other way. I think the problem we are trying to solve here in this thread is to support this (other) workflow:

    You keep working, and eventually build all the changes intermixed in
    your work tree, perhaps without any commit, or perhaps with a commit
    sequence that is only meant as snapshots and not as a logical
    sequence.  Your work tree state is in good shape right now (you do
    build and test at this "commit goal" state).  Now you would want to
    split the changes while making sure each step is good (i.e. builds and
    tests fine as well as the patch makes sense standalone).

One thing I think would make sense is to stash away _everything_ at this point. That would take you to the state before you started working. Then if we can selectively _unstash_ the parts that should logically be committed first to bring them to your work tree, then you can inspect that change against HEAD, test it, and when you are happy with it, you would make your first commit in the final sequence.

Once you have capability to unstash selectively and make that first commit in the final sequence like so, breaking up the remainder that is still in your stash to a reasonable sequence of commits can be done with the same workflow. Unstash the next batch, inspect, test and be satisfied and then commmit. Lather, rinse and repeat.