[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: git apologia [was: git pull fails with merge conflicts. ...]

From: Eli Zaretskii
Subject: Re: git apologia [was: git pull fails with merge conflicts. ...]
Date: Sat, 15 Nov 2014 18:51:51 +0200

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: address@hidden
> Date: Sun, 16 Nov 2014 01:25:30 +0900
> But most important, as an Emacs developer, you understand how conses
> work, and how to manipulate a Lisp list using car and cdr and push.
> So you don't need to study "git semantics" *at all*, because you
> already have a wealth of experience with them, once you grasp the
> (very accurate) analogy.

I understand that.  My point is that, while I do want to reason in
these terms about Emacs, which I help developing, I prefer not to have
to reason about Git in any similar way or to a similar depth.  I just
need to get the job done quickly, efficiently, and without errors.
Again, using Git is tangential to my interest here, which is develop
Emacs.  I don't want to know about its internals more than I know
about GCC, for example.

> "<program> <command> has different semantics" is not what I understand
> when someone says "I don't understand <program>'s semantics."

Well, I'll take my "English is not my first language" refuge here.

> But OK, yes, that's an issue users would (justifiably) rather not deal
> with.  If that's all you meant by "don't understand git semantics",

I did.

> you have my sympathy, but I think the majority of Emacs developers are
> going to be very pleased by the efficiency and power of git, and even
> you may find after a few months that vc and/or magit have improved to
> the point where you don't have to deal with git CLI at all any more.

I wasn't arguing for dropping Git, okay?  You asked me what was
confusing, and I explained in response what makes the learning curve
steeper than it could have been.  Once the decision was made to switch
to Git, I don't think anyone here heard me complaining (unlike what we
heard about bzr).

>  > The other result is that to see the diffs of the last commit, it is
>  > much easier to use "git show" than the more obvious "git diff".
> "git diff <commit>" has historical, and useful, semantics.  IMHO,
> "git show <commit>" is a surprisingly elegant UI for what it does,
> considering that this is git. :-)
> Sure, they *could* have implemented "git diff -c" as hg and bzr do,
> but I like "git show" better.  YMMV.

MMDNV.  But the point is that I need either forget about "git diff"
and switch to "git show" entirely, or use the former as replacement
for the "-c COMMIT" use case, and the latter for the others.  IOW, one
more thing to re-learn, that won't serve me with any other VCS.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]