bup get --append should --ff when applicable

7 views
Skip to first unread message

Stefan Monnier

unread,
Mar 19, 2023, 10:24:04 AM3/19/23
to bup-...@googlegroups.com
I backup my backup with a daily `bup get` from my backup server to an
offsite host. This works well, I also occasionally backup directly to
the offsite host (and then `bup get` in the other direction), so my
script uses `--append`.

This has the undesirable side-effect that I accumulate "identical"
commits (but with different commit ids) on my offsite host since every
`bup get --append` generates a new commit id, even when it didn't
fetch anything.

Shouldn't `bup get --append` behave like `bup get --ff` when the result
would be the same (modulo commit ids)?


Stefan

Stefan Monnier

unread,
Mar 19, 2023, 1:39:53 PM3/19/23
to bup-...@googlegroups.com
> Shouldn't `bup get --append` behave like `bup get --ff` when the result
> would be the same (modulo commit ids)?

I think I wasn't thinking right. What is more important is that when
`--append` finds nothing new, it should simply do nothing (whereas
currently it creates new commits for a reason that escapes me).


Stefan

Rob Browning

unread,
Mar 22, 2023, 10:36:32 PM3/22/23
to Stefan Monnier, bup-...@googlegroups.com
"'Stefan Monnier' via bup-list" <bup-...@googlegroups.com> writes:

> I think I wasn't thinking right. What is more important is that when
> `--append` finds nothing new, it should simply do nothing (whereas
> currently it creates new commits for a reason that escapes me).

I'll have to check more carefully later, but offhand, that sounds
plausible.

Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Rob Browning

unread,
Mar 26, 2023, 2:48:15 PM3/26/23
to Stefan Monnier, bup-...@googlegroups.com
Rob Browning <r...@defaultvalue.org> writes:

> "'Stefan Monnier' via bup-list" <bup-...@googlegroups.com> writes:
>
>> I think I wasn't thinking right. What is more important is that when
>> `--append` finds nothing new, it should simply do nothing (whereas
>> currently it creates new commits for a reason that escapes me).
>
> I'll have to check more carefully later, but offhand, that sounds
> plausible.

Just to verify, you're talking about cases where the commit hashes are
differet, but the underlying tree is the same, and in that case, you'd
just like an option to skip the append, ignoring any other possible
differences (commit message, etc.).

(Assuming so, offhand, I suspect (for now) the comparison would just
apply to each incoming tree as compared (each time) to the current
destination tree.)
Reply all
Reply to author
Forward
0 new messages