Dimitar Bonev <dsbonev@xxxxxxxxx> writes:
[administrivia: please do not drop people out of Cc list]
> Actually this is not the case as I tried to explain with the 'git
> commit' followed by 'git checkout HEAD~1 -- targetfile' followed by
> 'git commit --amend' example. The index and the working dir states are
> very well related.
That invites another question: if it is very well related, why isn't
it an option to start from the state you have in the working tree
(i.e. doing nothing), or in the index (i.e. "git checkout
controller")?
But the answer does not matter that much in the end.
> Lets imagine that I am adding an MVC feature X - it
> could be implemented with 3 or more files. If I stage the files and
> came up with an idea that requires a major rewrite of one of these
> files - lets say the controller one - then it is more convenient to
> checkout the file's HEAD state and build on top of it - I had been
> doing just that right before staging
So you have satisfactory changes for view and model in the index,
and changes to the controller that maybe is OK but you think it
could be improved, and you want to go back to the clean slate to
rethink the approach only for the controller part?
I think the story is essentially the same. Let's say you did
git diff HEAD controller | git apply -R
edit controller
to get rid of the changes in the working tree, further worked on the
controller part, and came up with a different implementation. Then
you would presumably do
git add controller
but at that point you would lose the "maybe OK" version you had in
the index. What if you think the version in the working tree might
end up being better than "maybe OK" but can still be improved
further? You never "git add" until the working tree version gets
into truly a better shape?
What happens fairly often is that you end up having more than _one_
versions that are both better than the version from the HEAD but
cannot immediately say one is clearly better than the others in all
counts, and at some point, you would need more than one intermediate
states (while the index can have only one), to keep these competing
versions. The next thing you would want to do is to take a deep
breath and pick better parts from these good versions to come up
with the single final version. Keeping one good version in the index
does not let you do so.
> ... commits - I treat them as finished work.
I think people should learn to take the biggest advantage of using a
distributed source control system, which is that commits do not have
to be "finished work", until you choose to declare they are done and
push them out for others to see.
Fear of commitment is a disease we do not have to suffer once we
graduated centralized systems ;-).
--
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