After sending v1 some days ago, some onlist and offlist discussion has
brought us to the following conclusions:
- we should fix it as soon as possible
- we should stick to the -p option (parent)
- we should rename the -i option (because it actually means
"clone source")
This is what v2 of this patch set is doing, besides fixing one and a
half bugs along the way: We turn -i into -c, emitting a fatal warning
should anybody use -i. As argued in the v1 cover letter, we should
really do this change now in order to avoid a lot of confused users that
"btrfs send -i" is doing things differently in a subtle way from what
"zfs send -i" is doing. We're better off coming up with our own
terminology, thus offering -p and -c options (both can be used to ask
for an incremental send stream, see the usage changes in patch 1),
without providing a "send -i" option at all.
Jan Schmidt (2):
Btrfs-progs: correcting misnamed parameter options for btrfs send
Btrfs-progs: bugfix for subvolume parent determination in btrfs send
cmds-send.c | 74 +++++++++++++++++++++++++++++++++-------------------------
send-utils.c | 4 +-
2 files changed, 44 insertions(+), 34 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
