Re: VC mode and git

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: address@hidden,
>     address@hidden
> Date: Sat, 04 Apr 2015 02:31:29 +0900
> 
> Eli Zaretskii writes:
> 
>  > I'm saying that trying to explain to newbies what a merge does by
>  > being "technically correct" is not helpful.
> 
> Being technically *incorrect* is even less helpful.

Teaching people new things often requires to start without rigor,
because otherwise you risk losing your audience.  Being "technically
correct", but confusing instead of explanatory is not helpful.

>  > I don't even understand all this attitude: do we want Git newbies
>  > to become more proficient in using Git,
> 
> No, we want to support their efforts to become more productive using
> git.

Take it from a bystander: that's not how many messages in this thread
sound.

> If they want to become proficient, I don't think there's any
> problem.  But Alan and Richard have expressed a rather strong desire
> to learn *nothing* about git

They didn't say that, please re-read their messages with open eyes.

What they did say is (a) they don't like investing an inordinate
amount of time and effort into studying Git, and (b) they would like
to keep their previous workflows as much as possible.

So if we want to help them become proficient, we need to go with them
and educate them while trying to honor these 2 desires.  Any other way
is bound to trigger bad feelings, and eventually fail our attempts to
help them become more proficient.

> yet insist on workflows that are infeasible if they remain ignorant
> of the details and options of git.

They are not infeasible.  They need only minor adaptations, see
GitQuickStartForEmacsDevs.  Those adaptations do not require any
details and options of git, just one new command.

> They can't have both; the first task is to make that clear, so that
> they can make their own choice as to whether to become proficient in
> git, or to adopt a workflow that is less than optimal according to
> their opinions.

That's one approach to teaching Git.  I think it's not a very
efficient one, at least in this case.  I think less radical approaches
might score better.

>  > If the former, why do we insist on being "technically correct"
>  > instead of explaining things in a way they could be understood?
> 
> Because it's entirely unclear to me what they are asking.

If you don't understand what they are asking, may I suggest that you
wait with your answers until you do, or ask someone else?

> Richard is incapable of describing what he actually did, yet bridles
> at any suggestion that his actions were involved in messing things
> up (despite repeated admissions that he forgot this or that).

What he did became clear, even to me, after he showed the information
we requested.

> They profess ignorance of git but assert that it is a "screw" and
> poorly designed.

People tend to become angry with a tool that seems to get in the way.
It's understandable.  If you want to help them, the last thing you
should do is become angry back, or somehow feel insulted on behalf of
the tool.  I make that mistake at times, and it never helps.

>  > No, it is described as "the action of storing a new snapshot of the
>  > project's state in the Git history by creating a commit object and
>  > advancing HEAD to point at the new commit".  By selectively omitting
>  > the parts of this description, you make it sound like I said
>  > something incorrect, which is false.
> 
> OK, you are correct, it is more than creating a commit object.  It
> also includes advancing HEAD.  How does that level of nitpicking
> advance the cause of explaining to Alan what a commit is?

It's for Alan to say if it's more helpful than saying that a merge is
"just a commit".  AFAIU, he explicitly expressed a desire to
understand what happens during a merge.  I think the above does help,
but that's me.

>  > > using the shorthand of "commit" for "commit object" described in the
>  > > noun section.
>  > 
>  > I already said that using shorthands in this discussion only increases
>  > confusion, and is not helpful to newbies who strive to understand a
>  > complex subject.
> 
> "Complain to the writers of the Git glossary, then.  I just read what
> they say there."

They stated a fact.  They didn't tell when to use that shorthand.

> You're perfectly capable of expressing yourself operationally; your
> post to Sergey was beautiful, concise and accurate, and after reading
> that I quite understood what you have been getting at the whole time.
> I wish you would write more posts like that.

Thanks, I'm trying.

> Your shouting about "READ!  READ!" on the other hand, is totally
> useless.

OK, I will try to avoid that.