Re: [PATCH 2/2] pull: improve default warning

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

 



Alex Henrie wrote:
> On Tue, Jun 22, 2021 at 8:20 PM Elijah Newren <newren@xxxxxxxxx> wrote:
> >
> > On Tue, Jun 22, 2021 at 2:22 PM Alex Henrie <alexhenrie24@xxxxxxxxx> wrote:
> > >
> > > While
> > > we're on the subject, do you have any thoughts on what (if anything)
> > > more should be done before making the switch to aborting instead of
> > > merging with a warning in `git pull`?
> >
> > I think Junio already answered that over here:
> > https://lore.kernel.org/git/xmqq360h8286.fsf@xxxxxxxxxxxxxxxxxxxxxx/
> > (he discussed it multiple times in that thread, but hopefully that's a
> > good enough example).
> 
> Wow, if I understand correctly from that message, Junio wouldn't mind
> making the switch right away. That's very encouraging.

Junio has not paid enough attention to this topic. He is not aware of
all the problems, and once he does he will very likely change his mind.

> On Wed, Jun 23, 2021 at 12:19 PM Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
> >
> > Similarly, until "git pull" does something sensible by default (which
> > isn't the case now), these debates will continue, and there's value in
> > them.
> 
> At this point, I'm inclined to push for s/advise/die/ in pull.c in the
> next release, without a transitional period, just to end the argument
> over how to best explain the current awkward situation. (I'm sure
> there will be more arguments after that, but hopefully they won't be
> as tiresome.)

Give it a try. You will inevitably stumble upon all the problems I
already fixed.

In the meantime what's the problem with v2?

Cheers.

[1] https://lore.kernel.org/git/20210623004815.1807-1-felipe.contreras@xxxxxxxxx/

-- 
Felipe Contreras



[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