Messages in this thread | | | Date | Mon, 16 Dec 2002 16:36:31 +0000 | From | Christoph Hellwig <> | Subject | Re: Linux v2.5.52 |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |