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: git commit/push and VC Date: Fri, 21 Nov 2014 11:12:32 +0200 Message-ID: <83lhn4533z.fsf@gnu.org> References: <871toysqyq.fsf@rosalinde.fritz.box> <838uj57u5b.fsf@gnu.org> <87ppchd9dk.fsf@Gertrud.fritz.box> <83fvdd612c.fsf@gnu.org> <877fypj5vg.fsf@zigzag.favinet> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1416561178 4011 80.91.229.3 (21 Nov 2014 09:12:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Nov 2014 09:12:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 21 10:12:50 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 1XrkGo-00071O-Cv for ged-emacs-devel@m.gmane.org; Fri, 21 Nov 2014 10:12:50 +0100 Original-Received: from localhost ([::1]:39318 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrkGn-0001AY-U8 for ged-emacs-devel@m.gmane.org; Fri, 21 Nov 2014 04:12:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40941) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrkGf-0001AO-Dq for emacs-devel@gnu.org; Fri, 21 Nov 2014 04:12:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrkGZ-0006nG-FR for emacs-devel@gnu.org; Fri, 21 Nov 2014 04:12:41 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:51063) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrkGZ-0006k7-7c for emacs-devel@gnu.org; Fri, 21 Nov 2014 04:12:35 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NFD00J00TJV4600@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Fri, 21 Nov 2014 11:12:33 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NFD00ITBTKXKF80@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Fri, 21 Nov 2014 11:12:33 +0200 (IST) In-reply-to: <877fypj5vg.fsf@zigzag.favinet> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:177924 Archived-At: > From: Thien-Thi Nguyen > Date: Fri, 21 Nov 2014 09:49:07 +0100 > > Switching the branch is easy, but after that, you'd almost > always need a full bootstrap, which might become annoying. > > The pain point seems to be bootstrap, so might as well > address it directly in the instructions: "If hacking TOPIC > will require bootstrap, then probably you want a separate > working tree on branch TOPIC. The main point here is not hacking TOPIC, it's working in parallel in master and in release branch. Those diverge very fast in Emacs, so switching almost always will require a full bootstrap. Most, if not all, of the other use cases can use a single clone. > We are talking about simplified instructions here, mind > you. Don't take that as a general advice for advanced > users: they don't need these instructions. > > I think it's okay to have a small conditional branch (argh, > another overloaded use of that word!) in these instructions. > Being explicit about intent puts the onus of choice on the > reader, which is where it belongs when it comes to managing > pain. If you mean that the instructions should explain the considerations for and against using "commit -a", then I don't think that's the place for that. The text might say "we recommend using 'commit -a' because it avoids the need to use 'git add', except when you add new files", but that's about all. The Wiki is not the place for describing these choices in too much detail, or we will lose the reader's attention. That page is already too long, IMO; I moved some of the stuff to the end of it so it doesn't interfere with the workflow description.