What is the idea for bare repositories?

What is the idea for bare repositories?

[David Kastrup]

Hi,

I have a repository declared as bare.  Some commands treat it as such,
other's don't.  For example, I get

git-diff [no complaint]
git-status
fatal: /usr/local/bin/git-status cannot be used without a working tree.
git-reset [no complaint]
git-reset --hard
HEAD is now at db862c1... installmanager.sh: setze GIT_WORK_TREE
git-commit
fatal: /usr/local/bin/git-commit cannot be used without a working tree.
git-add
fatal: This operation must be run in a work tree

So this is all somewhat inconsistent.  What is the situation supposed
to be?

-- 
David Kastrup

Re: What is the idea for bare repositories?

[Bruno Cesar Ribas]

A bare repository is the way to publish your changes to the public.
git-daemon  and http-clones use a bare repository that only contains
adminsitrative files.

>From man page
       --bare Make a bare GIT repository. That is, instead of creating
              <directory> and placing the administrative files in
              <directory>/.git, make the <directory> itself the $GIT_DIR. This
              obviously implies the -n because there is nowhere to check out
              the working tree. Also the branch heads at the remote are copied
              directly to corresponding local branch heads, without mapping
              them to refs/remotes/origin/. When this option is used, neither
              remote-tracking branches nor the related configuration variables
              are created.

On Mon, Nov 12, 2007 at 02:11:58PM +0100, David Kastrup wrote:
> 
> Hi,
> 
> I have a repository declared as bare.  Some commands treat it as such,
> other's don't.  For example, I get
> 
> git-diff [no complaint]
> git-status
> fatal: /usr/local/bin/git-status cannot be used without a working tree.
> git-reset [no complaint]
> git-reset --hard
> HEAD is now at db862c1... installmanager.sh: setze GIT_WORK_TREE
> git-commit
> fatal: /usr/local/bin/git-commit cannot be used without a working tree.
> git-add
> fatal: This operation must be run in a work tree
> 
> So this is all somewhat inconsistent.  What is the situation supposed
> to be?
> 
> -- 
> David Kastrup
> 
> -
> 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

-- 
Bruno Ribas - ribas@c3sl.ufpr.br
http://web.inf.ufpr.br/ribas
C3SL: http://www.c3sl.ufpr.br 

Re: What is the idea for bare repositories?

[Johannes Schindelin]

Hi,

On Mon, 12 Nov 2007, Bruno Cesar Ribas wrote:

> A bare repository is the way to publish your changes to the public. 
> git-daemon and http-clones use a bare repository that only contains 
> adminsitrative files.

More to the point, a bare repository is one which does not have a working 
directory attached.

As such, many commands do not make any sense at all, such as "git add" 
(_what_ do you want to add?  There is not even a working directory to work 
with!), or "git commit".

Ciao,
Dscho

Re: What is the idea for bare repositories?

[David Tweed]

On Nov 12, 2007 1:19 PM, Bruno Cesar Ribas <ribas@c3sl.ufpr.br> wrote:
> A bare repository is the way to publish your changes to the public.

Just to mention this: an incredibly minor use, but a bare repository
is also useful for "temporary storage" on a non-case-preserving
filesystem (particularly if you don't have the authority/capability to
change the filesystem for one that is case preserving).

[I have a USB stick that I also occasionally use on Windows so
couldn't reformat. My repo doesn't have files whose names differ only
by case, but does have files with capitals somewhere. Not caring
either way about having checked out files, I initially tried to put a
standard repo on the stick and it wouldn't fast-forward when I tried
to push an update to it because some files checked out files had
"vanished". Making it a bare repository avoided the issue problem.]

-- 
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee

Re: What is the idea for bare repositories?

[David Kastrup]

Bruno Cesar Ribas <ribas@c3sl.ufpr.br> writes:

> A bare repository is the way to publish your changes to the public.
> git-daemon  and http-clones use a bare repository that only contains
> adminsitrative files.
>
> From man page
>        --bare Make a bare GIT repository. That is, instead of creating
>               <directory> and placing the administrative files in
>               <directory>/.git, make the <directory> itself the $GIT_DIR. This
>               obviously implies the -n because there is nowhere to check out
>               the working tree. Also the branch heads at the remote are copied
>               directly to corresponding local branch heads, without mapping
>               them to refs/remotes/origin/. When this option is used, neither
>               remote-tracking branches nor the related configuration variables
>               are created.

Fine.  So why don't the following commands complain?  Apart from
git-reset without arguments (which could probably get along without a
working dir), they are supposed to employ a working directory.

> On Mon, Nov 12, 2007 at 02:11:58PM +0100, David Kastrup wrote:
>> 
>> I have a repository declared as bare.  Some commands treat it as such,
>> other's don't.  For example, I get
>> 
>> git-diff [no complaint]
>> git-reset [no complaint]
>> git-reset --hard
>> HEAD is now at db862c1... installmanager.sh: setze GIT_WORK_TREE


-- 
David Kastrup

Re: What is the idea for bare repositories?

[Jan Wielemaker]

On Monday 12 November 2007 14:57, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 12 Nov 2007, Bruno Cesar Ribas wrote:
> > A bare repository is the way to publish your changes to the public.
> > git-daemon and http-clones use a bare repository that only contains
> > adminsitrative files.
>
> More to the point, a bare repository is one which does not have a working
> directory attached.
>
> As such, many commands do not make any sense at all, such as "git add"
> (_what_ do you want to add?  There is not even a working directory to work
> with!), or "git commit".

As we are on the subject anyway. Though not tested with the very latest,
but when I was playing with them, I found out that cloning a empty bare
repository produces nothing at all, dispite the promising message:

	$ mkdir x && cd x
	$ git --bare init --shared=group
	Initialized empty shared Git repository in /home/nobackup/jan/tmp/x/
	$ cd ..
	$ git clone x y
	Initialized empty Git repository in /home/jan/nobackup/tmp/y/.git/
	$ ls y
	ls: cannot access y: No such file or directory

Is this a bug?

	--- Jan

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

[Johannes Schindelin]

Hi,

On Mon, 12 Nov 2007, Jan Wielemaker wrote:

> I found out that cloning a empty bare repository produces nothing at 
> all, [...]

If they are empty, what exactly do you mean to clone?

Ciao,
Dscho

Re: What is the idea for bare repositories?

[Jakub Narebski]

David Kastrup wrote:

