Re: VC mode and git

[Ricardo Wurmus]

Alan Mackenzie writes:

>> That's because a commit is just a way of delegating a pile of
>> record-keeping to the VCS.  In particular, it identifies a state of
>> development that you or others might want to replicate.
>
> A commit is a commitment.  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.

[...]

>> You can commit on any whim, and git's whole design is to make whimsical
>> commits as cheap as possible.  Part of that is the much derided staging
>> area as well as other aspects of caching the blobs and trees, but part
>> of that is "git reset --soft" and the DAG editing capabilities it
>> provides.  You can throw away commits while keeping the changes using
>> interactive rebasing, or do the commits on a branch and merge, or any
>> combination that makes sense to you.
>
> The only combination that makes sense to me is that which involves the
> least risk and the least time and effort wasted in ploughing through
> git's inadequate documentation.  I don't want to spend several hours
> learning how to "throw away commits while keeping the changes using
> interactive rebasing", or even in learning what that all really means.  I
> am one of these seemingly rare people who are not fascinated by the
> innards of git, and 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'm not "fascinated by the innards of git" and I don't find the man
pages very useful, but creating commits often and interactively rebasing
them before publishing (i.e. "git push") lies at the core of my
workflow, and I would not do it if it wasn't easy and convenient.

Your concept of a commit as "an affirmation [...] of the value of the
new code" does not need to apply to local, "whimsical", cheap commits.
Before publishing you can *easily* squash, delete, edit, rename, move
commits with interactive rebase.  You can defer the decision when
something is ready for publication without having to forgo commits (I
think of them as "quicksave" in games).

Committing often and rebasing for publication are both cheap operations
with little mental overhead.  It would be insanity for me to keep a
dirty working directory with potentially valuable changes uncommitted.

~~ Ricardo