Hi, On Wed, 14 Nov 2007, Bill Lear wrote: > 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! > 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". > >(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. > 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. > >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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
