--- Begin Message ---
|
Subject: |
[PATCH] vc-cvs-ignore writes absolute filenames and duplicate strings |
|
Date: |
Thu, 29 Aug 2019 00:32:22 +0200 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 |
When called with an absolute filename (which is the default
case), `vc-cvs-ignore' writes the entire path into the .cvsignore
file.
`vc-cvs-ignore' also writes duplicate strings into .cvsignore.
The attached patch fixes these errors.
0001-Do-not-write-absolute-filenames-and-duplicate-string.patch
Description: Text Data
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#37215: [PATCH] vc-cvs-ignore writes absolute filenames and duplicate strings |
|
Date: |
Sat, 22 Feb 2020 10:59:49 +0200 |
> Cc: address@hidden, address@hidden, address@hidden
> From: Wolfgang Scherer <address@hidden>
> Date: Fri, 21 Feb 2020 21:32:03 +0100
>
> > Please quote 'like this' in log messages, and try to avoid non-ASCII
> > characters there (they are generally only necessary in people's
> > names).
> OK
> >> +Patterns follow glob(7) syntax. Special characters \"?*[\\\" are
> >> +escaped with a backslash."
> > I'd say "should be escaped" here, since this is a requirement for the
> > argument passed to this function.
> Here is that amgbuity again ;-). It is only required, if the user
> wants a special character to match literally. It's perfectly fine to
> specify *.pyc as a pattern. I have phrased it like that.
> > Also, I'd mention that FILE can be a pattern, otherwise the reference
> > to patterns might come as a surprise to the reader.
> I emphasized more, that the basename of the FILE argument (not the
> entire FILE) is in fact a CVS ignore pattern.
> >> +to hear about anymore. If SORT is non-nil, sort the ines of the
> >> +ignore file." ^^^^
> > Typo: should be "lines".
> Right.
> >> + (goto-char (point-min))
> >> + (save-match-data
> >> + (unless (re-search-forward (concat "^" (regexp-quote str) "$") nil
> >> t)
> >> + (goto-char (point-max))
> > You could use non-nil, non-t 3rd argument of re-search-forward, in
> > which case the following goto-char would be redundant, right?
> Right, I just left the goto-char in there, because it makes it
> obvious what is going on. Switching to the side-effect optimization ...
Thanks, pushed to the release branch.
Please note that I need to make minor copyedits in the log message;
please try following this style in the future.
With this, I'm closing this bug report.
--- End Message ---