angel.ezquerra added a comment.
In https://phab.mercurial-scm.org/D5495#81562, @yuja wrote: > > +@predicate('merge(*withbranch)', safe=True) > > > > def merge(repo, subset, x): > > > > - """Changeset is a merge changeset. + """Changeset is a merge changeset + + All merge revisions are returned by default. If one or more "withbranch" + names are provided only merges with those branches (i.e. whose + second parent belongs to one of those branches) will be returned. > > I understand this will be useful in a certain branch strategy, but the > proposed syntax is hardly extensible. Maybe it can be a non-wildcard argument > of `stringmatcher` type so we can at least add another option later. > > Any thoughts? Do anyone love this feature? > > If we had a syntax to filter revisions by sub expression, this and the > samebranch option could be expressed as follows: > > merge() & filter($a, p2($a) & branch("...")) > merge() & filter($a, samebranch(parents($a))) > > where filter(argname, boolean-expr) > > > This is much more expressive (or verbose) and can support other types of > branches, but is hard to implement. Thank you for the review, @yuja I think it would be a good idea to make the "branch" arguments more flexible. One option could be to use a stringmatcher to add support for regular expressions as you suggest. I can look into that. However there may be some other options worth exploring. The one you suggest is very interesting although I find the syntax a bit complicated for the common use cases that I want to enable which are: 1. Ignore merges from the same branch, which in a named-branch based branching strategy are usually irrelevant 2. Look into merges with a specific branch (e.g. which branches have been merged with the default branch)? In my experience those two are the ones that are the most common and I think we should try to make the easy to use. That is, I think that even if mercurial had a filter function like the one you propose I would still want to be able to express those 2 common merge properties in a simple way. That being said, I really like your idea since I often find myself being unable to express what I want with a revset (as powerful as those are) because of the lack of a filtering mechanism. Adding a generic filter function would be very useful indeed. I'm not sure if the syntax you propose would work as is though. It seems that it would need a new "&" operator? In any case I believe that it is out of the scope of this particular set of patches. Do you agree? If so I can focus on improving this patch by adding the stringmatcher as you suggest (as it seems I'm not the only one who thinks this would be useful). Is that ok? REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D5495 To: angel.ezquerra, #hg-reviewers Cc: pulkit, yuja, mercurial-devel _______________________________________________ Mercurial-devel mailing list [email protected] https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
