On Sun, Jan 11, 2009 at 12:41:45PM +0100, Thomas Schwinge wrote: > Do you think it is worthwhile to preserve your individual commits?
Note that this is something to be decided by the maintainers accepting the changes, not the developer who created them... Though admittedly in this case there is not much difference :-) On Sun, Jan 11, 2009 at 12:50:58PM +0100, Thomas Schwinge wrote: > On Fri, Jan 09, 2009 at 09:38:20AM +0100, olafbuddenha...@gmx.net > wrote: > > On Sun, Jan 04, 2009 at 12:05:07AM +0100, Thomas Schwinge wrote: > > > For the GNU Mach Xen branch, I'd like Samuel to tell when that > > > one is ready for being merged into the main GNU Mach 1 branch > > > and then I intend to do that merge as one big aggregated > > > ``blob'' (i.e., without preserving the individual development, > > > testing, debugging, etc. commits. The same holds for the GSoC > > > branches. > > > > Don't do that. The whole point of a revision control system is to > > preserve history... A "blob" commit is unmanageable. > > Did you actually have a look at the individual commits on the Xen > branch? No. Is there a git import of that branch available anywhere? (Doing it with CVS would be endless pain.) > > If you think the history of the branch(es) is too messy, you can of > > course start a new branch, say xen-cleanup. This new branch should > > still contain a series of individual changes though, even if they > > don't reflect actual development history. > > Are you going to do that work of cleaning things up? No, this requires a good understanding of the changes -- it can not be reasonably done by anyone but the author of the changes. I wouldn't insist on it though if Samuel doesn't want to bother. It would be definitely nicer to have a clean patch series, where one can see what the individual changes do, revert them, bisect etc. -- I'm just not sure whether it's really worth the effort in a slow-moving project like the Hurd... However, if no clean patch series is created, having the original history is still way better than a single giant changeset. You could still see it as a single diff easily if that is what you want, whereas the opposite is not possible. It *never* hurts to have more history. > For the GSoC branches, the situation is indeed a different one. But > there are (roughly) only a handful of commits, so I'd rather replay > these manually on top of the new master branch instead of fiddling > with merging that I had done between the CVS branches. There should be no fiddling... As far as I am aware, in the xen_branch there was simply a lot of cherry-picking between that one and trunk. I don't think the import tool does even need to be aware of those... Otherwise there were some intermediate merges from HEAD to other branches. That too is rather standard -- I'm sure any sane import tool should be able to cope. > (I don't know if git-cvsimport and cvsps are smart enough to untangle > that.) git-cvsimport is generally known as the least robust import tool... If it doesn't work right, there are various other options. (Keith Packard actually created a new import tool for the Xorg migration, because the existing ones weren't able to cope with Xorg history...) > And, didn't (some of) the GSoCers work in git branches nevertheless? Yes: Two worked with git, one with svn, one with hg (IIRC). > Wouldn't we be able to directly import that Unfortunately, this is not easily possible. For one, I think some/most/all of them stopped updating the individual branches, once they imported to CVS. So you would have to take the original commits from the individual repositories, and then apply the CVS commits on top of them. The greater problem however is that originally the modules were developed out-of-tree, and only when checking into CVS were converted to build as part of the Hurd tree. So they can't be put in the main repository without some major fiddling... However, as the conflated commits just add new code, rather than modifying existing stuff, it's not really a problem in this case that no individual history is available... It's just an initial checkin really. > (rebasing it onto our master branch, of course)? I don't see the "of course" here :-) Keeping them at the original base would work just as well -- it depends on other circumstances which one is preferable... If any of the individual repositories is still in use, the rebase would actually cause problems. -antrik-
