On Thu, Jan 29, 2009 at 12:27:23PM +0100, Sverre Rabbelier wrote: > I thought instead we wanted to support the following workflow: > > $ (cd child && echo content >file && git add file && git commit -m one) > [normal commit output] > > Which is what the testcase tests. E.g., we want to support cloning an > empty repo so that the user can then _push_ to that repository to make > it non-empty, no? True, that is probably going to be more common (otherwise, why would the person who is going to push into the empty repo advertise it to you before they have put any content in it). But it will probably still be surprising not to have the branch merging setup: mkdir parent && (cd parent && git init) && git clone parent child && cd child && echo content >file && git add file && git commit -m one && git push origin master ;# note we have to explicitly mention the branch ... time passes ... git pull produces the "you haven't asked me which branch to merge" message. Which does make some sense, given how tracking configuration is set up. It's just that it's a little sad that cloning an empty repository and then later getting commits out of it (whether commits you put in or somebody else) does not behave the same as cloning a repository with commits. Which I thought was sort of the point, that this would work seamlessly. Otherwise, there is not much advantage over: mkdir parent && (cd parent && git init) && mkdir child && cd child && git init && echo content >file && git add file && git commit -m one && git push origin master ;# note we have to explicitly mention the branch With the empty clone, you get your "origin" remote set up, but in both cases you are missing the branch tracking. I don't know if there is a good solution, though. Perhaps it's best to just let what's there get released and see if people complain. -Peff -- 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
