Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> On Thu, 26 Jun 2008, Robert Anderson wrote:
>
>> Seems to me the concept of the "index" is a half-baked version of what
>> I really want, which is the ability to factor a working tree's changes
>> into its constituent parts in preparation for committing them.
>
> Half-baked is probably too strong a word.
>
> What you are basically asking for is to have the working directory
> as staging area, and to be able to stash away changes that are not to be
> committed.
>
> Now, this is not necessarily what everybody wants, which is why many
> people are fine with the index.
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.
> Having said that, I played with the idea of a "git stash -i", which would
> allow you to select the changes to stash away.
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.
--
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
