Re: [PATCH v3] build: add default aliases

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

 



On Tue, Sep 24, 2013 at 6:06 AM, John Szakmeister <john@xxxxxxxxxxxxxxx> wrote:
> On Tue, Sep 24, 2013 at 6:25 AM, Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
>> On Tue, Sep 24, 2013 at 4:19 AM, John Szakmeister <john@xxxxxxxxxxxxxxx> wrote:
>>> On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras
>>> <felipe.contreras@xxxxxxxxx> wrote:
>>>> For now simply add a few common aliases.
>>>>
>>>>   co = checkout
>>>>   ci = commit
>>>>   rb = rebase
>>>>   st = status
>>>>
>>>> Signed-off-by: Felipe Contreras <felipe.contreras@xxxxxxxxx>
>>>> ---
>>>>
>>>> I still think we should ship a default /etc/gitconfig, but the project needs to
>>>> agree it's a good change, and nobody every agrees changes are good. So this is
>>>> the minimal change that achieves the desired result.
>>>
>>> I wish you would stop attacking the project every time you send a
>>> patch--it's simply not productive and it's certainly not getting you
>>> any closer to a resolution.
>>
>> I'm not attacking the project, I'm making an objective claim, and I
>> can back it up with several instances of evidence where 99% of the
>> users would benefit from a change, yet it does not move forward.
>
> There's nothing objective about "Nobody every (sic) agrees changes are
> good".  If it were true, no changes would get in.

It is true, where by "changes" I mean "changes from common user's
point of view", actually, a tiny amount of then do sneak in, so let me
be precise: "Virtually nobody ever agrees important changes from the
common user's point of view are good".

So now that I'm being clear, do tell, name one important change in Git
from the user's point of view that happened in the last two years.

> Also, you don't know that any of those changes would benefit "99% of
> all users".  It's a guess or an estimate but it's not based on
> anything concrete.  It might be a good guess--and in this case, I
> think it is--but it's not a concrete fact.  Don't make it sound like
> it is.

Sure, it's not a concrete fact, but the actual probability most likely
follows a beta distribution with alpha=15 and beta=1. Is that more
precise for you?

>> If you don't agree my comment is accurate, that's one thing, but
>> labeling it as an attack is another.
>
> Don't turn it around.  A number of your patches and emails poke at the
> community of the Git project and you know it.  It's simply not helping
> the situation.

Show me a patch that "pokes" at the community. All my patches have
technical descriptions, and help improve Git.

> Your clearly a bright and motivated individual--which makes it all the
> more frustrating that you don't approach this differently.  I even
> agree with your motivations for Git: I'd like to see less shell and
> perl involved and to see Git run faster on Windows.  But I wish you'd
> stop with the jabs.

Don't worry, I'll stop the "jabs" (which are really objective
observations which are not particularly flattering for the project,
but true, and serious problems that need to be fixed) as soon when I
leave the project, which I'll do once it's clear my patches are going
nowhere without any valid justification, and we are right on track for
that.

>> I would admit I was wrong if an /etc/gitconfig is indeed shipped by
>> default, and agree that the Git project is indeed welcome to change,
>> but that's not going to happen.
>
> And there it is again.  Predicting the future now?  Objectively and
> accurately?  Please stop.

Yes I am. Feel free to go back to this mail and tell me I was wrong
when they do what I said they won't.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[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]