From f90511ec43aab339f1a928b705e9adc36e7708c2 Mon Sep 17 00:00:00 2001 From: derphysiker Date: Mon, 27 May 2024 18:33:44 +0000 Subject: [PATCH 1/3] --- ...t__58___List_all_locations__44___groups__38__wants.mdwn | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 doc/forum/Feature_request__58___List_all_locations__44___groups__38__wants.mdwn diff --git a/doc/forum/Feature_request__58___List_all_locations__44___groups__38__wants.mdwn b/doc/forum/Feature_request__58___List_all_locations__44___groups__38__wants.mdwn new file mode 100644 index 0000000000..9faa71542a --- /dev/null +++ b/doc/forum/Feature_request__58___List_all_locations__44___groups__38__wants.mdwn @@ -0,0 +1,7 @@ +Hi there! + +Maybe I have overseen this feature. I would like to have something like 'git annex list' which lists all basic info about the locations, such as name, group and wanted. + +Basically I need to go into 'git annex vicfg' to have some kind of overview of the remotes. + +Or did I miss something? From bab6d3e58ff45f55f7f0b229e2fbbb150b43ac51 Mon Sep 17 00:00:00 2001 From: "m.risse@77eac2c22d673d5f10305c0bade738ad74055f92" Date: Tue, 28 May 2024 12:06:39 +0000 Subject: [PATCH 2/3] Added a comment: Re: worktree provisioning --- ..._bace0128b326dba6394e0f23b743f049._comment | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 doc/todo/compute_special_remote/comment_8_bace0128b326dba6394e0f23b743f049._comment diff --git a/doc/todo/compute_special_remote/comment_8_bace0128b326dba6394e0f23b743f049._comment b/doc/todo/compute_special_remote/comment_8_bace0128b326dba6394e0f23b743f049._comment new file mode 100644 index 0000000000..7a65fd222e --- /dev/null +++ b/doc/todo/compute_special_remote/comment_8_bace0128b326dba6394e0f23b743f049._comment @@ -0,0 +1,22 @@ +[[!comment format=mdwn + username="m.risse@77eac2c22d673d5f10305c0bade738ad74055f92" + nickname="m.risse" + avatar="http://cdn.libravatar.org/avatar/59541f50d845e5f81aff06e88a38b9de" + subject="Re: worktree provisioning" + date="2024-05-28T12:06:39Z" + content=""" +(I forgot to tick \"email replies to me\", sorry for the late reply) + +My reasoning for suggesting to always stay in HEAD is this: +Let's assume we have a file \"data.grib\" that we want to convert into \"data.nc\" using this compute special remote. We use its facilities to make it do exactly that. +Now, if there was a bug in \"data.grib\" that necessitates an update, we would replace the file. The special remote could do two things then: + +1. Try to convert \"data.grib\" from current HEAD to \"data.nc\", possibly failing if the checksums no longer match (if git-annex is instructed to check those). +2. Silently use the old version of \"data.grib\", creating a mismatch between \"data.nc\" and \"data.grib\" as available on HEAD (and in this case using a buggy version of the data). + +I think the first error is preferable over the second, because the second one is much more subtle and easy to miss. + +This same reasoning extends to software as well, if it is somehow tracked in git: for the above mentioned conversion one could use \"cdo\" (climate data operators). One could pin a specific version of \"cdo\" with nix and its flake.lock file, meaning that there is an exact version of cdo associated with every commit sha of the git-annex/DataLad repository. If I update that lock file to get a new version of cdo, then as a user I would naively assume that re-converting \"data.grib\" to \"data.nc\" would now use this new version of cdo. With worktree provisioning it would silently use the old one instead. + +IMO worktree provisioning would create an explosion of potential inputs to consider for the computation (the entire git history so far), which would create a lot of subtle pitfalls. Always using stuff from HEAD would be an easier implementation, easier to reason about, and make the user explicitly responsible for keeping the repository contents consistent. +"""]] From f6c0f55ad115835803aab7b8eccc63ebcf85daa9 Mon Sep 17 00:00:00 2001 From: nobodyinperson Date: Tue, 28 May 2024 12:18:59 +0000 Subject: [PATCH 3/3] Added a comment: Yep, would be nice! --- .../comment_1_911c0ff3327f1ce418588cfb7dca487f._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/forum/Feature_request__58___List_all_locations__44___groups__38__wants/comment_1_911c0ff3327f1ce418588cfb7dca487f._comment diff --git a/doc/forum/Feature_request__58___List_all_locations__44___groups__38__wants/comment_1_911c0ff3327f1ce418588cfb7dca487f._comment b/doc/forum/Feature_request__58___List_all_locations__44___groups__38__wants/comment_1_911c0ff3327f1ce418588cfb7dca487f._comment new file mode 100644 index 0000000000..df8ed262e0 --- /dev/null +++ b/doc/forum/Feature_request__58___List_all_locations__44___groups__38__wants/comment_1_911c0ff3327f1ce418588cfb7dca487f._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="nobodyinperson" + avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5" + subject="Yep, would be nice!" + date="2024-05-28T12:18:58Z" + content=""" +This doesn't exist and you need to script it yourself, e.g. with `git annex info --fast --json` and then subsequent calls to `git annex group ...` etc. I want to include this in [`git annex control-center`](https://gitlab.com/nobodyinperson/git-annex-control-center) eventually, but didn't have the time yet. +"""]]