Re: On the adoption of transient.el

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 05 Aug 2021 16:45:29 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'm not sure we've used up the potential of "C-x v v" for Git.
> 
> The "C-x v v" workflow works for Git as far as you use Git as you use
> CVS.

Which is too little.  For example, the pull and push commands are part
of every simple Git workflow, but "C-x v v" doesn't support them,
AFAIK.  If you are going to claim that push and pull are not part of
"using Git as you use CVS", then I will claim that your notion of
using Git as CVS is pretty useless in practice.

> > I'd be interested to see a demonstration of how Magit makes doing some
> > fancy Git job without searching the Internet for solutions.  But
> > please take some really exotic job, not something semi-trivial.
> 
> AFAIK Magit is not advertised as a tool for doing exotic jobs without
> prior knowledge.

But if that is indeed so, and I still need to search the net for how
to do some non-trivial job with Git/Magit, then Magit will be less
helpful, because what I will find in my search will mostly be Git
commands from the shell prompt, and not their Magit equivalents.

> Magit is great at discoverability, ergonomics, and
> user-friendliness. This means that the capabilities of the tool are
> explicit, you operate the tool with a simple interface and the state you
> are operating on is obvious. Compare this with writing commands on the
> console (that you previously need to memorize) on a cycle of "see what I
> got -> do some change -> see what I got".

I'm afraid I'm not following.  If I find by searching the net the
sequence of Git commands to do some job, I just copy/paste them into
the shell window, and that's it.  And no need to memorize those
commands: the next time I need to do the same job, I do the net search
again.  Since the search hits the right answers very quickly, this is
very adequate for jobs I need to do rarely (which is why I don't
remember the commands in the first place).

What am I missing?

> But I'll try answering your request with two examples. First one: as you
> work on some feature you find and fix some typos here and there, or do
> some other quick change not directly related to your initial task. You
> end with those quick changes mixed with your main task. With Magit, it
> is trivial to separately commit the changes: on the Magit status buffer
> navigate to the fixed typos, select them as you select a region on
> Emacs, press `s' and the selected change goes to the staging area. Do
> the same for the rest and commit.

You mean, instead of selective "git add" (with or without -i) and/or
"git stash"?  I'm probably missing something, because I don't see how
that's significantly different.

> For the second example let's suppose that you implemented a complex
> feature as a series of commits on a branch. Those commits reveal all the
> gore details of your work: mistakes, backtracks, half-done subtasks,
> etc. Things that the rest of the world care nothing about. With Magit
> you can easily reorder, split, mix, rewrite, whatever, your commits.

I never do that.  I commit stuff and merge it exactly as I did
originally, and don't care what "the world" thinks about my mistakes
and back-tracking.  I _want_ to have the original history in the final
push.  That's why I always almost never use rebase.

> >> I do use other version control systems (especially SRC for single file
> >> "projects") and so having the same key bindings regardless of VCS is
> >> ideal for reducing friction.  This is where vc wins.
> >
> > Yes, and I think it could win more than it does now.  In general, the
> > adaptation of VC to modern VCSes is IMO incomplete, and we could do
> > much better.
> 
> I'm skeptical about this. VC works on some concepts that are hard to
> reconciliate with modern VCSes (as long as you want to take advantage of
> what those VCSes offer.)

The popular workflows are a few, and they cover 85% of typical usage.
It is true that at some points of the workflow there could be
ambiguity as to what should be the "next action", but that ambiguity
could be resolved either by some defcustom or by prompting the users,
asking them what would they want to do next from a short list of
possibilities.

So I think your skepticism is unjustified.

How about if we describe one of the simple Git workflows, and see how
hard would it be to come up with "C-x v v" support for it in its
entirety?

> Also, please note that "modern VCSes" are not an homogenous bunch,
> there are big differences among them

I'd be curious to see those big differences, specifically between Git,
Mercurial, and Bazaar.

> and those differences will increase with the new wave of VCSes (see
> Pijul, for instance.)

Let's bother about that when Emacs actually supports those.