> Bruno Cesar Ribas <ribas@c3sl.ufpr.br> writes:
> 
>> A bare repository is the way to publish your changes to the public.
>> git-daemon  and http-clones use a bare repository that only contains
>> adminsitrative files.
[...]
> 
> Fine.  So why don't the following commands complain?  Apart from
> git-reset without arguments (which could probably get along without a
> working dir), they are supposed to employ a working directory.
> 
>> On Mon, Nov 12, 2007 at 02:11:58PM +0100, David Kastrup wrote:
>>> 
>>> I have a repository declared as bare.  Some commands treat it as such,
>>> other's don't.  For example, I get
>>> 
>>> git-diff [no complaint]
>>> git-reset [no complaint]
>>> git-reset --hard
>>> HEAD is now at db862c1... installmanager.sh: setze GIT_WORK_TREE

git-diff can compare tree and tree, or tree and index; only for
comparing tree and files of index and files it needs working dir.

git-reset resets only refs and index. git-reset --hard resets also
files, so it needs working directory. Perhaps it should fail completely
and not only after doing mixed (non-hard) reset if we are in bare
repository.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: What is the idea for bare repositories?

[Jakub Narebski]

Jan Wielemaker wrote:

> As we are on the subject anyway. Though not tested with the very latest,
> but when I was playing with them, I found out that cloning a empty bare
> repository produces nothing at all, dispite the promising message:
> 
>         $ mkdir x && cd x
>         $ git --bare init --shared=group

Note that "git --bare init" and "git init --bare" are two *different*
things (first is no-op, by the way).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

[Matthieu Moy]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi,
>
> On Mon, 12 Nov 2007, Jan Wielemaker wrote:
>
>> I found out that cloning a empty bare repository produces nothing at 
>> all, [...]
>
> If they are empty, what exactly do you mean to clone?

I'd expect an empty repository, with the git remote configured
correctly.

I already mentionned this here (but didn't take time to write a
patch), a typical use-case is when I want to create a new project. I'd
like to initialize an empty bare repo on my backed up disk, and then
clone it to my local-fast-unreliable disk to get a working copy and do
the first commit there.

Currently, I have to create both independantly, and configure the
remote myself. Not terrible, but not conveinient either ;-).

-- 
Matthieu

Re: What is the idea for bare repositories?

[David Kastrup]

Jakub Narebski <jnareb@gmail.com> writes:

> David Kastrup wrote:
>
>> Bruno Cesar Ribas <ribas@c3sl.ufpr.br> writes:
>> 
>>> A bare repository is the way to publish your changes to the public.
>>> git-daemon  and http-clones use a bare repository that only contains
>>> adminsitrative files.
> [...]
>> 
>> Fine.  So why don't the following commands complain?  Apart from
>> git-reset without arguments (which could probably get along without a
>> working dir), they are supposed to employ a working directory.
>> 
>>> On Mon, Nov 12, 2007 at 02:11:58PM +0100, David Kastrup wrote:
>>>> 
>>>> I have a repository declared as bare.  Some commands treat it as such,
>>>> other's don't.  For example, I get
>>>> 
>>>> git-diff [no complaint]
>>>> git-reset [no complaint]
>>>> git-reset --hard
>>>> HEAD is now at db862c1... installmanager.sh: setze GIT_WORK_TREE
>
> git-diff can compare tree and tree, or tree and index; only for
> comparing tree and files of index and files it needs working dir.

Well, if called without arguments (as above), it compares tree and
index.  So it should complain about not having a tree.  It doesn't.

> git-reset resets only refs and index. git-reset --hard resets also
> files, so it needs working directory. Perhaps it should fail
> completely and not only after doing mixed (non-hard) reset if we are
> in bare repository.

Please reread the above: it does not fail at all.  Neither before nor
after the mixed reset.

-- 
David Kastrup

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

[Johannes Schindelin]

Hi,

On Mon, 12 Nov 2007, Matthieu Moy wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Mon, 12 Nov 2007, Jan Wielemaker wrote:
> >
> >> I found out that cloning a empty bare repository produces nothing at 
> >> all, [...]
> >
> > If they are empty, what exactly do you mean to clone?
> 
> I'd expect an empty repository, with the git remote configured 
> correctly.

Yeah, right.

Last time I checked, those geneticists did not clone thin air.  They 
always waited until they had something to clone.

Ciao,
Dscho

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

[Bill Lear]

On Monday, November 12, 2007 at 17:15:51 (+0000) Johannes Schindelin writes:
>Hi,
>
>On Mon, 12 Nov 2007, Matthieu Moy wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 
>> > On Mon, 12 Nov 2007, Jan Wielemaker wrote:
>> >
>> >> I found out that cloning a empty bare repository produces nothing at 
>> >> all, [...]
>> >
>> > If they are empty, what exactly do you mean to clone?
>> 
>> I'd expect an empty repository, with the git remote configured 
>> correctly.
>
>Yeah, right.
>
>Last time I checked, those geneticists did not clone thin air.  They 
>always waited until they had something to clone.

We have wanted this behavior; I don't think it's so foolish.  We have
an administrator create a new bare repo for us, and we populate it by
pushing into it.  It wold be nice if the administrator could create a
bare repo and we could clone from it, and push to it to populate it,
instead of cloning the bare repo from another repo that has already
been (partly) populated.


Bill

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

[Johannes Schindelin]

Hi,

On Mon, 12 Nov 2007, Bill Lear wrote:

> We have an administrator create a new bare repo for us, and we populate 
> it by pushing into it.  It wold be nice if the administrator could 
> create a bare repo and we could clone from it, and push to it to 
> populate it, instead of cloning the bare repo from another repo that has 
> already been (partly) populated.

I don't see what is soooo hard with using git-remote in the repo you are 
pushing from.  It's just a "git remote add origin <url>", and you can even 
use this to push right afterwards: "git push --all origin".

Besides, if you really want to work together, chances are that you do 
_not_ want to start with <n> independent initial commits.  So you need to 
populate the repository before starting _anyway_.

Why are easy solutions so unattractive?

Ciao,
Dscho

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

[David Kastrup]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi,
>
> On Mon, 12 Nov 2007, Matthieu Moy wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 
>> > On Mon, 12 Nov 2007, Jan Wielemaker wrote:
>> >
>> >> I found out that cloning a empty bare repository produces nothing at 
>> >> all, [...]
>> >
>> > If they are empty, what exactly do you mean to clone?
>> 
>> I'd expect an empty repository, with the git remote configured 
>> correctly.
>
> Yeah, right.
>
> Last time I checked, those geneticists did not clone thin air.  They 
> always waited until they had something to clone.

