mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2024-02-07 16:21:31 -04:00
commit 644317e86f
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
5 changed files with 199 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

8
doc/bugs/identically_configured_remotes_behave_differently/comment_1_d69d6a014c7265fb901dc407516e232b._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="jstritch"
avatar="http://cdn.libravatar.org/avatar/56756b34ff409071074762951d270002"
subject="comment 1"
date="2024-02-06T19:54:40Z"
content="""
This is possibly another manifestation of `pull doesn't work on adjusted branches`. I'll await your reply to it.
"""]]

131
doc/bugs/pull_doesn__39__t_work_on_adjusted_branches/comment_2_632a3616516605de477930ae09d4ca60._comment Normal file
View file

@ -0,0 +1,131 @@
[[!comment format=mdwn
username="jstritch"
avatar="http://cdn.libravatar.org/avatar/56756b34ff409071074762951d270002"
subject="comment 2"
date="2024-02-06T18:27:33Z"
content="""
If I commit a change, setting annex.adjustedbranchrefresh to true is not working as I *expected*. I want to pull to one specified remote only. I do not want to sync with any other repositories or special remotes that may happen to be available at the moment. This is possibly another manifestation of the issue I submitted about export not copying.
The `git annex sync` command is not happy with `here` as a remote name.
I see the same result if I change both `git annex adjust` from `--unlock` to `--lock`. If both adjust statements are commented out, pull-repo1 ends up with a broken link to the second file. The workflow should be the same for all cases.
Here's a script reproducing what I have:
[[!format sh \"\"\"
mkdir pull-repo1
mkdir pull-repo2
cd pull-repo1
git init --initial-branch main
git annex init pull-repo1
git config annex.adjustedbranchrefresh true
git config receive.denyCurrentBranch updateInstead
git annex config --set annex.largefiles include=*.xtx
git annex group here manual
git annex wanted here standard
echo \"test file one\" >> test-file-one.xtx
git annex add .
git commit -m \"add test file one\"
git annex adjust --unlock
cd ../pull-repo2
git clone --origin pull-repo1 ../pull-repo1 .
git annex init pull-repo2
cd ../pull-repo1
git remote add pull-repo2 ../pull-repo2
git annex push pull-repo2
cd ../pull-repo2
git config annex.adjustedbranchrefresh true
git config receive.denyCurrentBranch updateInstead
git annex config --set annex.largefiles include=*.xtx
git annex group here manual
git annex wanted here standard
git annex adjust --unlock
echo \"test file two\" >> test-file-two.xtx
git annex add .
git commit -m \"add test file two\"
cd ../pull-repo1
git annex pull --allow-unrelated-histories --content pull-repo2
git annex list
\"\"\"]]
And here's its output:
[[!format sh \"\"\"
Initialized empty Git repository in /home/juanito/Documents/pull-repo1/.git/
init pull-repo1 ok
(recording state in git...)
annex.largefiles include=*.xtx ok
(recording state in git...)
group here ok
(recording state in git...)
wanted here ok
(recording state in git...)
add test-file-one.xtx
ok
(recording state in git...)
[main (root-commit) 6eff4e8] add test file one
1 file changed, 1 insertion(+)
create mode 120000 test-file-one.xtx
adjust
Switched to branch 'adjusted/main(unlocked)'
ok
Cloning into '.'...
done.
init pull-repo2 (merging pull-repo1/git-annex into git-annex...)
(recording state in git...)
ok
(recording state in git...)
copy test-file-one.xtx (to pull-repo2...)
(recording state in git...)
ok
(recording state in git...)
push pull-repo2
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 12 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 426 bytes | 426.00 KiB/s, done.
Total 5 (delta 2), reused 0 (delta 0), pack-reused 0
To ../pull-repo2
* [new branch] main -> synced/main
* [new branch] git-annex -> synced/git-annex
ok
annex.largefiles include=*.xtx (merging synced/git-annex into git-annex...)
(recording state in git...)
ok
group here ok
(recording state in git...)
wanted here ok
(recording state in git...)
adjust ok
add test-file-two.xtx
ok
(recording state in git...)
[adjusted/main(unlocked) 57a9dab] add test file two
1 file changed, 1 insertion(+)
create mode 100644 test-file-two.xtx
pull pull-repo2
remote: Enumerating objects: 32, done.
remote: Counting objects: 100% (29/29), done.
remote: Compressing objects: 100% (21/21), done.
remote: Total 23 (delta 8), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (23/23), 2.24 KiB | 1.12 MiB/s, done.
From ../pull-repo2
* [new branch] adjusted/main(unlocked) -> pull-repo2/adjusted/main(unlocked)
* [new branch] git-annex -> pull-repo2/git-annex
ok
(merging pull-repo2/git-annex into git-annex...)
here
|pull-repo2
||web
|||bittorrent
||||
XX__ test-file-one.xtx
\"\"\"]]
Please observe test-file-two.xtx is not listed and also not in the first repository.
How should I proceed?
"""]]

