OK

Greetings, I humbly solicit for your partnership to transfer €15 million Euros into your personal or company’s account .Contact me for more detailed explanation. Kindly send me the followings Full Names Address Occupation Direct Mobile Telephone Lines Nationality Ahmed Zama +22675844869

OK

Greetings, Can we discuss business here in the internet ? Contact me for more details. Ahmed Zama

OK

Greetings, I humbly solicit for your partnership to transfer €15 million Euros into your personal or company’s account .Contact me for more detailed explanation. Kindly send me the follwings Full Names Address Occupation Direct Mobile Telephone Lines Nationality Ahmed Zama +22675844869

[PATCH 5/5] fmt_with_err: add a comment that truncation is OK

Functions like die_errno() use fmt_with_err() to combine the caller-provided format with the strerror() string. We use a fixed stack buffer because we're already handling an error and don't have any way to report another one. Our buffer should generally be big enough to fit this, but if it's not,

[PATCH 1/6] test_must_fail: support ok=sigabrt

functions.sh | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh index 7d620bf2a9a..926aefd1551 100644 --- a/t/test-lib-functions.sh +++ b/t/test-lib-functions.sh @@ -616,7 +616,7 @@ list_contains () { # ok=[,<...>]: # Don'

OK

Dear Friend, Please can both of us handle a lucrative deal.?? I will give you the full detail explanation as soon as I hear from you. Faithfully yours, Mr Ahmed Zama

OK

Dear Sir, Please can both of us handle a lucrative deal.?? I will give you the full detail explanation as soon as I hear from you. Faithfully yours, Mr Ahmed Zama

OK

Dear Friend I have a Beneficial Business Project for you worth €15 million Euros. Reply me for more information. Ahmed Zama

OK

Greetings, I am desperately in need of a foreigner with a foreign account. I have a profitable business that wil be of a benefit to both of us. Permit me to disclose the details of the business to you Ahmed Zama

[PATCH 1/3] t: document 'test_must_fail ok='

uch a bug go unnoticed. - - test_might_fail + Accepts the following options: + + ok=[,<...>]: + Don't treat an exit caused by the given signal as error. + Multiple signals can be specified as a comma separated list. + Currently recognized signal names are: sigpipe, succ

Re: RFC: Design and code of partial clones (now, missing commits and trees OK)

On Tue, 26 Sep 2017 17:26:33 +0200 Michael Haggerty wrote: > Maybe naming has been discussed at length before, and I am jumping into > a long-settled topic. And admittedly this is bikeshedding. > > But I find these names obscure, even as a developer. And terms like this >

Re: RFC: Design and code of partial clones (now, missing commits and trees OK)

Jonathan Tan writes: > I've pushed a new version: > > https://github.com/jonathantanmy/git/tree/partialclone3 Just FYI, the reason why I commented only on the first patch in your previous series at GitHub wasn't because I found the others perfect and nothing to comment

Re: RFC: Design and code of partial clones (now, missing commits and trees OK)

On Fri, 15 Sep 2017 13:43:43 -0700 Jonathan Tan wrote: > For those interested in partial clones and/or missing objects in repos, > I've updated my original partialclone patches to not require an explicit > list of promises. Fetch/clone still only permits exclusion of

Re: RFC: Design and code of partial clones (now, missing commits and trees OK) (part 3)

On Tue, 26 Sep 2017 10:25:16 -0400 Jeff Hostetler wrote: > >> Perhaps you could augment the OID lookup to remember where the object > >> was found (essentially a .promisor bit set). Then you wouldn't need > >> to touch them all. > > > > Sorry - I don't understand this.

Re: RFC: Design and code of partial clones (now, missing commits and trees OK)

On 09/22/2017 12:42 AM, Jonathan Tan wrote: > On Thu, 21 Sep 2017 13:57:30 Jeff Hostetler wrote: > [...] >> I struggled with the terms here a little when looking at the source. >> () A remote responding to a partial-clone is termed a >> "promisor-remote". () Packfiles

Re: RFC: Design and code of partial clones (now, missing commits and trees OK) (part 3)

On 9/22/2017 6:58 PM, Jonathan Tan wrote: On Fri, 22 Sep 2017 17:32:00 -0400 Jeff Hostetler wrote: I guess I'm afraid that the first call to is_promised() is going cause a very long pause as it loads up a very large hash of objects. Yes, the first call will cause a

Re: RFC: Design and code of partial clones (now, missing commits and trees OK) (part 2/3)

ow its size? The client doesn't have the size. It just knows it is missing and it needs it. It doesn't matter why it is missing. (But I guess the client could assume it is because it is large.) Ah, OK. So rev-list on the client could filter the objects it has by size. My

Re: RFC: Design and code of partial clones (now, missing commits and trees OK) (part 3)

On Fri, 22 Sep 2017 17:32:00 -0400 Jeff Hostetler wrote: > I guess I'm afraid that the first call to is_promised() is going > cause a very long pause as it loads up a very large hash of objects. Yes, the first call will cause a long pause. (I think fsck and gc can

Re: RFC: Design and code of partial clones (now, missing commits and trees OK) (part 2/3)

> > > The client doesn't have the size. It just knows it is missing and it > needs it. It doesn't matter why it is missing. (But I guess the client > could assume it is because it is large.) Ah, OK. > So rev-list on the client could filter the objects it has by size. My

Re: RFC: Design and code of partial clones (now, missing commits and trees OK)

On Fri, 22 Sep 2017 17:02:11 -0400 Jeff Hostetler wrote: > > I was struggling a bit with the terminology, true. > > > > Right now I'm thinking of: > > - promisor remote (as you defined) > > - promisor packfile (as you defined) > > - promisor object is an object

Re: RFC: Design and code of partial clones (now, missing commits and trees OK) (part 3)

On 9/21/2017 7:04 PM, Jonathan Tan wrote: On Thu, 21 Sep 2017 14:00:40 -0400 Jeff Hostetler wrote: (part 3) Additional overall comments on: https://github.com/jonathantanmy/git/commits/partialclone2 {} WRT the code in is_promised() [1] [1]

Re: RFC: Design and code of partial clones (now, missing commits and trees OK) (part 2/3)

} An early draft of this type of filtering is here [3]. I hope to push up a revised draft of this shortly. [3] https://public-inbox.org/git/20170713173459.3559-1-...@jeffhostetler.com/ OK - I'll take a look when that is done (I think I commented on an earlier version on that). FYI I just posted my RF

