Default modules to load ...

[Matthias Hopf]

On Oct 24, 06 09:48:42 -0400, Sean wrote:
> > Hm. And why don't I find this in my regularly cloned and updated git
> > repository? I just noted that I wouldn't find this commit after a
> > 'git-pull', but it would after a 'git-pull -t'.
> 
> "Git-pull -t" pulls down all remote tags (regardless of which branch

Yes, and the commit in question is accessible by a tag. That's why it
helped in this particular case to let the commit show up.

> "Git-pull" pulls down all the new commits for the branches you're
> following, and then any tags associated with any of the commits
> you pulled.

Understood.

> Git-pull does not automatically grab new branches from the remote
> repository.

And how do I 100% follow some upstream development? Including new
branches?
That is what I would typically want to do in a standard centralized
working repository environment (which we still have at X.org). I know
that this isn't git's preferred working environment.

> You shouldn't really ever need "git-pull -t"; just use "git pull".  It will
> automatically grab all the tags you need.

In that case it didn't. Well, -t didn't help too much either.

> But you will need to explicitly add new branches into your repo if you
> want to follow them.  Perhaps Git could make this easier.

So you're telling me git doesn't support this yet?
OMFG.

So basically I have to check 'git-ls-remote -h origin'
and add missing lines to .git/remotes/origin? Seems like it...

Now I'm using

   git-ls-remote -h origin | cut -f 2 | perl -e 'while (<>) { chomp; $h{$_}=$_; } open F, ".git/remotes/origin" or die; while (<F>) { print; if (/^Pull:\s+([^: ]*):/) { delete $h{$1}; } } foreach $f (keys %h) { print "Pull:   ${f}:$f\n"; }' >$tmpgit

to create a new .git/remotes/origin. Unfortunately, this slows down the
update process even more, which already is pretty damn slow. The only
thing of git that is slow, so it's even more recognizable.

> Please consider joining the Git mailing list and/or #Git on freenode IRC
> because they're often the quickest way to get answers and up to speed
> with Git.

I'm on that mailing list for several months now.
I'm following the development closely.

Still I happen to stumble upon seemingly trivial issues every now and
then. When we made the change from CVS to git I was under the impression
that git was stable and actually pretty feature complete. Guess I was
wrong, at least when it comes to centralized development.

Please don't get me wrong - I don't want to work with CVS any more.
Never ever.

> > BTW - apparently there also hasn't been a commit message - how could
> > something like that happen?
> 
> Not sure what you mean here, is there a commit mailing list that didn't
> see this commit?

The xorg-commit archive doesn't seem to have a commit message that
indicates the changes we're talking about. The change happened on
2006-09-15 (or -14 or -16 depending on time zone), so the ammount of
messages to scan was pretty low.

Matthias

-- 
Matthias Hopf <mhopf at suse.de>       __        __   __
Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat at mshopf.de
Phone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de