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 11:28:11 +0100 Message-ID: <878ujcoj0k.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1416047305 431 80.91.229.3 (15 Nov 2014 10:28:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Nov 2014 10:28:25 +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 11:28:19 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 1XpaaY-0000tr-LS for ged-emacs-devel@m.gmane.org; Sat, 15 Nov 2014 11:28:18 +0100 Original-Received: from localhost ([::1]:39784 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpaaY-0001Ju-5g for ged-emacs-devel@m.gmane.org; Sat, 15 Nov 2014 05:28:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59233) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpaaU-0001Je-Dk for emacs-devel@gnu.org; Sat, 15 Nov 2014 05:28:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XpaaS-0008T0-TD for emacs-devel@gnu.org; Sat, 15 Nov 2014 05:28:14 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45298) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpaaS-0008Sv-QF for emacs-devel@gnu.org; Sat, 15 Nov 2014 05:28:12 -0500 Original-Received: from localhost ([127.0.0.1]:52474 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpaaS-0006zA-4I; Sat, 15 Nov 2014 05:28:12 -0500 Original-Received: by lola (Postfix, from userid 1000) id AC39DE0B2B; Sat, 15 Nov 2014 11:28:11 +0100 (CET) In-Reply-To: <83vbmgg57x.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 15 Nov 2014 11:53:22 +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:177160 Archived-At: Eli Zaretskii writes: >> From: David Kastrup >> Cc: emacs-devel@gnu.org >> Date: Sat, 15 Nov 2014 10:12:37 +0100 >> >> >> git log --all --source >> > >> > This has the disadvantage of showing the branches in the obscure >> > refs/foo/bar/branch format. Its advantage (AFAIK) is that it will >> > also show commits on remote branches that are not (yet) tracked by the >> > repo (please correct me if I'm wrong). >> >> 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. > I didn't see that explained in detail anywhere. > > 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. 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. git-clone does not create more _local_ branches than the one it creates and checks out from the currently active branch of the remote repository. > 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). Updating a _local_ branch requires merging the state of the local branch with the state of the remote-tracking branch. Git only performs merges in a checked out working directory (if you want to pick nits: merges are performed in the index, but the index is kept reasonably close to a working directory and/or a particular checkout). So fetching will not update any local branch but only the remote-tracking branches. Fetching never merges: if the history of a remote-tracking branch has diverged from that of the remote repository, the old information will just get thrown away and replaced from the up-to-date version in the remote repository. Git does not throw away information from a _local_ branch without explicit instructions and/or warning, however. git-pull merges (or rebases) _one_ local branch. The one that is checked out. But it updates all remote-tracking branches. > 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 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. >> You are probably thinking of git showing remote-tracking branches >> (those are always destructively updated from the remote reference >> when fetching) as well as local branches (which may or may not have a >> remote upstream). > > I was talking about local branches that track remote ones. I'd call that "that have a remote upstream". Because technically those local branches track the remote-tracking branch. > (And "remote-tracking", btw, is a term that should have not been > there, because it unnecessarily muddies the water. I suggest to > refrain from using it.) Then you need to devise alternative terminology and submit it to the Git documentation. You have my blessings for that since that bit of terminology is really fundamentally messed up. I tend to use "tracking" _only_ in the context of remote-tracking, and otherwise refer to "upstream branch". But indeed, if you take a look at the option naming and description of "git-branch", you get -t, --track When creating a new branch, set up branch..remote and branch..merge configuration entries to mark the start-point branch as "upstream" from the new branch. This configuration will tell git to show the relationship between the two branches in git status and git branch -v. Furthermore, it directs git pull without arguments to pull from the upstream when the new branch is checked out. This behavior is the default when the start point is a remote-tracking branch. Set the branch.autosetupmerge configuration variable to false if you want git checkout and git branch to always behave as if --no-track were given. Set it to always if you want this behavior when the start-point is either a local or remote-tracking branch. --no-track Do not set up "upstream" configuration, even if the branch.autosetupmerge configuration variable is true. --set-upstream If specified branch does not exist yet or if --force has been given, acts exactly like --track. Otherwise sets up configuration like --track would when creating the branch, except that where branch points to is not changed. -u , --set-upstream-to= Set up 's tracking information so is considered 's upstream branch. If no is specified, then it defaults to the current branch. --unset-upstream Remove the upstream information for . If no branch is specified it defaults to the current branch. which means that "remote-tracking" and "tracking a remote branch" are actually describing different things. Good luck figuring that out if you are new to Git. Maybe a global replace of "remote-tracking" with "remote mirroring" and subsequent proofreading to check that one did not have too many false positives or negatives would sort out the bulk of this particular mess. It's been pretty much around from the early beginnings so it's likely a blind spot for people accustomed to Git. But if you want the terminology to change, you cannot change it just for Emacs developers. You need to do it upstream. -- David Kastrup