[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: [EDT][PATCH 11/11] Typo fix : implemenation --> implementation
From:       Denys Vlasenko <vda.linux () googlemail ! com>
Date:       2015-05-25 12:34:46
Message-ID: CAK1hOcOHhNsS9D9CN5emU8zyaqdgC_-aDfT1xjxA0vpcK7vcJQ () mail ! gmail ! com
[Download RAW message or body]

Applied all. Thanks.

On Thu, May 21, 2015 at 5:58 AM, Maninder Singh <maninder1.s@samsung.com> wrote:
> EP-E9D7571734A347E2ADA07C4134AB97EA
> Hi,
>
> Subject: [PATCH 11/11] typo fix
>
> implemenation --> implementation
>
> Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
> Reviewed-by: Akhilesh Kumar <akhilesh.k@samsung.com>
> ---
>  e2fsprogs/old_e2fsprogs/blkid/dev.c |    2 +-
>  e2fsprogs/old_e2fsprogs/blkid/tag.c |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/e2fsprogs/old_e2fsprogs/blkid/dev.c b/e2fsprogs/old_e2fsprogs/blkid/dev.c
> index 260e49c..84b7b0a 100644
> --- a/e2fsprogs/old_e2fsprogs/blkid/dev.c
> +++ b/e2fsprogs/old_e2fsprogs/blkid/dev.c
> @@ -90,7 +90,7 @@ void blkid_debug_dump_dev(blkid_dev dev)
>   *
>   * These routines do not expose the list.h implementation, which are a
>   * contamination of the namespace, and which force us to reveal far, far
> - * too much of our internal implemenation.  I'm not convinced I want
> + * too much of our internal implementation.  I'm not convinced I want
>   * to keep list.h in the long term, anyway.  It's fine for kernel
>   * programming, but performance is not the #1 priority for this
>   * library, and I really don't like the tradeoff of type-safety for
> diff --git a/e2fsprogs/old_e2fsprogs/blkid/tag.c b/e2fsprogs/old_e2fsprogs/blkid/tag.c
> index 7424ede..f10a701 100644
> --- a/e2fsprogs/old_e2fsprogs/blkid/tag.c
> +++ b/e2fsprogs/old_e2fsprogs/blkid/tag.c
> @@ -230,7 +230,7 @@ errout:
>   *
>   * These routines do not expose the list.h implementation, which are a
>   * contamination of the namespace, and which force us to reveal far, far
> - * too much of our internal implemenation.  I'm not convinced I want
> + * too much of our internal implementation.  I'm not convinced I want
>   * to keep list.h in the long term, anyway.  It's fine for kernel
>   * programming, but performance is not the #1 priority for this
>   * library, and I really don't like the tradeoff of type-safety for
> --
> 1.7.1
>
>
> Thanks
> Maninder Singh
> _______________________________________________
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]