[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