What is the idea for bare repositories?

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?

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.

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

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

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

On Monday 12 November 2007 14:57, Johannes Schindelin 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
	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

Hi,

On Mon, 12 Nov 2007, Jan Wielemaker wrote:

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

Ciao, Dscho

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

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

Hi,

On Mon, 12 Nov 2007, Matthieu Moy wrote:

Yeah, right.

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

Ciao, Dscho

On Monday, November 12, 2007 at 17:15:51 (+0000) Johannes Schindelin writes:

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

Hi,

On Mon, 12 Nov 2007, Bill Lear wrote:

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

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

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

So, what?

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.

Hi,

On Mon, 12 Nov 2007, Matthieu Moy wrote:

Wrong.  Wrong, wrong, wrong.

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

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

Ciao, Dscho

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

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 can reconsider this after reading the above.

Hi,

Look at the subject.  "Cloning empty repositories."

Nuff said, Dscho who sighs

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

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 Moy <Matthieu.Moy@imag.fr> 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.

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.

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

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

Nicolas

Hi,

On Mon, 12 Nov 2007, Nicolas Pitre wrote:

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?

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

So where is the problem with that?

Junio C Hamano wrote:

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.

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

He was suggesting to create the initial commit before cloning:

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 Moy <Matthieu.Moy@imag.fr> wrote:

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 O. Pearce" <spearce@spearce.org> writes:

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.

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

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

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

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

Brian Gernhardt <benji@silverinsanity.com> writes:

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.

Hi,

On Tue, 13 Nov 2007, Matthieu Moy wrote:

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

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

And I, and others, illustrated the opposite.

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

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

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

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

Matthieu Moy wrote:

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.

Hi,

On Tue, 13 Nov 2007, Matthieu Moy wrote:

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

Ciao, Dscho

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

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.

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

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

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 Moy <Matthieu.Moy@imag.fr> writes:

...

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?

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

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.

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.

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

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 Organov wrote:

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 <jnareb@gmail.com> writes:

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

Jakub Narebski <jnareb@gmail.com> writes:

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 Organov <osv@javad.com> writes:

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:

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:

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

[git init is needed here...]

Sorry for the sloppiness.

Bill

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

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:

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:

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.

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

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:

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!

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

And I am thankful that you bring up the vexing issues so that we can discuss (and hopefully fix) them.

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

Bill Lear wrote:

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.

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

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

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.

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 wrote:

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.

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.

Hi,

On Thu, 15 Nov 2007, Andreas Ericsson wrote:

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

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

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

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.

---

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.

---

Jeff King <peff@peff.net> writes:

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

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

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

On Monday 12 November 2007 18:47:14 Matthieu Moy wrote:

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

On Monday, November 12, 2007 at 17:30:10 (+0000) Johannes Schindelin writes:

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

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

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

On Mon, 12 Nov 2007, Johannes Schindelin wrote:

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

Nicolas

Hi,

On Mon, 12 Nov 2007, Nicolas Pitre wrote:

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"

On Mon, 12 Nov 2007, Johannes Schindelin wrote:

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

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

Nicolas

Johannes Schindelin wrote:

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.

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

Andreas Ericsson <ae@op5.se> writes:

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.

Junio C Hamano wrote:

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

Jan Wielemaker wrote:

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

On Nov 12, 2007 1:19 PM, Bruno Cesar Ribas <ribas@c3sl.ufpr.br> wrote:

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

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

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.

David Kastrup wrote:

[...]

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 <jnareb@gmail.com> writes:

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

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

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

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