Commit practices

Commit practices

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> I once posted a summary that I know about; see:
> 
>   http://lists.gnu.org/archive/html/emacs-devel/2006-11/msg00229.html
>   http://lists.gnu.org/archive/html/emacs-devel/2006-11/msg00234.html
>   http://lists.gnu.org/archive/html/emacs-devel/2006-11/msg00312.html
> 
> Richard commented here, basically approving my summary:
> 
>   http://lists.gnu.org/archive/html/emacs-devel/2006-11/msg00276.html
> 
> I suggested at the time to have these guidelines under admin/ but I
> guess no one volunteered to do that yet.

I had certainly never seen these guidelines before.  I may have been
violating them a lot recently simply because of the way VC-mode now
works.

Because VC now does group commits, I have been using the following
style: 

(1) Make a coherent group of changes.

(2) Write Changelog text describing them.

(3) Do a group commit, *including the Changelog*.  In the comment buffer, 
paste the text I wrote in step 2, tab-stripped.

I did it this way for a reason.  Someday we are going to want to
migrate the CVS tree to a VCS that has real changesets.  We're almost
certainly going to do it with a tool functionally like cvs2svn that
tries to reconstruct commit groups using date, the content of the
comments, and possibly this Commit-ID thing I see in the CVS logs. It
will be helpful, when we do that, if there as many similarities across
related commits as possible for the migration tool to grab onto.

This brings up the large topic of what to do about our workflow,
our tools, and the sad fact that Eli's guidelines (while intelligent
in their way) are basically an attempt to put lipstick on a pig.  What
we should really do is stop kissing the damned pig.

But that's a topic for another thread, which I'll start with my next post.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit practices

[Eli Zaretskii]

> Date: Sat, 29 Dec 2007 13:32:44 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> 
> This brings up the large topic of what to do about our workflow,
> our tools, and the sad fact that Eli's guidelines (while intelligent
> in their way) are basically an attempt to put lipstick on a pig.  What
> we should really do is stop kissing the damned pig.

As I wrote in that thread, those aren't _my_ guidelines:

    Those are not my rules, I just took a liberty of describing the rules
    Richard requested me to follow a long time ago.

So I cannot take the credits for the lipstick.

Re: Commit practices

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> > Date: Sat, 29 Dec 2007 13:32:44 -0500
> > From: "Eric S. Raymond" <esr@thyrsus.com>
> > 
> > This brings up the large topic of what to do about our workflow,
> > our tools, and the sad fact that Eli's guidelines (while intelligent
> > in their way) are basically an attempt to put lipstick on a pig.  What
> > we should really do is stop kissing the damned pig.
> 
> As I wrote in that thread, those aren't _my_ guidelines:
> 
>     Those are not my rules, I just took a liberty of describing the rules
>     Richard requested me to follow a long time ago.
> 
> So I cannot take the credits for the lipstick.

Understood.  Then I'll put it this way: *Richard's* rules are basically
an attempt to put lipstick on a pig.  My suggestions for how to stop kissing
the pig will follow shortly.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit practices

[Richard Stallman]

The reason I have asked people not to commit multiple files
is that they bloat the log entries of each file, making them
essentially unusable.

    I did it this way for a reason.  Someday we are going to want to
    migrate the CVS tree to a VCS that has real changesets.  We're almost
    certainly going to do it with a tool functionally like cvs2svn that
    tries to reconstruct commit groups using date, the content of the
    comments, and possibly this Commit-ID thing I see in the CVS logs. It
    will be helpful, when we do that, if there as many similarities across
    related commits as possible for the migration tool to grab onto.

In effect, the suggestion here is that we abandon the idea
of useful readable info associated by the VCS with each file.

That would mean that the ChangeLog file is the only place
for such info.

I won't say "absolutely not".

Re: Commit practices

[Stephen J. Turnbull]

Richard Stallman writes:

 > In effect, the suggestion here is that we abandon the idea
 > of useful readable info associated by the VCS with each file.