>> >> a empty bare repository produces nothing at 
>> >> all, [...]
>> >
>> > If they are empty, what exactly do you mean to clone?
>> 
>> I'd expect an empty repository, with the git remote configured 
>> correctly.
>
> Yeah, right.
>
> Last time I checked, those geneticists did not clone thin air.  They 
> always waited until they had something to clone.

git-init does not perform sexual intercourse, either.  I don't see why
geneticists should be relevant for determining what git-clone does.


-- 
David Kastrup

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

[Nicolas Pitre]

On Mon, 12 Nov 2007, Johannes Schindelin wrote:

> Hi,
> 
> On Mon, 12 Nov 2007, Matthieu Moy wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 
> > > On Mon, 12 Nov 2007, Jan Wielemaker wrote:
> > >
> > >> I found out that cloning a empty bare repository produces nothing at 
> > >> all, [...]
> > >
> > > If they are empty, what exactly do you mean to clone?
> > 
> > I'd expect an empty repository, with the git remote configured 
> > correctly.
> 
> Yeah, right.
> 
> Last time I checked, those geneticists did not clone thin air.  They 
> always waited until they had something to clone.

But we're not geneticists, and I think the above usage should
"just work (tm)".


Nicolas

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

[Matthieu Moy]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> I don't see what is soooo hard with using git-remote in the repo you are 
> pushing from.  It's just a "git remote add origin <url>", and you can even 
> use this to push right afterwards: "git push --all origin".

If "git remote add" is so easy, why does "git clone" set up the remote
for you?

And don't tell me that you didn't notice that "git clone" does more
than your proposed "git remote add origin ...".

> Besides, if you really want to work together, chances are that you do 
> _not_ want to start with <n> independent initial commits.

So, what?

> So you need to populate the repository before starting _anyway_.

Last time I checked, the thread was talking about bare repository.
Perhaps you have a magic formula to populate a bare repository without
pushing to it from another repo, but I don't.

-- 
Matthieu

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

[Johannes Schindelin]

Hi,

On Mon, 12 Nov 2007, Nicolas Pitre wrote:

> On Mon, 12 Nov 2007, Johannes Schindelin wrote:
> 
> > On Mon, 12 Nov 2007, Matthieu Moy wrote:
> > 
> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > > 
> > > > On Mon, 12 Nov 2007, Jan Wielemaker wrote:
> > > >
> > > >> I found out that cloning a empty bare repository produces nothing 
> > > >> at all, [...]
> > > >
> > > > If they are empty, what exactly do you mean to clone?
> > > 
> > > I'd expect an empty repository, with the git remote configured 
> > > correctly.
> > 
> > Yeah, right.
> > 
> > Last time I checked, those geneticists did not clone thin air.  They 
> > always waited until they had something to clone.
> 
> But we're not geneticists, and I think the above usage should "just work 
> (tm)".

I am still convinced that it is not very intelligent to start your 
development from a non-existing branch.

But since you're one of the people knowing git _internals_ pretty well, 
here's another reason just for you why this cannot be done: There is no 
way to find out where the HEAD points to.

Try it.  Create an empty repository.  Then call "git ls-remote <path>" on 
it.  It's _empty_.

Ciao,
Dscho "who is bored with this discussion"

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

[Bill Lear]

On Monday, November 12, 2007 at 17:30:10 (+0000) Johannes Schindelin writes:
>Hi,
>
>On Mon, 12 Nov 2007, Bill Lear wrote:
>
>> We have an administrator create a new bare repo for us, and we populate 
>> it by pushing into it.  It wold be nice if the administrator could 
>> create a bare repo and we could clone from it, and push to it to 
>> populate it, instead of cloning the bare repo from another repo that has 
>> already been (partly) populated.
>
>I don't see what is soooo hard with using git-remote in the repo you are 
>pushing from.  It's just a "git remote add origin <url>", and you can even 
>use this to push right afterwards: "git push --all origin".
>
>Besides, if you really want to work together, chances are that you do 
>_not_ want to start with <n> independent initial commits.  So you need to 
>populate the repository before starting _anyway_.
>
>Why are easy solutions so unattractive?

Well, 1) to answer your first point: it's not soooo hard, but it's an
extra step that just seems unnecessary.  2) It's not the *easiest*
solution that one can think of, so people naturally complain: "why do
I have to push in the clutch AND select the gear"?


Bill

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

[Johannes Schindelin]

Hi,

On Mon, 12 Nov 2007, Matthieu Moy wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > So you need to populate the repository before starting _anyway_.
> 
> Last time I checked, the thread was talking about bare repository. 

Wrong.  Wrong, wrong, wrong.

It was talking about _cloning_ an _empty_ repository.  (Bare or not is not 
interesting in this context.)

> Perhaps you have a magic formula to populate a bare repository without 
> pushing to it from another repo, but I don't.

No, but that was not what I was questioning.  No, sir, not at all.

Ciao,
Dscho

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

[Matthieu Moy]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi,
>
> On Mon, 12 Nov 2007, Matthieu Moy wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 
>> > So you need to populate the repository before starting _anyway_.
>> 
>> Last time I checked, the thread was talking about bare repository. 
>
> Wrong.  Wrong, wrong, wrong.

Repeating it 4 times doesn't make it correct. You can even try 5
times, it won't change.

Grep for "bare" in the following text:

