Thread (10 messages) flat view 10 messages, 6 authors, 2016-06-15

Re: Cloning empty repositories, was Re: What is the idea for bare repositories?

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:43:51

Possibly related (same subject, not in this thread)

Hi,

On Wed, 14 Nov 2007, Bill Lear wrote:
On Wednesday, November 14, 2007 at 20:58:29 (+0000) Johannes Schindelin writes:
quoted
...
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".
quoted
(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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help