Added update option which supports adding additional, new images

[0-ast-0]

from another source directory (the images are tracked witha SHA256 checksum in data.json so duplicates are ignored).

Update is implicit if the destination directory looks like a gallery, i.e. it contains a data.json file and a view subdirectory.

Removal of images from the img subdirectory is also supported, in which case the -u option is required when operating on the one gallery directory.

Update rewrites data.json as well as index.html and thus can also be used to simply replace titles/names in the html files. It also recreates the view subdirectory so existing galleries can get the new JavaScript and CSS files if they didn't use symlinks to the shared view directory.

[kensanata]

I'm a bit disappointed in the new name change. I dislike the fact that we now have a script called efgallery and a repo called sitelen-mute. I'll probably check this in as https://github.com/kensanata/efgallery. What do you think?

[0-ast-0]

Beyond being able to hand over a clean pull request for the update feature, the intent of my last fork was twofold: 1) finally get a version into pkgsrc that has all the bells and whistles I implemented over the last year and 2) to not have to put up with a name I cannot identify with. At first I had intended to take sitelen-mute release points as the master repo for pkgsrc package, but this way I now do not need to patch the pkgsrc efgallery at all as I have full control over it's master repo here at github.

I also clearly state that in the README.md: This github repository will serve to cherry pick features coming from the other fgallery versions out there and is the master site for the pkgsrc package. After having patched - and patched - 1.x to get something better into pkgsrc, I wasn't going to start day 1 on the 2.x path with yet another set of patches in the pksgsrc tree!

To me it doesn't make sense at all that you took the new name. I expected you to just merge the update feature as the first "cherry pick" from efgallery (then still called sitelen-mute). Doesn't that work easily in github? Some of the changes I make in efgallery you might want to adopt but I'm practically certain not all as I am going to continue the change things into the BSD direction for efgallery. I will definitely like to cherry pick any changes going into sitelen-mute that strike my fancy! A case in point is that efgallery is not going to worry about all the Linux distributions because honestly I don't have the resources and passion to look at any of that. However on the large scale of things it may be a disillusionment to other contributors and at the very least a loss that now, for example, the Docker stuff is not in the README.md anymore.

The idea (and the name) came to me on the spur of the moment as I was wondering how I was doing to track the new sitelen-mute under the old pkgsrc fgallery. Since submitting pull requests is made easy after forks at github, it was natural to fork again, submit the pull request for the update feature and then I made the other "non compatible" changes. I could imagine that it would remain very easy to cherry pick further changes either way (albeit not with github's GUI but using a CLI git workflow as filenames changed). For that reason I'm a bit surprised you also decided to adopt efgallery as the new name.

[kensanata]

Well, the name change was in your pull request so I naturally assumed that’s the change you wanted to submit. I didn’t realize that you had intended for efgallery and sitelen-mute to fork. Just making sure, here: is that what you intend to do?

[0-ast-0]

Weird, I specifically remember creating the pull request based on a brand new fork from sitelen-mute yet before making the additional "incompatible" changes (name change, README.md). Did those subsequent changes also get put into that pull request?

What I didn't consider was that with the script name change, future github merging won't work out of the GUI because it can't find the corresponding file (or will want to change its name). I'm not so familiar with the githib GUI as I do git on the CLI. Could a branch serve my purpose of tracking sitelen-mute with my changes (including filename changes, additions, and removals)?

I want a repo whose live cycle is controlled by me so that no patches need to go into the build on pkgsrc (which, BTW, I will soon promote into the proper /usr/pkgsrc/graphics/efgallery tree together with graphics/facedetect). Possibly github GUI merging might still work for such a "pkgsrc" branch I maintain here?

[0-ast-0]

Looking at https://github.com/kensanata/sitelen-mute/pull/12/commits I indeed see the whole stack of commits. Don't know why github added my "private" ones after I created the pull request after the first one, large, commit implementing update. I expected you to get only that commit, maybe you can revert the subsequent ones (except for the much later unlink() fix) and life will go back to normal as we both have our branch? It'd be great if the two repos could sit side-by-side and all the merges could go either way even if filenames change (but stay different in each repo). I really think the Docker stuff should be reverted back into the siteline-mute README.md (unless you don't want to maintain that either ;-)

[kensanata]

OK. I will revert the renaming and some of the other changes, then. But yeah, unless maintainers for the various distros will package things up, I won't be maintaining any packages. And I don't use docker, either, so unless somebody steps up to maintain it, it will also have to go the way of the bitrot. As for the way GitHub works: you make a pull request for a branch. If you add further commits to the branch, these get added to the pull request. Thus, before making a pull request, you need to create a feature branch. Then the onus is on you: if you keep working on your master branch and find that a certain commit should also be part of the pull request, you have to cherry pick it from your master onto the branch that is the base of the pull request.