Use of GIT with epub contents/editing

[KevinH]

Hi All,

We (Sigil Developers) have had a number of requests to interface Sigil to a git repository for keeping version control for epub files. I personally do not use one but I am willing to take a shot at creating sample Sigil plugins that people could use to interface to git (or some other version control system).

I am looking for feedback on what would make the most sense for the most Sigil users.

Option A
----------
I am thinking of a sequence of 2 plugins:

1. An input plugin to extract/copy whatever is currently in master at a particular *local* repo and create an epub to load it in Sigil.

If some other version is wanted the user would have to checkout that revision in the target repo via a commit number before running this plugin.

2. An output plugin to write and then commit to master the epub as it stands inside Sigil when invoked.

To simplify things I would assume a local git repo (as represented by a path on the machine running Sigil) for all ebooks exists and that each ebook (as determined uniquely by the main uuid in the opf) would have its own directory inside that repo.

The input plugin would have a preference for the path to the local repo, and it would parse the repo to create a list of the dc:title and main uuid for each subdirectory in the local repo and present a gui allowing the user to pick one for input.

Similarly the output plugin would use the same path to the local repo (a shared preferences file?) and it would search for a match for the main uuid in the repo and copy all files to that directory and do the commit, or if the main uuid directory does not exist, create a new folder copy the files to it and init and commit it.


OR


Option B
----------

Ignore the repo itself and just create a generic output plugin that copies all ebook files to a target directory (you choose via a gui).

And a generic input plugin that loads all files in a directory into an epub zip to input into Sigil?

The user would then have to handle all git commits, branches, diffs etc themselves.


Obviously:

Option B would be a lot easier to implement and if it would do enough for most users who do version control, it can probably be done in an afternoon.

Option A would be a lot harder as it will require a git repo structured in a manner Sigil would understand and would need to handle commits and diffs. And it would only work with a local git repo, other version control systems would not be supported.


Which is better? Option B to get a quick and simple, repo-independent, folder input / output plugin or Option A the full blown git-only interface.

Thanks for your feedback.

KevinH

[DiapDealer]

I think option B would offer more flexibility for more people in general. Opening and saving to a folder would be useful even without a VCS (not to mention that it would allow VCSs other than git to be used).

[jcsalomon]

Definitely something like Option B: it’d be much easier to implement and won’t interfere with however I choose to use Git. Easier for you and a better experience for us.

(What I currently do is have a pair of shell scripts or batch files: one deleted the unpacked tree and unzips the EPUB, the other deletes the EPUB then correctly zips up the directory. I use Sigil as usual, then use the unpacker script before I commit with Git; and when I’ve done something with Git—change branch, for example—I run the packer script.)

[Tex2002ans]

Yep, I would also vote for Option B. A lot more flexibility, and even helpful for people who don't use version control.

[KevinH]

See this post for working betas of FolderIn and FolderOut plugins:

https://www.mobileread.com/forums/sh...5&postcount=23