Re: Moving to git

[olafBuddenhagen]

Hi,

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:

> The old CVS repositories will of course remain available for history
> inspection.  I consider the new git repositories mostly for a
> looking-forward perspective.
> 
> I'm not yet convinced that we really need these old, unused branches
> in the fresh git repositories.  How often do you look things up in the
> GNU Mach HEAD branch (as compared to our current gnumach-1-branch,
> where all the work is done)?  Or in the Hurd's miles-orphaned-changes
> branch or the ams-branch?
> 
> If you people strongly want to have all available history present in
> the new git repositories, then I can arrange for that to happen, of
> course. I wouldn't do that, however.

Yes, people do sometimes check Mach HEAD. Not often, but it does happen.
There is no reason why those should have to hunt around for some old
repository, deal with inferior tools etc.

By your reasoning, we could also flatten all the older history,
preserving only the last couple of years...

I don't know how it happened, but somehow you totally got sidetracked
with this project. The idea of the conversion is to use an infinitely
better tool to work with the existing history -- not to get rid of half
the history...

But from your followup, it seems that you realized that now :-)

> And why provide legacy branches that no one uses and that will only
> confuse people?

Why would the existance of other branches confuse anyone?

Note that regarding gnumach, I'm not at all against renaming the
branches. (Making gnumach-1 master again.) On the contrary, I'm strongly
in favour of it -- and indeed, in this particular instance, the
conversion is really a convenient moment to do it...

Also note that it's trivial to drop branches at any later point --
totally no reason to do it as part of the conversion.

> > > Split Hurd modules into separate repositories.
> > 
> > I stand by what I said on this topic before: *If* we decide to make
> > such a change, it should be done independently of the Git migration.
> 
> Indeed it should be done independently, and I say that it should be
> done *before* the Git migration, so that we start with unencumbered
> git repositories.

No, afterwards. Git can keep track of such fundamental changes, CVS
can't.

There is a reason why we want to switch...

> Yes, but we are not in a hurry with the migration.

Actually, we are: GSoC preparations start in a couple of weeks, and I'd
*really* want to have it in git by then...

> > Indeed, it's not possible to properly disentangle the modules
> > retrospectively. So we *have* to keep the original history, even if
> > we really want the split to happen ultimately.
> 
> It is the *very vast* majority of commits that do *not* touch several
> modules.

That's like someone who lost his legs in an accident while driving twice
the speed limit saying that it's not a problem at all, because all the
other times he drove too fast nothing happened... ;-) SCNR

-antrik-