Re: VC mode and git

[Eli Zaretskii]

> Date: Wed, 1 Apr 2015 12:32:41 +0000
> From: Alan Mackenzie <address@hidden>
> Cc: Andreas Schwab <address@hidden>, Harald Hanche-Olsen <address@hidden>,
>       address@hidden, address@hidden
> 
> I do not constrain my git pulls exclusively to the times when I'm
> ready to make a sensible commit.

May I ask why do you pull (a.k.a. "merge from master") at all while
working on a feature?

Also, are we talking about you working on a feature branch, or about
working directly on master?

Generally, work that takes more than, say, an hour or two, and is
expected to involve a non-trivial amount of changes, is better done on
a separate branch, which you then merge onto master when you are done.
While working on such a branch, it makes little sense to merge from
master, because that just brings unrelated changes that could
potentially disrupt your development.  Instead, wait until you are
finished with your changes, and then merge.  If you do that, then the
potential conflicts due to pull/merge from master simply cannot
happen.

IOW, while working on a feature branch, you commit when you have
finished some well-defined part of the job, preferably something that
can be, and have been, unit-tested.  You then commit something that
you know has been tested and was proved to work.  Commit log messages
in this arrangement describe your advance.  Here's an example: the
first 10 commits from one of my past feature branches (produced by
"git log --oneline"):

  a12d75c Added initial version of biditest.el and Unicode data file it needs.
  2f3daa5 Optimize memory footprint of the bidi level stack.
  a7fed5a Added BidiBrackets.txt and related Unicode properties to 
unidqata-gen.el.
  2fca7ae Fixed problems revealed by -Wall.
  23dbf47 Updated bidi_resolve_weak.  Removed next_en_* members from stack.
  991b257 Updated pushing and popping the bidi stack, and sos calculations. 
Added the necessary members to bidi_stack.
  5d84f5d Fix find_first_strong_char and implement Unicode 8.0 isolate 
corrections.
  d9abb28 Finished coding of explicit directional format characters.
  8ccc6fa Remove bidi_ignore_explicit_marks_for_paragraph_level.
  4f6bc3c Started working on implementing UBA v6.3.

If, OTOH, you are working directly on master, it makes no sense IMO to
make intermediate commits, except in some rare situations (like you
are off-line for some reason), because if you feel the need to do
that, it's a clear sign that you should have done this on a branch.
So assuming you DTRT and only do short one-off jobs in master, you can
either commit right before you pull from upstream, or do the opposite:
pull, then commit.  (Both alternatives can run into conflicts, but
that's inevitable.)  Then you push, and that's it.

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

I see no reasons for making "silly commits".  IMO, a commit should
have a good reason, and "I need to pull" is not one of them.

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

I gave some above and in my other messages.

Basically, I disagree with what Stephen says above: a commit should
generally be a more-or-less complete unit of work, preferably
something that can be tested.  At least as a rule.

That said, as Stephen points out, the tools allow you to commit at any
time for a very small price: you need to come up with one line
describing the changes in the commit.  So if for some reason you need
to make a break in your work, and would like to record what you've
accomplished, feel free to commit.  (Once again, this is much better
done on a feature branch than on master.)  I don't feel ashamed to
have all my intermediate commits with their logs on the project's DAG
after the merge; if anything, this forces me to think for a few
seconds before I write the log messages.  (People who prefer rebasing
will probably disagree.)

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

It does.

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

That's fine; I do that, too.  But still work on a non-trivial feature
or fix involves numerous steps and phases, which are usually coded and
unit-tested separately.  Committing after every such step is IMO good
practice, and supports your methodology, I think.

I don't quite understand the "dirty linen" part.  When you have
developed and tested a part of a feature, it might leave Emacs with
known bugs elsewhere, since your work is incomplete.  But if part of
that work is complete and tested, where's the "dirty linen" here? what
is there to be ashamed of?

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

Right, but we are not talking about pushing, do we?  We are talking
about _local_ commits that are not pushed to a public repository,
until after you are done with the feature and have merged it to
master.

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

That's okay; people are generally divided into two camps: those who
want to clean up their local commit mess before they make it public,
and those who don't make a mess to begin with, at least not a mess
they will feel ashamed about.  You seem to belong to the second group
(so do I); there's nothing wrong about that.  It just means you won't
use the tools mentioned by Stephen too much.  (You will still need
some of them to fix stupid errors done on master, like forgetting to
commit a file, or committing a change you didn't want to, if you catch
them before pushing.)  But it still makes sense to make local commits
on a feature branch once some unit of your work is completed.

> 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, that's not the real answer.  It could be the popular answer, but
there are good reasons to do that; I've mentioned some.