Merging branches (was: Moving to git)

[olafBuddenhagen]

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, olafBuddenhagen@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-