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: git apologia Date: Mon, 17 Nov 2014 09:14:14 +0900 Message-ID: <87k32uvg2x.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20141114183737.GB3168@acm.acm> <5466517B.50705@porkrind.org> <20141114215404.GD3168@acm.acm> <838ujchods.fsf@gnu.org> <8761egx1k2.fsf@uwakimon.sk.tsukuba.ac.jp> <83sihkg2ds.fsf@gnu.org> <87vbmgv3b9.fsf@uwakimon.sk.tsukuba.ac.jp> <83389jdtae.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1416183309 19869 80.91.229.3 (17 Nov 2014 00:15:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Nov 2014 00:15:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 17 01:15:02 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 1Xq9y9-00083G-Lp for ged-emacs-devel@m.gmane.org; Mon, 17 Nov 2014 01:15:01 +0100 Original-Received: from localhost ([::1]:45508 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xq9y6-0006jb-Rr for ged-emacs-devel@m.gmane.org; Sun, 16 Nov 2014 19:14:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58806) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xq9xn-0006Wy-0D for emacs-devel@gnu.org; Sun, 16 Nov 2014 19:14:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xq9xf-0002ww-HI for emacs-devel@gnu.org; Sun, 16 Nov 2014 19:14:38 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:39961) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xq9xX-0002uM-FI; Sun, 16 Nov 2014 19:14:23 -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 DFD021C39C2; Mon, 17 Nov 2014 09:14:14 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C76F61A2844; Mon, 17 Nov 2014 09:14:14 +0900 (JST) In-Reply-To: <83389jdtae.fsf@gnu.org> 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:177371 Archived-At: Eli Zaretskii writes: > Actually, it turns out neither this nor HEAD~n is what I want. What I > want is to display information about commits N..M where N and M are > ordinal numbers from the linear "git log" output. I'm not sure how you would go about doing that in git. The ~ notation follows first parents, as "bzr log -n1" would. Your use of --skip seems to be the best way to accomplish what you want.q > And waddaya know? HEAD~n etc. seem to _skip_ merge-commits, It only seems to do so. In my (not quite up-to-date) emacs repo, "git log @~10..@~1" displays no merges, but apparently that's because there's a long sequence of non-merges (fast-forwards) on mainline. However, "git log @~10..@" displays several, as does "git log @10..@^2~1". Or by "merge-commits" do you mean the off-trunk commits? > so (a) the counts end up being wrong, and (b) if you want to see > those merge-commits, you need to _know_ they are merge-commits and > then use HEAD^2 etc. (i.e. explicitly request the 2nd parent). > This is awful. If you say so, I guess it is for you. I'm curious why it's useful to you. In the situation I imagine, I typically fire up another terminal and do "git log | less" rather than try to guess at appropriate n and m. Or use gitk. Is it just that those aren't quite as efficient for you, or do you have a different purpose for -n..-m?