[WIP] feature: list files in tree

[necaris]

Includes code stolen from @dsludwig (see dsludwig@68edeb4)

Closes #1978

Note this is still very incomplete and needs design discussion, which (as I understand it) should be happening on the issue?

[lunny]

This file should be put in github.com/go-gitea/git not here.

[necaris]

@lunny these types are for the API representation of the tree listing, matching the GitHub API, and to make the tree listing API easier to test -- otherwise they add little to the git.Tree and git.TreeEntry types that already exist. Would it be better to avoid defining public types, and instead add JSON annotations to those types in go-gitea/git ?

[bkcsoft]

If we're sending them over to the Client they should be defined in go-gitea/go-sdk 🙂

[bkcsoft]

How does GitHub API represent them? usually we create a APIFormat function for things like this

[bkcsoft]

It's not though, since git cat-file prints the size along with the ref and filename :/

[HoffmannP]

Is anyone currently working on this?

[lunny]

@HoffmannP I think no since this PR doesn't update for 1 month. @necaris are you still working on this?

[necaris]

I've still got the WIP code, just haven't had time to get it working again. I'll have more time in the next couple of weeks and should knock this out.

…

On Sun, Nov 18, 2018 at 8:20 PM Lunny Xiao ***@***.***> wrote: @HoffmannP <https://github.com/HoffmannP> I think no since this PR doesn't update for 1 month. @necaris <https://github.com/necaris> are you still working on this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2749 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAcH4ZOMJ9VyEQJU_9eXlVB0UzjXrdmJks5uwgdxgaJpZM4QAt6O> .

-- Rami Chowdhury "A mind all logic is like a knife all blade - it makes the hand bleed that uses it." -- Rabindranath Tagore +1-408-372-6496 / +44-7581-430-517 / +88-0189-245544

[lunny]

@necaris anothr PR #4185 also try to fix the issue. If you have too much time, maybe you could give some review on that and close this one?

[necaris]

@HoffmannP FYI, as @lunny suggested I'm going to close this in favor of #4185 which is already more complete -- looking at that code it looks like it's doing pretty much the same, but reinventing fewer data structures that have been added in the meantime. In case anyone finds this code useful I have rebased it to be up to date, though.