I don't understand why you expect that effect.  Certainly, there are
developers who, given the opportunity, will commit megapatches, and
associate them with megalogs, which are unreadable.  This is a social
problem.  Lash them with a wet noodle or chmod their cvs to 0644 until
they mend their evil ways.

However, all of the dVCS (distributed VCS) advocates strongly advocate
"coherent changesets", ie, keeping all the changes needed to implement
a fix or a feature in one changeset, and keeping others out.  Eg, do
you object to

----------------------------------------------------------------
2007-12-30  Stephen J. Turnbull  <stephen@xemacs.org>

Resolve bug where bar() frotzes instead of bazzing in a
quuxotic context.

* foo.h (bar): Add baz argument to prototype.

* foo.c (bar): Implement new baz argument, which when non-NULL
causes bar() to baz rather than frotz.

* quux.c (a, b, c, d, e): Update calls to bar() with bar = NULL.
(f): Update call to bar() with appropriate baz value.
----------------------------------------------------------------

as a common commit notice for foo.h, foo.c, and quux.c?  I find this
style of log, cross-referencing the declaration, the implementation,
and the already fixed uses, very useful.  But in the "coherent
changeset" style something like

----------------------------------------------------------------
2007-12-30  Stephen J. Turnbull  <stephen@xemacs.org>

* foo.h (glorp): Fix typo in comment.
----------------------------------------------------------------

would *not* be acceptable if merged into the above.  Is this close to
what you want?

I grant that a change such as merging the Emacs-Unicode branch will
not fit into this model.  But I personally don't think it fits well
into the one-notice-per-file model, either, as the cross-referencing
will be missing, and the logs, if at all detailed, will be very long
anyway.  Big merges are just horrid to create useful logs for.

As a practical matter, dVCSes enable this style by making frequent
commits easy.  Coherent changesets are easier to write good logs for.
Some dVCSes even provide facilities allowing selection of which hunks
to use in the commit, making it possible to omit gratuitous typo fixes
from the main commit.  Such a feature could be made generic (in Emacs)
by adding a front-end based on diff-mode.

In projects I observe where VCSes more modern than CVS are in use, it
is typically the case that static ChangeLog files have been abandoned
in favor of histories generated by the VCS, and nobody misses the
files.  (NB: I'm not telling you what to think, I'm simply presenting
an observation.)

Re: Commit practices

[Eric S. Raymond]

Stephen J. Turnbull <stephen@xemacs.org>:
> In projects I observe where VCSes more modern than CVS are in use, it
> is typically the case that static ChangeLog files have been abandoned
> in favor of histories generated by the VCS, and nobody misses the
> files.

Exactly. See my upcoming proposal.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit practices

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
> In effect, the suggestion here is that we abandon the idea
> of useful readable info associated by the VCS with each file.

Right.  Information about changes is most useful when it has *changeset*
granularity, not file granularity.
 
> That would mean that the ChangeLog file is the only place
> for such info.

No, it means that the information now in the Changelog belongs in the
CVS history, but with per-commit granularity rather than per-file granularity.
 
> I won't say "absolutely not".

Good.  I'm preparing a post with a major proposal about this.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit practices

[David Kastrup]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> Richard Stallman <rms@gnu.org>:
>> In effect, the suggestion here is that we abandon the idea
>> of useful readable info associated by the VCS with each file.
>
> Right.  Information about changes is most useful when it has
> *changeset* granularity, not file granularity.
>  
>> That would mean that the ChangeLog file is the only place for such
>> info.
>
> No, it means that the information now in the Changelog belongs in the
> CVS history, but with per-commit granularity rather than per-file
> granularity.

I have to agree here.  In fact, I felt very uneasy about committing
multi-file changes until I discovered PCL-CVS which, in contrast to VCS,
allows me to commit several files as one change set.

I believe that VCS should get a "stage for change" operation which works
inside of one Emacs session and prepares one of multiple files for a
single commit.  git actually has a concept of this operation at the
working directory level, so it would make sense to map this "staging"
process for the git backend to the appropriate operation outside of
Emacs.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Commit practices

