"Avery Pennarun" <apenwarr@xxxxxxxxx> writes:
> On 7/16/08, Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 ;-)
--
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
