On Wed, Apr 14, 2010 at 05:35:36PM +0200, Stefan Sperling wrote:
> On Wed, Apr 14, 2010 at 04:21:56PM +0200, Daniel Näslund wrote:
> > Hi!
> > #3610  is about ignoring white space changes to be able to apply
> > patches that have been mangled, i.e. a mailing software converting tabs
> > to spaces, removing trailing white spaces or leading white spaces.
> > It means that if a certain option is given, we will match and apply
> > hunks if the only thing differing is white spaces.
> I'd say it means that if a certain option is given, we will match
> and apply hunks even if amount of whitespace doesn't match (everything
> else must match though).
> I.e. we'll add some optional magic in match_hunk(), making it skip over
> whitespace on either side (as determined by isspace()), but comparing
> any other characters.
Note that a whitespace may be tabs beeing translated to spaces, e.g.
it's not enough to just look at the trailing or leading whitespaces.
I've used this approach (comparing the the lines with all whitespaces
char *stripped_hunk_line = apr_pstrdup(pool,
char *stripped_target_line = apr_pstrdup(pool, target_line);
lines_matched = ! strcmp(stripped_hunk_line,
> > The problem
> > -------------
> > The '+' lines will be applied with the white spaces changes
> > in the patch. That's the intended behaviour. But it would be preferable if
> > the context lines would be read from the target. For leading and
> > trailing context, I can do that. But in the case when there are context
> > lines in the middle of a hunk I can't since svn_hunk_t uses a stream
> > called modified_text that makes no distinction between '+' lines and context
> > lines, e.g. the leading ' ' or '+' are removed.
> > The options
> > ------------
> > 1) Just say that the whole hunk will be applied and we make no
> > guarantees on what the white spaces will be.
> Yes. Just use whatever comes from the patch, including context lines.
> This is consistent with the current behaviour. I think we should avoid
> special cases where this rule is currently not true anymore.
I'll do that.
> (I'm not sure how UNIX patch behaves wrt context lines, actually.
> Might be worth checking.)
> If people don't like the result of patching, they can edit the patch
> to their liking and re-apply it (or ask the submitter to resubmit
> the patch -- mangled patches are usually the submitter's fault).
my thoughts exactly.
Received on 2010-04-14 17:51:04 CEST