Re: Git user survey and `git pull`

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]