Getting xorg-7.4 from git ?

[Eirik Byrkjeflot Anonsen]

Donnie Berkholz <dberkholz at gentoo.org> writes:

> On 08:27 Fri 26 Sep     , Carl Worth wrote:
>> On Fri, 2008-09-26 at 01:14 -0700, David Sharp wrote:
>> > this could be made easier by tagging releases for the katamari with a
>> > common tag, like "Xorg-7.4"
>> 
>> And even easier with a super-module repository that would just need one
>> tag. Didn't Zack even prototype such a thing once? Has anyone looked
>> into how reasonable it would be to use such a thing for releases?
>> 
>> I've heard some claim that the supermodule approach wouldn't work well
>> for just tracking the latest development at the tip of all the master
>> branches, but it sounds perfect for tracking releases.
>
> When git folks added submodule support, somehow they managed to miss the 
> (obvious to me) use case of tracking all the submodule HEADs instead of 
> sticking to specific commits. It was even discussed in the thread where 
> the patch was proposed, and an early version of the patch did track 
> HEADs. If this is a blocker, it shouldn't be much work to add a flag for 
> it.
>

I thought it was strange at first, too.  But once I had thought about
it, I came to the conclusion that the current behaviour is what you
want.  What you'll realize when you understand the various use cases
is that there is no truly correct behaviour.  And the current one is
probably the one with the least nasty surprises.

For example, in the "correct" case where all the submodules are truly
independent projects, you don't want magic dependencies between the
tags/branches in those (independent) projects.  It's just nasty.

Consider checking out "master" of the supermodule.  If you get the
revisions of the submodule that was actually used when "master" on the
supermodule was checked in, it works as intended.  But if you instead
get the "master" branches of the submodules, all bets are off.  The
alternative, making special branches in the submodule for the
supermodule, is obviously getting the dependencies between modules
turned the wrong way around (the submodule should not need to know
that it is used by the supermodule).

The use case for doing it differently is when the git repos are not
independent projects, but a single project split into small pieces.  I
guess in the case of X, many of the modules makes little sense outside
of X.  But that is not the use case that git submodule support is
designed to solve.  And I would say it is not the most important use
case to handle.

The submodule support in git has many problems.  Everybody knows it,
but I think the git people are worried about breaking it beyond
repair.  Which seems to be a sensible approach right now.

eirik