Re: VC mode and git

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 25 Mar 2015 10:43:15 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, emacs-devel@gnu.org
> 
>   > Even when a remote has been declared, git cannot know about any sequence of 
>   > commits whether it's intended to be published to that remote.  It might be 
>   > exploratory programming, done with the option to reset to a prior state
>   > in mind.
> 
> 1. If that's what you want, why do a commit?  You can test the modified
> files without committing them.

Indeed, I generally commit after I tested.  But having written and
tested a small part of a large feature doesn't yet mean I'm ready to
publish it.  As a matter of fact, the small part that I've written and
tested might not be useful on its own right, or might even break other
features.  IOW, the tested code is incomplete.

So pushing might be inappropriate.  But I still want to keep the
history of mu changes recorded in the VCS, because if I later find
that I introduced a bug, I want to be able to see which change did
that.

And there are other good reasons to commit frequently without pushing.

Such workflows are widely used these days, and we cannot possibly
ignore them, even if you or someone else never uses them.  Users will
not forgive us if we do.

> 2. That is rather sophisticated use; a user who might want to do this
> would know how to get what he wants.  He could set a flag saying
> that C-x v v should not push in this repository, or whatever it takes.

Yes, pushing should be optional.  The question is how exactly to
implement the option, and whether "C-x v v" should do anything else
before pushing.  For example, I always do a "git show" before pushing,
to have one last look at what I will push and make sure I didn't miss
anything, or made some mistake.  Fixing mistakes in local commits is
easy; doing that after pushing is much harder (basically impossible,
except by another commit/push).

So perhaps "C-x v v" after a local commit should do a "git show", and
offer to push from there.

> In general, the messages opposing this change have presented arguments
> that are weak: possible problems for expert git users that have
> obvious solutions that would be be easy for an expert git user to use.

AFAIR, none of the messages described any expert uses of Git, they all
describe very simple and basic workflows, ones that are widely used by
everyone.  It would be wrong to make "C-x v v" disrupt those
workflows.