Jonathan Nieder [off-list ref] writes:
Thomas Rast wrote:
quoted
The problem with -b is that it's a backwards-compatibility shorthand for
--binary, which used to pass --allow-binary-replacement (or --binary) to
git-apply. However, that option was obsoleted in 2b6eef9 (Make apply
--binary a no-op., 2006-09-06) and has been a no-op for over 5 years.
It has also not been documented since cb3a160 (git-am: ignore --binary
option, 2008-08-09).
So perhaps we can safely claim -b for --keep-non-patch, like so:
We can delete "git am -b" (as it was deprecated long time ago), wait
for a cycle or two, and then repurpose it. I do not mind starting
the first step (delete, but do not say anything about repurposing)
before 1.7.10-rc1 happens.
On Mon, Mar 12, 2012 at 11:04:23AM -0700, Junio C Hamano wrote:
quoted
quoted
So perhaps we can safely claim -b for --keep-non-patch, like so:
We can delete "git am -b" (as it was deprecated long time ago), wait
for a cycle or two, and then repurpose it. I do not mind starting
the first step (delete, but do not say anything about repurposing)
before 1.7.10-rc1 happens.
From my user experience and what I see on a number of coworkers, users
tend to make big jumps when they need a new feature, so in practice,
not offering the option in a version or two would probably not affect
most users, especially the ones still relying on the old behaviour. So
I don't see much benefit in waiting for repurposing the option.
Just my 2 cents,
Willy
Willy Tarreau wrote:
From my user experience and what I see on a number of coworkers, users
tend to make big jumps when they need a new feature, so in practice,
not offering the option in a version or two would probably not affect
most users, especially the ones still relying on the old behaviour. So
I don't see much benefit in waiting for repurposing the option.
The benefit is that if it does turn out to be a regression, early
adopters will complain to us because their scripts have stopped
working and we get a chance to back out the change without having to
worry about others who have started to rely on the option.
Regards,
Jonathan
On Mon, Mar 12, 2012 at 01:54:40PM -0500, Jonathan Nieder wrote:
Willy Tarreau wrote:
quoted
From my user experience and what I see on a number of coworkers, users
tend to make big jumps when they need a new feature, so in practice,
not offering the option in a version or two would probably not affect
most users, especially the ones still relying on the old behaviour. So
I don't see much benefit in waiting for repurposing the option.
The benefit is that if it does turn out to be a regression, early
adopters will complain to us because their scripts have stopped
working and we get a chance to back out the change without having to
worry about others who have started to rely on the option.
Indeed you're right. I forgot the case of the old script relying
on the silently ignored parameter!
Regards,
Willy