On Fri, Jul 01, 2022 at 03:19:12PM +0200, Oswald Buddenhagen wrote:
> On Fri, Jul 01, 2022 at 03:10:54PM +0200, Yuri D'Elia wrote:
> > But I can definitely start taking a note if you want more detailed info
> > in where it gets stuck.
> >
> yes, please. make the external timeout long enough so tha
On Fri, Jul 01, 2022 at 03:10:54PM +0200, Yuri D'Elia wrote:
But I can definitely start taking a note if you want more detailed info
in where it gets stuck.
yes, please. make the external timeout long enough so that it
accomodates isync's timeout on top of a reasonably worst-case time for a
su
On Fri, Jul 01 2022, Oswald Buddenhagen wrote:
> in short, it's a mess.
Fully agree with this.
> but if you find tangible evidence for isync's Timeout not working in
> some other scenario, i'm all ears.
> i suppose the most promising way to debug this would be running with -D
> (maybe -Dn is suff
On Fri, Jul 01, 2022 at 01:03:11PM +0200, Yuri D'Elia wrote:
A good distinction could really be if retrying makes sense or not.
yes, but the followup questions are then: retry after how much time, and
how often? it's hard to know that if you don't know *exactly* what went
wrong.
otoh, network
On Fri, Jul 01 2022, Oswald Buddenhagen wrote:
> yeah, i've been pondering this, and i'm somewhat undecided how to go
> about it. the problem is that there are lots of conditions, and how one
> "condenses" them into a single flag is somewhat arbitrary. my current
> thinking is that it would be bett
On Fri, Jul 01 2022, Oswald Buddenhagen wrote:
> i don't like the "either", as it implies XOR, which is contradicted a
> moment later. how about this:
>
>>>Return an extended exit code: Add 32 or 64 to the code if any
>>>modifications were made on the far or near side, respectively;
>>>these are no
On Fri, Jul 01, 2022 at 12:35:47PM +0200, Yuri D'Elia wrote:
I would still consider, if possible, to include a way to distinguish
between temporary errors (all network errors) and hard errors.
yeah, i've been pondering this, and i'm somewhat undecided how to go
about it. the problem is that the
On Fri, Jul 01, 2022 at 11:48:04AM +0200, Yuri D'Elia wrote:
One tab too much.
oops
"Add either 32 or 64 to the code if any modifications were made [...]
i don't like the "either", as it implies XOR, which is contradicted a
moment later. how about this:
Return an extended exit code: Add
On Fri, Jul 01 2022, Yuri D'Elia wrote:
> Just trying out the current main branch to play with the current version
> of the --ext-exit option :). Thanks for considering this, it's quite
> convenient to trigger local hooks.
I would still consider, if possible, to include a way to distinguish
betwee
Just trying out the current main branch to play with the current version
of the --ext-exit option :). Thanks for considering this, it's quite
convenient to trigger local hooks.
The cli help looks fine in the source, but it's shifted when run:
-y, --dry-run do not actually modify anythin
10 matches
Mail list logo
