Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)

[Jeff King <peff@peff.net>]

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