14
doc/forum/how_to___34__move__34___URL_between_remotes__63__/comment_4_46ad0779ff71cfbadd663fe413d32ffb._comment Normal file
View file

@ -0,0 +1,14 @@
[[!comment format=mdwn
username="yarikoptic"
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
subject="comment 4"
date="2024-02-07T18:47:19Z"
content="""
> `git-annex registerurl --move-from=foo $key`
looks good
> Since registering an url also marks it present, all you would need after that is to mark it as not present any longer on your special remote.
it is `--move-from`, not `--copy-from`, so wouldn't it mark it not present any longer on `foo`?
"""]]

22
doc/todo/add_--json-progress_support_in_push_and_pull/comment_2_ff0b1ca16b03d2e6c8331645adad84a6._comment Normal file
View file

@ -0,0 +1,22 @@
[[!comment format=mdwn
username="jstritch"
avatar="http://cdn.libravatar.org/avatar/56756b34ff409071074762951d270002"
subject="comment 2"
date="2024-02-06T16:10:56Z"
content="""
To me, the purpose of any progress message is twofold: 1) let the user know the program is not stuck and 2) provide information about what was happening if it does get stuck. Push and pull do this now without JSON.
I agree the same JSON progress object format should be used for all commands. Currently the action progress information includes: command, file, input, byte-progress, total-size, and percent-progress.
The calling application is able to \"know\" which command it issued to cause the progress reports.
A separate, optional field could be added for the particular remote involved. For example, messages like \"Copy file A to remote-one X% complete\" and \"Export file B to remote-two X% complete\" should be possible.
I'm in favor of documenting data structures. Forcing developers to reverse-engineer the structure is inefficient at best. While the principle that all git-annex json output should be discoverable by simply running the command sounds good, I find it leaves much to be desired. Just to find out what's available, someone must setup and run the command. I suggest updating the requirement to \"All git-annex JSON output objects are documented.\"
Users will get impatient and grow frustrated without some type of indication work is in progress.
I'm OK with leaving Git operations silent for now.
Please improve the end-user experience by devising a way to inform the user git-annex is making progress with JSON.
"""]]

24
doc/todo/add_--json-progress_support_in_push_and_pull/comment_3_a11ee71f4ee907b011aebcfe270b7ee3._comment Normal file
View file

@ -0,0 +1,24 @@
[[!comment format=mdwn
username="jstritch"
avatar="http://cdn.libravatar.org/avatar/56756b34ff409071074762951d270002"
subject="comment 3"
date="2024-02-07T15:52:18Z"
content="""
Additional clarification of my posts above:
1) JSON allows optional fields. That is, fields which are only present when needed. I am specifically saying not to include all fields every time with `null` values as needed.
2) Occasionally tacking the remote name onto the end of a string named `command` is not discoverable. The `command` key would have to be renamed to something like `commandAndSometimesRemote` to be discoverable. jstritch's naming rule #5: If a name needs a conjunction to accurately describe it, the design can be improved.
3) The optional field name is more easily observed than the optional string content.
4) Consider the application code consuming the JSON. A test for the presence of the remote name is required either way. Do you want those applications writing the test \"if the command value contains one space\" or \"if the remote key is present\"? Code is written once and read hundreds of times. The second test conveys the intent, reducing maintenance cost.
5) The application code to deal with splitting the string and handling each part becomes unnecessary with the optional field.
6) The documentation of the JSON could include a matrix showing the key name and its data type versus the commands, similar to a feature comparison table.
7) Documenting the JSON does not make it less discoverable.
I hope you find this information helpful to improve the end-user experience. Let me know if you have any questions.
"""]]