Re: Linux v2.5.52

[Christoph Hellwig <hch@infradead.org>]

On Mon, Dec 16, 2002 at 10:16:39AM -0500, Ben Collins wrote:
> > This merge looks fishy.  It seems to be yet another let's throw my CVS
> > repo in merge and backs out Al's work yo get rid of lots of devfs crap.
> 
> Quit talking shit. I go through a lot of effort to merge in changes sent
> to Linus' tree into the Linux1394 repo. I don't just dump changes for no
> good reason.
> 
> How about pointing out some specifics?

Take a look at the changeset at
http://linus.bkbits.net:8080/linux-2.5/diffs/drivers/ieee1394/dv1394.c@1.15?nav=index.html|src/|src/drivers|src/drivers/ieee1394|hist/drivers/ieee1394/dv1394.c.

Your big BLOB merge basically undoes everything in there.

> Maybe make my job easier by getting me some patches directly.

It was Al's patch, not mine.

> Trying to track two seperate source tree's isn't as easy as you might think.

In fact it's not difficult at all with a proper SCM, a bit of care and the
right attitude.  I merge the changes from XFS (and about half a donzend
XFS-related repositories inside SGI that all need proper merging / keeping
in sync) to Linus all the time.  And by keeping the changesets (or atomic
commits in SVN terminlogoy) as one patch each, hand-editing as needed when
merge conflicts arrive that works very well, even if I had been away and
the changes for four weeks need merging or as now we're five patchlevels
away from Linus tree (at 2.5.47).  I've not lost a single upstream change
with that merge policy yet.

And no, that's no BK advertisment, SGI uses a RCS-based SCM internally and
I use unfied diffs to get it into a staging repository for Linus to pull.