Support for remote (git) repository

[kestal]

Would it be possible to modify this library as to support specifying a remote repository location and working with it instead of a local one?

My use case is the following: I'm using github to maintain a sort of wiki, and would like to use gitit to "publish" it and make it easily accessible/editable. It would be feasible to just create a synchronization script that would take care of maintaining a local git repo up-to-date with github, but I think making gitit do it directly would maybe be cleaner, and I think filestore is the place where such a feature would be implemented.

I guess filestore should then be modified as to first pull from the remote before every content request, and directly push at each modification; this could lead to conflicts, in which case I'm not sure of the best strategy.

Thank you!

[jgm]

Possible, yes, but as you say the issue of conflicts is a big one.

+++ kestal [Nov 16 16 03:11 ]:

Would it be possible to modify this library as to support specifying a remote repository location and working with it instead of a local one?

My use case is the following: I'm using github to maintain a sort of wiki, and would like to use gitit to "publish" it and make it easily accessible/editable. It would be feasible to just create a synchronization script that would take care of maintaining a local git repo up-to-date with github, but I think making gitit do it directly would maybe be cleaner, and I think filestore is the place where such a feature would be implemented.

I guess filestore should then be modified as to first pull from the remote before every content request, and directly push at each modification; this could lead to conflicts, in which case I'm not sure of the best strategy.

Thank you!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, [1]view it on GitHub, or [2]mute the thread.

References

1. https://github.com/jgm/filestore/issues/24
2. https://github.com/notifications/unsubscribe-auth/AAAL5LCkwy8NWzi0detL4tcFYqlCEvwoks5q-uTegaJpZM4KztxJ

[Chaddai]

Pragmatically, it would make sense to act as if there were no conflicts possible (and throw an exception if it still happen). That would preserve the current interface. A new interface could be proposed with more control over conflicts and their resolution. That way the complexity would be hidden in the simple cases where filestore is the main client of a repository (with others being careful in their manipulations) and the full(er) capacity would be exposed if the user is willing to deal with the complexity of "not so ideal" cases.

[kestal]

OK, I'll try and write a GitRemote.hs module that behaves as simply and conservatively as possible and delegates to Git.hs. My idea for now is to simply make any change on the remote take precedence over one done in the local repo (i.e. the local repo acts as a "follower"); and doing the opposite (i.e. the local repo is the "leader") shouldn't be much different.

[kestal]

I've started adapting the code and think a simple but good enough strategy is to wrap the different methods of Git.hs as follows:

• All read operations are done after a git pull
• All write operations are followed by a git push

But now the following question arises: Where should the authentication be done? The most simple way would be to include the credentials in the init method, but I'm not sure it's a good approach because that means having credentials stored during the whole running time, and this means that in the case of gitit, the gitit server itself should have credentials to the remote server. My preferred approach would be to adapt the FileStore type so as to be able to specify credentials at each calls. In the case of gitit, it would allow to actually do pushes with the current user's credentials. The drawback here is that it makes a non triival change to the "API".