From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alexis Newsgroups: gmane.emacs.devel Subject: Re: Obscure error/warning/information message from git pull Date: Thu, 20 Nov 2014 11:57:15 +1100 Message-ID: <87k32q3c9s.fsf@gmail.com> 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 X-Trace: ger.gmane.org 1416446019 13295 80.91.229.3 (20 Nov 2014 01:13:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Nov 2014 01:13:39 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 20 02:13:32 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 1XrGJQ-0004j1-79 for ged-emacs-devel@m.gmane.org; Thu, 20 Nov 2014 02:13:32 +0100 Original-Received: from localhost ([::1]:33132 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrGJP-0005UR-Ng for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 20:13:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39006) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrGJE-0005Rh-AL for emacs-devel@gnu.org; Wed, 19 Nov 2014 20:13:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrGJ5-0000yJ-9g for emacs-devel@gnu.org; Wed, 19 Nov 2014 20:13:20 -0500 Original-Received: from mail-pa0-x22f.google.com ([2607:f8b0:400e:c03::22f]:63801) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrGJ5-0000xz-2m for emacs-devel@gnu.org; Wed, 19 Nov 2014 20:13:11 -0500 Original-Received: by mail-pa0-f47.google.com with SMTP id kq14so1410691pab.6 for ; Wed, 19 Nov 2014 17:13:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:to:subject:date:in-reply-to:message-id:mime-version :content-type; bh=HWcjzClLdsBbX8hz5W7NYuveQSAoKdRuEF90jPrmc+U=; b=n3XjB2mloQN+3XjZWjta9i6zDOMbLlewxdidnXuftyfYLN05ixrXch350WGNru5Pwk 2N8HGpWgGkGYSCoFilYUL/aFPaKqfls82IdruGkVwZ+sQVwWjS08yocGfNCjuJa72bxG ych6HzCvYl7VAK9ZBn6uCzpHn+3aBba4HMcnq2r8TqWX1Gwejlbpp3VAGVZMVdYwL1Np pXO4fov8f8E0JN75n4h6Lpolo76CD+tf5pEtvecgQSuDR7SFYAO1yuGo50+PavMUZB7L 0ygYp+hjYaOBPw0FD1sRDg/HlPp0YCOxhBNmI9ZzycD5A5hpHRtWn33hCYwTHtsb/Lcy 9bXA== X-Received: by 10.70.138.104 with SMTP id qp8mr50407802pdb.99.1416445989700; Wed, 19 Nov 2014 17:13:09 -0800 (PST) Original-Received: from localhost (ppp118-209-40-19.lns20.mel4.internode.on.net. [118.209.40.19]) by mx.google.com with ESMTPSA id uy8sm399949pab.44.2014.11.19.17.13.07 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 19 Nov 2014 17:13:08 -0800 (PST) In-reply-to: <20141119135530.GA3986@acm.acm> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::22f 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:177837 Archived-At: Alan Mackenzie writes: > 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. It seems git simply discards > this information. Well, here's a scenario to consider, again using the example from upthread: - C - D <- foo / ... - A - B \ - E - F <- bar Let's say ... - A - B is an exploratory feature branch called 'experiment'. After commit B, the group working on this branch split into two camps as to how next to proceed. So they decided to create two branches, 'foo' and 'bar', off 'experiment', to apply the two camps' respective approaches and see what problems and solutions result. At this point, neither 'foo' nor 'bar' are /the/ 'official' continuation of 'experiment'. From a workflow perspective, they have equal authority - any linear ordering imposed by when the branches got created is irrelevant. Yes, at a later time, it might be decided that the 'bar' branch becomes the 'official' continuation of the 'experiment' branch, i.e. the structure would become: - C - D ... Z <- foo / ... - A - B - E - F ... <- bar But until that time, it makes no sense to speak of either the 'foo' branch or 'bar' branch as /the/ continuation of the 'experiment' branch. Alexis.