Re: On the adoption of transient.el

["Óscar Fuentes" <ofv@wanadoo.es>]

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.

> 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. 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". However, you still need to
know the basic concepts of Git to use Magit.

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.

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.
Thanks to this you can end with a tidy series of commits, which are much
more adequate for the public consumption (suppossing that the public is
more interested on how the feature is implemented that on your personal
method of writing code.)

>> 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.) Also, please note that "modern VCSes" are not
an homogenous bunch, there are big differences among them, and those
differences will increase with the new wave of VCSes (see Pijul, for
instance.)