Default modules to load ...
Matthias Hopf
mhopf at suse.de
Tue Oct 24 09:43:42 PDT 2006
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
More information about the xorg
mailing list