Re: RFC: Design and code of partial clones (now, missing commits and trees OK)

low up in a second email with specific questions and comments to keep this from being too long). OK - thanks for your detailed comments. I like that git-clone saves the partial clone settings in the .git/config. This should make it easier for subsequent commands to default to the right settings.

Re: RFC: Design and code of partial clones (now, missing commits and trees OK) (part 3)

On Thu, 21 Sep 2017 14:00:40 -0400 Jeff Hostetler wrote: > (part 3) > > Additional overall comments on: > https://github.com/jonathantanmy/git/commits/partialclone2 > > {} WRT the code in is_promised() [1] > > [1] >

Re: RFC: Design and code of partial clones (now, missing commits and trees OK) (part 2/3)

decided > what to do with it. It would be difficult to add tree-trimming > at this level, for example. That is true. > {} An early draft of this type of filtering is here [3]. I hope to > push up a revised draft of this shortly. > > [3] > https://public-inbox.org/git/20170713173459.3559-1-...@jeffhostetler.com/ OK - I'll take a look when that is done (I think I commented on an earlier version on that).

Re: RFC: Design and code of partial clones (now, missing commits and trees OK)

cific questions > and comments to keep this from being too long). OK - thanks for your detailed comments. > I like that git-clone saves the partial clone settings in the > .git/config. This should make it easier for subsequent commands to > default to the right settings. > > Do w

Re: RFC: Design and code of partial clones (now, missing commits and trees OK) (part 3)

(part 3) Additional overall comments on: https://github.com/jonathantanmy/git/commits/partialclone2 {} WRT the code in is_promised() [1] [1] https://github.com/jonathantanmy/git/commit/7a9c2d9b6e2fce293817b595dee29a7eede0#diff-5d5d5dc185ef37dc30bb7d9a7ae0c4e8R1960 {} it looked like it

Re: RFC: Design and code of partial clones (now, missing commits and trees OK) (part 2/3)

(part 2) Additional overall comments on: https://github.com/jonathantanmy/git/commits/partialclone2 {} I think it would help to split the blob-max-bytes filtering and the promisor/promised concepts and discuss them independently. {} Then we can talk about about the promisor/promised

