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

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

 



On Mon, 18 Mar 2019 10:07:08 -0700
Elijah Newren <newren@xxxxxxxxx> wrote:

> 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?

I usually mean diff A..B in this case.

Thanks

Michal



[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