git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Jan 29, 2009, 11:37 UTC
Message-ID
<20090129113735.GA6505@coredump.intra.peff.net>
In-Reply-To
<bd6139dc0901290327u572cc30ci9dc719c912fbf875@mail.gmail.com>
On Thu, Jan 29, 2009 at 12:27:23PM +0100, Sverre Rabbelier wrote:
Show 8 quoted lines
> 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
Previous: Sverre RabbelierNext: Pieter de Bie
Message 7 of 30 in “What's cooking in git.git (Jan 2009, #07; Wed, 28)”
  1. Junio C HamanoJan 29, 2009
  2. Jeff KingJan 29, 2009
  3. Jeff KingJan 29, 2009
  4. Jeff KingJan 29, 2009
  5. Junio C HamanoJan 29, 2009
  6. Sverre RabbelierJan 29, 2009
  7. Jeff KingJan 29, 2009
  8. Pieter de BieJan 29, 2009
  9. Sverre RabbelierJan 29, 2009
  10. Jeff KingJan 29, 2009
  11. Sverre RabbelierJan 29, 2009
  12. Jeff KingJan 30, 2009
  13. Johannes SchindelinJan 30, 2009
  14. Jeff KingJan 30, 2009
  15. Junio C HamanoFeb 1, 2009
  16. Junio C HamanoFeb 12, 2009
  17. Sverre RabbelierFeb 12, 2009
  18. Johannes SchindelinFeb 12, 2009
  19. Junio C HamanoFeb 12, 2009
  20. Johannes SchindelinFeb 12, 2009
  21. Jeff KingFeb 12, 2009
  22. Jeff KingJan 29, 2009
  23. Nico -telmich- SchotteliusJan 29, 2009
  24. Jeff KingJan 30, 2009
  25. Charles BaileyJan 29, 2009
  26. Junio C HamanoJan 29, 2009
  27. Charles BaileyJan 29, 2009
  28. Charles BaileyJan 30, 2009
  29. Kirill SmelkovFeb 1, 2009
  30. Junio C HamanoFeb 1, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.