Re: RFC: Design and code of partial clones (now, missing commits and trees OK)

There's a lot in this patch series. I'm still studying it, but here are some notes and questions. I'll start with direct responses to the RFC here and follow up in a second email with specific questions and comments to keep this from being too long). On 9/15/2017 4:43 PM, Jonathan Tan wrote:

Re: RFC: Design and code of partial clones (now, missing commits and trees OK)

Jonathan Tan writes: > For those interested in partial clones and/or missing objects in repos, > I've updated my original partialclone patches to not require an explicit > list of promises. Fetch/clone still only permits exclusion of blobs, but > the infrastructure is

RFC: Design and code of partial clones (now, missing commits and trees OK)

For those interested in partial clones and/or missing objects in repos, I've updated my original partialclone patches to not require an explicit list of promises. Fetch/clone still only permits exclusion of blobs, but the infrastructure is there for a local repo to support missing trees and

Re: t7300-clean.sh fails "not ok 32 - should avoid cleaning possible submodules" on debian jessie

ble and I get this > >> error (tests upto this succeeds). > >> > >> not ok 32 - should avoid cleaning possible submodules > > > > How about re-running the script with -i -v -x? If the output is still > > not shining enough light on it, maybe you want to

Re: t7300-clean.sh fails "not ok 32 - should avoid cleaning possible submodules" on debian jessie

On 2016, ജൂൺ 7 9:16:01 PM IST, Stefan Beller wrote: >On Tue, Jun 7, 2016 at 8:43 AM, Stefan Beller >wrote: >> (Are you telling me that patch is faulty?) > >The patch is not part of v2.8.1 but part of v2.8.3, >so take a later version, or cherry-pick that

Re: t7300-clean.sh fails "not ok 32 - should avoid cleaning possible submodules" on debian jessie

On Tue, Jun 7, 2016 at 8:43 AM, Stefan Beller wrote: > (Are you telling me that patch is faulty?) The patch is not part of v2.8.1 but part of v2.8.3, so take a later version, or cherry-pick that patch manually. -- To unsubscribe from this list: send the line "unsubscribe git"

Re: t7300-clean.sh fails "not ok 32 - should avoid cleaning possible submodules" on debian jessie

http://thread.gmane.org/gmane.comp.version-control.git/293025 TL;DR: don't run tests as root, or cherry-pick cadfbef98032fbc6874b5efd70d1e33dbeb4640d (Are you telling me that patch is faulty?) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to

Re: t7300-clean.sh fails "not ok 32 - should avoid cleaning possible submodules" on debian jessie

On Tuesday 07 June 2016 04:00 PM, Johannes Schindelin wrote: > Hi Pirate Praveen, > > On Tue, 7 Jun 2016, Pirate Praveen wrote: > >> I'm trying to rebuild git 2.8.1 on debian jessie/stable and I get this >> error (tests upto this succeeds). >> >> not ok

Re: t7300-clean.sh fails "not ok 32 - should avoid cleaning possible submodules" on debian jessie

Hi Pirate Praveen, On Tue, 7 Jun 2016, Pirate Praveen wrote: > I'm trying to rebuild git 2.8.1 on debian jessie/stable and I get this > error (tests upto this succeeds). > > not ok 32 - should avoid cleaning possible submodules How about re-running the script with -i -v -x? I

t7300-clean.sh fails "not ok 32 - should avoid cleaning possible submodules" on debian jessie

Hi, I'm trying to rebuild git 2.8.1 on debian jessie/stable and I get this error (tests upto this succeeds). not ok 32 - should avoid cleaning possible submodules I added debian stretch repo to apt sources.list and ran apt-get source -b git. You can see the build options passed here http

OK DEAR

