On Sun, 5 Feb 2006, Sander Striker wrote:
> Peter N. Lundblad wrote:
> > On Fri, 3 Feb 2006, Sander Striker wrote:
> [...]
> >> I wonder if we want options to our own code to be passed with -x.
> >> I can see it for eXternal commands.
> >
> > I'm not entirely comfortable with -x/--extensions being used as if our own
> > diff library was some external applications.
>
> Yes, that's what I felt too.
>
> > My concern is, besides rooneg's good point about being able to use the GNU
> > diff option names, that we may bloat our own "option space", especially if
> > we want more diff options later.
>
> While this is true, I feel that we are jumping through hoops to not have
> subcommand specific options. In case of diff, merge (and maybe blame) these
> are almost unavoidable (with exception of the long option names ofcourse).
>
I don't understand what you're getting at in the last paragraph. I think
if we don't got he -x route, we should just include long option names for
these, even though it seems like the short forms are available (at least
for the cmdline client). I have no strong feeling about this. Do others
have an opinion?
> >>>--strip-trailing-cr (maybe)
> >>
> >>Hmm, in that case I would say go for --ignore-eol-style.
> >
> > I'm wondering what exactly the semantics would be. Treat all line endings
> > as the platform line endings, or treat all line endings as LF?
>
> What's the difference? On comparison they will be the same in both
> cases no? In that light normalizing to LF seems easiest, but
> that's a meer implementation detail.
>
Since we're not outputting the normalized lines, there is no difference.
If we implement --ignore-eol-style, we want to keep some eol marker to
differentiate the case of no newline at end of file. If we just do
--ignore-eol, we can just drop the eol marker completely when normalizing
as brane suggests. Maybe that's more useful.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 5 22:03:40 2006