On 03/03/2008, Jeff King <peff@xxxxxxxx> wrote: > On Sat, Mar 01, 2008 at 07:40:39PM +0000, Reece Dunn wrote: > > > Consider the following workflow: > > > > $ mkdir foo > > $ cd foo > > $ git --bare init > > > > $ git log > > fatal: bad default revision 'HEAD' > > > > This message is confusing for a newbie. Displaying "no commits" would > > make more sense here. > > The tricky thing here is that "git log" doesn't know we have no > commits in the repo; it only knows that HEAD is bogus. But it may be > that we can just say something like: > > fatal: unable to resolve HEAD; do you have any commits? That would be better. The current message would indicate something like a corrupt repository (or at least the metadata to the repository). > > $ git clone foo bar > > Initialized empty Git repository in /home/reece/bar/.git/ > > $ ls -a /home/reece > > . .. foo > > As of 1.5.4, this now says "fatal: cannot clone empty repository". There > has been work recently on a C version of clone which tries to match the > sequence of "init && remote add && fetch && checkout" more closely. I > haven't looked closely, but I suspect it may just work (by which I mean > create an empty repo with origin config pointing to the parent repo). I have verified that behaviour with 1.5.4. Having an empty repository (possibly with a warning issued about cloning an empty repository) with the origin pointing to the parent repository is what I would expect to happen. > > It appears from the git output (with the inconsistently capitalized > > git - see --version output above) that the clone succeeded, but it > > does not create bar/.git/, even though it said that it did. > > It did create it...it just deleted it afterwards without telling you. :) :) Thanks, - Reece -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
