[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: git apologia

From: David Kastrup
Subject: Re: git apologia
Date: Mon, 17 Nov 2014 17:57:12 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: "Stephen J. Turnbull" <address@hidden>
>> Cc: address@hidden
>> Date: Mon, 17 Nov 2014 09:14:14 +0900
>>  > 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 @address@hidden" 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 @address@hidden".
>> Or by "merge-commits" do you mean the off-trunk commits?
> Yes, it turns out that's what they were, as Andreas pointed out.  I
> was fooled by the fact that they are shown by default (unlike what I'm
> used to with bzr), and they seem to have no visual cues in the default
> output format that they are off-trunk (like, e.g., the indentation
> used by "bzr log").

git log --graph

> I will probably convince myself to add --first-parent to my "git log"
> aliases, as Andreas suggested.  After all, that's what "bzr log" does
> by default.  Then HEAD~n will work as I expect.  (And don't get me
> started on the reader-unfriendly description of --first-parent on the
> git-log man page.)
> Or maybe I will start using "C-x v L" ;-)

No need for a smilie.  VC is supposed to provide unifying workflows, and
Git is supposed to be flexible enough for a variety of workflows.
Making use of preexisting work for matching Git to workflows you are
more comfortable with is pretty much what VC is about.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]