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 a
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 ?
This applies not just to the messag
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. For example,
>
>
> git log -
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 to
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 like
> >
> > fat
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 you
>> need to reset the counter, or the repos
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 for anyone? I'd feel be
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 the original commit 067fbd
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 that option" made me
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 &&
> test_commit 410 &&
>
> T
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, even when the
>> repository is cold and not
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: Stefan Beller
> ---
>
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' meaning in another tes
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 --recurse-submodules will update the co
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 existing packfile corruption te
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 to learn from? e.g.
>>
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 marked relies on hard co
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
./t1001-read
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 st
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 co
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
>> it as well; at least, it may m
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 guys.
>
> This pat
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 Philippe,
I am not quite certai
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 I'd recommend is that instead o
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 (repository_format_lazy
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 user
operates mostly on par
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 Story
27 matches
Mail list logo
