Re: VC mode and git

[Eli Zaretskii <eliz@gnu.org>]

> From: Thien-Thi Nguyen <ttn@gnu.org>
> Date: Wed, 25 Mar 2015 23:31:18 +0100
> 
>    The relevant question is: would this be useful in enough use
>    cases to justify the feature, at least as an option?
> 
> I think the time when people would respect VC imposing its
> unified model on the underlying VCS is past.

I'm not talking about imposing some model, I'm talking about
recognizing useful and frequent patterns, and then codifying those in
"C-x v v".  See below for the patterns I can easily identify.

Besides, if someone feels "C-x v v" is not for them, they can just
refrain from using it.  That command certainly isn't imposing itself
on users, does it?

> When they were all centralized, such an imposition lifted the burden
> of having to remember fiddly details such as command-line options.

That's not my understanding of the "C-x v v" usefulness.  IMO, it has
very little to do with "centralized".  It had much more to do with the
fact that there is a particular order/pattern of VC commands one needs
to perform while working on changes.  Look at the doc string of
vc-next-action, and you will see that pattern clearly identified for
RCS.

A dVCS, IMO, makes this single-pattern approach too limited, because a
dVCS enables many more workflows that were unavailable with RCS and
its ilk.  But that doesn't mean there are no patterns at all, or that
the patterns are limited to what vc-next-action currently supports for
a dVCS.  Again, if you read the doc string for "merging-based version
control systems", whatever that means, you will, I think, agree that
vc-next-action is next to useless for a modern dVCS, because it
basically always commits and does nothing else.

> But the schism between centralized and distributed is here, and here
> to stay, and so a unified model spanning these models now is an
> impediment to fully exploiting the tools.

The lack of a _single_ pattern doesn't mean there are no patterns at
all.  Here's what I do all the time in Emacs maintenance, when I need
to make a change that is a single one-off job I expect to take an hour
or so:

  . git pull
  # make changes, build, fix errors, test, fix bugs, write logs
  . git pull
  . if new files added:
    . git add NEW-FILES...
  . git status -s
  . git commit -a
  . git show
  . if I found some deficiency in the commit, looking at "git show" display:
    . git reset HEAD^
    # fix whatever needs fixing
    . git commit -a
    . git show # verify all is OK now
  . git push
  . if push rejected:
    . git pull
    . if conflicts found:
      . fix conflicts
      . git commit -a
  . git show
  . git push

I see a clear, non-trivial pattern here that is useful enough to have
vc-next-action remember it for me.  I also am quite sure I'm not the
only one who uses this pattern, perhaps with minor deviations.

There are other useful patterns, e.g., when I work on a larger feature
on a separate branch.  As long as I just make changes and commit them,
the pattern is

   # make changes, build, fix errors, test
  . if new files added:
    . git add NEW-FILES...
  . git status -s
  . git commit -a

Once I want to land the feature on a public branch, there's another
pattern, something like

  . git checkout master
  . git pull
  . git merge FEATURE
  . if there are conflicts:
    # resolve conflicts
    . git add FILES-THAT-CHANGED
  . git status -s
  . git commit
  . git show
  . git push

Etc. etc. -- the only difference is that there are several widely used
patterns instead of just one.

Why can't vc-next-action support these patterns?  If it needs to be
told which pattern to use, that can be solved by a simple command that
is unlikely to be needed too frequently, and so is not an annoyance.

> It's a lose/lose situation when DWIM must straddle disparate M based
> on disparate models.

I don't see where this could lose, and so I don't share your
pessimism.  Having such patterns is certainly a win for people who
don't commit/push changes frequently enough to have the patterns burnt
into their finger memory, because even the simplest patterns are much
more complex with a dVCS than they were with RCS, see above.

And I didn't even start talking about a plight of someone who needs to
use more than one VCS.  Contemporary projects use Git, SVN, and
Mercurial, so remembering the subtly different semantics of their
commands is a burden, especially if you use some of them rarely.
That's where vc-next-action could shine.

> That said, within any particular camp (cent or dist), some
> unification is still possible (and desirable).  But the thrust
> should be away from DWIM and towards clean primitives exposed
> directly to the user.  Centralized camp is already happy.
> Distributed is only one lacuna away from happiness (IMHO).

I see no "centralized vs distributed" schism here.  What I see is the
need to generalize DWIM in a useful way for the modern VCSes.  Having
several DWIM patterns switchable by user commands seems to be one such
useful generalization.  Maybe we could even do better by having VC
intuit the pertinent pattern(s) for at least some cases and suggest
them, or default to them unless told otherwise.

IOW, vc-next-action, IMO, is about making complex, but routine tasks
easier on users, by serving as a substitute for their (absent) finger
memory.  I think having this would be a Good Thing, and is certainly
not impossible.  Patches are welcome, as always.