,----
| Hi,
| 
| On Mon, 12 Nov 2007, Jan Wielemaker wrote:
| 
| > I found out that cloning a empty bare repository produces nothing at 
| > all, [...]
| 
| If they are empty, what exactly do you mean to clone?
| 
| Ciao,
| Dscho
`----

And then, guess how I ended-up with that text (hint : cut-and-paste).

>> Perhaps you have a magic formula to populate a bare repository without 
>> pushing to it from another repo, but I don't.
>
> No, but that was not what I was questioning.  No, sir, not at all.

Perhaps you can reconsider this after reading the above.

-- 
Matthieu

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

[Johannes Schindelin]

Hi,

> > On Mon, 12 Nov 2007, Matthieu Moy wrote:
> >
> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >> 
> >> > So you need to populate the repository before starting _anyway_.
> >> 
> >> Last time I checked, the thread was talking about bare repository.

Look at the subject.  "Cloning empty repositories."

Nuff said,
Dscho who sighs

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

[Matthieu Moy]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi,
>
>> > On Mon, 12 Nov 2007, Matthieu Moy wrote:
>> >
>> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> >> 
>> >> > So you need to populate the repository before starting _anyway_.
>> >> 
>> >> Last time I checked, the thread was talking about bare repository.
>
> Look at the subject.  "Cloning empty repositories."

Look at the content. "cloning a empty bare repository".

I insist that the content is the content that _YOU_ quoted, which is
the starting point of the discussion.

-- 
Matthieu -- who finds it hard to discuss with people only reading
            subject in emails.

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

[Nicolas Pitre]

On Mon, 12 Nov 2007, Johannes Schindelin wrote:

> Hi,
> 
> On Mon, 12 Nov 2007, Nicolas Pitre wrote:
> 
> > On Mon, 12 Nov 2007, Johannes Schindelin wrote:
> > 
> > > Last time I checked, those geneticists did not clone thin air.  They 
> > > always waited until they had something to clone.
> > 
> > But we're not geneticists, and I think the above usage should "just work 
> > (tm)".
> 
> I am still convinced that it is not very intelligent to start your 
> development from a non-existing branch.

Well, that's an orthogonal question and I'm not providing any opinion 
about that.

> But since you're one of the people knowing git _internals_ pretty well, 
> here's another reason just for you why this cannot be done: There is no 
> way to find out where the HEAD points to.

So?  Why couldn't you just do the 'git remote add' dance implicitly in 
that case anyway?


Nicolas

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

[Jan Wielemaker]

On Monday 12 November 2007 18:47:14 Matthieu Moy wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > I don't see what is soooo hard with using git-remote in the repo you are
> > pushing from.  It's just a "git remote add origin <url>", and you can
> > even use this to push right afterwards: "git push --all origin".
>
> If "git remote add" is so easy, why does "git clone" set up the remote
> for you?
>
> And don't tell me that you didn't notice that "git clone" does more
> than your proposed "git remote add origin ...".
>
> > Besides, if you really want to work together, chances are that you do
> > _not_ want to start with <n> independent initial commits.
>
> So, what?
>
> > So you need to populate the repository before starting _anyway_.
>
> Last time I checked, the thread was talking about bare repository.
> Perhaps you have a magic formula to populate a bare repository without
> pushing to it from another repo, but I don't.

Hey guys, don't fight about the details.  Just stick to

	* Creating a bare empty repositiory is possible and a perfectly
	valid way to create a shared repositiory.
	* Clone and push is the natural way to modify it.  At least to
	me this was the obvious thing to do.  Explicitely playing with
	remotes is -as far as i'm concerned- lesson 2.
	* If this cannot be done (but, what is wrong with an empty tree?)
	at least
		- git clone should *not* say it created a repository
		- The documentation should have a note on that

	Cheers --- Jan

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

[Andreas Ericsson]

Johannes Schindelin wrote:
> Hi,
> 
> On Mon, 12 Nov 2007, Nicolas Pitre wrote:
> 
>> On Mon, 12 Nov 2007, Johannes Schindelin wrote:
>>
>>> On Mon, 12 Nov 2007, Matthieu Moy wrote:
>>>
>>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>>
>>>>> On Mon, 12 Nov 2007, Jan Wielemaker wrote:
>>>>>
>>>>>> I found out that cloning a empty bare repository produces nothing 
>>>>>> at all, [...]
>>>>> If they are empty, what exactly do you mean to clone?
>>>> I'd expect an empty repository, with the git remote configured 
>>>> correctly.
>>> Yeah, right.
>>>
>>> Last time I checked, those geneticists did not clone thin air.  They 
>>> always waited until they had something to clone.
>> But we're not geneticists, and I think the above usage should "just work 
>> (tm)".
> 
> I am still convinced that it is not very intelligent to start your 
> development from a non-existing branch.
> 

That's what happens with every new project though. The question is if
something starts with making space for things to be in, or if it starts
with things appearing in that space.

> But since you're one of the people knowing git _internals_ pretty well, 
> here's another reason just for you why this cannot be done: There is no 
> way to find out where the HEAD points to.
> 

$ mkdir foo; cd foo; git init; git symbolic-ref -q HEAD
refs/heads/master

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

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

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>>> > On Mon, 12 Nov 2007, Matthieu Moy wrote:
>>> >
>>> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>> >> 
>>> >> > So you need to populate the repository before starting _anyway_.
>>> >> 
>>> >> Last time I checked, the thread was talking about bare repository.
>>
>> Look at the subject.  "Cloning empty repositories."
>
> Look at the content. "cloning a empty bare repository".

But both of Johannes's points apply equally well to an empty
bare repository and to an empty non bare repository.  IOW,
bareness does not matter to the suggestion Johannes gave.

But you are acting as if the bareness of the target repository
makes his point irrelevant.  I am a bit confused.

About his point 1, I'd just stop at saying that "it is not so
hard" does not mean "we do not have to make it even easier".

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.

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

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> Johannes Schindelin wrote:
>
>> But since you're one of the people knowing git _internals_ pretty
>> well, here's another reason just for you why this cannot be done:
>> There is no way to find out where the HEAD points to.
>
> $ mkdir foo; cd foo; git init; git symbolic-ref -q HEAD
> refs/heads/master

Johannes is talking about the lack of native protocol support to
transfer symref information.  That's the reason git-clone dances
around finding where HEAD really points at.  It simply does not
know -- all it gets about a symref is what SHA-1 the ref points
at.

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

[Nicolas Pitre]

On Mon, 12 Nov 2007, Junio C Hamano wrote:

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

While that could well be true, I don't see this condition happening 
solely in the context (hence because) of an empty clone.


Nicolas

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

[Johannes Schindelin]

Hi,

On Mon, 12 Nov 2007, Nicolas Pitre wrote:

> On Mon, 12 Nov 2007, Junio C Hamano wrote:
> 
> > 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.
> 
> While that could well be true, I don't see this condition happening 
> solely in the context (hence because) of an empty clone.

Hehe.  That is a very delicate play with predicates.

If Alice and Bob clone from an empty repository, and both work on it, 
there is _no way_ that they can have a common ancestor[*].  Hence, an 
empty clone _would_ be a cause of that condition.

The only way to _not_ have this condition would be at least one side 
starting with a non-empty clone.  Or with an _effectively_ non-empty 
clone.

Ciao,
Dscho

[*] Oh yes, theoretically they could commit the same commit with the same 
author info and author timestamp, but to be a common ancestor, they would 
also have to use the same _committer_information, which means that Alice 
== Bob, as far as Git is concerned.  Do I have to go on?

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

[Jakub Narebski]

Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>> Johannes Schindelin wrote:
>>
>>> But since you're one of the people knowing git _internals_ pretty
>>> well, here's another reason just for you why this cannot be done:
>>> There is no way to find out where the HEAD points to.
>>
>> $ mkdir foo; cd foo; git init; git symbolic-ref -q HEAD
>> refs/heads/master
> 
> Johannes is talking about the lack of native protocol support to
> transfer symref information.  That's the reason git-clone dances
> around finding where HEAD really points at.  It simply does not
> know -- all it gets about a symref is what SHA-1 the ref points
> at.

Do I remember correctly that there was some talk about extending git
protocol to avoid this compicated dance, and transfer symbolic refs
directly?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

[Andreas Ericsson]

Junio C Hamano wrote:
> 
> 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.


If we assume zero communication between these two, the alternative
is this:
Bill starts hacking in his own repo and then uploads his .git dir
to the server.
David starts hacking in his own repo and then uploads his .git
dir to the server.

The only difference between the two scenarios is (assuming they
have write access to those shared directories) that the last-in
wins in the second case, while first-in wins in the first one.

Oh, and the fact that the first to upload his .git dir to the
server will lose all his refs if he isn't careful to save his
original copy until they both have established which "first"
commit to use, which could take a while in this imaginary world
where they don't seem to be speaking to each other but are still
working together.

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

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

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> But both of Johannes's points apply equally well to an empty
> bare repository and to an empty non bare repository.  IOW,
> bareness does not matter to the suggestion Johannes gave.

He was suggesting to create the initial commit before cloning:

>> So you need to populate the repository before starting _anyway_.

To create an initial commit in a non-bare repository, I put files in
it, git add, and git commit.

To create an initial commit in a bare repository, the most natural way
for me is to clone it, create the commit in the clone, and then push.

Bare-ness _does_ matter for that.

I repeat the use-case I mentionned above :

,----
| a typical use-case is when I want to create a new project. I'd
| like to initialize an empty bare repo on my backed up disk, and then
| clone it to my local-fast-unreliable disk to get a working copy and do
| the first commit there.
`----

