DO GET BACK IF INTERESTED!!

Hello I am Mr Micheal Lennings , an Auditor Officer, PNC bank here in U.S.A. I believe it is the wish of God for me to come across you now. I have been in search of someone with this last name ,so when I saw you online, I was pushed to contact you and see how best we can assist each other. I

Re: Guidlines for error messages

Kaartic Sivaraam writes: > On reading the CodingGuidelines, I saw a section that specifies rules > about the structure ... > ... > That makes me wonder, has the guideline changed ? > Is this something that must be fixed ? > Am I missing something ?

Re: [PATCH/RFC] setup: update error message to be more meaningful

Kaartic Sivaraam writes: > Though the message seems to be most fitting one, I'm a little reluctant > to use it as it "might" create a wrong picture on the minds of the user > making them think this would be the case in other cases too, which we > know is not true.

Guidlines for error messages

Hello all, On reading the CodingGuidelines, I saw a section that specifies rules about the structure and formatting of error messages. I have reproduced it below, Error Messages  - Do not end error messages with a full stop.  - Do not capitalize ("unable to open %s", not "Unable

Re: [PATCH/RFC] setup: update error message to be more meaningful

On Wed, 2017-07-26 at 13:09 -0700, Junio C Hamano wrote: > Jonathan Nieder writes: > > > For an initial guess: in the example > > > > git grep test -n > > > > ... > > 2. Focus on "argument" instead of "filename" so that the message > > could still apply: something

Re: reftable [v3]: new ref storage format

On Fri, Jul 28, 2017 at 7:18 PM, Michael Haggerty wrote: > On Fri, Jul 28, 2017 at 3:12 PM, Shawn Pearce wrote: >> I'm with you this far, and like the {min,max}_update_index in the >> header. I'm concerned about update_index in 32 bits. At some point

Re: reftable [v3]: new ref storage format

On Fri, Jul 28, 2017 at 3:12 PM, Shawn Pearce wrote: > I'm with you this far, and like the {min,max}_update_index in the > header. I'm concerned about update_index in 32 bits. At some point you > need to reset the counter, or the repository is broken. 4b updates is > enough

Re: [RFC PATCH 1/4] environment, fsck: introduce lazyobject extension

Jonathan Tan writes: >> > extern int repository_format_precious_objects; >> > +extern char *repository_format_lazy_object; >> >> This is not a new problem, but I think these two should be >> called repository_extension_$NAME not repository_format_$NAME. > > Looking at

Re: [RFC PATCH 1/4] environment, fsck: introduce lazyobject extension

On Thu, 27 Jul 2017 11:55:46 -0700 Junio C Hamano wrote: > My reading hiccupped after the first sentence, as the problem > description made it sound like this was a boolean ("are we using > lazy object feature?"), after reading "data type string". And then > "the command in

Re: [PATCH 2/2] t6500: mark tests as SHA1 reliant

Stefan Beller writes: > The first test marked relies on hard coded sha1: > > # We need to create two object whose sha1s start with 17 > # since this is what git gc counts. As it happens, these > # two blobs will do so. > test_commit 263 && >

Re: reftable [v3]: new ref storage format

On Thu, Jul 27, 2017 at 7:28 AM, Michael Haggerty wrote: > On Sat, Jul 22, 2017 at 11:29 AM, Shawn Pearce wrote: >> 3rd iteration of the reftable storage format. >> >> [...] >> ### Objectives >> >> - Near constant time lookup for any single reference,

Re: [PATCH 1/2] alter hash function: expose test dependencies on sha1

Stefan Beller writes: > DO NOT APPLY. > > Alter the hash function such that with this patch > any dependency on sha1 in tests will make the test > fail. This patch applied on master yields this list: > > ./t-basic.sh > > ./t8008-blame-formats.sh > > Signed-off-by:

Re: [PATCH 2/2] t6500: mark tests as SHA1 reliant

On Fri, Jul 28, 2017 at 10:59 AM, Junio C Hamano wrote: > There is another one that is better suited for this demonstration patch, > whose sole point is about creating bunch of objects that prefix conflicts > with each other to test the abbreviation machinery. 'Another one'

[PATCH] Documentation/checkout: clarify submodule HEADs to be detached

Signed-off-by: Stefan Beller --- On top of sb/submodule-recursive-checkout-detach-head I also checked other man pages such as read-tree, which already mentions the behavior as the fix implements: --[no-]recurse-submodules Using

[PATCH] tests: ensure fsck fails on corrupt packfiles

t1450-fsck.sh does not have a test that checks fsck's behavior when a packfile is invalid. It does have a test for when an object in a packfile is invalid, but in that test, the packfile itself is valid. Add such a test. Signed-off-by: Jonathan Tan --- I think the

Re: [PATCH v2] contrib/rerere-train: optionally overwrite existing resolutions

On 26/07/17 04:41 PM, Junio C Hamano wrote: > Raman Gupta writes: > >> On 26/07/17 02:05 PM, Junio C Hamano wrote: >>> I haven't tried this patch, but would this work well with options >>> meant for the 'git rev-list --parents "$@"' that grabs the list of >>> merge commits

Re: [PATCH 2/2] t6500: mark tests as SHA1 reliant

There is another one that is better suited for this demonstration patch, whose sole point is about creating bunch of objects that prefix conflicts with each other to test the abbreviation machinery. On Fri, Jul 28, 2017 at 10:18 AM, Stefan Beller wrote: > The first test

[PATCH 1/2] alter hash function: expose test dependencies on sha1

DO NOT APPLY. Alter the hash function such that with this patch any dependency on sha1 in tests will make the test fail. This patch applied on master yields this list: ./t-basic.sh ./t0002-gitfile.sh ./t0005-signals.sh ./t0013-sha1dc.sh ./t0021-conversion.sh ./t0090-cache-tree.sh

[PATCH 2/2] t6500: mark tests as SHA1 reliant

The first test marked relies on hard coded sha1: # We need to create two object whose sha1s start with 17 # since this is what git gc counts. As it happens, these # two blobs will do so. test_commit 263 && test_commit 410 && The next two seem to rely on

[RFD PATCH 0/2] How to migrate our test infrastructure away from sha1

Brian got the ball rolling with his object-id patches to fixup the code base, but we also need to discuss how we approach our test infrastructure eventually. C.f.: * jb/t8008-cleanup (2017-07-26) 1 commit - t8008: rely on rev-parse'd HEAD instead of sha1 value * sb/t4005-modernize (Remove hard

Re: [PATCH] hash: Allow building with the external sha1dc library

On Fri, Jul 28, 2017 at 5:58 PM, Ævar Arnfjörð Bjarmason wrote: > On Tue, Jul 25, 2017 at 7:57 AM, Takashi Iwai wrote: >> Some distros provide SHA1 collision detect code as a shared library. >> It's the very same code as we have in git tree, and git can link with

Re: [PATCH] hash: Allow building with the external sha1dc library

On Tue, Jul 25, 2017 at 7:57 AM, Takashi Iwai wrote: > Some distros provide SHA1 collision detect code as a shared library. > It's the very same code as we have in git tree, and git can link with > it as well; at least, it may make maintenance easier, according to our > security

Re: requesting permission to use some Git for Windows code

Ditto, on any of my portions, if any left :) -- .marius On 7/28/2017 00:31, Brandon Casey wrote: Hi Philippe, Please feel free to use my portions of the mentioned works under the GPLv3. -Brandon On Tue, Jul 25, 2017 at 6:53 AM, Johannes Schindelin wrote: Hi

