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

Re: Git user survey and `git pull`

From
Linus Torvalds <torvalds@osdl.org>
Date
Sep 21, 2006, 17:38 UTC
Message-ID
<Pine.LNX.4.64.0609211027440.4388@g5.osdl.org>
In-Reply-To
<20060921164048.GY8259@pasky.or.cz>
On Thu, 21 Sep 2006, Petr Baudis wrote:
> 
> This is artifact of the BitKeeper terminology. This is the meaning in
> most other VCSes but in BitKeeper, pull meant "get changes and merge
> them", not just "get changes". So the BitKeeper legacy lives on. :-)
Indeed. "pull/push" are the operations bk has.

BK doesn't have branches, and cannot do a "fetch", so there's no confusion in BK - the pulls and the pushes are not mirror-images, but since there are no other operations you'd normally use, you can pretty much ignore it.

(That's not entirely true. In BK, you can do "bk receive" and "bk resolve" to "fetch" and "merge" another branch, but quite frankly, I personally found them so confusing that I never used them at all).

I agree that the clarifications from Shawn are probably improvements, but I'd actually like to solve the problem a bit differently. Namely, I was hoping that the per-branch configuration would solve the confusion.

Right now, a plain "git pull" means "fetch all branches and merge the first one", and the thing is, that's generally the right thing _only_ if you pull into "master".

It's usually exactly the _wrong_ thing to do for any other branch. In particular, if you work with a project that has lots of branches, and you're working in another branch (that is directly tracking a remote, for example), doing a "git pull" definitely should _not_ merge the first head. It should fetch everything, and possibly merge the _matching_ head.

Which it doesn't do right now.

So I think the problem with "git pull" is not that it's a "fetch and merge", it's that it merges the wrong head. It always merges the first remote one (aka the remote "HEAD"), regardless of which head we happen to be at right now.

So I was kind of hoping that the per-branch configuration stuff (that petered out after the .git/config file format was worked out) would solve the problem.

That said, maybe Shawn's suggestion is better. And maybe the fact that we'd change the semantics mid-stream would make things even WORSE. I dunno.

		Linus
Previous: Petr BaudisNext: Nicolas Pitre
Message 3 of 16 in “Git user survey and `git pull`”
  1. Shawn PearceSep 21, 2006
  2. Petr BaudisSep 21, 2006
  3. Linus TorvaldsSep 21, 2006
  4. Nicolas PitreSep 21, 2006
  5. Junio C HamanoSep 22, 2006
  6. SantiSep 22, 2006
  7. Junio C HamanoSep 22, 2006
  8. SantiSep 22, 2006
  9. Nicolas PitreSep 21, 2006
  10. Shawn PearceSep 21, 2006
  11. Johannes SchindelinSep 21, 2006
  12. Jakub NarebskiSep 21, 2006
  13. Matthias UrlichsSep 22, 2006
  14. Alan ChandlerSep 23, 2006
  15. Johannes SchindelinSep 23, 2006
  16. Jakub NarebskiSep 23, 2006

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.