From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Obscure error/warning/information message from git pull Date: Sat, 15 Nov 2014 17:56:21 +0100 Message-ID: <87ioigmmh6.fsf@fencepost.gnu.org> References: <87389mkjwo.fsf@thinkpad-t440p.tsdh.org> <20141114141434.GM3565@embecosm.com> <20141114180521.GA3168@acm.acm> <20141114230235.GF3168@acm.acm> <87lhncoqrp.fsf@fencepost.gnu.org> <83389khn1g.fsf@gnu.org> <87h9y0omii.fsf@fencepost.gnu.org> <83vbmgg57x.fsf@gnu.org> <878ujcoj0k.fsf@fencepost.gnu.org> <20141115120506.GA3581@acm.acm> <87r3x4mszs.fsf@fencepost.gnu.org> <87a93s8niw.fsf@maru2.md5i.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1416070641 22484 80.91.229.3 (15 Nov 2014 16:57:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Nov 2014 16:57:21 +0000 (UTC) Cc: Alan Mackenzie , Eli Zaretskii , emacs-devel@gnu.org To: Michael Welsh Duggan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 15 17:57:13 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xpgeu-0002H8-Qz for ged-emacs-devel@m.gmane.org; Sat, 15 Nov 2014 17:57:12 +0100 Original-Received: from localhost ([::1]:41118 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xpgeu-0006tD-Hv for ged-emacs-devel@m.gmane.org; Sat, 15 Nov 2014 11:57:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41745) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xpgeh-0006sw-Vw for emacs-devel@gnu.org; Sat, 15 Nov 2014 11:57:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xpgeg-0004Qz-Ma for emacs-devel@gnu.org; Sat, 15 Nov 2014 11:56:59 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51540) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xpgeg-0004Qv-Ja for emacs-devel@gnu.org; Sat, 15 Nov 2014 11:56:58 -0500 Original-Received: from localhost ([127.0.0.1]:58711 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpgeI-0006h4-M9; Sat, 15 Nov 2014 11:56:50 -0500 Original-Received: by lola (Postfix, from userid 1000) id E2339E0B2B; Sat, 15 Nov 2014 17:56:21 +0100 (CET) In-Reply-To: <87a93s8niw.fsf@maru2.md5i.com> (Michael Welsh Duggan's message of "Sat, 15 Nov 2014 10:57:27 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:177206 Archived-At: Michael Welsh Duggan writes: > When you clone a repo without giving it any special arguments (i.e., > just the location of the remote repository and possible the name of > the directory you wish to clone into) you get a copy of the whole > remote repository; all branches, the whole DAG, and all blobs > referenced by the DAG. Looks like it. At some previous time, the default was to only clone the default branch I think. More often than not, that was a total nuisance. At any rate, the behavior can be changed by editing .git/config, in particular the [remote "origin"] section. > Each branch in your on-disk copy of the clone is called a "remote > branch", since it is a branch from a remote source. (That last > sentence is shaky, and perhaps incorrect, but bear with me.) Not more shaky and perhaps incorrect than the normal Git documentation. It's your local notion of the remote branches, also called "remote-tracking branches". > Now, you do not normally check-out these "remote branches", and by > check-out I mean specifically generate a working directory from them. Yes and no. Remote-tracking branches are _not_ actually branches one can check out. If you check out such a "branch", you actually just check out its current state as a "detached HEAD". Whatever you commit to such a detached HEAD will get _lost_ if you change branches without creating a local branch or a tag for those commits. The remote-tracking branch cannot be associated with your new commits (unless you _push_ them) since it keeps mirroring the remote (in the last known form). > Rather you work with a "local branch" which is usually "linked" to the > "remote branch". (The "link" is what the --track option to the branch > command handles, I believe.) When you initially clone a repo, you (by > default) get a "local branch" named "master" which is linked to > (tracks) the remote master branch. According to your terminology. I think it diverges more than necessary for the purpose of arriving at something sane and consistent from the Git terminology. > One of the fundamental confusing bits is that the word "local" in > local branch does not mean "on local disk". It is on local disk. But > so are the repositories copies of the "remote branches". When you do > a "git fetch --all", it will sync up the on-disk representation of the > "remote branches" with an actual remote repository. When you do a > "git merge" from a working directory (local branch), you merge the > differences from the linked (tracked) "remote branch" (on your local > disk!) into your local branch. "git pull" does both the fetch, > updating your on-disk representation of the "remote branch", Of _all_ remote branches. > and the merge (updating your "local branch"). > I apologize if any of this is incorrect, but I agree with Alan and Eli > that much of this is confusing. I'm not entirely certain I have a > correct understanding of this myself. As I stated already: in Git's documentation "remote-tracking" is not treated sanely, at least as far as I remember it. I haven't checked recently. -- David Kastrup