bug#17087: cp -i/yes gets ignored

[Pádraig Brady]

On 03/26/2014 03:29 PM, Paul Eggert wrote:
> Pádraig Brady wrote:
>> In general we should allow these patches a little
>> while for review before pushing.
> 
> Perhaps I was a bit enthusiastic here, but still, I don't know, when in doubt 
> I prefer an Emacs-like approach (push early and often and fix as soon as you 
> can) to a glibc-like approach (everything needs review and lots of problems 
> just don't get fixed).

I'm not suggesting everything _needs_ review.
I'm just suggesting we might take advantage of review.
I.E. we're posting the patches to the list anyway,
so just hold off on the submission until a review happens
or a few hours pass.  git branching makes this trivial to manage,
and so there should be no extra process.

Ideally more than one person should be looking at the code anyway,
and if that happens in a timely enough fashion to be in the
commit feedback loop that's even better.

> the maintenance procedures of coreutils are enough of a pain

Are you referring to GNU coding style,
commit message summary format or something else?
Is there anything we could make more lightweight here?

> and the code is enough of a tangle, that nobody is following up on Karl's 
> eminently reasonable suggestions to improve cp's behavior in this area.

So I responded with 2 reasons why we might not make 'y' imply '-f' for 
unwritable files.
I'll think some more about what can be done here, but for me at least
code complexity it never a reason for not doing something.
The code here isn't that complex, it's the external implications
that are confusing and hard to consider (and thus best tracked in tests).

thanks,
Pádraig.

p.s. I use this git alias to sort branches by date:
  brdate = for-each-ref --sort=-committerdate 
--format='%(committerdate:iso8601) %(refname:short)' refs/heads/