Re: [Census] So who uses git?

Carl Worth <cworth@cworth.org> writes:

I agree it is a worthy goal. Unfortunately I lost my git virginity long time ago, so a fresh perspective is really appreciated in this discussion.

As Linus mentioned in an earlier message in this thread, one of the important task for him is to take other peoples' trees and merge it into his mainline. The workflow goes like this:

	$ git pull from-somewhere
        ... oops there are conflicts
        $ edit conflicted/file
        $ edit more/conflicted/file
        ... maybe compile test ...
	$ git diff -c ;# final sanity check
        $ git update-index conflicted/file
        $ git update-index more/conflicted/file
        $ git commit

He does *not* want to do "git commit -a" here, because he usually has unrelated changes in his working tree he has not done update-index on and does _not_ want to commit [*1*]. "git commit" to imply "git commit -a" increases the risk of accidentally committing those unrelated changes mixed in the merge (eh, actually makes the risk 100%).

We _could_ detect that we were in the middle of a merge, enumerate the paths touched by the merged branches. Then we can say paths that are different between the index and the working tree and not in the paths touched by the merge are his unrelated changes. But it is conceivable he may need to modify a file neither branch touches in order to _logically_ resolve the merge, even when the merge phisically does not conflict in textual diff basis, so while that heuristics may work pretty well most of the time, doing so might make things even less easier to explain to other people.

[Footnotes]

*1* The reason he has unrelated changes while doing a merge is because he works on things himself (I am speculating about this), and for these modified paths he never runs git-add nor git-update-index until he is ready to commit his changes (I am not speculating about this). As long as he knows what he is pulling in from outside does not overlap with what he has been working on, he can merge and commit the result without worrying about his own unrelated changes, and git is careful not to touch anything in his working tree to cause information loss when the changes do overlap [*2*].

He is committing something that he never tested himself in his working tree as a whole. The tree resulting from the merge never existed outside his index file, so there is no way he could have even compile tested it properly. But for somebody who is playing an integrator's role, it is not his primary job to examine and test every change he merges in as a whole at nitty-gritty level -- that is what the originator of the change should have done. So having uncommitted changes in the working tree for an integrator person is not a sign of bad discipline at all, and supporting this workflow _is_ important for git.

The primary reason I first got involved in git was because I wanted to help the workflow of the kernel people, especially Linus and the subsystem maintainers. To be honest, I personally still consider the kernel people the first tier customers for me, and I stop and try to think twice when thinking about a change or a new feature that may help individual developers and newcomers, to make sure such a change does not make life less convenient for the 'integrator' people. Helping integrators to be more efficient is important because they can become bottlenecks.

*2* I once got yelled at by Linus when I carelessly broke this feature and changed 'git-merge' to require a clean working tree without changes before starting a merge; it was quickly reverted.