Re: Making git as easy as CVS, for handling merge conflicts

[Adam Spiers]

On Thu, Nov 07, 2019 at 03:54:23PM +0200, Eli Zaretskii wrote: 
> > Date: Fri, 1 Nov 2019 14:52:21 +0000 
> > From: Adam Spiers <address@hidden> 
> > Cc: Taylan Kammer <address@hidden>, address@hidden 
> >
> > git uses fundamentally different paradigm to the model on which VC was 
> > designed.  One of many examples of this is that it requires staging changes 
> > before committing them.  My personal opinion is that it makes no sense to use a 
> > version control frontend which is totally outdated relative to the backend in 
> > question.  I enjoyed using VC for many years (and hacked various extensions to 
> > it), but it hasn't kept pace with the evolution of modern VCS frontends.  I 
> > estimate that its functionality is probably about 5% of what magit offers. 
>
> I wonder when did you last took a look at Emacs's VC.  It was 
> completely revamped several years ago to support dVCSes, and I'd be 
> surprised to learn that its functionality is only 5% of what Magit 
> offers; I think it's much more than that. 

Apologies if my knowledge is out of date.  I did a quick check before 
writing the above, and in the Version Control section of manual for 
26.1 I cannot find a single mention of staging, nor any obvious way to 
selectively stage hunks, let alone selected links within a hunk.  I 
could well be missing something, but it seems that maybe the manual 
hasn't kept pace, even if the code has. 

> Many active Emacs 
> developers routinely use VC, and since our VCS is Git, that gives us 
> some evidence about the functionality VC provides for Git. 

I was of course aware of the emacs source moving to git, but it's good 
to know that dogfooding on VC is occurring. 

> If you indeed didn't look at VC for several years, I urge you to take 
> another look.  You probably won't want to switch from Magit, 
> especially if you use only Git in your VCS-related work, but you might 
> change your mind regarding the current functionality of VC, including 
> when Git is the backend. 

Yeah, based on another quick glance I'd revise my estimate to maybe 20 
or 30%.  It seems that there are still huge gaps, for example support 
for rebase/squash/amend/cherrypick/bisect workflows, management of 
branches and remotes, and options for standard operations such 
logging.