From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Obscure error/warning/information message from git pull Date: Sat, 15 Nov 2014 13:13:28 +0200 Message-ID: <83ppcog1if.fsf@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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1416050062 7547 80.91.229.3 (15 Nov 2014 11:14:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Nov 2014 11:14:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 15 12:14: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 1XpbIw-00020X-RF for ged-emacs-devel@m.gmane.org; Sat, 15 Nov 2014 12:14:10 +0100 Original-Received: from localhost ([::1]:39845 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpbIw-0007kP-9w for ged-emacs-devel@m.gmane.org; Sat, 15 Nov 2014 06:14:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40039) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpbIo-0007jd-JV for emacs-devel@gnu.org; Sat, 15 Nov 2014 06:14:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XpbId-0004BI-QZ for emacs-devel@gnu.org; Sat, 15 Nov 2014 06:13:58 -0500 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:33912) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpbIX-00048i-5Y; Sat, 15 Nov 2014 06:13:45 -0500 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NF200900UJVHC00@mtaout29.012.net.il>; Sat, 15 Nov 2014 13:11:58 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NF2005QYV3YFQ50@mtaout29.012.net.il>; Sat, 15 Nov 2014 13:11:58 +0200 (IST) In-reply-to: <878ujcoj0k.fsf@fencepost.gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.185 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:177163 Archived-At: > 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. > > 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, and how is it different from "creates the initial branch"? What does "update" in "update the remote-tracking branches" means, and how is it different from what is described after that for the master branch? Sorry, but this old curmudgeon cannot grok that; I'd very much prefer your own words. > > 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? Below you seem to say it doesn't; but in that case, how would Git "know what's there" and show that to me while offline? > 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? Does it do something else? > > 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? > > 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? Thanks for taking time to explain this.