My greeting to you over there and i hope all is fine, how are you doing, please my dear i saw your profile on FB and i became interested to know more about you, and i hope it will be the same from you, please i will like you to contact me to my email so that i will tell you more about me below,(

[PATCH 5/5] t5504: drop sigpipe=ok from push tests

These were added by 8bf4bec (add "ok=sigpipe" to test_must_fail and use it to fix flaky tests, 2015-11-27) because we would racily die via SIGPIPE when the pack was rejected by the other side. But since we have recently de-flaked send-pack, we should be able to tighten up these tests

Re: [PATCH v1 2/2] add "ok=sigpipe" to test_must_fail and use it to fix flaky tests

On 28 Nov 2015, at 18:10, Jeff King wrote: > On Fri, Nov 27, 2015 at 10:15:14AM +0100, larsxschnei...@gmail.com wrote: > >> From: Lars Schneider >> >> t5516 "75 - deny fetch unreachable SHA1, allowtipsha1inwant=true" is >> flaky in the following case:

Re: [PATCH v1 2/2] add "ok=sigpipe" to test_must_fail and use it to fix flaky tests

On Fri, Nov 27, 2015 at 10:15:14AM +0100, larsxschnei...@gmail.com wrote: > From: Lars Schneider > > t5516 "75 - deny fetch unreachable SHA1, allowtipsha1inwant=true" is > flaky in the following case: > 1. remote upload-pack finds out "not our ref" > 2. remote sends a

[PATCH v1 2/2] add "ok=sigpipe" to test_must_fail and use it to fix flaky tests

ith SIGPUPE. Accept such a death-with-sigpipe also as OK when we are expecting a failure. Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> --- t/t5504-fetch-receive-strict.sh | 5 ++--- t/t5516-fetch-push.sh | 6 +++--- t/test-lib-functions.sh | 3 +++ 3 files chan

[PATCH v6 2/6] add "ok=sigpipe" to test_must_fail and use it to fix flaky tests

ith SIGPUPE. Accept such a death-with-sigpipe also as OK when we are expecting a failure. Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> --- t/t5504-fetch-receive-strict.sh | 3 +-- t/t5516-fetch-push.sh | 6 +++--- t/test-lib-functions.sh | 4 3 files chan

[PATCH v5 2/6] add "ok=sigpipe" to test_must_fail and use it to fix flaky tests

ith SIGPUPE. Accept such a death-with-sigpipe also as OK when we are expecting a failure. Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> --- t/t5504-fetch-receive-strict.sh | 3 +-- t/t5516-fetch-push.sh | 6 +++--- t/test-lib-functions.sh | 4 3 files chan

`-u`/`update-head-ok` unsupported on pull

According to the documentation these options are supported: $ git help pull | grep -e '--update-head-ok' -u, --update-head-ok However: $ git pull --update-head-ok error: unknown option `update-head-ok' Using: $ git --version git version 2.6.1 $ pacman --query --info git | grep ^Version

Re: `-u`/`update-head-ok` unsupported on pull

+Paul Tan who rewrote git pull in C recently. The manpage: -u, --update-head-ok By default git fetch refuses to update the head which corresponds to the current branch. This flag disables the check. This is purely for the internal use for git pull to communicate with git

Re: [PATCH] fsck: it is OK for a tag and a commit to lack the body

Hi Junio, On 2015-06-29 07:42, Junio C Hamano wrote: Johannes Schindelin johannes.schinde...@gmx.de writes: Hmm. Maybe we should still warn when there is no empty line finishing the header explicitly, or at least make it FSCK_IGNORE by default so that maintainers who like a stricter check

Re: [PATCH] fsck: it is OK for a tag and a commit to lack the body

On Sun, Jun 28, 2015 at 2:18 PM, Junio C Hamano gits...@pobox.com wrote: When fsck validates a commit or a tag object, it scans each line in the header the object using helper functions such as start_with(), s/header/ of/ etc. that work on a NUL terminated buffer, but before a1e920a0

[PATCH] fsck: it is OK for a tag and a commit to lack the body

When fsck validates a commit or a tag object, it scans each line in the header the object using helper functions such as start_with(), etc. that work on a NUL terminated buffer, but before a1e920a0 (index-pack: terminate object buffers with NUL, 2014-12-08), the validation functions were fed the

Re: [PATCH] fsck: it is OK for a tag and a commit to lack the body

Johannes Schindelin johannes.schinde...@gmx.de writes: +/* + * We did not find double-LF that separates the header + * and the body. Not having a body is not a crime but + * we do want to see the terminating LF for the last header + * line. + */ +if (size

Re: [PATCH] fsck: it is OK for a tag and a commit to lack the body

Hi Junio, On 2015-06-28 20:18, Junio C Hamano wrote: diff --git a/fsck.c b/fsck.c index 88c92e8..3f264e7 100644 --- a/fsck.c +++ b/fsck.c @@ -255,6 +255,15 @@ static int require_end_of_header(const void *data, unsigned long size, } } + /* + * We did not

[PATCH 2/2] Revert test-lib: allow prefixing a custom string before ok N etc.

}ok $test_count - $@ + say_color ok $test_count - $@ } test_failure_ () { test_failure=$(($test_failure + 1)) - say_color error ${statusprefix}not ok $test_count - $1 + say_color error not ok $test_count - $1 shift echo $@ | sed -e 's

[PATCH v4 7/8] test-lib: allow prefixing a custom string before ok N etc.

@@ -316,12 +319,12 @@ trap 'die' EXIT test_ok_ () { test_success=$(($test_success + 1)) - say_color ok $test_count - $@ + say_color ${statusprefix}ok $test_count - $@ } test_failure_ () { test_failure=$(($test_failure + 1)) - say_color error not ok $test_count

[PATCH v3 7/8] test-lib: allow prefixing a custom string before ok N etc.

@@ -316,12 +319,12 @@ trap 'die' EXIT test_ok_ () { test_success=$(($test_success + 1)) - say_color ok $test_count - $@ + say_color ${statusprefix}ok $test_count - $@ } test_failure_ () { test_failure=$(($test_failure + 1)) - say_color error not ok $test_count

[PATCH v2 5/6] test-lib: allow prefixing a custom string before ok N etc.

@@ -316,12 +319,12 @@ trap 'die' EXIT test_ok_ () { test_success=$(($test_success + 1)) - say_color ok $test_count - $@ + say_color ${statusprefix}ok $test_count - $@ } test_failure_ () { test_failure=$(($test_failure + 1)) - say_color error not ok $test_count

Re: [PATCH 5/6] test-lib: allow prefixing a custom string before ok N etc.

or for your use-case, but placing this prefix before the {ok,not ok} breaks the TAProtocol. http://podwiki.hexten.net/TAP/TAP.html?page=TAP Maybe you can put the prefix _after_ the {ok, not ok} and test number. Actually that was half on purpose. You will notice I did not document that option

Re: [PATCH 5/6] test-lib: allow prefixing a custom string before ok N etc.

and the main run. Maybe we do not care about standards for this library or for your use-case, but placing this prefix before the {ok,not ok} breaks the TAProtocol. http://podwiki.hexten.net/TAP/TAP.html?page=TAP Maybe you can put the prefix _after_ the {ok, not ok} and test number. Actually

[PATCH 5/6] test-lib: allow prefixing a custom string before ok N etc.

[^=]*=\(.*\)') + shift ;; *) echo error: unknown test option '$1' 2; exit 1 ;; esac @@ -316,12 +319,12 @@ trap 'die' EXIT test_ok_ () { test_success=$(($test_success + 1)) - say_color ok $test_count - $@ + say_color ${statusprefix}ok $test_count

[PATCH v7 1/7] tests: test number comes first in 'not ok $count - $message'

From: Adam Spiers g...@adamspiers.org The old output to say not ok - 1 messsage was working by accident only because the test numbers are optional in TAP. Signed-off-by: Adam Spiers g...@adamspiers.org Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t-basic.sh | 4 ++-- t/test-lib.sh

[PATCH v6 1/7] tests: test number comes first in 'not ok $count - $message'

The old output to say not ok - 1 messsage was working by accident only because the test numbers are optional in TAP. Signed-off-by: Adam Spiers g...@adamspiers.org --- t/t-basic.sh | 4 ++-- t/test-lib.sh| 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/t/t

[PATCH 1/2] config, gitignore: failure to access with ENOTDIR is ok

/.config/git/config': Not a directory warning: unable to access '/home/jrn/.config/git/config': Not a directory warning: unable to access '/home/jrn/.config/git/config': Not a directory Compare v1.7.12.1~2^2 (attr:failure to open a .gitattributes file is OK with ENOTDIR, 2012-09-13). Signed-off

Re: [PATCH v2 2/6] Make 'not ok $count - $message' consistent with 'ok $count - $message'

On Wed, Sep 19, 2012 at 06:15:11PM +0100, Adam Spiers wrote: test_failure_ () { test_failure=$(($test_failure + 1)) - say_color error not ok - $test_count $1 + say_color error not ok $test_count - $1 Interesting. I wondered what TAP had to say about this, and in fact we were

[Blackfin] arch: Fix BUG - Enable ISP1362 driver to work ok with BF561

: Sat Feb 2 15:10:51 2008 +0800 Committer: Bryan Wu [EMAIL PROTECTED] CommitDate: Sat Feb 2 15:10:51 2008 +0800 [Blackfin] arch: Fix BUG - Enable ISP1362 driver to work ok with BF561 This fixes a bug (zero pointer access) only seen on BF561, during USB Mass Storage/SCSI Host

email-clients.txt: sylpheed is OK at IMAP

Feb 7 00:13:42 2008 -0800 Committer: Linus Torvalds [EMAIL PROTECTED] CommitDate: Thu Feb 7 08:42:17 2008 -0800 email-clients.txt: sylpheed is OK at IMAP This comment is not helpful (no reason given) and is incorrect. Just stick to facts that are useful regarding working on Linux

x86 setup: OK - ok (no need to scream)

: Wed Jan 30 13:33:03 2008 +0100 Committer: Ingo Molnar [EMAIL PROTECTED] CommitDate: Wed Jan 30 13:33:03 2008 +0100 x86 setup: OK - ok (no need to scream) Unnecessary capitals are shouting; no need for it here. Thus, change OK to ok and add a space. Signed-off-by: H. Peter

[MIPS] Only build r4k clocksource for systems that work ok with it.

Nov 24 22:33:28 2007 + Committer: Ralf Baechle [EMAIL PROTECTED] CommitDate: Mon Nov 26 17:26:14 2007 + [MIPS] Only build r4k clocksource for systems that work ok with it. In particular as-is it's not suited for multicore and mutiprocessors systems where

[POWERPC] pseries: device node status can be ok or okay

: Fri Aug 10 09:27:00 2007 +1000 Committer: Paul Mackerras [EMAIL PROTECTED] CommitDate: Tue Oct 2 22:09:56 2007 +1000 [POWERPC] pseries: device node status can be ok or okay It seems that some versions of firmware will report a device node status as the string okay. As we

make powerpc BUG_ON() OK with pointers and bitwise

26 17:35:49 2007 +0100 Committer: Linus Torvalds [EMAIL PROTECTED] CommitDate: Thu Jul 26 11:11:57 2007 -0700 make powerpc BUG_ON() OK with pointers and bitwise Since powerpc insists on printing the _value_ of condition and on casting it to long... At least let's make it a force

docs: static initialization of spinlocks is OK

Jul 15 23:41:50 2007 -0700 Committer: Linus Torvalds [EMAIL PROTECTED] CommitDate: Mon Jul 16 09:05:52 2007 -0700 docs: static initialization of spinlocks is OK Static initialization of spinlocks is preferable to dynamic initialization when it is practical. This patch updates

[PATCH 3/4] add --missing-ok option to write-tree

Add --missing-ok option to git-write.tree. This option allows a write-tree even if the referenced objects are not in the database. Signed-off-by: Bryan Larsen [EMAIL PROTECTED] --- diff --git a/Documentation/git-write-tree.txt b/Documentation/git-write-tree.txt --- a/Documentation/git-write

[PATCH 4/4] switch cg-commit -N to use --missing-ok instead of --no-check

Make cg-commit aware of the rename of git-write-tree --no-check to --missing-ok. Signed-off-by: Bryan Larsen [EMAIL PROTECTED] --- diff --git a/cg-commit b/cg-commit --- a/cg-commit +++ b/cg-commit @@ -111,13 +111,13 @@ forceeditor= ignorecache= infoonly= commitalways= -nocheck= +missingok

Errors received during git pull from linux-2.6.git, but resulting kernel looks OK.

|1 4622 files changed, 271839 insertions(+), 156792 deletions(-) Despite the errors from the git pull, the files look OK. Steven - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org

Re: Errors received during git pull from linux-2.6.git, but resulting kernel looks OK.

Dear diary, on Thu, Apr 21, 2005 at 03:55:26PM CEST, I got a letter where Steven Cole [EMAIL PROTECTED] told me that... Executive summary: I received some alarming errors while doing a git pull of the latest kernel from kernel.org, but it appears that all is well. Continue reading for the gory