[Eric S. Raymond]

David Kastrup <dak@gnu.org>:
> I have to agree here.  In fact, I felt very uneasy about committing
> multi-file changes until I discovered PCL-CVS which, in contrast to VCS,
> allows me to commit several files as one change set.

If by "VCS" you mean "VC mode", it does that now.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit practices

[Miles Bader]

"Eric S. Raymond" <esr@thyrsus.com> writes:
>> I have to agree here.  In fact, I felt very uneasy about committing
>> multi-file changes until I discovered PCL-CVS which, in contrast to VCS,
>> allows me to commit several files as one change set.
>
> If by "VCS" you mean "VC mode", it does that now.

Is there a user interface to this functionality other than vc-directory
mode?

-Miles

-- 
Quidquid latine dictum sit, altum viditur.

Re: Commit practices

[Eric S. Raymond]

Miles Bader <miles@gnu.org>:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
> >> I have to agree here.  In fact, I felt very uneasy about committing
> >> multi-file changes until I discovered PCL-CVS which, in contrast to VCS,
> >> allows me to commit several files as one change set.
> >
> > If by "VCS" you mean "VC mode", it does that now.
> 
> Is there a user interface to this functionality other than vc-directory
> mode?

No.  Do you need one?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit practices

[Miles Bader]

"Eric S. Raymond" <esr@thyrsus.com> writes:
>> Is there a user interface to this functionality other than vc-directory
>> mode?
>
> No.  Do you need one?

Er, well, I'd rather _like_ one...

[One reason of course is that vc-directory has historically been
completely unusable.  I gather that you've fixed that now (or at least
tried to), but still, sometimes I just want to commit foo.c and foo.h as
a unit, and don't want to fraf around with a browser interface like
vc-directory.]

-Miles

-- 
The key to happiness
 is having dreams.	[from a fortune cookie]

Re: Commit practices

[Eric S. Raymond]

Miles Bader <miles@gnu.org>:
> >> Is there a user interface to this functionality other than vc-directory
> >> mode?
> >
> > No.  Do you need one?
> 
> Er, well, I'd rather _like_ one...
> 
> [One reason of course is that vc-directory has historically been
> completely unusable.  I gather that you've fixed that now (or at least
> tried to), but still, sometimes I just want to commit foo.c and foo.h as
> a unit, and don't want to fraf around with a browser interface like
> vc-directory.]

Please describe what you want in a UI.  Perhaps I can implement it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit practices

[Miles Bader]

"Eric S. Raymond" <esr@thyrsus.com> writes:
> Please describe what you want in a UI.  Perhaps I can implement it.

The interface you describe in your reply to David sounds reasonable.

I suppose maybe some extra bindings in the "*vc-log*" buffer too would
be useful (since that's mainly where I would want to check the state of
what I'm commiting)... [e.g., maybe special versions of the + and -
commands that prompt for buffer names instead of operating on the
current buffer.]

-Miles

-- 
.Numeric stability is probably not all that important when you're guessing.

Re: Commit practices

[David Kastrup]

Miles Bader <miles@gnu.org> writes:

> "Eric S. Raymond" <esr@thyrsus.com> writes:
>> Please describe what you want in a UI.  Perhaps I can implement it.
>
> The interface you describe in your reply to David sounds reasonable.
>
> I suppose maybe some extra bindings in the "*vc-log*" buffer too would
> be useful (since that's mainly where I would want to check the state of
> what I'm commiting)... [e.g., maybe special versions of the + and -
> commands that prompt for buffer names instead of operating on the
> current buffer.]

I don't think that this would require extra bindings since in this case
the buffer has no associated file and is special.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Commit practices

