emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VC mode and git


From: Alan Mackenzie
Subject: Re: VC mode and git
Date: Wed, 1 Apr 2015 22:34:32 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

Hello, Ricardo.

On Wed, Apr 01, 2015 at 09:50:46PM +0200, Ricardo Wurmus wrote:

> Alan Mackenzie writes:

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

Is having to invent a meaningful commit message for each and every commit
not inconvenient?

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

Why "insane"?  Do you have your repository in a "more secure" place?  For
me, my repository is on the same RAID pair of disks as my working
directory.  So committing things in my working directory doesn't make
them any more secure.  I don't do it because it would be extra work,
however little.  As you intimate above, these extra commits would need to
be dealt with by squashing, deleting, editing, renaming, interactive
rebasing, or whatever.

I honestly don't understand why people advocate frequent committing.

> ~~ Ricardo

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]