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 15:30:31 +0100 Message-ID: <87vbmgmt88.fsf@fencepost.gnu.org> References: <20141114120604.GA3859@acm.acm> <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> <83ppcog1if.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1416062358 26657 80.91.229.3 (15 Nov 2014 14:39:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Nov 2014 14:39:18 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 15 15:39:11 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 1XpeVK-0006oI-D7 for ged-emacs-devel@m.gmane.org; Sat, 15 Nov 2014 15:39:10 +0100 Original-Received: from localhost ([::1]:40753 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpeVK-0001Va-0n for ged-emacs-devel@m.gmane.org; Sat, 15 Nov 2014 09:39:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpeUk-0000Tu-V0 for emacs-devel@gnu.org; Sat, 15 Nov 2014 09:38:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XpeUj-00036i-Ft for emacs-devel@gnu.org; Sat, 15 Nov 2014 09:38:34 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49096) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpeUj-00036a-CL for emacs-devel@gnu.org; Sat, 15 Nov 2014 09:38:33 -0500 Original-Received: from localhost ([127.0.0.1]:56271 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpeUi-0007jV-Ia; Sat, 15 Nov 2014 09:38:32 -0500 Original-Received: by lola (Postfix, from userid 1000) id B98DDE0B2B; Sat, 15 Nov 2014 15:30:31 +0100 (CET) In-Reply-To: <83ppcog1if.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 15 Nov 2014 13:13:28 +0200") 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:177183 Archived-At: Eli Zaretskii writes: >> From: David Kastrup >> Cc: emacs-devel@gnu.org >> Date: Sat, 15 Nov 2014 11:28:11 +0100 >> >> >> git cannot magically show anything that isn't in the repo. >> > >> > It is unclear to me, at my current level of knowledge, what exactly >> > "is in the repo". >> >> All the references you fetched/cloned and everything they point to. > > Thanks, but that explains nothing. Unless you take very special pains (like using a "shallow" repository), Git makes sure that it can follow _any_ SHA1/object/reference as far as it wants: it knows the tree for any commit known to it, it knows the parent commits to any commits known to it, it knows the blobs for any file in any tree known to it. When you do "git fetch", it updates the heads of its remote-mirroring branches to point to the new SHA1 hash code. Afterwards it makes sure that it, again, knows everything about any reachable object from this new state (the actual references are updated once this everything-can-be reached state has actually been accomplished: if you bomb out with SIGINT before, you'll get dangling objects, having some SHA1 and substance behind it, but nothing pointing to them. They will either disappear with some future git-gc, or get a reference on some future fetch and then stay around: there are no linkages other than the SHA1 for anything). So "git fetch" updates references and then completes the repository by fetching all objects that are referenced but not present. >> > For example, "git clone" is advertised as "clone a repository", but >> > that evidently only "fully" clones the master branch; other branches >> > won't even be updated by the following "git pull"s unless you say >> > "git checkout BRANCH" once (or give some other command that has the >> > same effect). Then what exactly is brought downstream by 'clone', and >> > why is it called "repository" rather than "branch"? >> >> The manual is clear about that. > > "Clear", right. > >> Clones a repository into a newly created directory, creates >> remote-tracking branches for each branch in the cloned repository >> (visible using git branch -r), and creates and checks out an initial >> branch that is forked from the cloned repository\u2019s currently active >> branch. >> >> After the clone, a plain git fetch without arguments will update all >> the remote-tracking branches, and a git pull without arguments will in >> addition merge the remote master branch into the current master branch, >> if any (this is untrue when "--single-branch" is given; see below). >> >> This default configuration is achieved by creating references to the >> remote branch heads under refs/remotes/origin and by initializing >> remote.origin.url and remote.origin.fetch configuration variables. > > Sorry, but that's a bunch of gobbledygook. What does "create > remote-tracking branches" mean, Fetching the references to their heads. > and how is it different from "creates the initial branch"? The initial branch is a local branch that is not a remote-tracking branch but rather tracks the corresponding remote branch (remember that "remote-tracking" is a magical phrase meaning "mirroring a remote branch" rather than "tracking a remote branch" for some unfathomable reason). > What does "update" in "update the remote-tracking branches" means, Making the references point to the same objects that the remote repository has and making sure that the referenced objects (and everything referenced by them) are fetched into your repository as well. > and how is it different from what is described after that for the > master branch? _Your_ master branch is a local branch. It cannot be fetched from the remote site. But the _remote_ master branch is fetched into its remote-tracking branch in your repository, and then your local master branch is merged with the remote-tracking branch of the corresponding remote master branch. >> > Furthermore, even if you have other branches tracked, "git pull" >> > evidently won't update them as it does with the current branch, since >> > switching to another branch after a pull will cheerfully tell you that >> > you are behind the branch tip and need another "git pull" to fix that. >> > Then what exactly does "branch tracking" mean, by default? >> >> It means that Git tracks the remote branches: it knows what's there and >> can show you even when offline (of course, it shows the state since the >> last fetch). > > Does that include updating their parts of the DAG? Yes. > Below you seem to say it doesn't; Then appearances would seem to deceive. >> git-pull merges (or rebases) _one_ local branch. The one that is >> checked out. But it updates all remote-tracking branches. > > "Updates" how? Does it update their part of the DAG? Yes. >> > These and other similar complexities stand in the way of my >> > understanding of what exactly do I have in my clone of the repository, >> > and what I don't have. >> >> git branch -a should tell you. > > It shows the list of the branches, where I know how to discern a > branch I call "tracking", i.e. the one for which I did a checkout at > some point, and those for which I didn't. What else should it tell > me? That tells you the branches that are available for viewing/merging/operating in your repository even when you are offline. git branch -a -v tells some more details. >> > It is all the more perplexing, since (AFAIU) the repo met-data is (or >> > includes) the history DAG, where (AFAIK) branches are all interwoven >> > in a single graph. So how come a 'pull' doesn't update the whole DAG, >> > and if it does, why do I need to do something in addition to have all >> > my branches updated? >> >> A pull updates those parts of the DAG that can be reached from the >> references you have in your "fetch" specification. > > What is my "fetch specification", and how did I specify that? Take a look in your .git/config file. You'll find a section [remote "origin"] containing, among other things, a fetch specification. For a typical repository containing all branches (whether that is the case depends on the fetch specification), the complete DAG is available. git pull updates _all_ fetched remote-tracking branches. But it only merges the currently checked-out _local_ branch with the remote-tracking branch for the corresponding remote branch. Strictly speaking, the local branch is tracking the remote-tracking branch, and the remote-tracking branch is not actually "tracking" the remote in the sense that "tracking" is used for local branches, but mirroring it. As I said: "remote-tracking" is a magical buzzword to be replaced by "remote-mirroring" or whatever. "tracking" in the "proper" sense is a connection to a branch that is happening in your local repository, either tracking another local branch, or tracking a remote-tracking branch. As I said: replace the exact letter-combination "remote-tracking" with "remote-mirroring" everywhere, and you have one less muddled piece of terminology to worry about. I think that particular bit may well be about the most enfuriatingly confuddled bit of terminology in general Git operations. -- David Kastrup