Re: VC mode and git

[Alan Mackenzie]

Hello, Stephen.

On Wed, Apr 01, 2015 at 10:25:31AM +0900, Stephen J. Turnbull wrote:
> 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.

Stephen, that is complete sophistry.  I do not constrain my git pulls
exclusively to the times when I'm ready to make a sensible commit.

> 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.

Of course there are.  I want to avoid the hassle of them; the hassle of
having to write down coherently one or more of these options; the hassle
of having to remember each time to do one of them; the hassle of having
to look up my notes each time.

>  > > 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".

That's a disappointing answer, largely negative.  I was hoping for some
new insight into the advantages of frequent committing.

> 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.

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

> 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.

> 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.

CVS's commit is equivalent to git's push, not its commit.  The social
weight of git push is the same as cvs commit.

> 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.

> 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.

Personally, I don't have any trouble with not touching finished changes.

>  > 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.

The answer you gave above essentially just asserted it was a good thing
to have a copies (in the repository) of what one is working on.  This is
perilously close to begging the question.

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, 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.

Sorry, I'll try to be more definite in the future.

>  > > 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.

Yes.

>  > > 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.

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.

> Regards,

-- 
Alan Mackenzie (Nuremberg, Germany).