[PATCH 2 of 2] lfs: migrate most file filtering from threshold to custom filter

[Yuya Nishihara]

On Tue, 16 Jan 2018 14:20:32 +0100, Boris Feld wrote:
> On Tue, 2018-01-16 at 08:05 -0500, Matt Harbison wrote:
> > On Jan 16, 2018, at 5:26 AM, Boris Feld <boris.feld at octobus.net>
> > wrote:
> > > I also realized that the revset is in Evolve and not in Core, which
> > > makes it a good opportunity to upstream it.
> > > 
> > > I'm not sure if we should keep only the equivalent of
> > > allprecursors(),
> > > what about having a predecessor() and allpredecessors() revsets.
> > > 
> > > predecessors() would returns the closests locally known
> > > predecessors,
> > > like the {predecessors} template keyword while allpredecessors()
> > > would
> > > returns all the locally known predecessors.
> > > 
> > > What do you think?
> > 
> > I think a dedicated revset to find the first generation, for lack of
> > a better word, of predecessors is useful.  I use it all the time to
> > ensure rebase/evolve conflict resolution didn’t drop anything, though
> > it only works if it wasn’t split or folded.
> 
> I think the term we used is closest predecessor, at least we have a
> function named closestpredecessors in obsutil.py.
> 
> > There was a proposal for short handing something like this, so maybe
> > a dedicated predicate won’t be needed in the future.  But it would be
> > nice if the template and revset agreed, and I don’t see an “all”
> > template as being as useful as the current one.
> > 
> > 
> > http://mercurial.markmail.org/thread/sjnnwa43s4eksu62
> > 
> 
> I was not aware of this proposal. I think a dedicated predicate would
> be usefull too to have more verbose and more readable templates.

Perhaps.

For the record, the core already has successors() which behaves more like
allsuccessors() in evolve. Maybe it could have depth=n option?