Re: [PATCH/RFC/GSoC 0/2] add a add.patch config variable

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

 



Dominik Fischer <d.f.fischer@xxxxxx> writes:

> I strove to create an add.patch configuration option that did the same
> as always passing the parameter --patch to git-add. Junio C Hamano
> then made me aware that when set, this option would influence and
> possibly destroy other commands that internally use git-add. So I
> implemented the recursion counter, which is now the first of the two
> commits.

This does not solve the problem of scripting. People write scripts, and
write git commands in these scripts. "git add" is a very good candidate
to appear in scripts, indeed.

You can't break people's scripts without a very solid transition plan.
And most of the time, safe transition plans are also painful for
everyone (remember the push.default change? I'm happy it's done, but
that wasn't a lightweight change ...).

In this case, it's quite clear to me that any transition plan would be
far more painful than the possible benefits. Without breaking backward
compatibility, I can already set "alias.p = add --patch" and use "git p"
instead of "git add --patch". Even better: that's 2 less keystrokes.

A config variable to set an option by default is good when the user
wants to set it and forget about it. In this case, you clearly can't
"forget about it", as running "git add" and "git add -p" correspond to
really different use-cases.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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]