On Wednesday, November 14, 2007 at 20:58:29 (+0000) Johannes Schindelin writes:
quoted text
>...
>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'.  Is there not a way to configure it "as if"
I had done a 'git clone' and thereafter could just do 'git push'?

I want to do: 1) point to origin; 2) push; and not have to remember
"oh yeah, this is that 'special' repo and I have to tack on 'origin
master' or it won't work", or to clone it somewhere else and work
there.

quoted text
>If you really think that this workflow has anything to do with cloning an 
>empty repository, I cannot help you.  I mean, you did not need to clone 
>the big, empty void to do the initial commit, or did you?

I just want to point to it and treat it as if it had been cloned to
begin with: it is my future "point of origin".  If it is not cloning,
then it is "pointing to it as my origin", as if it were created by the
clone.

What's wrong with 'git init --mirror git://host/repo'?  Is it just
another special case that's busy work helping only a few, or does
it belong elsewhere in your opinion?

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.  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.

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.


Bill
-
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