[David Kastrup]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> Miles Bader <miles@gnu.org>:
>> "Eric S. Raymond" <esr@thyrsus.com> writes:
>> >> I have to agree here.  In fact, I felt very uneasy about committing
>> >> multi-file changes until I discovered PCL-CVS which, in contrast to VCS,
>> >> allows me to commit several files as one change set.
>> >
>> > If by "VCS" you mean "VC mode", it does that now.
>> 
>> Is there a user interface to this functionality other than vc-directory
>> mode?
>
> No.  Do you need one?

I think so.  I have previously used PCL-CVS for this.  I don't know
whether vc-directory is now supposed to be a full-blown replacement for
PCL-CVS, but actually using PCL-CVS for this purpose already was a
crutch: it should not be necessary to acquire a VC directory listing
just for the purpose of being able to commit several files in one
commit.

Maybe C-x v i can be made to do this?  Expand its meaning from "register
new file" to "register the current file/state for the next commit"?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Commit practices

[Eric S. Raymond]

David Kastrup <dak@gnu.org>:
> Maybe C-x v i can be made to do this?  Expand its meaning from "register
> new file" to "register the current file/state for the next commit"?

That would be a very confusing way to overload C-x v i.  But if what
you actually want is a way to edit the marked set without doing a directory
listing, that might be arranged.

Possible UI sketch:

C-x v +  = Add the visited buffer to the selection set.

C-x v -  = Remove the visited buffer from the selection set.

C-x v ?  = Display the current selection set.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit practices

[David Kastrup]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> David Kastrup <dak@gnu.org>:
>> Maybe C-x v i can be made to do this?  Expand its meaning from "register
>> new file" to "register the current file/state for the next commit"?
>
> That would be a very confusing way to overload C-x v i.

Not overload, rather expand its meaning.  Basically, it would do what
"git add" does.

> But if what you actually want is a way to edit the marked set without
> doing a directory listing, that might be arranged.
>
> Possible UI sketch:
>
> C-x v +  = Add the visited buffer to the selection set.
>
> C-x v -  = Remove the visited buffer from the selection set.
>
> C-x v ?  = Display the current selection set.

That sounds useful.  Depending on the version control system in
question, there might be a difference between "add file" and "add
buffer" which needs to be dealt with by asking "save?" questions and by
warning if you try saving a buffer which has been modified after adding
it to the selection set.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Commit practices

[Richard Stallman]

    > In effect, the suggestion here is that we abandon the idea
    > of useful readable info associated by the VCS with each file.

    Right.  Information about changes is most useful when it has *changeset*
    granularity, not file granularity.

That form is very useful, but we already have it in the ChangeLog
file.  Having a duplicate of that in the VCS does no harm, but doesn't
add anything either.

RCS and CVS logs give the information per file.  That adds something
precisely because it is different: it is convenient for looking at the
history of one file.  However, if one file's CVS log gets full of
change info for other files, then it is harder to use the CVS logs
for this purpose, which means they are not as useful.

If we switch to maintaining VCS logs in changeset terms, we will
entirely lose the feature of convenient presentation of one file's
changes.  That would mean going back to the situation as it was
in 1990, when all we had was ChangeLog.

Just ChangeLog was sufficient in 1990, and it would be sufficient
again, but it is nonetheless a change for the worse.

Perhaps we could substitute for that lost capability
with a new feature in Change Log mode to selectively display
the items that pertain to a certain file.

Re: Commit practices

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
> Perhaps we could substitute for that lost capability
> with a new feature in Change Log mode to selectively display
> the items that pertain to a certain file.

It's not necessary. Because the report from svn log (or hg log, or bzr
log) is generated from the commit history, filtering for the change
history for a particular file is trivial.  All modern VCSes support
this, and I mean *all*.

So: say "svn log", and you get the entire commit history.  Say "svn
log foo.c" and you get the history of all commits touching foo.c, and
only those commits.  Similarly for bzr and hg.

Keeping what is now the Changelog info in the commit comments
would gives us the ability to see either the commit history as a whole
or any file's individual history.  We would lose nothing.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit practices