Re: [RFC PATCH 0/4] Some patches for fsck for missing objects

On 7/27/2017 1:25 PM, Jonathan Tan wrote: On Wed, 26 Jul 2017 23:42:38 + "brian m. carlson" wrote: I looked at this and I like the direction it's going. It's pretty simple and straightforward, which I also like. ditto, simple is good! Thanks. What

Re: [RFC PATCH 2/4] fsck: support refs pointing to lazy objects

On 7/27/2017 7:50 PM, Jonathan Tan wrote: On Thu, 27 Jul 2017 11:59:47 -0700 Junio C Hamano wrote: @@ -438,6 +438,14 @@ static int fsck_handle_ref(const char *refname, const struct object_id *oid, obj = parse_object(oid); if (!obj) { + if

Re: [RFC PATCH 1/4] environment, fsck: introduce lazyobject extension

On 7/27/2017 2:55 PM, Junio C Hamano wrote: Jonathan Tan writes: Currently, Git does not support repos with very large numbers of objects or repos that wish to minimize manipulation of certain blobs (for example, because they are very large) very well, even if the

Dear Talented

Dear Talented, I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue Sky Studio a Film Corporation Located in the United State, is Soliciting for the Right to use Your Photo/Face and Personality as One of the Semi -Major Role/ Character in our Upcoming ANIMATED Stereoscope 3D Movie-The

Re: [PATCH] packed_ref_store: handle a packed-refs file that is a symlink

On Thu, Jul 27, 2017 at 12:40 PM, Junio C Hamano wrote: > Jeff King writes: > >> On Thu, Jul 27, 2017 at 10:19:48AM -0700, Junio C Hamano wrote: >> >>> Makes sense. Makes me wonder why we need a separate .new file >>> (instead of writing into the .lock