Re: Considering teaching plumbing to users harmful

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 16, 2008, 18:18 UTC
Message-ID: <7v7iblsnfh.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <32541b130807161053w24a21d7bh1fa800a714ce75db@mail.gmail.com>

"Avery Pennarun" <apenwarr@gmail.com> writes:

Show 14 quoted lines

> On 7/16/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>  Am I the only one who deems teaching plumbing to users ("I like it raw!
>>  So I teach it the same way!") harmful?
>
> I believe the only way you can get away with such a simple learning
> sequence is if your workflow is as simple as that you seem to
> describe: everyone has push access to the central 'master'.
>
> That works (and mostly just as well as any other "supposedly easy"
> VCS, like svn), but because git's power is so tempting, almost
> nobody's real-life repository actually works like that.
>
> At the very least, there will be branches.  And where there are
> branches, there's merging.  And with merging comes merge conflicts.

Well, you are wrong. Even when people work only with a single branch 'master', once you have more than one repository involved, there's already merging. Dscho just described how he would guide new people into the process without going into the details in that message, by the time his audiences need merge conflict resolution they are already comfortable with the index.

>        git diff :{1,3}:path/to/filename
>
> Which is a great command, but svn definitely makes it easier to do the
> same thing.

I've never seen anybody who finds "diff :{1,3}:path" *useful*.

Well, if you are coming from SVN or CVS where a merge is just a large goo of everything that happened on a side branch squashed into one, perhaps it might look useful.

What you should learn and teach instead is:

	git log -p --merge

This shows individual changes from the commits involved in the conflict with rationale (of course your committers must be disciplined enough to write usable commit log messages for you to take full benefit of this). Add path/to/filename if you want to process one path at a time. Also adding --left-right to the command line may make it more understandable if you are merging two histories, both of which are from other people, and you do not know which commit is from which side of the merge.

> Even if you have a repo with widespread push access, git's log looks
> annoying compared to svn because of all the merge commits.  That's a
> primary reason why rebase was invented, of course.

Please don't talk nonsense if you do not know history. I invented rebase primarily because I wanted to help e-mail based contributors. There is nothing about merge avoidance to it.

You can skip merges with "git log --no-merges", just in case you didn't know.

I won't comment on the remainder but that is not because I agree with anything you said there ;-)