hg grep users, feedback wanted
Matt Mackall
mpm at selenic.com
Wed May 19 15:31:35 UTC 2010
On Wed, 2010-05-19 at 09:48 -0500, Steve Borho wrote:
> On Wed, May 19, 2010 at 4:39 AM, Masklinn <masklinn at masklinn.net> wrote:
> > On 2010-05-19, at 11:28 , Gilles Moris wrote:
> >>
> >> On Wednesday 19 May 2010 10:32:14 am Martin Geisler wrote:
> >>>>> Not having to filter out build garbage and other cruft is quite
> >>>>> useful; and as I replied separately, grep is not always available. I
> >>>>> think this is the behavior new users expect when they use 'hg grep'
> >>>>
> >>>> All I can say is that it never was the behavior I expected when I
> >>>> first discovered a grep built into my VCS, I would have found that not
> >>>> very useful.
> >>>
> >>> I agree, I also think 'hg grep' should search through history by
> >>> default. New users wont even recognize the command from its name, and if
> >>> they do recognize the name, well then they can use/install a real grep.
> >>>
> >>> We may want to look at 'hg cat', another command which has it's name
> >>> from a popular Unix command. Doing 'hg cat foo' will show the file as it
> >>> was commited in the working copy parent revision, not as it currently
> >>> looks on disk. I guess everybody will agree that making 'hg cat' output
> >>> the file as it is on disk seems redundant and so I don't think 'hg grep'
> >>> should do that either.
> >>
> >> I think the point is
> >
> > That's the point of the initial change, but the issue I was raising, and
> > with which Martin seems to agree (at least I now know I'm not mad) is about
> > the sensibility of the default (bare `hg grep`).
> >
> > I believe the current behavior is most sensible, because it's both the most
> > useful (as far as I'm concerned given the other behavior in great part
> > replicates system tools available in pretty much every OS under the sun in
> > one form or another) and the most logical in the light of a VCS-provided
> > content search (grep).
> >
> > Steve did raise a good point on UI coherence earlier when he pointed
> > out that the commands which can involve the working copy usually do so by
> > default (status, diff), and `git grep` behaving the way his proposal would
> > also supports the motion though. On the other hand, Martin also raises
> > an interesting point with `hg cat`.
>
> hg cat does not support working copy contents at all, so I think it's
> still consistent.
Yes, we currently have no precedent at all for a command that works on
the working directory when given a switch. Commands either work on the
working directory by default (eg status) or not at all (eg cat). In
other words, we'd have to invent such a switch name or invent a concept
analogous to '-r .' for the working directory then make sure it doesn't
break the world when people tried to use it in random places.
--
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial
mailing list