[PATCH 3 of 3] lfs: teach '{lfs_files}' to handle removed files

[Yuya Nishihara]

On Fri, 09 Feb 2018 20:28:14 -0500, Matt Harbison wrote:
> On Fri, 09 Feb 2018 08:04:04 -0500, Yuya Nishihara <yuya at tcha.org> wrote:
> > On Fri, 09 Feb 2018 00:30:23 -0500, Matt Harbison wrote:
> >> +  $ hg log -T "{lfs_files % '{rev} {file}: {lfspointer.oid}\n'}"
> >> +  6 lfs.test:  
> >> sha256:43f8f41171b6f62a6b61ba4ce98a8a6c1649240a47ebafd43120aa215ac9e7f6
> >> +  5 lfs.test:  
> >> sha256:43f8f41171b6f62a6b61ba4ce98a8a6c1649240a47ebafd43120aa215ac9e7f6
> >> +  3 lfs.catchall:  
> >> sha256:31f43b9c62b540126b0ad5884dc013d21a61c9329b77de1fceeae2fc58511573
> >> +  3 lfs.test:  
> >> sha256:8acd23467967bc7b8cc5a280056589b0ba0b17ff21dbd88a7b6474d6290378a6
> >> +  2 lfs.catchall:  
> >> sha256:d4ec46c2869ba22eceb42a729377432052d9dd75d82fc40390ebaadecee87ee9
> >> +  2 lfs.test:  
> >> sha256:5489e6ced8c36a7b267292bde9fd5242a5f80a7482e8f23fa0477393dfaa4d6c
> >
> > Including removed files makes sense, but I think the pointer should be  
> > "null"
> > in which case because the file doesn't exist. I have no idea how the  
> > "null"
> > lfs pointer should look like, though.
> 
> Interesting thought, I hadn't considered it.  I guess was going for being  
> able to identify which file was removed.  But that doesn't quite work,  
> because lfs files can transition to non-lfs first.
> 
> My only concern would be not complicating the template writing.  Having to  
> wrap lfspointer inside an {if()} before accessing lfspointer.foo or  
> lfspointer % oid seems unfortunate. IDK how to represent a null pointer

If lfspointer is an empty dict, lfspointer.foo and % oid should just work.

> either (internally or externally), so I guess I'll let it sit a few days  
> to see if anyone has an idea.  I'm waiting on stable to merge before I can  
> submit a similar patch for set:lfs().

Okay, merged and pushed to hg-committed.