[PATCH 0/3] Fix typos

[Rob Browning]

Thanks for the help. Redirected to bup-list as-per HACKING from pull
request https://github.com/bup/bup/pull/35

bedhanger (3):
README.md: poem: fix typo ``teh'' -> ``the''
DESIGN: resolve duplicates: ``to to'' & ``and and''
DESIGN: remove surplus ``relevant''

DESIGN | 6 +++---
README.md | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)

--
2.15.1

[Rob Browning]

From: bedhanger <bedh...@gmx.de>

Signed-off-by: bedhanger <bedh...@gmx.de>
---
README.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index 82c50df8..a3dea129 100644
--- a/README.md
+++ b/README.md
@@ -8,7 +8,7 @@ this time? Me neither.
Despite its unassuming name, bup is pretty cool. To give you an idea of
just how cool it is, I wrote you this poem:

- Bup is teh awesome
+ Bup is the awesome
What rhymes with awesome?
I guess maybe possum
But that's irrelevant.
--
2.15.1

[Rob Browning]

From: bedhanger <bedh...@gmx.de>

Signed-off-by: bedhanger <bedh...@gmx.de>
---

DESIGN | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/DESIGN b/DESIGN
index 97dc96d5..f825cd7e 100644
--- a/DESIGN
+++ b/DESIGN
@@ -196,7 +196,7 @@ sequence data.
As an overhead percentage, 0.25% basically doesn't matter. 488 megs sounds
like a lot, but compared to the 200GB you have to store anyway, it's
irrelevant. What *is* relevant is that 488 megs is a lot of memory you have
-to use in order to to keep track of the list. Worse, if you back up an
+to use in order to keep track of the list. Worse, if you back up an
almost-identical file tomorrow, you'll have *another* 488 meg blob to keep
track of, and it'll be almost but not quite the same as last time.

@@ -374,7 +374,7 @@ So that's the basic structure of a bup repository, which is also a git
repository. There's just one more thing we have to deal with:
filesystem metadata. Git repositories are really only intended to
store file contents with a small bit of extra information, like
-symlink targets and and executable bits, so we have to store the rest
+symlink targets and executable bits, so we have to store the rest
some other way.

Bup stores more complete metadata in the VFS in a file named .bupm in
--
2.15.1

[Rob Browning]

From: bedhanger <bedh...@gmx.de>

Signed-off-by: bedhanger <bedh...@gmx.de>
---

DESIGN | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/DESIGN b/DESIGN
index f825cd7e..e8aa8d08 100644
--- a/DESIGN
+++ b/DESIGN
@@ -548,7 +548,7 @@ the index and backs up any file that is "dirty," that is, doesn't already
exist in the repository.

Determination of dirtiness is a little more complicated than it sounds. The
-most dirtiness-relevant relevant flag in the bupindex is IX_HASHVALID; if
+most dirtiness-relevant flag in the bupindex is IX_HASHVALID; if
this flag is reset, the file *definitely* is dirty and needs to be backed
up. But a file may be dirty even if IX_HASHVALID is set, and that's the
confusing part.
--
2.15.1

[Rob Browning]

Rob Browning <r...@defaultvalue.org> writes:

> index 82c50df8..a3dea129 100644
> --- a/README.md
> +++ b/README.md
> @@ -8,7 +8,7 @@ this time? Me neither.
> Despite its unassuming name, bup is pretty cool. To give you an idea of
> just how cool it is, I wrote you this poem:
>
> - Bup is teh awesome
> + Bup is the awesome
> What rhymes with awesome?
> I guess maybe possum
> But that's irrelevant.

I believe this bit was intentional on Avery's part, but the other
patches look good. I'll merge them in a bit.

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]

Pushed to master.

[Rob Browning]