Andreas Hartmann (98a7b189) at 17 Mar 05:57

Andreas Hartmann (98a7b189) at 17 Mar 05:57

Andreas Hartmann (341774bd) at 17 Mar 05:54

Andreas Hartmann (98a7b189) at 17 Mar 05:51

Andreas Hartmann (96efea1c) at 17 Mar 05:49

The --cleanup CLI argument in gls-merge should remove any local branches pointing to the same HEAD as the remote branch that is being deleted. In theory there is code to handle this in place, but in practice it hasn't worked for a very long time now. Hence, after running gls merge ... and merging/deleting a branch that exists locally, one has to manually remove their local branch afterward.

The reason for this is most likely an oversimplification in identifying such local branches that are now merged. A more sophisticated solution should probably identify all local refs that push to the remote ref that has been deleted as part of the cleanup. How exactly that is done, though, I currently can't tell.

Restore local branch cleanup and make it delete all local branches that point to the upstream branch which has been merged. This should also catch any backup copies or renames and similar.

If deleting a local branch fails, the script will continue to run regardless and print a warning. This design was chosen since local changes can easily be performed by hand (especially with the hint from the warning messages) and are limited in scope to the person that ran this script. Remote operations will fail execution simply to alert of the fact that action is required, as remote resources are shared.

The original bug was caused by a simple omission of leading git in the rev-parse subcommand.

User-facing changes

The -c/--cleanup option to gls merge now deletes local branches pointing to the remote branch that has been merged. This means you no longer have to manually delete local branches after calling gls merge -c, since ideally gls merge now does that for you.

This has been a long-standing issue and I apologize for the inconvenience it has caused in all this time.

Closes: #4

Andreas Hartmann (01554598) at 17 Mar 05:49

... and 1 more commit

Marking this as draft pending further manual tests.

Side-note: I should probably think of a proper testing framework for all of this. :/

Restore local branch cleanup and make it delete all local branches that point to the upstream branch which has been merged. This should also catch any backup copies or renames and similar.

If deleting a local branch fails, the script will continue to run regardless and print a warning. This design was chosen since local changes can easily be performed by hand (especially with the hint from the warning messages) and are limited in scope to the person that ran this script. Remote operations will fail execution simply to alert of the fact that action is required, as remote resources are shared.

The original bug was caused by a simple omission of leading git in the rev-parse subcommand.

User-facing changes

The -c/--cleanup option to gls merge now deletes local branches pointing to the remote branch that has been merged. This means you no longer have to manually delete local branches after calling gls merge -c, since ideally gls merge now does that for you.

This has been a long-standing issue and I apologize for the inconvenience it has caused in all this time.

Closes: #4

Andreas Hartmann (96efea1c) at 13 Mar 07:33

Andreas Hartmann (9491fa37) at 13 Mar 07:18

... and 11 more commits

Andreas Hartmann (54fb0bd8) at 13 Mar 07:18

As far as I'm aware, the only component in this script collection that requires an internet connection is c14h-metadata. That is because it reads the c14h metadata from the NoName e.V. website and processes that accordingly before returning the result.

This of course also means that testing, right now, requires an internet connection. One could work around this by mocking c14h-metadata for the purpose of testing. However, I would prefer a solution where c14h-metadata gets an additional flag (and maybe env variable) that, when set, takes as argument a JSON file with downloaded c14h metadata and then works on that.

To me that seems like the least complicated option to decouple testing from the internet. It could also provide a fail-safe when processing past videos without an internet connection (e.g. on a train).

Implement offline mode for 'c14h-metadata' which uses a JSON file containing c14h metadata to resolve c14h IDs.

There are no checks in place to ensure the JSON file content is valid since likewise the upstream at noname-ev.de has no such mechanism either. Existing tests that relied on obtaining metadata for individual c14h IDs now use this feature as well, meaning that tests can now be run offline.

User-facing changes

The c14h-metadata script from this project now has a new CLI option --metadata. It takes one argument, which must be a JSON-formatted file with c14h metadata information. If this option is given, metadata is not downloaded from the NoName e.V. homepage and the file content is taken for granted instead.

To obtain metadata for offline use, you can use the following command:

curl -L "https://www.noname-ev.de/c14h.json" -o "c14h-metadata.json"

If you want c14h-metadata to use this offline metadata even when not calling it directly (i.e. if you're using c14h-banner which calls c14h-metadata internally), you can set the C14H_METADATA_JSON environment variable like this:

declare -rx C14H_METADATA_JSON="c14h-metadata.json"
# From now on, all background calls to `c14h-metadata` will use the offline
# metadata.
c14h-banner 675

Closes: #1

Andreas Hartmann (7ef2d120) at 13 Mar 07:17

... and 1 more commit

Andreas Hartmann (54fb0bd8) at 13 Mar 07:13

Andreas Hartmann (c53d4189) at 13 Mar 07:12

Implement offline mode for 'c14h-metadata' which uses a JSON file containing c14h metadata to resolve c14h IDs.

There are no checks in place to ensure the JSON file content is valid since likewise the upstream at noname-ev.de has no such mechanism either. Existing tests that relied on obtaining metadata for individual c14h IDs now use this feature as well, meaning that tests can now be run offline.

User-facing changes

The c14h-metadata script from this project now has a new CLI option --metadata. It takes one argument, which must be a JSON-formatted file with c14h metadata information. If this option is given, metadata is not downloaded from the NoName e.V. homepage and the file content is taken for granted instead.

To obtain metadata for offline use, you can use the following command:

curl -L "https://www.noname-ev.de/c14h.json" -o "c14h-metadata.json"

If you want c14h-metadata to use this offline metadata even when not calling it directly (i.e. if you're using c14h-banner which calls c14h-metadata internally), you can set the C14H_METADATA_JSON environment variable like this:

declare -rx C14H_METADATA_JSON="c14h-metadata.json"
# From now on, all background calls to `c14h-metadata` will use the offline
# metadata.
c14h-banner 675

Closes: #1

Andreas Hartmann (9e4cebea) at 13 Mar 07:06