[Richard Stallman]

    > Perhaps we could substitute for that lost capability
    > with a new feature in Change Log mode to selectively display
    > the items that pertain to a certain file.

    It's not necessary. Because the report from svn log (or hg log, or bzr
    log) is generated from the commit history, filtering for the change
    history for a particular file is trivial.

It doesn't do the same job.

    So: say "svn log", and you get the entire commit history.  Say "svn
    log foo.c" and you get the history of all commits touching foo.c, and
    only those commits.  Similarly for bzr and hg.

That's not the same thing.  "Commits touching foo.c" is NOT the same
as just the items pertaining to foo.c.  If those commits are
multi-file commits, they will be full of items about other files as
well as items about foo.c.

So I think the Change Log mode feature is still desirable.

Re: Commit practices

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
> That's not the same thing.  "Commits touching foo.c" is NOT the same
> as just the items pertaining to foo.c.  If those commits are
> multi-file commits, they will be full of items about other files as
> well as items about foo.c.
> 
> So I think the Change Log mode feature is still desirable.

I was assuming that we would retain the Changelog item format keying on
files and functions.

In that case, extracting items pertaining to foo.c from log output
would be no more difficult than extracting them from a separate
Changelog.  Less so, actually -- the pre-filtering for commits
touching foo.c would throw out a lot of chaff.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit practices

[Richard Stallman]

    > That's not the same thing.  "Commits touching foo.c" is NOT the same
    > as just the items pertaining to foo.c.  If those commits are
    > multi-file commits, they will be full of items about other files as
    > well as items about foo.c.
    > 
    > So I think the Change Log mode feature is still desirable.

    I was assuming that we would retain the Changelog item format keying on
    files and functions.

    In that case, extracting items pertaining to foo.c from log output
    would be no more difficult than extracting them from a separate
    Changelog.  Less so, actually -- the pre-filtering for commits
    touching foo.c would throw out a lot of chaff.

Yes, it could be used in that mode too, if you want to.

An additional nice feature would be the ability to type C-c C-d and
have it show you the change set corresponding to that point in
ChangeLog.  (It could do that by matching dates and approximate
matching against the log entry.)

Re: Commit practices

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
> The reason I have asked people not to commit multiple files
> is that they bloat the log entries of each file, making them
> essentially unusable.
>
>     I did it this way for a reason.  Someday we are going to want to
>     migrate the CVS tree to a VCS that has real changesets.  We're almost
>     certainly going to do it with a tool functionally like cvs2svn that
>     tries to reconstruct commit groups using date, the content of the
>     comments, and possibly this Commit-ID thing I see in the CVS logs. It
>     will be helpful, when we do that, if there as many similarities across
>     related commits as possible for the migration tool to grab onto.
>
> In effect, the suggestion here is that we abandon the idea
> of useful readable info associated by the VCS with each file.
>
> That would mean that the ChangeLog file is the only place
> for such info.
>
> I won't say "absolutely not".

