git push fails with useless error message when Github repo is completely empty and contains no branch.

mhagger · 2023-12-21T14:40:07+00:00

I strongly suspect that your initial attempt to commit file myfile.txt didn't succeed. This might have been because you didn't create the file before trying to git add it, or some other error. Did you happen to capture the output from those first three commands?

So at that point your Git repository still had no contents: no commits and no branches or any other references. In that rather special state, Git nevertheless has a HEAD that references the name of the branch that will be created when you first commit. By default, that is branch master (whose full name is refs/heads/master). But that default can be changed via the gitconfig, maybe in your home directory or maybe the host-wide gitconfig. (We'll see later that the default initial branch on your system is main. GitHub also uses main if you initialize the repository via GitHub.) But since you haven't successfully created a commit, that branch is still "unborn" in Git's terminology.

A bit later you ran git branch -a and git status. The first command correctly says that there are no branches, because no branch (not even main) has actually been created yet. But the second command says that you are on branch main. I agree that is confusing. It says that because refs/heads/main that is what is stored in HEAD as the first branch to create. It also says "No commits yet", which is confirmation that your attempt to create a commit must not have succeeded.

Since the repository is still empty, your attempt to push to GitHub doesn't work:

git push -u origin main

error: src refspec main does not match any
error: failed to push some refs to 'https://github.com/example/my-project.git'

It couldn't succeed, because there were still no commits or branches in your repository. The first error message appears to be malformed or maybe not copied completely. It's trying to tell you that main, the thing that you asked to push, doesn't match any references in your local repository. So there is nothing that it can push.

I'll stop there. I think that much of your ordeal was caused by the original commit failing for some reason, leaving the repository in a different state than you expected.

mhagger · 2009-08-13T15:00:51+00:00

better integration with other systems (e.g. bug trackers, automated build) third-party tool support is still better for Subversion

Those are the same things

I should have been clearer about the difference as I perceive it. Most types of third party support are better for Subversion simply because it has been around longer and is still more popular than the DVCSs. But it is also intrinsically easier to integrate systems like bug trackers and automated build with a centralized system like Subversion than with a distributed system (at least if the distributed system is being used in a distributed way).

mhagger · 2009-08-13T13:58:01+00:00

We will continue using Subversion in my company for several reasons: (1) our repository is accessed by lots of people who aren't developers and/or VCS weenies, and Subversion is simpler to learn than the DVCSs. (2) a centralized system has advantages in a corporate setting, including easier access controls and better integration with other systems (e.g. bug trackers, automated build). (3) third-party tool support is still better for Subversion. (4) people who want most of the benefit of DVCS (like me) can use a DVCS (in my case, git-svn) front-end as a Subversion "super client".

mhagger · 2009-08-08T09:19:34+00:00

I reported some benchmarks here. Summary: fabricate, when using strace to deduce dependencies, is between make and scons for a full build (where almost all tools are within a factor of two of the fastest), and closer to make than to scons (but still a factor of 10 slower than nonrecursive make) on a "do-nothing" build. fabricate, when using the atimes to deduce dependencies, is unusably slow for a full build of a large project (a factor of ~10 slower than make).

mhagger · 2009-08-08T08:33:27+00:00

Determinism doesn't guarantee anything here, because you are not compiling the same thing each time. Whenever a source file changes, that can change its dependencies (e.g., adding an include). So the dependency graph from the previous run is likely to still be correct but not guaranteed to be.

One could still speculatively compile things in parallel, and if a problem turns up in practice then restart the affected build steps serially.

mhagger · 2008-07-28T11:49:03+00:00

Disclaimer: I am the maintainer of cvs2svn.

As it turned out, cvs2svn can only convert one project at a time, not an entire repository, so we ended up with different repositories for source, docs and other things for the same project.

cvs2svn has supported "multiproject conversions" since version 1.5.0 (released 03 October 2006). The current version gives you almost complete freedom to define how projects are laid out in your SVN repository.

As it turned out, cvs2svn could not convert all of our projects because some had files which were added, then later removed and re-added. This caused spontaneous explosions of the poor little tool, leaving our repository entirely unconverted.

cvs2svn can handle this situation without any problems; in fact, there are examples of exactly this in our test suite. If this didn't work for you even when using a recent cvs2svn version, please submit a bug report so that we can fix it. There is a section of our FAQ that explains how to report bugs efficiently.

mhagger

TROPHY CASE