On Fri, Jun 27, 2008 at 11:15 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. We are seeing eye-to-eye here. > But I agree with you that calling the index half-baked is missing the > point. What I said is that the index is a half-baked version of _what I want_, which is the ability to do partial commits from testable states. Clearly the index is a way to do partial commits, but it does not address the "untested state" issue, so it is only halfway there, i.e., half-baked. > 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). Fair enough. I did not mean "half baked" to be particular provocative, fwiw. > 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. Exactly. That was a good summary of the workflow I proposed in my original email. > 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. Bingo. Time permitting, I will propose a more well thought through UI for this workflow. If you like it, we can talk about how it might be implemented. Thanks, Bob -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