I find this quite natural, and up to now, no one gave me either a
rationale not to do that, or a _simple_ way to achieve this. As I
said, it's currently not _very_ hard to do, but I have to edit
.git/config by hand, while git clone knows how to do this much faster
than I for non-empty repositories.

-- 
Matthieu

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

[Shawn O. Pearce]

Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> I repeat the use-case I mentionned above :
> 
> ,----
> | a typical use-case is when I want to create a new project. I'd
> | like to initialize an empty bare repo on my backed up disk, and then
> | clone it to my local-fast-unreliable disk to get a working copy and do
> | the first commit there.
> `----
> 
> I find this quite natural, and up to now, no one gave me either a
> rationale not to do that, or a _simple_ way to achieve this. As I
> said, it's currently not _very_ hard to do, but I have to edit
> .git/config by hand, while git clone knows how to do this much faster
> than I for non-empty repositories.

Its a goal to redefine git-clone as the following, as that is
really all it does:

	mkdir foo && cd foo && git init &&
	git remote add -f origin $url &&
	git checkout -b master origin/master

So setting up an empty tree is basically that:

	mkdir foo && cd foo && git init &&
	git remote add origin $url

Is that really so difficult?  git-clone is a handy crutch for when
we didn't have things like git-remote.  Or remote tracking branches.
IMHO the above may seem a little low level but it may make it easier
to teach to newbies.  They are more likely to grasp the concept of
their repository being just like someone else's, and that they can
track other repositories beyond just their origin.

-- 
Shawn.

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

[Jakub Narebski]

Matthieu Moy wrote:

> I repeat the use-case I mentionned above :
> 
> ,----
> | a typical use-case is when I want to create a new project. I'd
> | like to initialize an empty bare repo on my backed up disk, and then
> | clone it to my local-fast-unreliable disk to get a working copy and do
> | the first commit there.
> `----
> 
> I find this quite natural, and up to now, no one gave me either a
> rationale not to do that,

The rationale is that current git just simply cannot do this.
You are welcome to add support for this corner case in git-clone,
or add git protocol extension for symref transfer.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

[Matthieu Moy]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> So setting up an empty tree is basically that:
>
> 	mkdir foo && cd foo && git init &&
> 	git remote add origin $url

It is not.

The "git remote add" thing adds this to my .git/config:

