login
Search
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 -
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.
--
Bruno Ribas - ribas@c3sl.ufpr.br
http://web.inf.ufpr.br/ribas
C3SL: http://www.c3sl.ufpr.br
-
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 -
Hi, 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 -
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, If they are empty, what exactly do you mean to clone? Ciao, Dscho -
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 -
Hi, Yeah, right. Last time I checked, those geneticists did not clone thin air. They always waited until they had something to clone. Ciao, Dscho -
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, 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 -
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 -
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 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 -
Hi, Wrong. Wrong, wrong, wrong. It was talking about _cloning_ an _empty_ repository. (Bare or not is not No, but that was not what I was questioning. No, sir, not at all. Ciao, Dscho -
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 `---- Perhaps you can reconsider this after reading the above. -- Matthieu -
Look at the subject. "Cloning empty repositories." Nuff said, Dscho who sighs -
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.
-
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. -
Hi, 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? -
So where is the problem with that? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -
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 -
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 -
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. -
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
-
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 -
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 -
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 -
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 -
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 -
Hi, Of course I was suggesting to push into the still empty, bare repository, before anybody is cloning. Ciao, Dscho -
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. -
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 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 -
... 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? -
In my case, it's more often a "backed-up and slow NFS disk" Vs "local 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 -
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. -
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. -
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.] Sorry for the sloppiness. Bill -
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, 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 -
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 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 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 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, 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" 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. 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" And I am thankful that you bring up the vexing issues so that we can 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 -
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 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 -
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 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 -
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, 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 -
Hi, 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 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 -
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" -
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" -
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 -
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 -
But we're not geneticists, and I think the above usage should "just work (tm)". Nicolas -
Hi, 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" -
Well, that's an orthogonal question and I'm not providing any opinion So? Why couldn't you just do the 'git remote add' dance implicitly in that case anyway? Nicolas -
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 $ 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 -
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. -