From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Obscure error/warning/information message from git pull Date: Thu, 20 Nov 2014 01:42:54 +0900 Message-ID: <87oas3ta41.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20141114230235.GF3168@acm.acm> <20141117141123.GA4294@acm.acm> <83lhn89zxn.fsf@gnu.org> <83bno49xtw.fsf@gnu.org> <20141118224326.GA5167@acm.acm> <87mw7n8k0f.fsf@Rainer.invalid> <20141119135530.GA3986@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1416415407 19287 80.91.229.3 (19 Nov 2014 16:43:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Nov 2014 16:43:27 +0000 (UTC) Cc: Achim Gratz , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 19 17:43:22 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 1Xr8Lg-0001Ip-Sk for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 17:43:21 +0100 Original-Received: from localhost ([::1]:59479 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr8Lg-00083N-Hp for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 11:43:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45313) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr8LX-0007zi-1G for emacs-devel@gnu.org; Wed, 19 Nov 2014 11:43:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xr8LP-0007fA-6Z for emacs-devel@gnu.org; Wed, 19 Nov 2014 11:43:10 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:45594) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr8LO-0007cu-TA for emacs-devel@gnu.org; Wed, 19 Nov 2014 11:43:03 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 5AE921C3B19; Thu, 20 Nov 2014 01:42:54 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 35BD61A2844; Thu, 20 Nov 2014 01:42:54 +0900 (JST) In-Reply-To: <20141119135530.GA3986@acm.acm> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:177779 Archived-At: Alan Mackenzie writes: > > >> - C - D <- foo > > >> / > > >> ... - A - B > > >> \ > > >> - E - F <- bar > OK, commit A might have been made on some other branch not in the > diagram. But commit A was made before commit B (that is what these > lines _mean_) Yes. > and commit B was made before branch bar was created (and possibly > before branch foo if that was branched of of B also, rather than > being the continuation of the branch A was made on). You can't tell that from the diagram though. While the DAG gives you information about the (partial) order of commits, it tells you nothing about what branches existed at any given point of time except NOW, or where the commits were actually created. For example, starting on trunk, you can bzr commit -m A # all commits are preceded by hacking cd .. bzr branch trunk foo bzr branch foo bar cd trunk bzr commit -m B # trunk and foo have diverged cd ../bar bzr pull ../trunk # bar and foo have diverged # at this point we must have 3 branches # since bar did not branch from trunk bzr commit -m E bzr commit -m F cd ../foo bzr pull ../trunk # trunk and foo have reconverged bzr commit -m C # trunk and foo have diverged bzr commit -m D I have no idea how you propose to interpret that consistently with your claims about knowing where and when a branch was created, or what commits are on which branch, apart from reachability. > The very essence of a branch is its creation on the trunk (or other > branch) and divergence from it. Its point of creation is essential > - without it, it isn't a branch at all. Uh, if it's not a branch, what in the world is it? > It seems git simply discards this information. Yes. AFAICS it's not terribly useful. I used to use a tag in CVS, and that could be done in git, too: # echo 'git tag $1-bp-`date +%Y%m%d%H%M%S` > /usr/local/bin/git-makenode # echo 'git branch $1 $2' >> /usr/local/bin/git-makenode # chmod 0755 /usr/local/bin/git-makenode but I find git's ".." notation gives me everything I want. > That is where git's abstraction is broken. A is reachable from branch > bar, yet isn't on it and never has been - it's on the trunk, (or maybe > branch foo). Actually, I think *your* abstraction is incompatible with all DVCSes. All support a mode of operation where repo == branch == workspace. Now, suppose I have a branch foo, and from its parent directory I do "$VCS clone foo bar". Nobody (with the possible exception of you) would say that bar is an empty branch, and that directory bar contains branch foo. > The practical outcome is that git doesn't keep track of your branches. > You've got to remember your branching structure (or write it on a piece > of paper) if you ever want, say, to get a list of changes made on branch > bar. Most of the time this is trivial. "git log master..bar". But I don't understand why you care *where* the changes were made. I always am looking for a set of commits that represent the changes by which two revisions or branches differ; I don't care that C is a branch of B which branched from A, I just care about A and C (and want to know what happened on B as well as C since "our" branches forked from A). > I think that is what the "..." in "master...bar" is all about. You want ".." here. "..." gives the changes on *both* branches since the fork. Note that a VCS that knows about branches is no help if you want "bar..master" or "bar...master": master goes all the way back to root! Whose abstraction is broken here?