Hi,

On Wed, 14 Nov 2007, Bill Lear wrote:

quoted text
> On Wednesday, November 14, 2007 at 20:58:29 (+0000) Johannes Schindelin writes:
> >...
> >I have a better idea:
> >
> >[the initial import, on another machine:]
> >% mkdir new_repo
> >% cd new_repo
> >% git init
> >[add content]
> >% git commit -a -m "Initial stuff"
> >% git remote add origin git://host/repo
> >% git push origin master
> >
> >If you do not want to be bothered with setting up the default 
> >"remote" and "merge" config variables manually, it is reasonable to ask 
> >for support to do that in "git remote".
> 
> Um, ok, but the above means that this repo now differs from other
> repos, in that pushing now involves more than 'git push', i.e.,
> 'git push origin master'.

Nope.  That is necessary only for the initial push.

Remember: "git push" defaults to pushing to the remote "origin", and _all_ 
local branches which the remote knows about.

And the latter is the reason why the initial push needs a special 
handling: the local and the remote repository have no branches in common, 
because the remote one does not have _any_ branch yet!

So, once you pushed the initial push, you can drop the "origin master" 
from subsequent pushes!

quoted text
> What's wrong with 'git init --mirror git://host/repo'?

It's highly unlikely that you have the same in mind as git when you say 
"--mirror" in this context.  Just have a look at git-push, which has 
recently acquired that option.

Besides, we really have "clone" for "init + fetch".

quoted text
> >(I actually think that it is another example of cvs/svn damage, where 
> >you _need_ to clone first, or otherwise you will _never_ be able to 
> >commit to the repository.)
> 
> I think there is a tendency here to blame every shortcoming of git on 
> someone else's supposedly unsanitary past rather than facing up to 
> inherent problems in git itself.

I am not blaming here.  I just try to see where it comes from.

In git, all repositories are equal.  Provided you can connect two of them 
(or not even that; think of bundles), you can push back and forth between 
_all_ of them.

Since this is something I like about git, I had some problems finding out 
where this "I have to clone from the same repository I want to push to" 
idea comes from.

quoted text
>  We have several very senior, very dedicated software developers who 
> LOVE git, and who loathe CVS, but who nevertheless find many vexing 
> issues in git.

And I am thankful that you bring up the vexing issues so that we can 
discuss (and hopefully fix) them.

quoted text
> >BTW I am somewhat disgusted by your usage of git:// for pushing.
> 
> Whatever.  We went through this before on the list and push support was 
> added to git://.  We have SUCKY sysadmin support at our company and 
> permissions were getting HOSED using ssh pushes.  The git:// protocol 
> makes everything clean on the repo side and no nasty surprises with 
> permissions and no delays begging the support team to clean things up.

Hey, if it works for you, I am all the happier! (Of course, I am in a 
better position than you, here; I _am_ the sysadmin, and my ssh setup Just 
Works...)

Ciao,
Dscho

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html