Re: VC mode and git

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > Stephen, that is complete sophistry.

Will you stop the name calling?

 > Git should support how ever often a developper wants to commit,
 > whether every 5 minutes or just once per fix.

It does.  It just doesn't support your workflow by default, so you
have to learn more than a few bare commands that DWIM.

 > A commit is a commitment.

No, it is nothing of the kind.  A check-in (push) is a commitment.
You can *choose* to only make commits to the VCS that you are willing
to commit to in some normative sense.  But that doesn't make a commit
a commitment in principle, only by the accident of your preferences.

 > It is an affirmation, possibly public, of the value of the new
 > code, to its integrity, it is a declared willingness to stand up
 > and defend the thing committed to.  I do not commit my dirty linen,
 > which is what people seem to be advocating I should do.

Do you save your "dirty linen"?  If you don't, I bet your Emacs does.

 > [I] simply want an appropriate tool for communicating changes from
 > and to savannah.  I know I'm not the only one.  I think you have
 > trouble accepting this position.

I have no trouble accepting that position.  I'm simply unwilling to
exert any effort on your behalf, because I like git the way it is.
OTOH, my acceptance does you no good, because Emacs uses git.  That
is:

 > It seems the real answer is "everybody" commits often, so it must
 > be good thing to do.  I've never found that sort of reasoning
 > persuasive.

No, the real answer is that "everybody" commits often, so there is no
willingness to change git to serve the "nobody" who doesn't.  You can
throw all the tantrums you want, but unless you rewrite git and/or vc
yourself, it won't get done.  Of course you'd have to learn a hell of
a lot about git to be able to do so.

 > I have asked for git help in the past, and got answers varying in
 > quality from the deliberately infuriating to just right.  But doing
 > this takes up other people's time, so I don't like doing it too
 > often.  Perhaps I'm just too used to finding the answers to simple
 > questions in documentation.

The questions you are asking are *not* simple, because your
requirements are misaligned with those of the git developers.