Re: Deprecating git diff ..; dealing with other ranges

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

 



On Tue, Mar 12, 2019 at 2:01 PM Ævar Arnfjörð Bjarmason
<avarab@xxxxxxxxx> wrote:
> On Tue, Mar 12 2019, Andreas Schwab wrote:
> > On Mär 12 2019, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> >
> >> I however think it may be worth making sure that our docs do not
> >> encourage "diff A..B" and teach "diff A B" when comparing two
> >> endpoints.  That can be done without changing anything in the code.
> >
> > The nice thing about "diff A..B" is that you can c&p the output from the
> > fetch run without the need to edit it.
>
> Not to shoot down this effort, just to add another similar thing I do
> regularly for ff-branches:
>
>  1. Copy/paste A..B fetch output
>  2. git log A..B
>  3. ^log^diff
>
> I.e. I just need to tell my terminal to re-run the same "log" command
> with "diff" instead of "log".
>
> Of course as covered in the linked thread it doesn't work for some
> (non-ff) cases, and I'll sometimes end up cursing it and swapping around
> ".." for "..." with log/diff.

Doesn't this somewhat imply that although you use diff A..B here for
convenience, that it's actually wrong since what you really want is
A...B?  Or said another way, the end goal of deprecating "diff "A..B"
then later reinstating "diff A..B" to mean the same thing as "diff
A...B" would actually be better even for your usecase?

Of course, switching to the removal period may just be too painful for
too many folks since there are obviously people that use it, but I
just want to see if I'm understanding correctly here.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux