mirror of
https://github.com/kdave/btrfs-progs
synced 2024-12-22 14:13:04 +00:00
btrfs-progs: do interactive fixing of some ambigous typos
Typos fixed manually using the following: === Do not change lines below === { "chain": [], "cmd": "codespell -w -i 3 -C 2", "exit": 0, "extra_inputs": [], "inputs": [], "outputs": [], "pwd": "." } ^^^ Do not change lines above ^^^ Author: Yaroslav Halchenko <debian@onerussian.com> Signed-off-by: David Sterba <dsterba@suse.com>
This commit is contained in:
parent
1c710603b3
commit
5b3bb3973a
@ -56,7 +56,7 @@ as a reply to the mailinglist after you've reviewed a patch. See below.
|
||||
Reviewed-by:
|
||||
^^^^^^^^^^^^
|
||||
|
||||
The patch has been reviewed and the singed person is putting his hand into
|
||||
The patch has been reviewed and the signed person is putting his hand into
|
||||
fire. If there's a bug found in this patch, the person is usually a good
|
||||
candidate for a CC: of the bugreport.
|
||||
|
||||
@ -157,7 +157,7 @@ Controversial changes
|
||||
This happens, not every patch gets merged. In the worst case there are not even
|
||||
any comments under the patch and it's silently ignored. This depends on many
|
||||
factors, most notably \*cough*time*cough*. Examining potential drawbacks or
|
||||
forseeing disasters is not an easy job.
|
||||
foreseeing disasters is not an easy job.
|
||||
|
||||
Let's be more positive, you manage to attract the attention of some developer
|
||||
and he says, he does not like the approach of the patch(es). Better than
|
||||
|
@ -239,7 +239,7 @@ Patches
|
||||
|
||||
- additional information
|
||||
|
||||
- if there's a stack trace relevant for the patch, add it ther (lockdep,
|
||||
- if there's a stack trace relevant for the patch, add it there (lockdep,
|
||||
crash, warning)
|
||||
- steps to reproduce a bug (that will also get turned to a proper fstests
|
||||
case)
|
||||
|
@ -336,7 +336,7 @@ def print_block_groups(mountpoint):
|
||||
p_left = args_buffer_size
|
||||
|
||||
for _ in range(0, s.args.nr_items):
|
||||
# for each itme, copy the header from the buffer into
|
||||
# for each item, copy the header from the buffer into
|
||||
# our header struct
|
||||
ctypes.memmove(h, p, header_size)
|
||||
p += header_size
|
||||
|
@ -62,7 +62,7 @@ static int ext2_open_fs(struct btrfs_convert_context *cctx, const char *name)
|
||||
/*
|
||||
* We need to know exactly the used space, some RO compat flags like
|
||||
* BIGALLOC will affect how used space is present.
|
||||
* So we need manuall check any unsupported RO compat flags
|
||||
* So we need manually check any unsupported RO compat flags
|
||||
*/
|
||||
ro_feature = ext2_fs->super->s_feature_ro_compat;
|
||||
if (ro_feature & ~EXT2_LIB_FEATURE_RO_COMPAT_SUPP) {
|
||||
|
@ -194,7 +194,7 @@ static const uint32_t crc32c_table[256] = {
|
||||
};
|
||||
|
||||
/*
|
||||
* Fallback implementatin. Step through buffer one byte at at time, calculates
|
||||
* Fallback implementation. Step through buffer one byte at at time, calculates
|
||||
* reflected crc using table, can accept an unaligned buffer.
|
||||
*/
|
||||
static uint32_t crc32c_ref(uint32_t crc, unsigned char const *data, uint32_t length)
|
||||
|
Loading…
Reference in New Issue
Block a user