[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
- Re: git apologia, (continued)
- Re: git apologia, Eli Zaretskii, 2014/11/16
- Re: git apologia, Andreas Schwab, 2014/11/16
- Re: git apologia, Eli Zaretskii, 2014/11/16
- Re: git apologia, Andreas Schwab, 2014/11/16
- Re: git apologia, Eli Zaretskii, 2014/11/16
- Re: git apologia, Teemu Likonen, 2014/11/16
- Re: git apologia, Stephen J. Turnbull, 2014/11/16
- Re: git apologia, Eli Zaretskii, 2014/11/17
- Re: git apologia, Andreas Schwab, 2014/11/17
- Re: git apologia, Eli Zaretskii, 2014/11/17
- Re: git apologia,
David Kastrup <=
- Re: git apologia, Achim Gratz, 2014/11/17
- Re: git apologia, Yuri Khan, 2014/11/17
- Re: git apologia, Thien-Thi Nguyen, 2014/11/18
- Re: git apologia, John Yates, 2014/11/18
- Re: git apologia, Thien-Thi Nguyen, 2014/11/18
- Re: git apologia, Andreas Schwab, 2014/11/18
- Re: git apologia, Barry Warsaw, 2014/11/18
- Re: git pull fails with merge conflicts. How can this possibly happen?, Sergey Organov, 2014/11/17
- Re: git pull fails with merge conflicts. How can this possibly happen?, Eli Zaretskii, 2014/11/17
- Re: git pull fails with merge conflicts. How can this possibly happen?, David Kastrup, 2014/11/17