On Mon, 9 Nov 2009, Ganesh Sittampalam wrote:
On Tue, 3 Nov 2009, Ganesh Sittampalam wrote:
Hi,
On Sat, 31 Oct 2009, Kamil Dworakowski wrote:
A new primitive match type that allows for picking patches based on the
hunk contents. It takes a regex and matches the pattern inside either a
remove or an add line of a hunk. An example usage is:
darcs changes -i --match "hunk pattern"
So, my first question is whether we really want this feature, and whether
it fits in well with the darcs UI as it stands. My general feeling is it's
worth having, and that it sits nicely alongside the "touch" matcher. By
coincidence someone on IRC (sm) was just talking about doing exactly this
kind of search. But I'd welcome further input from the watching masses..
In this case, I'm going to take silence as assent and apply this, unless
someone steps forward with an objection within the next day or so.
Actually, Eric points out this is a good test of the feature resistance
ideas he outlined in his recent email. So I'll give them a go:
1. To what extent does this make new things possible (as opposed to
simply more convenient)?
For just browsing patches, it doesn't, in that darcs changes -v | less is
an alternative; but it's a pretty ugly alternative and harder to use. As
Kamil says in issue1636:
"At the moment I do it by searching inside darcs changes -v | less. Though
it seems that it would be nice to browse through the changes interactively
(as in darcs changes -i), because many times the comment of the patch will
make it clear that this patch is not interesting ('remove trailing
whitespace' for example). When searching with less one has to back search
for the header of the patch."
However, it does make it possible to use this kind of matching with darcs
pull etc, which isn't now possible. Whether this is useful or not, I don't
know.
2. Does this change any pre-existing workflows? Does this introduce
any incompatibilities?
Not that I know of.
3. What are the possible unintended interactions with other
pre-existing features?
None that I can think of. Any weird interactions would also arise for the
touch matcher, I think.
4. What are the alternative approaches to solving the same problem?
Why do we prefer this one?
The partial alternative is the aforementioned 'darcs changes -v | less'. I
don't think there are any reasonable complete alternatives.
I like this one because it slots cleanly in next to an existing feature
(the touch matcher) and in fact suggests a way of cleaning up the
implementation of that feature (see the other part of this thread which
discusses how we can get at primitive patches inside compound patches).
Ganesh
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
