Re: [Libusb-devel] libusb-stuge.git broke cygwin compilation

[Peter S. <pe...@st...>]

Pete Batard wrote:
> > libusb-stuge.git is the current state of my working tree.
..
> libusb-stuge broke cygwin compilation.

Thanks for testing it! Awesome!


> .in'ig.status: error: cannot find input file: `
> 
> Yup, the last line is verbatim.

Crazy. :) I'll follow up to the other messages. This one is more
about the process.


> And I'm going to rant again, but was it really necessary to split
> the configure.ac changes into 9 commits?

Yes, absolutely. They are distinct changes, and they were not all
split after the fact. Any time a commit needed to be split, it was
because I had made a mistake and/or not planned or prepared well.


> What good will come of going atomic with such single liners as
> "Quote AC_COMPILE_IFELSE() input" or "Trivial whitespace changes
> and reordering", *REALLY*?

Again, distinct changes, they may or may not be applied. git is quite
able to deal with many commits, and high commit resolution allows us
to get the most out of git.


> IMO, a simple "configure.ac improvements" with bullet points detailing
> each improvements could do wonders, especially as configure.ac is far
> from being our bread and butter.

Actually here the distinct commits help a lot, specifically *because*
we're still learning about configure.ac. It makes each step clear for
reviewers. You may already have noticed that several of the commits
touch the same code, and quite a lot of information about the way
from point A in the code to point B would have been lost if
everything was jammed into a single commit. Very difficult to review,
and I think not acceptable at least for anything in libusb core. As
for backend-specific changes I will try to follow Daniel's lead and
go with whatever patches are sent.


> If producing such commits has been taking time away from
> progressing on the actual official integration for 1.0.9,
> maybe we need to review our approach...

It is very much a part of the work to prepare the next release.

The many commits is how I work, and also how I expect others to work;
because it allows us to take full advantage of git, and because it is
logical, which makes it easy for others to follow.

One change = one commit.

I rebased quite frequently making those changes, because I didn't
have a plan and was learning along the way, and because I discovered
more and more things to fix. This is why I like personal repos -
they're a sandbox, but still allow easy review so that the sandcastle
can be made even greater. :)


//Peter