Re: [PATCH 4 of 4] Implement diag + sparse, diag - sparse, sparse + diag, sparse - diag

[Jason Riedy]

And John W. Eaton writes:
> So it is just better to use an attachment.

Will do.

> In any case, I think detailed information about why a change is needed
> belongs in a comment in the sources, not in a commit message or
> ChangeLog entry.

I'll try to follow that, as well, but sometimes it's difficult
to explain wider reasons in a code comment.

> Also, I don't understand the purpose of the
> From 76c98628f1943d583d5813321ec0a3c684d7ac84 Mon Sep 17 00:00:00 2001

A mistake from mis-interpreting what hg wants.  hg can generate
git-style patches, so I thought it was interpreting them as well.
I think I've fixed it now.

> Signed-off-by: Jason Riedy <address@hidden>

I had a default set in my gitconfig.  Removed.  Thanks!

> I don't know of a reference, but I didn't find having multiple
> branches in a single archive to be very useful for my purposes.

Fair enough.  I'm mostly imitating my git use.  And for the
changes I've been making, ccache suffices for speeding up the
compilation cascades.

Except when something wedges in liboctave...  Occasionally make
declares an error has occurred, but I haven't figured out what's
causing it.  I end up running make distclean moderately often.
(Someone else beat me to the y.tab.h problem.)

> But what do you want the multiple branches for?  If it is managing
> pending patches, then I think MQ is better for doing that.

I tend to work on branches for independent topics.  The only
overlap between the permutation*sparse and diag*sparse operations
is in the forward declarations, so merging isn't much of a
problem.  And there's a ChangeLog merge driver in gnulib that
handles those sensibly.

Jason