Fixed a CI failure caused by my additions ( failed on including emscripten.h ). Travis CI now fails at same test as the latest PR submitted (#4677) so I guess that failure has nothing to do with the emscripten stuff. Also merged so that my branch is in sync with upstream master.

So I am excited about this, but, of course, we can't just comment out code willy-nilly to work in emscripten. What is your plan here, @petersalomonsen? Is this branch aimed at just getting things working, then refactoring and tidying up later? Or should the core contributors be providing feedback into how we would like to see things organized?

@ethomson Thanks for response. Would be very happy to get feedback about how you would like to see things organized. Since last feedback from you the tls stream for emscripten is separated out in the src/streamsfolder. You mentioned also you wanted it as a separate transport, and it's unclear to me if that means like it is organized now, or if you want an even more separated implementation. The only place where code is disabled is in src/transports/http.c, and that's because a http protocol parser is not needed in the browser since it already has one. Otherwise the code of that file is used as is, and if going to make a separate version that would be much duplicate code.

I think we're past the "getting things to work part", it works very well as far as I can tell. So now it's more about organizing it properly so that it can be a part of the official libgit2 repository.

Cool, that was the impression that I got! I'll try to spend some time on this 🔜

@petersalomonsen Git protocol version v2 was recently introduced: https://github.com/git/git/blob/master/Documentation/technical/protocol-v2.txt

If you had glanced at it, do you think it changes anything wrt need of CORS proxy to communicate with GitHub during in-browser cloning?

Probably still not, right?

@vadimkantorov Seems like for github a proxy will still be needed. As for my own use case I've made a git hosting solution using JGit which has http server support, and then I can of course set the CORS headers to what I want.

@petersalomonsen js filters in your last commit sounds very interesting! Would you have an example of how to use them? As in function sig: what params the js filter would take, what it should return?

@maks below is my filter function implemented in Javascript for replacing staged content with a git LFS style pointer. The last line is for registering the filter with libgit2. The hex and sha256 functions are implemented in the full example file which you can find here: https://github.com/fintechneo/libgit2/blob/master/emscripten_hacks/jsgitfiltertest.js

What I'm trying to do is to handle when users are adding large binary files to the git repository, and store a pointer (inspired by Git LFS) instead of the actual content. With my git server I'm also going to implement a storage for the actual content. Trying to implement this using filters, just like LFS does.

jsgitfilterfunctions = {"filter=lfs": (path, attrs, mode, buf) => {
    console.log("Filtering", path, "matching attributes", attrs, 
        "Mode is", mode ? "clean" : "smudge", "Content length", buf.length);
    
    if(mode) {
        
    const filtered = `version https://git-lfs.github.com/spec/v1
oid sha256:${hex(sha256(buf))}
size ${buf.length}`;

        return Uint8Array.from(filtered,(x)=>x.charCodeAt(0))
    } else {
        return buf;
    }
}
};

jsgitregisterfilter("lfs", "filter=lfs", -1);

A successful LFS commit from the web-browser: fintechneo/browsergittestdata@8e181f3

A simple client implementation of LFS is in this project here: https://github.com/fintechneo/angular-git-filebrowser#large-files-using-git-lfs

Added emscripten to the build pipelines: https://dev.azure.com/libgit2/libgit2/_build/results?buildId=1171&view=logs

Sources of the docker image used for the build / test is here: https://github.com/fintechneo/libgit2/tree/master/emscripten_hacks/docker

Some updates to this pull request today:

• Rebased on top of latest libgit2
• Squashed to one single commit
• Created separate src/transports/emscriptenhttp.c (to avoid "willy-nilly" commenting out code in src/transports/http.c )
• Updated to using latest emscripten
• Output webassembly binaries removed from PR

We should be closer to something that could be merged now, or what do you think @ethomson ?

Todays update added a https transport for nodejs, and a few more additions to the js example library ( reset hard, last error, choose file_favor on pull).

Rebased on latest origin master as of 2019-06-25.

Some fixes to the nodejs version, and have successfully used it in an AWS lambda function.

Binaries can be found here: https://www.npmjs.com/package/libgit2.js

changed to using https://hub.docker.com/r/trzeci/emscripten/ for building in azure pipeline, and can also be used if you don't want to install emscripten.

Removed "ugly" patching of file permissions because of use of the sticky bit, which isn't handled by emscripten. Instead patching the permissions function of emscripten to grant permission if the sticky bit is set:

https://github.com/libgit2/libgit2/pull/4400/files#diff-38a5347ca2d81378f5963b6bb1d36c45R33

Also rebased on latest upstream master.