I'd like to do this sequence, but I can't figure out how without

editing the config file. There doesn't seem to be a simple command to

move the origin.
git clone linus

move origin to digispeaker.git

git pull
What's the simplest way to do this?
--

Jon Smirl

jonsmirl@gmail.com

-

Hi,
Hth,

Dscho
-

I really think people should at least also mention:
	"Or just edit your .git/config file by hand"
Quite frankly, the latter is *easier* to do. It's really hard to remember

all the config entry names and then run "git config <entry> <value>". The

command itself may be fairly simple, but rememberign the options is *not*.
In contrast, when you open up .git/config in your editor, it's all almost

totally *obvious*.
So telling people to edit the config file is usually much more helpful in

the long run. 
		Linus

-

I finally got everything working. There is still some issue where I

need to run update-server-info manually. The error messages at the

client side when update-server-info needs to be run are not useful.
This sequence does work:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

digispeaker

cd digispeaker

git config remote.origin.url

http://git.digispeaker.com/projects/digispeaker-kernel.git

git pull
Should we allow this instead:

   git remote add origin

http://git.digispeaker.com/projects/digispeaker-kernel.git

and print a message saying the origin was changed? That would teach

people more about how remotes work.
I did need to go back to my server and clone kernel.org first, then

push my changes into it. That step is necessary so that my changes

don't end up in the giant pack along with the base kernel.
It is also a requirement to compile the git tools with NO_MMAP if

there are going to work in a shared hosting environment like

dreamhost. NO_MMAP is the key, changing git config doesn't help.
After my initial clone from kernel.org it only takes a minute now to
--

Jon Smirl

jonsmirl@gmail.com

-

Hi,
FWIW I agree.  The intent of git-repo-config (as it was named then) was to

have a program for _scripts_ to use.
But for some reasons, people on IRC refuse to edit .git/config by hand.

*sigh*  Will have to relearn giving proper help.
Thanks,

Dscho

-

It is eaiser to put

  git config remote.origin.url

http://git.digispeaker.com/projects/digispeaker-kernel.git

in a cookbook web page sequence than say edit the config file by hand.
I added the cookbook sequence to my git project page.

http://git.digispeaker.com/

Without cloning from kernel.org first it takes an hour to clone from

dreamhost, but what do you want for $5/mth. I'll more to a better host

when traffic picks up.
--

Jon Smirl

jonsmirl@gmail.com

-

I think that falls under "scripting" (it's just that your interpreter is
It sounds like you are posting commits on top of Linus' kernel tree. Why

not use repo.or.cz's hosting? It's free, and it _already_ has the

linus-2.6 tree, so you can start a 'fork' and not even waste any space.
-Peff

-

It's the kernel for a larger embedded project. After I get the kernel

going I will add the user space environment at the same web site.
The project is described at www.digispeaker.com. It is an open source

multi-room audio system. Wifi based to allow easy installation. Uses

the MPC5200B PowerPC chip.
--

Jon Smirl

jonsmirl@gmail.com

-

There is more to this:
jonsmirl@terra:~/foo$ git clone

git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

ds

clone.....

jonsmirl@terra:~/foo/ds$ git config remote.origin.url

http://git.digispeaker.com/projects/digispeaker-kernel.git

jonsmirl@terra:~/foo/ds$ git pull

You asked me to pull without telling me which branch you

want to merge with, and 'branch.master.merge' in

your configuration file does not tell me either.  Please

name which branch you want to merge on the command line and

try again (e.g. 'git pull <repository> <refspec>').

See git-pull(1) for details on the refspec.
If you often merge with the same branch, you may want to

configure the following variables in your configuration

file:
    branch.master.remote = <nickname>

    branch.master.merge = <remote-ref>

    remote.<nickname>.url = <url>

    remote.<nickname>.fetch = <refspec>
See git-config(1) for details.
--

Jon Smirl

jonsmirl@gmail.com

-

Hi,
And this does not come up here.
Maybe you don't have a master branch on digispeaker.
Ciao,

Dscho
-

It edited origin:[remote "origin"]

        url = http://git.digispeaker.com/projects/digispeaker-kernel.git
At digispeaker remote repo:

[daedalus]$ git branch

  m24

  m25

  m26

  m28

  m29

* master

[daedalus]$
gitweb is at:

git.digispeaker.com
[daedalus]$ cd refs

[daedalus]$ find

.

./heads

./heads/m24

./heads/m25

./heads/m26

./heads/m28

./heads/m29

./heads/master

./tags
--

Jon Smirl

jonsmirl@gmail.com

-

Hi,
You haven't shown me that this is set correctly in your set up, and if it

is, when it stops being correctly set up.
Ciao,

Dscho

-

Running git update-server-info at the remote end fixed it.
I am using 'git push' to send changes, I though that was supposed to
--

Jon Smirl

jonsmirl@gmail.com

-

It is typically triggered by the post-update hook. Make sure that your

remote repo's .git/hooks/post-update has the execute bit set.
-Peff

-

Execute bit was not set. I just set it for all the scripts. +x is not

getting turned on with a default git init-db. I just made a new repo

to check, no +x on the scripts.
--

Jon Smirl

jonsmirl@gmail.com

-

That's by design: "git init" gives you _example_ hooks, but they won't

run until you activate them explicitely with the appropriate chmod.
That said, I'm not sure there's a really good reason not to run

update-server-info by default on push. It doesn't cost much and saves

a lot of troubles for beginners. Perhaps there are cases where the

performance cost is non-negligible.
--

Matthieu

-

One incarnation of u-s-i we had in the past was quite a lot more

expensive, but we discarded the complexity, so I'd agree it

won't cost much in the current shape now.
The expensive one tried to record information to help dumb

transports better, such as "if you have this revision then you

do not have to fetch that pack but instead fetch this", as we

were discussing packs that have objects from duplicated,

staggered ranges.  The idea did not quite pan out.
-

Could we add an alternates entry on the server that would cause the

client to first go fetch all objects the alternate has, then come back

and fetch from the initial server with a normal fetch? It's like a URL

redirect. You wouldn't fetch heads or tags from the alternate, just

all of the objects.
--

Jon Smirl

jonsmirl@gmail.com

-

I assume by "all the scripts" you mean "all of the post-update scripts

in my repositories" and not "all of the hook scripts in this

repository". Because I think some of the included hooks are not suitable

to run without some configuration, which is why they are disabled by
Right. git-init just copies the files from the templates directory

(probably /usr/share/git-core/templates or similar), so if the hook is

not enabled there, it will not be in the new repo. And git ships with

all hooks disabled by default.
cogito used to enable the post-update hook by default for bare repos (if

you called cg-admin-setuprepo), but git never has.
It is mentioned in the "exporting a git repository via http" section of

the user manual.
-Peff

-

Actually, fetching from kernel.org first and then switching the origin

isn't helping. The host is http only since I can't get access to the

git network port. When I pushed up my local repo it ends up in one big

pack.
I do this:

git clone kernel.org

move the origin

git pull

-- it still pulls down the entire pack and takes an hour
Will this fix it?

at my remote host, first clone from kernel.org

then push my local changes?
--

Jon Smirl

jonsmirl@gmail.com

-

Yep, the http fetch code doesn't understand about fetching parts of

packs (there was some discussion about using partial HTTP transfers, but
Yes, it should. The goal is to not put your changes and the upstream

commits in the same pack. You could also push _just_ the upstream

commits first, then in a different push, send your local changes. But

when they get pushed together, they all end up in the same pack.
-Peff

-