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

On Wednesday, November 14, 2007 at 11:32:32 (-0800) Junio C Hamano writes:

Sergei Organov [off-list ref] writes:

quoted

Junio C Hamano [off-list ref] writes:

quoted

His second point is also a real issue.  If you allowed cloning
an empty repo (either bare or non-bare), then you and Bill can
both clone from it, come up with an initial commit each.  Bill
pushes his initial commit first.  Your later attempt to push
will hopefully fail with "non fast forward", if you know better
than forcing such a push, but then what?  You need to fetch, and
merge (or rebase) your change on top of Bill's initial commit,
and at that point the history you are trying to merge does not
have any common ancestor with his history.

Just a wild idea. Doesn't it make sense to introduce perfect ultimate
common ancestor of the universe, probably calling it "the NULL commit"?
At first glance it seems that it can help to avoid corner cases
automagically.

...
But cloning void to start the same project by multiple people
and pushing their initial commits as roots to start a project
indicates the lack of developer communication (besides, it just
feels like a bad style, a hangover from centralized SCM
mentality, but that is fine). ...

We have several users who have been using git for the past 9 months
and they each find this unreasonably complicated.  We realize it is
work, perhaps not of the highest importance, but it's also easy for
more experienced users to simply pooh-pooh the ideas that newer users
have as "silly" because instead of the two steps they would like, they
can "just" do the five "easy" steps.

Well, here's what we'd like:

% mkdir new_repo
% cd new_repo
% git --bare init

[on another machine:]
% git clone git://host/new_repo
% cd new_repo
% git init
[add content]
% git commit -a -m "Initial stuff"
% git push

So, this is hard work, and other priorities intrude.  Ok.

Instead, we have to 1) figure out how to do this right, because it's
difficult to remember and not intuitive, and 2) once we have "figured
it out", really figure it out, because there are a few gotchas:

% mkdir new_repo
% cd new_repo
% git --bare init

% mkdir new_repo
% cd new_repo
[add content]
% git commit -a -m "Initial stuff"
% git config remote.origin.url git://host/new_repo
% git push
[ach! fails!  what's up??]
[poke, read, poke some more, try other things..]
[try setting the remote.origin.fetch?  No, that doesn't work]
[try setting branch.master.remote?  Just edit by hand??]
% git push master
[fails again; read some more; think, think, think...]
% git push origin master
[aha! finally it works]

But now, I have a repo in which I cannot just say "git push" to update
my remote repo.

So, if we can't have clone "do the right thing", then it would be nice
if we had something to allow us to do this, perhaps an argument to git
init:

% mkdir new_repo
% cd new_repo
% git --bare init

[on another machine:]
% mkdir new_repo
% cd new_repo
% git init --mirror git://host/new_repo
[add content]
% git commit -a -m "Initial stuff"
% git push

Where 'git init --mirror <blah>' just sets up the config file
properly.

Something to think about ...


Bill