Grouping each logical change together in one commit (even when the
change involves multiple files) allows tools like cvs2cl to do their
job (see http://www.red-bean.com/cvs2cl for more).  Thus, the info
recorded by the VCS *would* still be useful -- no need to abandon that
idea.  By the way, cvs2svn uses essentially the same algorithm.

So, the ChangeLog would not be the only place for this info.

Also:

All the CVS documentation I've seen specifically recommends grouping
each logically unified change together in one commit.  That is also
the way I have always used CVS, and the way CVS maintainers use CVS.
I realize this sounds like "argument from authority", but given our
finite resources, the time-tested experience of others may be worth
taking into account.

-Karl

Re: Commit practices

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  > The reason I have asked people not to commit multiple files
  > is that they bloat the log entries of each file, making them
  > essentially unusable.

Your opposition to multiple file commits seems to be based on the
assertion that this "bloats the log entries of each file, making them
essentially _unusable_".  

It's hard to find this assertion valid. 

In the worst case we would end with the log for each file containing the
whole ChangeLog (and that is obviously absurd).
Even in that absurd case isearch is quite efficient.
Now that isearch can switch to a different file ChangeLog file,
starting a C-s from lisp/ChangeLog and searching for 1985-05-11 (the
last entry in lisp/ChangeLog.1) takes no observable time and that is on
the slowest machine that I tried: a 500MHz P3.

GCC has been doing multiple file commits for at least 10 years. And the
logs are quite readable, you can check for yourself.

On the other hand doing only single file commits has a high cost in
developer time. Sometime CVS is very slow, waiting for each commit to go
through takes a while. 
The most efficient tool we have now for committing to CVS, PCL-CVS works
very well selecting a group of files for a logical commit, writing a
ChangeLog for them and committing them in one shot.  This process
is much less labor intensive than committing files one by one.  And
developer time is the most precious resource that we have.

  >     I did it this way for a reason.  Someday we are going to want to
  >     migrate the CVS tree to a VCS that has real changesets.  We're almost
  >     certainly going to do it with a tool functionally like cvs2svn that
  >     tries to reconstruct commit groups using date, the content of the
  >     comments, and possibly this Commit-ID thing I see in the CVS logs. It
  >     will be helpful, when we do that, if there as many similarities across
  >     related commits as possible for the migration tool to grab onto.
  > 
  > In effect, the suggestion here is that we abandon the idea
  > of useful readable info associated by the VCS with each file.
  > 
  > That would mean that the ChangeLog file is the only place
  > for such info.

There's no reason to go that far. As shown above allowing multiple file
commits is not a problem.

Re: Commit practices

[Richard Stallman]

    Your opposition to multiple file commits seems to be based on the
    assertion that this "bloats the log entries of each file, making them
    essentially _unusable_".  

    It's hard to find this assertion valid. 

Perhaps that's because what's useful for me is not the same as
what's useful for you.

    Even in that absurd case isearch is quite efficient.

Isearch is efficient on the ChangeLog file, too.  That makes it
possible to see all the entries for file foo, one by one.

What the CVS log does (when there are no multi-file checkins) is make
it possible to see all the entries for file foo, compactly, many at
once on a single screen.  Sometimes I find this a useful capability.
Just searching through ChangeLog doesn't do the same job.

Thus I proposed a feature for filtering the ChangeLog file as a new
way to do that job.

Re: Commit practices

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     Your opposition to multiple file commits seems to be based on the
  >     assertion that this "bloats the log entries of each file, making them
  >     essentially _unusable_".  
  > 
  >     It's hard to find this assertion valid. 
  > 
  > Perhaps that's because what's useful for me is not the same as
  > what's useful for you.

That is true, but please consider that what you consider useful also has
a HUGE cost, and the benefit seems to be only for you (Nobody else seems
to agree that there is a benefit at all). 

The cost is HUGE:
  - the multi-tty branch could have merged a few months earlier, it
  waited until Glenn and I had time to spend a few days rewriting the
  logs. The benefit of that: zero as far as I can see. 
  - the unicode branch is waiting for someone to rewrite the logs. 
Merging this branches later costs a lot because many more people could
use/test/debug/improve them. Time spent working on emacs by volunteers
is totally context dependent.

  >     Even in that absurd case isearch is quite efficient.
  > 
  > Isearch is efficient on the ChangeLog file, too.  That makes it
  > possible to see all the entries for file foo, one by one.
  > 
  > What the CVS log does (when there are no multi-file checkins) is make
  > it possible to see all the entries for file foo, compactly, many at
  > once on a single screen.  Sometimes I find this a useful capability.
  > Just searching through ChangeLog doesn't do the same job.
  > 
  > Thus I proposed a feature for filtering the ChangeLog file as a new
  > way to do that job.

Does that mean that you don't object to multi-file commits anymore?

Re: Commit practices

[Johan Bockgård]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> That is true, but please consider that what you consider useful also has
> a HUGE cost, and the benefit seems to be only for you (Nobody else seems
> to agree that there is a benefit at all). 

I do, FWIW.

-- 
Johan Bockgård