Re: Cleaning up git user-interface warts

Linus Torvalds <torvalds@osdl.org> writes:

I had a bit different feeling about yesterday's discussion myself.

If somebody uses git like you do in "truly distributed way", the current pull behaviour and pull being an operational mirror to push are natural consequence of the model and concepts, and there is nothing to fix (modulo "the default merge source per branch" should be made easier to use). Renaming the pull to merge would not make it any easier to use unless the underlying model is understood, and I fully agree with you on that.

But for people working in a project organized around central repository in the CVS/SVN fashion, the workflow is quite different. CVS does not even let you "fetch" without either merging (co) or throwing away your work (co -C), and we already do support that model with:

	git clone
        git pull
        work work work; git commit
        git push
        : oops not fast forward?
        git pull
        resolve work; git commit
	git push

without ever using a local branch, any tracking branch, nor use of git-fetch. So we do support both extremes ("truly distributed" and "not distributed at all") reasonably well.

The trouble starts when the users hear about this wonderful "distributed" stuff git offers, and try to use it without understanding the key concepts. People tend to learn by doing and there is a leap the user need to make because now they need to understand branched development, branches and fetching like you explained if they want to use git the same way as you do. Once they understand them, then the current set of tools offer them a simple and very straightforward user interface (the tools directly reflect the concepts and it is straightforward only because we are talking about users who understood the concepts).

But we have to admit that this leap may rather be difficult for people who are used to other models. Telling them that our model is different and it is different for a good reason does not change the fact that the more different something is, the more difficult to learn it.

I suspect that there could be a way to use git, not like you or I do. Our workflows are already quite different (e.g. you almost never do topic branch merge yourself in your repository, but I have abundance of them). There is no reason to think there won't be other workflows that are suitable for other people. Some workflows might be classified less distributed and inferiour compared to the "truly git way" from "truly distributed is the point of git" point of view, but nevertheless could be "good enough" for those people. In other words, a workflow that is a bit more advanced than just a single trunk CVS/SVN usage could still take advantage of some of the features to support distributed development model git has, while not taking full advantage of truly distributed nature of git.

I think the complaints in the yesterday's discussion are mostly about frustration that, while we have a reasonable support for the both extremes, we do not either know what that middle ground workflow is, or even if we know what that is, we do not support it very well.

And I am not opposed to people exploring what that different workflow would be, and while they do so if they come up with a set of commands (get/put perhaps) to suppor that slightly different workflow, that would be a very good thing.

Add foreign SCM importers in the mix and the situation becomes more difficult and interesting. cvsimport mostly works and quacks like git-fetch with set of tracking branches, which I think is the right model for the importers, and would integrate well with the current set of tools. I believe svnimport is the same way. But I do not know about git-svn.