Igor Djordjevic writes:
> On 15/03/2018 00:11, Igor Djordjevic wrote:
>>
>> > > > Second side note: if we can fast-forward, currently we prefer
>> > > > that, and I think we should keep that behavior with -R, too.
>> > >
>> > > I agree.
>> >
>> > I'm admittedly
On Sun, Mar 18, 2018 at 10:50 PM, Dan Jacques wrote:
> Currently, the generated Perl script headers are emitted by commands in
> the Makefile. This mechanism restricts options to introduce alternative
> header content, needed by Perl runtime prefix support, and obscures the
>
Add a new Makefile flag, RUNTIME_PREFIX_PERL, which, when enabled,
configures Perl scripts to locate the Git installation's Perl support
libraries by resolving against the script's path, rather than
hard-coding that path at build-time.
RUNTIME_PREFIX_PERL requires that system paths are expressed
Currently, the generated Perl script headers are emitted by commands in
the Makefile. This mechanism restricts options to introduce alternative
header content, needed by Perl runtime prefix support, and obscures the
origin of the Perl script header.
Change the Makefile to generate a header by
Enable Git to resolve its own binary location using a variety of
OS-specific and generic methods, including:
- procfs via "/proc/self/exe" (Linux)
- _NSGetExecutablePath (Darwin)
- KERN_PROC_PATHNAME sysctl on BSDs.
- argv0, if absolute (all, including Windows).
This is used to enable
This patch set expands support for the RUNTIME_PREFIX configuration flag,
currently only used on Windows builds, to include Linux, Darwin, and
FreeBSD. When Git is built with RUNTIME_PREFIX enabled, it resolves its
ancillary paths relative to the runtime location of its executable
rather than
Hi Dear, my name is Jack and i am seeking for a relationship in which i will
feel loved after a series of failed relationships.
I am hoping that you would be interested and we could possibly get to know each
other more if you do not mind. I am open to answering questions from you as i
think
On Sun, Mar 18, 2018 at 11:41 PM, Jacob Keller wrote:
>
> I don't have a good summary yet, but I think a section about the
> discussion regarding the new recreate-merges and rebasing merges
> that's been on going might be useful?
Yeah sure, we would gladly accept a
On Sun, Mar 18, 2018 at 7:49 PM, kalle wrote:
> 1.I wonder, why the "user-manual" is so hidden on the (official?) site
> git-scm.com [it is accessible at git-scm.com/docs/user-manual ,but is
> not viewable in /docs ]
The git-scm.com website is maintained as a distinct
hello,
1.I wonder, why the "user-manual" is so hidden on the (official?) site
git-scm.com [it is accessible at git-scm.com/docs/user-manual ,but is
not viewable in /docs ]
2.I did not receive an answer to my mail. Maybe it could have to do with
a possible stopped maintainment of the
Hello
Greetings to you and everyone around you please did you get my previous email
regarding my proposal ?
please let me know if we can work together on this.
Best Reagrds
Melisa Mehmet
Andreas Heiduk wrote:
> The email address in --authors-file and --authors-prog can be empty but
> git-svn translated it into a syntethic email address in the form
> $USERNAME@$REPO_UUID. Now git-svn behaves like git-commit: If the email
> is explicitly set to the empty string,
On Thu, Mar 15, 2018 at 12:44 PM, Nguyễn Thái Ngọc Duy
wrote:
> v2 fixes comments from Eric and rebases on 'master' since 'worktree
> move' has been merged. Commit messages are updated to reflect this.
Thanks. Aside from a couple minor commit message tweaks (not worth a
On Thu, Mar 15, 2018 at 12:44 PM, Nguyễn Thái Ngọc Duy
wrote:
> Automatic detection of worktree relocation by a user (via 'mv', for
> instance) was removed by 618244e160 (worktree: stop supporting moving
> worktrees manually - 2016-01-22). Prior to that,
>
On Thu, Mar 15, 2018 at 12:44 PM, Nguyễn Thái Ngọc Duy
wrote:
> This "link" was a feature in early iterations of multiple worktree
> functionality for some reason it was dropped [1]. Since nobody creates
> this "link", there's no need to check it.
>
> This is mostly used to let
On Sun, Mar 18, 2018 at 11:21 AM, Christian Couder
wrote:
> Hi,
>
> A draft of a new Git Rev News edition is available here:
>
>
> https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-37.md
>
> Everyone is welcome to contribute in any section
Hello,
I am interested in the "Convert scripts to builtins" project. I have
recently started to analyze it better and see exactly what it entails
and a few questions came to my mind.
First of all, I find it difficult to pick which scripts would benefit
the most by being rewritten. I am thinking
On Sun, Mar 18, 2018 at 5:19 PM, Andreas Heiduk wrote:
> No comments on this one?
I can't speak for Eric W., but my impression was that v2 did not
address his concern that patch 2/2's unconditional change of behavior
was unacceptable[1]. He didn't say so explicitly, but
No comments on this one?
--
Hello Dear
Am a dying woman here in the hospital, i was diagnose as a cancer
patient 2 years ago. I am from (Zarqa) Jordan, a business woman
dealing with Gold Exportation. I have a charitable and unfufilment
project that am about to handover to you, if you are interested please
reply
* Junio C Hamano [2018-02-07T11:49:39-0800]:
> Stefan Moch writes:
>
> > * Jonathan Nieder [2017-12-15T17:31:30-0800]:
> >> This sounds like a reasonable thing to add. See builtin/mv.c for
> >> how "git mv" works if you're looking
On Fri, Mar 16, 2018 at 10:29 PM, Jeff King wrote:
> On Fri, Mar 16, 2018 at 09:01:42PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> One thing that can make repositories very pathological is if the ratio
>> of trees to commits is too low.
>>
>> I was dealing with a repo the other day
On 18/03/18 15:55, Duy Nguyen wrote:
> On Sun, Mar 18, 2018 at 9:18 AM, Nguyễn Thái Ngọc Duy
> wrote:
>> +ifneq ($(or $(filter gcc6,$(COMPILER_FEATURES)),$(filter
>> clang4,$(COMPILER_FEATURES))),)
>> +CFLAGS += -Wextra
>
> Another thing we can add here is -Og instead of
Hi,
A draft of a new Git Rev News edition is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-37.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this GitHub
Dear Sir/Ma’am,
We are an Online Marketing Group, comprising young and dynamic professionals.
We have executed a number of projects in the below mentioned categories:
Website Design & Development
PHP & MySQL website application development
E-Commerce Applications/ Websites
We Specialize in
On Sun, Mar 18, 2018 at 9:18 AM, Nguyễn Thái Ngọc Duy wrote:
> +ifneq ($(or $(filter gcc6,$(COMPILER_FEATURES)),$(filter
> clang4,$(COMPILER_FEATURES))),)
> +CFLAGS += -Wextra
Another thing we can add here is -Og instead of standard -O2 (or -O0
in my build), which is
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
On Sun, Mar 18 2018, Nguyễn Thái Ngọc Duy jotted:
> v6 fixes the one optimization that I just couldn't get right, fixes
> two off-by-one error messages and a couple commit message update
> (biggest change is in 11/11 to record some numbers from AEvar)
Thanks, aside from the minor typo I just
On Sun, Mar 18 2018, Nguyễn Thái Ngọc Duy jotted:
> It's very very rare that an uncompressedd object is larger than 4GB
So this went from a typo of "uncompressd" in v5 to "uncompressedd",
needs one less "d": "uncompressed".
Instead of using 8 bytes (on 64 bit arch) to store a pointer to a
pack. Use an index instead since the number of packs should be
relatively small.
This limits the number of packs we can handle to 16k. For now if you hit
16k pack files limit, pack-objects will simply fail [1].
[1] The escape
We only cache deltas when it's smaller than a certain limit. This limit
defaults to 1000 but save its compressed length in a 64-bit field.
Shrink that field down to 16 bits, so you can only cache 65kb deltas.
Larger deltas must be recomputed at when the pack is written down.
Signed-off-by: Nguyễn
Because of struct packing from now on we can only handle max depth
4095 (or even lower when new booleans are added in this struct). This
should be ok since long delta chain will cause significant slow down
anyway.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
It's very very rare that an uncompressedd object is larger than 4GB
(partly because Git does not handle those large files very well to
begin with). Let's optimize it for the common case where object size
is smaller than this limit.
Shrink size field down to 32 bits [1] and one overflow bit. If
This field is only need for pack-bitmap, which is an optional
feature. Move it to a separate array that is only allocated when
pack-bitmap is used (it's not freed in the same way that objects[] is
not).
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/pack-objects.c | 3 ++-
Allowing a delta size of 64 bits is crazy. Shrink this field down to
31 bits with one overflow bit.
If we find an existing delta larger than 2GB, we do not cache
delta_size at all and will get the value from oe_size(), potentially
from disk if it's larger than 4GB.
Signed-off-by: Nguyễn Thái
Previous patches leave lots of holes and padding in this struct. This
patch reorders the members and shrinks the struct down to 80 bytes
(from 136 bytes, before any field shrinking is done) with 16 bits to
spare (and a couple more in in_pack_header_size when we really run out
of bits).
This is
These delta pointers always point to elements in the objects[] array
in packing_data struct. We can only hold maximum 4G of those objects
because the array size in nr_objects is uint32_t. We could use
uint32_t indexes to address these elements instead of pointers. On
64-bit architecture (8 bytes
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/pack-objects.c | 3 +++
pack-objects.h | 28 +---
2 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 647c01ea34..83f8154865
An extra field type_valid is added to carry the equivalent of OBJ_BAD
in the original "type" field. in_pack_type always contains a valid
type so we only need 3 bits for it.
A note about accepting OBJ_NONE as "valid" type. The function
read_object_list_from_stdin() can pass this value [1] and it
v6 fixes the one optimization that I just couldn't get right, fixes
two off-by-one error messages and a couple commit message update
(biggest change is in 11/11 to record some numbers from AEvar)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index fb2aba80bf..4406af640f 100644
---
The role of this comment block becomes more important after we shuffle
fields around to shrink this struct. It will be much harder to see what
field is related to what.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
pack-objects.h | 45 +
On Wed, Mar 14 2018, Derrick Stolee jotted:
> +'git commit-graph write' [--object-dir ]
> +
> +
> +DESCRIPTION
> +---
> +
> +Manage the serialized commit graph file.
> +
> +
> +OPTIONS
> +---
> +--object-dir::
> + Use given directory for the location of packfiles and commit
Hi Dear, my name is Jack and i am seeking for a relationship in which i will
feel loved after a series of failed relationships.
I am hoping that you would be interested and we could possibly get to know each
other more if you do not mind. I am open to answering questions from you as i
think
On Sun, Mar 18, 2018 at 10:26 AM, Jeff King wrote:
> On Sun, Mar 18, 2018 at 09:18:34AM +0100, Nguyễn Thái Ngọc Duy wrote:
>
>> The set of extra warnings we enable when DEVELOPER has to be
>> conservative because we can't assume any compiler version the
>> developer may use. Detect
On Sun, Mar 18, 2018 at 5:28 AM, Jeff King wrote:
> On Sun, Mar 18, 2018 at 05:06:07AM -0400, Eric Sunshine wrote:
>> On MacOS, "cc -v" output is:
>> --- >8 ---
>> Apple LLVM version 9.0.0 (clang-900.0.39.2)
>> Target: x86_64-apple-darwin16.7.0
>> Thread model: posix
>>
On Sun, Mar 18, 2018 at 05:06:07AM -0400, Eric Sunshine wrote:
> On MacOS, "cc -v" output is:
>
> --- >8 ---
> Apple LLVM version 9.0.0 (clang-900.0.39.2)
> Target: x86_64-apple-darwin16.7.0
> Thread model: posix
> InstalledDir: ...
> --- >8 ---
Is that really way ahead of the clang releases
On Sun, Mar 18, 2018 at 09:18:34AM +0100, Nguyễn Thái Ngọc Duy wrote:
> The set of extra warnings we enable when DEVELOPER has to be
> conservative because we can't assume any compiler version the
> developer may use. Detect the compiler version so we know when it's
> safe to enable -Wextra and
On Sun, Mar 18, 2018 at 5:17 AM, Duy Nguyen wrote:
> On Sun, Mar 18, 2018 at 10:06 AM, Eric Sunshine
> wrote:
>> On MacOS, "cc -v" output is:
>> --- >8 ---
>> Apple LLVM version 9.0.0 (clang-900.0.39.2)
>> Target: x86_64-apple-darwin16.7.0
>> Thread
On Sun, Mar 18, 2018 at 10:17:41AM +0100, Duy Nguyen wrote:
> On Sun, Mar 18, 2018 at 10:06 AM, Eric Sunshine
> wrote:
> > On Sun, Mar 18, 2018 at 09:18:34AM +0100, Nguyễn Thái Ngọc Duy wrote:
> >> The set of extra warnings we enable when DEVELOPER has to be
> >>
On Sun, Mar 18, 2018 at 10:06 AM, Eric Sunshine wrote:
> On Sun, Mar 18, 2018 at 09:18:34AM +0100, Nguyễn Thái Ngọc Duy wrote:
>> The set of extra warnings we enable when DEVELOPER has to be
>> conservative because we can't assume any compiler version the
>> developer may
On Sun, Mar 18, 2018 at 09:18:34AM +0100, Nguyễn Thái Ngọc Duy wrote:
> The set of extra warnings we enable when DEVELOPER has to be
> conservative because we can't assume any compiler version the
> developer may use. Detect the compiler version so we know when it's
> safe to enable -Wextra and
On Sat, Mar 17, 2018 at 8:53 PM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Sat, Mar 17 2018, Nguyễn Thái Ngọc Duy jotted:
>
>> Previous patches leave lots of holes and padding in this struct. This
>> patch reorders the members and shrinks the struct down to 80 bytes
>> (from 136
On Sun, Mar 18, 2018 at 4:25 AM, Duy Nguyen wrote:
> On Sun, Mar 18, 2018 at 3:11 AM, Eric Sunshine
> wrote:
>> On Sat, Mar 17, 2018 at 3:53 AM, Nguyễn Thái Ngọc Duy
>> wrote:
>>> -extern int test_lazy_init_name_hash(struct
On Sat, Mar 17, 2018 at 11:05 PM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Wed, Feb 28 2018, Duy Nguyen jotted:
>
>> linux-2.6.git current has 6483999 objects. "git gc" on my poor laptop
>> consumes 1.7G out of 4G RAM, pushing lots of data to swap and making
>> all apps nearly
On Sun, Mar 18, 2018 at 3:11 AM, Eric Sunshine wrote:
> On Sat, Mar 17, 2018 at 3:53 AM, Nguyễn Thái Ngọc Duy
> wrote:
>> diff --git a/cache.h b/cache.h
>> @@ -333,7 +333,7 @@ struct index_state {
>> -extern int test_lazy_init_name_hash(struct
On Sun, Mar 18, 2018 at 6:09 AM, Junio C Hamano wrote:
>> + uint32_t truncated_limit = (uint32_t)limit;
>> +
>> + return limit == truncated_limit;
>> +}
>
> I am guessing that a compiler that is clever enough will make this
> function a no-op on a 32-bit arch and that
The set of extra warnings we enable when DEVELOPER has to be
conservative because we can't assume any compiler version the
developer may use. Detect the compiler version so we know when it's
safe to enable -Wextra and maybe more.
Helped-by: Jeff King
Signed-off-by: Nguyễn Thái
Some comments inline
On Fri, Mar 09, 2018 at 06:35:32PM +0100, lars.schnei...@autodesk.com wrote:
> From: Lars Schneider
>
> Git recognizes files encoded with ASCII or one of its supersets (e.g.
> UTF-8 or ISO-8859-1) as text files. All other encodings are usually
>
58 matches
Mail list logo