[PATCH 5 of 5 RFC] lfs: control tracked file selection via a tracked file

Matt Harbison mharbison72 at gmail.com
Tue Jan 23 22:30:15 EST 2018


On Sat, 20 Jan 2018 03:01:51 -0500, Jun Wu <quark at fb.com> wrote:

> Excerpts from Matt Harbison's message of 2018-01-14 23:58:52 -0500:
>> [...]
>>
>> Jun previously expressed concern about efficiency when scaling to large  
>> repos,
>> so I tried avoiding 'repo[None]'.  (localrepo.commit() gets repo[None]  
>> already,
>
> Is repo[None] slow? I thought it's an O(1) operation and '.hglfs' in  
> wctx is
> like os.path.exists test.
>
> FWIW I added a similar behavior reading config in working copy [1] for  
> the
> "dirsync" extension (which is a hacky temporary solution).
>
> Given the fact .hgignore uses working copy version, and whether to use  
> lfs
> or not feels similar to what .hgignore does, I think the working copy
> version might be a simple and more flexible choice. But I don't feel  
> strong.

I checked again, and you're correct.  It does look O(1).  I'll simplify  
this.

> Greg has a proposal checking in a .hgrc. I think that is a more general
> purposed solution for these kinds of stuffs. Since we now have  
> configitems,
> maybe it's doable by carefully whitelisting configs.

I'd love to get Greg's proposal landed.  (My use would be aliases for  
filesets and revsets, so that's probably an extra layer of whitelisting.)

That said, even if that were available now, I think a dedicated file like  
this is simpler for the user to reason about.  Consider the case where you  
want to always exclude certain files, but you want a catchall at the end.   
You *can* do this with the lfs.track config by wrapping the whole  
expression in '()' and subtracting things off, but that's a bit subtle  
when there's a 'none()' predicate.  If you have a lot of entries, shorter  
lines are easier to read, and it fits in with how you'd read .hgignore and  
.hgeol.  OTOH, this file doesn't prevent you from cramming it all into one  
line if there's a performance concern over readability.

> [1]: https://bitbucket.org/facebook/hg-experimental/commits/de0cc94acd
>
>> [...]


More information about the Mercurial-devel mailing list