darcs

Issue 2038 darcs get --tag should not match on a regexp

Title darcs get --tag should not match on a regexp
Priority bug Status unknown
Milestone Resolved in
Superseder Nosy List bfr
Assigned To
Topics

Created on 2011-01-26.10:55:37 by bfr, last changed 2015-03-27.22:40:31 by gh.

Files
File name Uploaded Type Edit Remove
test.sh bf, 2014-04-09.20:34:37 application/x-shellscript
unnamed kowey, 2014-03-28.06:00:41 text/html
Messages
msg13589 (view) Author: bfr Date: 2011-01-26.10:55:36
"darcs get --tag" matches on a regexp. This is a very questionable
design choice. When getting from a repo with a tag you typically want
to check out a certain specific version. The probability of getting the
wrong version is high: imagine you have the two tags "1.2" and "1.2.1",
then "darcs get --tag=1.2" will select the later version 2.1.1, not
1.2. This is very error-prone. You have to remember to bracket the tag
name between ^ and $, and since the latter is (in Unix) a shell meta
character, everything has to be quoted. This is all very cumbersome.
A backward compatible solution would be some option like --exact-match,
which the user could then put in his ~/.darcs/defaults file.
msg17238 (view) Author: alex.aegf Date: 2014-03-28.05:29:18
It may be that if I understand well, one solution can be generated the regexp of the string/tag, say r, with 
the prefix ^ and sufix $. Ie, right now the regexp is generated of this way `mkRegex r` and I propose 
generate of this way ` mkRegex $ "^" ++ r ++ "$" ` .

But I don't full understand which may be the problem with backward compatible.
msg17239 (view) Author: kowey Date: 2014-03-28.06:00:42
Hmm, interesting.

--tag . is a very handy darcs idiom that outlive sad to lose

Having tag behave inconsistently in get v other commands would be a pain
Having matches behave inconsistently with each other would also be bad
(otoh you could argue tag is different)

Maybe Max's flag is way forward

Or maybe darcs would issue a BTW after the fact (there are also 56 matches,
including 1.2, 1.1.2; did you mean --tag '^1.2$'?

On Friday, 28 March 2014, Alejandro Gadea <bugs@darcs.net> wrote:

>
> Alejandro Gadea <alex.aegf@gmail.com <javascript:;>> added the comment:
>
> It may be that if I understand well, one solution can be generated the
> regexp of the string/tag, say r, with
> the prefix ^ and sufix $. Ie, right now the regexp is generated of this
> way `mkRegex r` and I propose
> generate of this way ` mkRegex $ "^" ++ r ++ "$" ` .
>
> But I don't full understand which may be the problem with backward
> compatible.
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net <javascript:;>>
> <http://bugs.darcs.net/issue2038>
> __________________________________
> _______________________________________________
> darcs-devel mailing list
> darcs-devel@darcs.net <javascript:;>
> http://lists.osuosl.org/mailman/listinfo/darcs-devel
>


-- 
Eric Kow <http://erickow.com>
Attachments
msg17317 (view) Author: bf Date: 2014-04-09.20:34:37
My rationale for first proposing a "non-standard" behaviour (i.e. that
darcs get --tag always does an exact match) was that currently the
command 'darcs get --tag' is not well-defined for non-unique matches. An
indication is that the manual doesn't say what happens in that case.
Indeed, the test I attached (not in standard test format, just a quick
demo) demonstrates that the result depends on the order in which patches
are applied. IMHO this is very nasty, but it is a separate issue.

The reason I walked back from my first proposal: the incompatibility is
that people (like me) work around the issue by saying: darcs get --tag
'^the-real-tag-name$'. If we were to change the meaning of --tag to be
the exact tag name then such uses, e.g. in scripts, would break.

This is why my second proposal was to add --exact switch.
Attachments
History
Date User Action Args
2011-01-26 10:55:37bfrcreate
2011-06-08 11:47:30galbollesetpriority: bug
2014-03-17 01:26:41ghsetassignedto: alex.aegf
nosy: + alex.aegf
2014-03-28 05:29:19alex.aegfsetmessages: + msg17238
2014-03-28 06:00:43koweysetfiles: + unnamed
messages: + msg17239
2014-04-09 20:34:38bfsetfiles: + test.sh
messages: + msg17317
2015-03-27 22:40:31ghsetnosy: - alex.aegf
assignedto: alex.aegf ->