From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sergey Organov Newsgroups: gmane.emacs.devel Subject: Re: A simple git workflow for the rest of us Date: Mon, 24 Nov 2014 18:25:56 +0300 Message-ID: References: <87sihkicso.fsf@Rainer.invalid> <87vbmfym7i.fsf@olgas.newt.com> <87mw7hzs8f.fsf@olgas.newt.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1416842832 730 80.91.229.3 (24 Nov 2014 15:27:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Nov 2014 15:27:12 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 24 16:27:05 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 1XsvXX-00043C-SP for ged-emacs-devel@m.gmane.org; Mon, 24 Nov 2014 16:27:00 +0100 Original-Received: from localhost ([::1]:53179 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsvXX-0006xC-EJ for ged-emacs-devel@m.gmane.org; Mon, 24 Nov 2014 10:26:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39040) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsvXB-0006wM-Rn for emacs-devel@gnu.org; Mon, 24 Nov 2014 10:26:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XsvWs-0002Qp-1T for emacs-devel@gnu.org; Mon, 24 Nov 2014 10:26:37 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:44810) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XsvWr-0002Qd-Jg for emacs-devel@gnu.org; Mon, 24 Nov 2014 10:26:17 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XsvWm-0003Kw-Nt for emacs-devel@gnu.org; Mon, 24 Nov 2014 16:26:12 +0100 Original-Received: from 89.175.180.246 ([89.175.180.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Nov 2014 16:26:12 +0100 Original-Received: from sorganov by 89.175.180.246 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Nov 2014 16:26:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 39 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89.175.180.246 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:178179 Archived-At: Bill Wohler writes: > Steinar Bang writes: > >>>>>>> Bill Wohler : >> >>> I'd second setting it globally to ensure that it happens universally >>> to avoid the spurious merge commits that otherwise ensue. >> >> (I've never understood why "spurious merge commits" bother people so >> much. Personally I'm much more concerned with what might happen to my >> individual commits if I'm hitting a conflict during rebase: the commit's >> diff may no longer be the clear and meaningful diff I indented it to be) > > Like many things, it depends. > > If a merge in either direction doesn't add any information, it's > spurious. If it's useful, it's not spurious. For me, a merge commit from > a pull breaks up the flow of my unpushed commits and usually doesn't add > anything. I can imagine that folks used to Subversion would prefer > pull --rebase as well as that mimics svn update. Sort of. > > If it's vital to capture that merge in the middle of your own commits, > then the pull should be merged. I've just never encountered this > situation. In the situation you presented, could you use git rebase > --abort and then run git merge origin/master to recover? > > In any event, there is no right or wrong answer. It all depends. AFAIK, one can pull with merge, then finally, before pushing, call "git rebase" by hand, and Git will get rid of all those intermediate merges while rebasing. This doesn't play nicely with intended local merges. The latter is unlikely to make any difference for simple workflows though. One probably needs to enable "rerere" to avoid repeating the same merge resolution. -- Sergey.