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 2023-11-14 15:02:06 -04:00
commit bca22426d8
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 68 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

68
doc/bugs/__96__git_annex_sync___60__REMOTE__62____96___swallows_network_failure.mdwn Normal file
View file

@ -0,0 +1,68 @@
### Please describe the problem.
`git annex sync` does not report when `git fetch` and `git push` fail due to
network issues. While `git fetch`'s error messages are printed, the exit
status of `git annex sync` will still be `0`.
Looking at the source code, this seems to be a deliberate design decision. The
synchronization operation are coded in such a way that failing to send/receive
commits to/from a remote is not reported as an error. (See `pullRemote` and
`pushRemote` in `Command/Sync.hs`.) This has the advantage of allowing the user
to simply say `git annex sync` without worrying too much about whether all of
their configured remotes are reachable.
However, this poses problems when trying to use `git annex sync` in an
automated way. If networking issues (including authentication failures) are
ignored, this can easily convince a script using `git annex sync` that the
operation has succeeded, when in fact it has failed.
I can think of a few ways of addressing this issue:
1. Keep going of any of the `pullRemote`/`pushRemote` invocations fail, but
keep track of the fact that something has failed, and exit with status 1 if
this happens. This has the advantage that scripts will be properly alerted
when things go wrong, but isn't strictly backwards compatible.
2. Add an option to `git annex sync` which causes any failures within
`pullRemote`/`pushRemote` to be considered fatal errors. Perhaps the option
could be called `--batch` or `--report-errors`. This would allow for strict
backwards-compatibility.
3. Make failures of `pullRemote`/`pushRemote` fatal errors if exactly one
remote is given on the command line. This isn't backwards compatible, and
also has issues because the semantics are not necessarily obvious to those
using `git annex sync`.
I'm sure there are other solutions, but I think users of `git annex sync` need
a way of detecting network errors and responding to them appropriately.
Especially when you're only trying to synchronize with a single remote, and
failing to reach that remote is by definition a failure of the entire process.
### What steps will reproduce the problem?
Attempt to pull from any standard properly-configured `git-annex` remote
`<REMOTE>` with
[[!format sh """
$ git annex sync <REMOTE>
"""]]
when `<REMOTE>` is not reachable on the network.
Then check the exit status with
[[!format sh """
$ echo $?
"""]]
You should get `0` as the result.
### What version of git-annex are you using? On what operating system?
I'm using the latest version in Debian stable, 8.20210223-2.
### Please provide any additional information below.
Not really sure what to put here. Except perhaps to apologize for the overly
design-oriented bug report. Also, be aware that I'm more than happy to put in
the legwork of fixing the issue I've described above. But I'd like to make sure
we agree on a solution before I spend a lot of effort assembling a patch
series.
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Oh yes, I've used `git annex` for many years now to handle synchronizing files
between various machines. Many thanks for your work on this project.