Julian Foad wrote:
> Hyrum K. Wright wrote:
>> This patch fixes a bug where multiple --target switches fail silently
>> for all but the final one. Instead, this patch concatenates all targets
>> specified by multiple --target switches into one array.
> Ah, but is it a bug?
I believe you were the one to point it out :) :
* If multiple "--targets" options are given, all but the last are
> We intentionally ignore all but the last of multiple occurrences of an
> option-taking-an-argument (except "-r"/"--revision"), perhaps in order
> to let the user have an alias which begins with some default option
> value and yet can be overridden with another value later on the command
> line. e.g.
> alias mysvn='svn --config-dir=~/my-svn-config/'
> mysvn diff # Uses ~/my-svn-config/
> mysvn diff --config-dir=~/.subversion/ # No error; uses ~/.subversion/
For the --config-dir option, this is understandable; it doesn't make
sense to use multiple config-dirs for a particular invocation of svn.
However, with --targets, a user could conceivably have an alias with a
default value, which is then augmented by the second switch:
alias svnfoo='svn --targets defaults'
svnfoo # Uses the targets in `defaults'
svnfoo --targets more # Uses the targets in `defaults' and `more'
> So -0.5 on this patch.
> Unless there is a demonstrable requirement for this behaviour, AND we
> document the new behaviour (in the on-line help, at least), I would much
> prefer the behaviourally simpler alternative which is to raise an error
> if the option is given more than once, if we agree that the existing
> behaviour should be changed (because it is unexpected, perhaps).
> I'm not saying whether the behaviour should be changed at all.
I'm not married to a particular design decision. I just think that to
silently ignore all but the last --target switch is probably not
correct. (Although I could be swayed otherwise.) I do agree that
including a note in the on-line help is important either way.
> (On the "GNU grep" developers' mailing list there is an on-going
> discussion about how repeated options should be treated - error, use
> only the last, try to combine them, etc. - and there is inconsistency in
> the present implementation and strongly conflicting views on what is the
> "right" or "best" interpretation for various different types of
> options. Combining multiple --targets options may be a reasonable thing
> to do, but if that behaviour is not required then we should obey the
> KISS design principle - keep it (the behaviour, the design, the
> functionality) simple.)
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jun 1 01:05:44 2006