From: Thien-Thi Nguyen <ttn@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: git apologia
Date: Tue, 18 Nov 2014 09:58:25 +0100 [thread overview]
Message-ID: <87a93onavi.fsf@zigzag.favinet> (raw)
In-Reply-To: <83ioidbwz5.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 17 Nov 2014 18:41:50 +0200")
[-- Attachment #1.1: Type: text/plain, Size: 334 bytes --]
() Eli Zaretskii <eliz@gnu.org>
() Mon, 17 Nov 2014 18:41:50 +0200
What's more natural than asking for
the Nth previous commit?
Personally, i use ‘git-show-branch’ and ‘more-vc-git-show’
(sample output and definitions attached) and additionally
bind ‘C-c C-s’ to the latter in compilation mode buffers.
[-- Attachment #1.2: buffer w/ ‘git-show-branch’ output --]
[-- Type: text/plain, Size: 700 bytes --]
Directory: ~/build/GNU/guile-sdl/
! [ack] Release: 0.5.1
! [p] Fix typo: Spell "compatib..." correctly!
! [q] Fix typo: Spell "compatib..." correctly!
* [q-fix-k2c] also pass ‘DEFS’ and ‘SDL_CFLAGS’ to k2c, via new var ‘cppopts’
! [z-gfx-font] Add ‘set-font!’ and ‘builtin-font’.
-----
* [q-fix-k2c] also pass ‘DEFS’ and ‘SDL_CFLAGS’ to k2c, via new var ‘cppopts’
* [q-fix-k2c^] make k2c handle command-line ‘-- CFLAGS’
* [q-fix-k2c~2] bootstrap w/ Guile-BAUX module ‘minus-i-dirs’
++* [p] Fix typo: Spell "compatib..." correctly!
+ [z-gfx-font] Add ‘set-font!’ and ‘builtin-font’.
+++*+ [ack] Release: 0.5.1
[-- Attachment #1.3: git-show-branch.el --]
[-- Type: application/emacs-lisp, Size: 5004 bytes --]
[-- Attachment #1.4: more-vc.el --]
[-- Type: application/emacs-lisp, Size: 10740 bytes --]
[-- Attachment #1.5: Type: text/plain, Size: 1033 bytes --]
This way i don't need to count anything and stuff before
the earliest branch (in the example, ‘ack’) is never shown
to begin w/; instead, i move point to a ref (e.g., branch
name in square braces, or SHA1) and type ‘C-c C-s’.
That's most natural to me. The compilation mode support
is to be able to likewise type ‘C-s C-s’ in *compilation*
on arbitrary shell command output (e.g., "git stash list"
or "git log --oneline -42").
The crux is func ‘more-vc-ref-at-point’, which could stand
to be improved, surely...
Anyway, i find "git log" to be only marginally useful (see
my previous grumblings re ChangeLog grepping) but that
will probably change, seeing where things are headed.
Nonetheless, i don't think manually counting commits will
ever be part of my workflow.
--
Thien-Thi Nguyen
GPG key: 4C807502
(if you're human and you know it)
read my lisp: (responsep (questions 'technical)
(not (via 'mailing-list)))
=> nil
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2014-11-18 8:58 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-14 18:37 git pull fails with merge conflicts. How can this possibly happen? Alan Mackenzie
2014-11-14 19:01 ` David Caldwell
2014-11-14 21:54 ` Alan Mackenzie
2014-11-15 5:41 ` Yuri Khan
2014-11-15 8:14 ` Eli Zaretskii
2014-11-15 9:20 ` Stephen J. Turnbull
2014-11-15 10:54 ` Eli Zaretskii
2014-11-15 11:15 ` David Engster
2014-11-15 11:19 ` David Kastrup
2014-11-15 11:30 ` Eli Zaretskii
2014-11-15 14:38 ` David Kastrup
2014-11-15 16:21 ` Eli Zaretskii
2014-11-15 16:31 ` Stephen J. Turnbull
2014-11-15 16:55 ` Eli Zaretskii
2014-11-15 17:05 ` David Kastrup
2014-11-15 17:03 ` David Kastrup
2014-11-15 18:25 ` Stephen J. Turnbull
2014-11-15 16:25 ` git apologia [was: git pull fails with merge conflicts. ...] Stephen J. Turnbull
2014-11-15 16:51 ` Eli Zaretskii
2014-11-15 18:16 ` Stephen J. Turnbull
2014-11-15 18:41 ` David Kastrup
2014-11-15 19:13 ` Git's victory and an entertaining irony Eric S. Raymond
2014-11-16 0:04 ` Stephen J. Turnbull
2014-11-16 6:00 ` Eric S. Raymond
2014-11-15 18:26 ` git apologia [was: git pull fails with merge conflicts. ...] Andreas Schwab
2014-11-15 18:37 ` Eli Zaretskii
2014-11-15 18:47 ` David Kastrup
2014-11-16 16:06 ` git apologia Eli Zaretskii
2014-11-16 16:36 ` Andreas Schwab
2014-11-16 18:04 ` Eli Zaretskii
2014-11-16 18:20 ` Andreas Schwab
2014-11-16 18:38 ` Eli Zaretskii
2014-11-16 18:50 ` Andreas Schwab
2014-11-16 18:58 ` Eli Zaretskii
2014-11-16 18:55 ` Teemu Likonen
2014-11-17 0:14 ` Stephen J. Turnbull
2014-11-17 16:41 ` Eli Zaretskii
2014-11-17 16:50 ` Andreas Schwab
2014-11-17 17:47 ` Eli Zaretskii
2014-11-17 16:57 ` David Kastrup
2014-11-17 18:55 ` Achim Gratz
2014-11-18 1:16 ` Yuri Khan
2014-11-18 8:58 ` Thien-Thi Nguyen [this message]
2014-11-18 13:53 ` John Yates
2014-11-18 19:45 ` Thien-Thi Nguyen
2014-11-18 9:39 ` Andreas Schwab
2014-11-18 16:42 ` Barry Warsaw
2014-11-17 12:38 ` git pull fails with merge conflicts. How can this possibly happen? Sergey Organov
2014-11-17 16:05 ` Eli Zaretskii
2014-11-17 16:54 ` David Kastrup
2014-11-17 21:09 ` Sergey Organov
2014-11-18 3:29 ` Glenn Morris
2014-11-18 22:57 ` Alan Mackenzie
2014-11-15 10:56 ` David Kastrup
2014-11-15 13:43 ` Stephen J. Turnbull
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a93onavi.fsf@zigzag.favinet \
--to=ttn@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).