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

Sergei Organov [off-list ref] writes:

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.

The tools do not have problem with the multiple-root issue; we
can merge without common ancestor just fine.  So in that area,
we do not need to kludge like that at the physical level (you
can think of root commits having "the NULL" as their parents).

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

If the "feature" can be supported with zero cost, I do not have
a problem.  If that feature does something one does not agree
with (be it promoting a bad workflow or whatever), one does not
have to use it.  All one has to do is try not to recommend using
that feature to others.

But this time, the "feature" is not a zero cost thing.  As
Matthieu said in the thread, we do not let you do so right now.
Which means that it would involve new development, the code
changes would risk regressing behaviour existing users rely on,
and we would need testing for that.  These all take resources.

We already spent quite a lot of time on this thread, and at
least to me I feel that my time would have been better spent if
instead I were looking at patches on some other topics, or
working on cleaning up cherry-pick/revert implementation.

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

[I sent a few mistakes --- edited below.]
On Wednesday, November 14, 2007 at 14:16:45 (-0600) Bill Lear writes:

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

[No git init would be needed here, obviously.]

[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

[git init is needed here...]

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

Sorry for the sloppiness.


Bill

El 14/11/2007, a las 21:16, Bill Lear escribió:

% 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]

Instead of using git-config I think the following would have worked:

git remote add origin git.example.com:/pub/git/path_repositories/ 
repo.git
git push --all

I guess it is not necessarily obvious the first time, which more than  
anything makes this a documentation issue. I now can't remember how I  
learnt this; probably by reading this list.

Cheers,
Wincent

Hi,

On Wed, 14 Nov 2007, Bill Lear wrote:

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

quoted

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

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

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

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

BTW I am somewhat disgusted by your usage of git:// for pushing.

Ciao,
Dscho

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

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?

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

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

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

On Wed, Nov 14, 2007 at 11:32:32AM -0800, Junio C Hamano wrote:

We already spent quite a lot of time on this thread, and at
least to me I feel that my time would have been better spent if
instead I were looking at patches on some other topics, or
working on cleaning up cherry-pick/revert implementation.

Personally, I think cloning empty repositories should be allowed, but
there are many more interesting things to be working on right now.
However, I think the current behavior of not printing anything is quite
bad, so here is a productive email that didn't take too long to write.

-- >8 --
git-clone: print an error message when trying to clone empty repo

Previously, cloning an empty repository looked like this:

$ (mkdir parent && cd parent && git --bare init)
$ git-clone parent child
Initialized empty Git repository in /home/peff/clone/child/.git/
$ cd child
-bash: cd: child: No such file or directory
$ echo 'wtf?' | mail git@vger.kernel.org

Now we at least report that the clone was not successful.

---

diff --git a/git-clone.sh b/git-clone.sh
index 18003ab..e2b7a9c 100755
--- a/git-clone.sh
+++ b/git-clone.sh

@@ -278,7 +278,8 @@ yes)
 				      find objects -type f -print | sed -e 1q)
 			# objects directory should not be empty because
 			# we are cloning!
-			test -f "$repo/$sample_file" || exit
+			test -f "$repo/$sample_file" ||
+				die "fatal: cannot clone empty repository"
 			if ln "$repo/$sample_file" "$GIT_DIR/objects/sample" 2>/dev/null
 			then
 				rm -f "$GIT_DIR/objects/sample"

Bill Lear wrote:

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

It wouldn't match other --mirror options. You would want it to set up
refs/remotes namespace for you, but the other --mirror options (those
in push/fetch) are meant to explicitly ignore refs/remotes and make
sure branches are named exactly the same on both sides (hence --mirror).

I wouldn't mind if it was given some other option that did what you
wanted, but having --mirror mean two such very different things would
be bad.

"git init --remote origin=git://host/repo", where the lhs of the equal
sign would default to "origin" might be a good way to implement it.

Personally I don't have any problems with the current way of getting
things done, so it's not my itch.

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

git is not perfect. It's just better than everything else. Bringing up
those vexing issues here is one way of making it better though, so thanks
for doing that. :)

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Junio, can I get an ACK or NAK on the patch below? There doesn't seem to
be a patch for making cloning empty repos work on the horizon, but can
we at least improve the error message?

-- >8 --
git-clone: print an error message when trying to clone empty repo

Previously, cloning an empty repository looked like this:

$ (mkdir parent && cd parent && git --bare init)
$ git-clone parent child
Initialized empty Git repository in /home/peff/clone/child/.git/
$ cd child
-bash: cd: child: No such file or directory
$ echo 'wtf?' | mail git@vger.kernel.org

Now we at least report that the clone was not successful.

---

diff --git a/git-clone.sh b/git-clone.sh
index 18003ab..e2b7a9c 100755
--- a/git-clone.sh
+++ b/git-clone.sh

@@ -278,7 +278,8 @@ yes)
 				      find objects -type f -print | sed -e 1q)
 			# objects directory should not be empty because
 			# we are cloning!
-			test -f "$repo/$sample_file" || exit
+			test -f "$repo/$sample_file" ||
+				die "fatal: cannot clone empty repository"
 			if ln "$repo/$sample_file" "$GIT_DIR/objects/sample" 2>/dev/null
 			then
 				rm -f "$GIT_DIR/objects/sample"