Junio C Hamano <gits...@pobox.com> wrote: > Dimitar Bonev <dsbo...@gmail.com> writes: > > [administrivia: please do not drop people out of Cc list] > > 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. >
It isn't an option to start from the staged state, because the staged implementation modified code that is present in the HEAD state. So the new implementation that I have in my mind requires to add its own kind of modifications which are incompatible with the staged implementation. It is much easier to start from HEAD state when both implementations require modifying 10% HEAD code and adding 90% new code. If I start from staged state I have to drop 90% new code and to figure out if the 10% modified state can work without the 90% dropped code. At the same time I know HEAD state is stable working code. There is no doubt that I have to start from HEAD state of the controller file for the described MVC example > > 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? > Yes, I 'git add' only what is to become part of the next commit so at least it has to be stable code (that passes some smoke tests or something similar). > 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. > My case was not like that but if it was I would have made a commit to preserve the old implementation while working on the new one. > > 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 ;-). I used the wrong words - I meant 'stable state' instead of 'finished work'. If every commit was finished work then all my branches would have contain one specific commit. My branches are built from more than one commit and every commit adds a subfeature and the commit should be stable in sense that it should run without throwing exceptions - like trying to load some file that would be created in a future commit. One should be able to checkout a random commit and be able to run, inspect, write tests against, add new subfeature on top of that commit. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
