Re: VC mode and git

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > And have my repository clogged up with meaningless arbitrary commits with
 > commit messages like "Just before resync with savannah, 2015-03-31
 > 22-58"?

I see nothing arbitrary about:

2015-03-31  Alan Mackenzie  <address@hidden>

        Development of foobar complete, all tests pass, documentation done.

        * foobar.el:  New file.

2015-04-01  Alan Mackenzie  <address@hidden>

        Integration of foobar to trunk complete, all tests pass.

        * foobar.el (foo, bar, baz):
        Refactor: use pcase, now that it has decent docs.

IMHO, these are specific, well-defined milestones that merit commits.
YMMV, but IME these last-minute adjustments to others' changes involve
far more than their share of defects, so having a next-to-last commit
in the known, comfortable pre-pull context and then one last commit
for integration is likely to do far more than its share of bug
localization when bisecting.

 > Then I'd have the hassle of somehow ensuring these silly commits
 > wouldn't find their way back to savannah.

There are plenty of options for this.

 > > It is indeed a bad idea to do a lot of work without committing and
 > > then merging.
 > 
 > Why?

See the general theorem.

 > > But that's a trivial deduction from the general theorem: it is a bad
 > > idea to do a lot of work without committing.
 > 
 > Why?

Because the only advantage to *not* committing is avoiding the two
minutes it takes to ask how to accomplish the task of "somehow
ensuring these silly commits wouldn't find their way back to
savannah", and learning how to type "git pull --rebase".  That would
mean you have at least two copies of all current work (one in the
working tree and one in .git/objects), and can easily back up to
another host with "git push".

Of course, you and Richard want git (and in his case vc.el) to default
to supporting your workflows, but that's not going to happen, at least
for git.  git is a very flexible tool for supporting a variety of
workflows, and not only are the workflows that involve "commit early
and often" already popular, they're gaining.

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.  In CVS and
other centralized VCSes, a check-in (to the public repository, using
Richard's felicitous terminology) is the only way to commit, which
makes it a very heavyweight operation indeed.  Even if you have a very
good connection to the server, it's still socially heavy because the
whole project shares it thereafter.

In DVCS, check-in is not the only way to commit: just committing and
waiting to push at an appropriate time is available.  This means that
the social weight of a check-in is no longer an issue.  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.

When I have achieved a state that deserves publication, I want to save
it in a reliable way that doesn't involve me remembering not to touch
that workspace, etc.  Maybe you don't want to do that, but I assure
you the cost of learning to use an appropriate workflow is far lower
than the cost of reproducing even a score of lines that disappeared
due to a silly typo or a tool whose documentation was unclear.

 > These two "why?"s are not rhetorical questions.

Yes, they are.  You (and Richard) don't want to know the answers
because acknowledging them would very likely induce changes in your
workflows, and everybody else already does know the answers.

 > No, I'm not confused on [the different usage of merge, fetch, and
 > pull in git and hg].

Well, the language you use makes it very difficult to determine
whether you are or aren't.  For example, when you write "merge", it's
hard to tell whether you are referring to a particular VCS's designed
semantics, to the goal you want to achieve in the workspace, or to the
particular command provided by a given VCS.  I suspect, but can't say
for sure for lack of verbal cues, that you actually switch back and
forth from one sentence to the next.

 > > What else would it do?  Merge tools have changed the working tree
 > > from time immemorial.
 > 
 > That's poor, Stephen.  [...]  The fact is, the documentation
 > doesn't say this

I'm sorry, but that point is moot.  Emacs chose git despite the
well-known deficiencies of its documentation, primarily because there
are a lot of Emacs workers who like git and know it fairly well.  One
now needs to use git to work on Emacs efficiently.  So suck it up and
use the wetware that has accumulated around you.

 > > What's different from traditional 3-way merge tools (that aren't
 > > part of a VCS) is that git *also* creates a commit with more than
 > > one parent (which is what is meant by joining development
 > > histories).
 > 
 > Do development histories have 40-byte hashes?  :-)

Of course they do.  Each commit implies a whole development history
through the parents attribute, just as each cons implies a whole list
through the cdr attribute.

 > The documentation is part of the program.  Whether bugs are in the
 > doc or the prog, it costs just as much wasted time and energy.

Only because you're unwilling to ask for help.  Asking for help from
Emacs developers is a very cheap and effective substitute for good
docs, and surely you have sufficient standing in the community to
warrant attention to your questions.  Of course you probably want to
choose the advice of someone like Eli rather than somebody like
Andreas, but both would undoubtedly answer your questions.

Regards,