Re: VC mode and git

[Eric S. Raymond]

Richard Stallman <address@hidden>:
>  > 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.

Because quite frequently, while exploring, there are states you want to save
- so you can roll back to them - that are not final.  For example, a refactor
(which should have its own change comment) during an attempted fix.
 
> 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.

He does know how to get what he wants. He gets it by not pushing until he
is ready to commit.

Separating these operations is the simplest possible way to afford
this flexibility.  Adding policy flags adds complexity and should
not be done unless they bring a larger gain in utility, which is I'm
theoretically possible but I'm not seeing.

What people are trying to tell you is that you are trying to force-fit
a DVCS into behaving like a centralized VCS because your thinking
about how to use it is still limited by old mental habits from RCS/CVS
days.  Early in my learning process about DVCSes I had the same
problem and had to get past it. Now it's your turn.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>