[remote "origin"]
        url = /tmp/git1
        fetch = +refs/heads/*:refs/remotes/origin/*

While clone normally does a bit more:

[remote "origin"]
        url = /tmp/git1/.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master

So, it's really

$ git remote add origin url
$ $EDITOR .git/config    # or perhaps I missed the way to set the two
                         # options easily.

I find it so conveinient to have it for non-empty clones, it's
frustrating to have to do it by hand for empty clones.

-- 
Matthieu

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

[Johannes Schindelin]

Hi,

On Tue, 13 Nov 2007, Matthieu Moy wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > But both of Johannes's points apply equally well to an empty bare 
> > repository and to an empty non bare repository.  IOW, bareness does 
> > not matter to the suggestion Johannes gave.
> 
> He was suggesting to create the initial commit before cloning:
> 
> >> So you need to populate the repository before starting _anyway_.

Of course I was suggesting to push into the still empty, bare repository, 
before anybody is cloning.

Ciao,
Dscho

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

[Jeff King]

On Tue, Nov 13, 2007 at 11:50:16AM +0100, Matthieu Moy wrote:

> The "git remote add" thing adds this to my .git/config:
> 
> [remote "origin"]
>         url = /tmp/git1
>         fetch = +refs/heads/*:refs/remotes/origin/*
> 
> While clone normally does a bit more:
> 
> [remote "origin"]
>         url = /tmp/git1/.git
>         fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "master"]
>         remote = origin
>         merge = refs/heads/master

Also, git-clone sets up the HEAD symref automagically (you can specify
it manually with git-remote, but git-clone will put it from the remote's
HEAD).

-Peff

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

[Nicolas Pitre]

On Tue, 13 Nov 2007, Shawn O. Pearce wrote:

> Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> > I repeat the use-case I mentionned above :
> > 
> > ,----
> > | a typical use-case is when I want to create a new project. I'd
> > | like to initialize an empty bare repo on my backed up disk, and then
> > | clone it to my local-fast-unreliable disk to get a working copy and do
> > | the first commit there.
> > `----
> > 
> > I find this quite natural, and up to now, no one gave me either a
> > rationale not to do that, or a _simple_ way to achieve this. As I
> > said, it's currently not _very_ hard to do, but I have to edit
> > .git/config by hand, while git clone knows how to do this much faster
> > than I for non-empty repositories.
> 
> Its a goal to redefine git-clone as the following, as that is
> really all it does:
> 
> 	mkdir foo && cd foo && git init &&
> 	git remote add -f origin $url &&
> 	git checkout -b master origin/master
> 
> So setting up an empty tree is basically that:
> 
> 	mkdir foo && cd foo && git init &&
> 	git remote add origin $url
> 
> Is that really so difficult?  git-clone is a handy crutch for when
> we didn't have things like git-remote.  Or remote tracking branches.
> IMHO the above may seem a little low level but it may make it easier
> to teach to newbies.  They are more likely to grasp the concept of
> their repository being just like someone else's, and that they can
> track other repositories beyond just their origin.

FWIW all my Git tutorials for $work so far always avoided 'git clone'. 
The 'git init' + 'git remote add' + 'git fetch' is what I ask people to 
do.  It is more obvious to give a good name for the remote repo that 
way, and this can be performed into either a new or an existing repo 
when the data is related.


Nicolas

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

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

> To create an initial commit in a bare repository, the most natural way
> for me is to clone it, create the commit in the clone, and then push.
>
> Bare-ness _does_ matter for that.

You are still wrong.

The most natural is to create a commit in a non-bare repository
you create, and push into a bare empty repository.  The
repository that is pushed into can be non-bare, but bareness of
that does _NOT_ matter.

Where bareness matters is on your end, the local private
repository you create the initial commit in.

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

[Brian Gernhardt]

On Nov 13, 2007, at 5:50 AM, Matthieu Moy wrote:

> While clone normally does a bit more:
>
> [remote "origin"]
>        url = /tmp/git1/.git
>        fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "master"]
>        remote = origin
>        merge = refs/heads/master

But how is clone expected to do that when the origin is an empty  
repo?  There is no branch for it to track, and automagically setting  
it to master is bogus because then it's tracking something that  
doesn't exist.

The easy way to set up the last bit is "git checkout -b master --track  
origin/master".  But that won't work if origin/master doesn't exist.   
The following will always work:

git config branch.master.remote origin
git config branch.master.merge refs/heads/master

But asking git-clone do do this sort of odd magic for an empty repo is  
dubious at best.  Perhaps convenient for your situation, but creates  
repos that don't actually work.  (Will give errors when trying to  
merge a non-existent branch, at the very least.)

~~ Brian

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

[Matthieu Moy]

Brian Gernhardt <benji@silverinsanity.com> writes:

> On Nov 13, 2007, at 5:50 AM, Matthieu Moy wrote:
>
>> While clone normally does a bit more:
>>
>> [remote "origin"]
>>        url = /tmp/git1/.git
>>        fetch = +refs/heads/*:refs/remotes/origin/*
>> [branch "master"]
>>        remote = origin
>>        merge = refs/heads/master
>
> But how is clone expected to do that when the origin is an empty
> repo?  There is no branch for it to track, and automagically setting
> it to master is bogus because then it's tracking something that
> doesn't exist.

An implementation of that would probably need to special-case the
empty repository. But an empty repository is already a special case.
HEAD already points to master, and master is already hardcoded here:

$ cat .git/HEAD 
ref: refs/heads/master

So, it's possible for HEAD to point to a branch which doesn't exist
yet, it's possible to commit to a branch which doesn't exist yet. It
would make sense to extend that to allow a remote to point to a branch
which doesn't exist either.

But don't get me wrong: I probably won't implement that myself, so I
can't _ask_ people to do it for me. I would just appreciate if people
stopped calling me (and other users interested in a sane empty clone
behavior) idiot because I think it would make sense to do it.

-- 
Matthieu

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

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> To create an initial commit in a bare repository, the most natural way
>> for me is to clone it, create the commit in the clone, and then push.
>>
>> Bare-ness _does_ matter for that.
>
> You are still wrong.
>
> The most natural is to create a commit in a non-bare repository
> you create, and push into a bare empty repository.

Yes, we agree on that point.

But I do find (incorrect with current git)

(1)

$ mkdir ~/bare-repo
$ cd ~/bare-repo
$ git --bare init
$ cd
$ git clone bare-repo local/non-bare
$ cd local/non-bare
<put files, git add, git commit>
$ git push

Simpler than (valid with current git)

(2)

$ mkdir ~/bare-repo
$ cd ~/bare-repo
$ git --bare init
$ cd
$ mkdir local/non-bare
$ cd local/non-bare
$ git init
<put files, git add, git commit>
$ git push ~/bare-repo
$ git remote add origin ~/bare-repo
$ git config branch.master.remote origin
$ git config branch.master.merge refs/heads/master

Where the bare-ness of ~/bare-repo matters is that with a bare
repository, I could have actually created the initial commit there
(valid with current git too):

(3)

$ mkdir ~/non-bare-repo
$ cd ~/non-bare-repo
$ git init
<put files, git add, git commit>
$ cd
$ git clone bare-repo local/non-bare

> The repository that is pushed into can be non-bare, but bareness of
> that does _NOT_ matter.

Either there is a way to achive (3) above with a bare repository which
I don't know, or bare-ness does matter in this case.

-- 
Matthieu

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

[David Kastrup]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> If Alice and Bob clone from an empty repository, and both work on it,
> there is _no way_ that they can have a common ancestor[*].  Hence, an
> empty clone _would_ be a cause of that condition.

So where is the problem with that?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Johannes Schindelin]

Hi,

On Tue, 13 Nov 2007, Matthieu Moy wrote:

> I would just appreciate if people stopped calling me (and other users 
> interested in a sane empty clone behavior) idiot because I think it 
> would make sense to do it.

Oh, come on.  Nobody called _you_ idiot.

But I illustrated that cloning from an empty repository makes no sense.

There is a huge difference between calling somebody an idiot on the one 
side, and investing some time to help somebody who has a suboptimal 
workflow on the other one.

But I fear that you took my help as a personal attack, and as a 
consequence you feel insulted, and I wasted my precious time.

Ciao,
Dscho

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

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

> (2)
>
> $ mkdir ~/bare-repo
> $ cd ~/bare-repo
> $ git --bare init
> $ cd
> $ mkdir local/non-bare
> $ cd local/non-bare
> $ git init

...

If your publishing repo is local like the above, then

 $ mkdir /tmp/junk && cd /tmp/junk
 $ git init; tar xf /tmp/project.tar; git add .; ... populate ... 
 $ git commit -m initial
 $ cd /else/where/to/publish
 $ git clone --bare /tmp/junk myproject.git
 $ rm -fr /tmp/junk

would be enough to get your published repository started, isn't
it?  Then wouldn't:

 $ cd $HOME
 $ git clone /else/where/to/publish/myproject.git myproject

set up your ~/myproject exactly the same way as other people who
will work with that published repository?

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

[Matthieu Moy]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> But I illustrated that cloning from an empty repository makes no sense.

And I, and others, illustrated the opposite.

> There is a huge difference between calling somebody an idiot on the one 
> side, and investing some time to help somebody who has a suboptimal 
> workflow on the other one.

You didn't show me where my proposed flow was suboptimal.

> But I fear that you took my help as a personal attack, and as a 
> consequence you feel insulted, and I wasted my precious time.

Do you call _that_ "help"?

,----
| Last time I checked, those geneticists did not clone thin air.  They 
| always waited until they had something to clone.
`----

To me, this classifies either as "totally irrelevant remark", or as
"making fun of someone". Definitely not "help".

-- 
Matthieu

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

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> If your publishing repo is local like the above, then

In my case, it's more often a "backed-up and slow NFS disk" Vs "local
disk" than a matter of publishing, but the result is similar.

>  $ mkdir /tmp/junk && cd /tmp/junk
>  $ git init; tar xf /tmp/project.tar; git add .; ... populate ... 
>  $ git commit -m initial
>  $ cd /else/where/to/publish
>  $ git clone --bare /tmp/junk myproject.git
>  $ rm -fr /tmp/junk
>
> would be enough to get your published repository started, isn't
> it?  Then wouldn't:
>
>  $ cd $HOME
>  $ git clone /else/where/to/publish/myproject.git myproject
>
> set up your ~/myproject exactly the same way as other people who
> will work with that published repository?

Sure, it definitely works. But that (creating a temporary repository,
and right after, delete it) also is an extra step. Not a huge one, but
still an extra step.

Take the same with bzr for example:

$ bzr init ~/repo
$ bzr checkout ~/repo ~/local/work/
$ cd ~/local/work/
<put files, bzr add, bzr commit>
<continue working in ~/local/work/, commit, whatever>

(bzr checkout is a bit different from git clone, but the difference it
not totally relevant here).

I litterally have just two bzr commands before I can start working
normally.

-- 
Matthieu

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

[Sergei Organov]

Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>>> > On Mon, 12 Nov 2007, Matthieu Moy wrote:
>>>> >
>>>> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>> >> 
>>>> >> > So you need to populate the repository before starting _anyway_.
>>>> >> 
>>>> >> Last time I checked, the thread was talking about bare repository.
>>>
>>> Look at the subject.  "Cloning empty repositories."
>>
>> Look at the content. "cloning a empty bare repository".
>
> But both of Johannes's points apply equally well to an empty
> bare repository and to an empty non bare repository.  IOW,
> bareness does not matter to the suggestion Johannes gave.
>
> But you are acting as if the bareness of the target repository
> makes his point irrelevant.  I am a bit confused.
>
> About his point 1, I'd just stop at saying that "it is not so
> hard" does not mean "we do not have to make it even easier".
>
> 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.

-- 
Sergei.

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

[Jakub Narebski]

Sergei Organov wrote:

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

No. Sometimes you want unrelated branches in repository ('html', 'man',
'todo' branches in git.git), sometimes multiple roots are natural (merging
in a project, like git-mailtools, gitweb, gitk, git-gui in git.git).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

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

[Matthieu Moy]

Jakub Narebski <jnareb@gmail.com> writes:

> Sergei Organov wrote:
>
>> 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.
>
> No. Sometimes you want unrelated branches in repository ('html', 'man',
> 'todo' branches in git.git), sometimes multiple roots are natural (merging
> in a project, like git-mailtools, gitweb, gitk, git-gui in git.git).

There's no contradiction IMHO. At least bzr and Mercurial have the
notion of "null revision" that is a kind of virtual ancestor of the
first revision of a project, and AFAICT, they supprot having unrelated
branches in the same repository, and merging originally unrelated
projects together (not sure for Mercurial, but bzr can do it).

It just depends on the definition of "starting a project". Either you
say you start the project with "init", in which case all projects
start with the same thing, or you say you start with the first
"commit" in which case every project start with something different.

Anyway, we can't modify existing git projects now (adding an ancestor
to the initial revision would change each sha1 sum), so adding this
concept to git now would probably break all of it :-\.

-- 
Matthieu

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

[Sergei Organov]

Jakub Narebski <jnareb@gmail.com> writes:

> Sergei Organov wrote:
>
>> 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.
>
> No. Sometimes you want unrelated branches in repository ('html', 'man',
> 'todo' branches in git.git), sometimes multiple roots are natural (merging
> in a project, like git-mailtools, gitweb, gitk, git-gui in git.git).

Sorry, I fail to see how does it interfere with the idea of the NULL
commit. What if  "unrelated" is defined as "the only common
ancestor is the NULL commit"?

Anyway, I'm not going do defend the idea further. I just recalled I
heard about it somewhere, probably in Bazaar-NG, and I thought I'd
mention it here as it appeared very natural to me.

-- 
Sergei.

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

[Junio C Hamano]

Sergei Organov <osv@javad.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> 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.

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

[Bill Lear]

On Wednesday, November 14, 2007 at 11:32:32 (-0800) Junio C Hamano writes:
>Sergei Organov <osv@javad.com> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> 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

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

[Bill Lear]

[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

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

[Wincent Colaiuta]

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

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

[Johannes Schindelin]

Hi,

On Wed, 14 Nov 2007, Bill Lear wrote:

> On Wednesday, November 14, 2007 at 11:32:32 (-0800) Junio C Hamano writes:
>
> >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

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

[Bill Lear]

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

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

[Johannes Schindelin]

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

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

[David Kastrup]

Junio C Hamano <gitster@pobox.com> writes:

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

I do not like the approach of policy by force.  It assumes that the
developers know better than the users what the users are going to do
with git.

For example, I use git for tracking and versioning installations and
updaters of complex programs.  They are basically built into a directory
tree, and this tree is checked into a bare repository in a branch
corresponding to a particular customer.  The trees are _target_ trees
created completely by something akin to make install.  So every checkin
is from scratch.  The checkins for a particular customer happen in one
branch so that it is easy to generate a diff and from that an updater
(the diff gets converted into a batch file removing old files and a zip
file unpacking new files over the old ones).

There simply is no common reference/starting point for the disparate
branches.  I have some "README" in master, but that is an utterly stupid
and unnatural starting point.

One might argue that one should use one repository per customer and just
share the objects (many of which are similar).  But that disallows
making diffs between the trees of different customers.  Since the
purpose of git here is just to track history and not do any sort of
merging or rebasing, there are no interesting ancestry connections
between branches.

Am I stupid for using git for this sort of thing?  I believe not.  And
yet git developers choose to call me stupid because my work flow does
not lend any sense to a common ancestor commit.

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

And they will continue to take resources.  And since the trend goes more
and more into name-calling on those who still feel that their workflow
justifies disparate branches without common registered ancestry, it will
increasingly drain the most important resources of all: goodwill and
enthusiasm.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Jeff King]

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"

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

[Andreas Ericsson]

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.

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

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

[Andreas Ericsson]

David Kastrup wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> 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).
> 
> I do not like the approach of policy by force.  It assumes that the
> developers know better than the users what the users are going to do
> with git.
> 

Junio just said "but that is fine", so afaiu he's not against allowing
it per se. It's just that him and the other frequent contributors don't
have this particular problem, so if *they* fix it it will
a) Not be done with enthusiasm, and it would indeed drain enthusiasm and
   happiness from the project.
b) Perhaps not be done the way those who want this feature would like it.
c) Take another scarce resource (time) from other, more pressing issues
   which may or may not affect your workflow too.

Junio also suggested what's likely to be needed for this to work "properly",
ie, an extension to the git protocol to let it transfer symref content.

Since empty repositories have HEAD pointing to refs/heads/master by default,
you might get away with a simpler implementation.

> For example, I use git for tracking and versioning installations and
> updaters of complex programs.  They are basically built into a directory
> tree, and this tree is checked into a bare repository in a branch
> corresponding to a particular customer.  The trees are _target_ trees
> created completely by something akin to make install.  So every checkin
> is from scratch.  The checkins for a particular customer happen in one
> branch so that it is easy to generate a diff and from that an updater
> (the diff gets converted into a batch file removing old files and a zip
> file unpacking new files over the old ones).
> 
> There simply is no common reference/starting point for the disparate
> branches.  I have some "README" in master, but that is an utterly stupid
> and unnatural starting point.
> 
> One might argue that one should use one repository per customer and just
> share the objects (many of which are similar).  But that disallows
> making diffs between the trees of different customers.  Since the
> purpose of git here is just to track history and not do any sort of
> merging or rebasing, there are no interesting ancestry connections
> between branches.
> 
> Am I stupid for using git for this sort of thing?  I believe not.  And
> yet git developers choose to call me stupid because my work flow does
> not lend any sense to a common ancestor commit.
> 

Not stupid, but most likely unusual. Optimizing git for your needs would
imho be a bad idea. It's perfectly fine to use a tool for something else
than what it was intended for, but then you'll have to live with the
fact that it *will* have a few shortcomings and that you'll have to work
around them or fix them yourself.

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

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

[Johannes Schindelin]

Hi,

On Thu, 15 Nov 2007, Andreas Ericsson wrote:

> Since empty repositories have HEAD pointing to refs/heads/master by 
> default, you might get away with a simpler implementation.

I recently had somebody asking me "how do I rename master in an empty 
repository?"  It is only logical to think in those terms if you want to 
start your common development on no common basis at all (i.e. the empty 
set).

> > Am I stupid for using git for this sort of thing?  I believe not.  
> > And yet git developers choose to call me stupid because my work flow 
> > does not lend any sense to a common ancestor commit.
> 
> Not stupid, but most likely unusual. Optimizing git for your needs would 
> imho be a bad idea. It's perfectly fine to use a tool for something else 
> than what it was intended for, but then you'll have to live with the 
> fact that it *will* have a few shortcomings and that you'll have to work 
> around them or fix them yourself.

Yes, I agree.  That's what Open Source is: some take their formula one car 
to go shopping.  In some cases, others laugh because that crate of beer 
tied to the front spoiler sure looks funny.  In some of these cases, the 
driver laughs back, because only this car allows her to go shopping for 
dinner in a town across the continent.

Seriously again, there are sure things git was not optimised for.  If 
some complaints involving such (from git's POV) suboptimal workflows are 
retorted by saying so, it is not calling somebody "stupid".  Sheesh.

Ciao,
Dscho

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

[David Kastrup]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Seriously again, there are sure things git was not optimised for.
> If some complaints involving such (from git's POV) suboptimal
> workflows are retorted by saying so, it is not calling somebody
> "stupid".  Sheesh.

"Conditioned by retarded systems" is pretty close, and it was pretty
much the wording employed.  And then, when someone gets upset, he gets
"Sheesh"ed off, basically calling him stupid again.

"People skills" is not something I would associate with the git
developer list in general.

-- 
David Kastrup

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

[Jeff King]

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"

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Junio, can I get an ACK or NAK on the patch below?

I do not think it would hurt.  Is the "local" case the only
codepath that needs this (iow, we would not need this message if
other transports die more loudly and/or we cannot tell if the
failure is wrong URL or empty remote repository)?

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

[Jeff King]

On Sat, Nov 17, 2007 at 05:06:51PM -0800, Junio C Hamano wrote:

> > Junio, can I get an ACK or NAK on the patch below?
> 
> I do not think it would hurt.  Is the "local" case the only
> codepath that needs this (iow, we would not need this message if
> other transports die more loudly and/or we cannot tell if the
> failure is wrong URL or empty remote repository)?

Good question, and the answer is yes, it is the only spot that produces
no useful output. The other errors are:

via ssh, git-daemon, or file:// (all using receive-pack) you get:
$ git-clone localhost:foo bar
Initialized empty Git repository in /home/peff/bar/.git/
fatal: no matching remote head
fetch-pack from 'localhost:foo' failed.

via http, you get:
$ git-clone http://localhost/git/foo bar
Initialized empty Git repository in /home/peff/bar/.git/
Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?

I didn't try rsync, though I expect it should be the same as http.

-Peff