Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

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

Re: [PATCH v6 1/3] Makefile: generate Perl header from template file

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 >

[PATCH v6 2/3] Makefile: add Perl runtime prefix support

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

[PATCH v6 1/3] Makefile: generate Perl header from template file

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

[PATCH v6 3/3] exec_cmd: RUNTIME_PREFIX on some POSIX systems

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

[PATCH v6 0/3] RUNTIME_PREFIX relocatable Git

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 Pretty,

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

Re: Draft of Git Rev News edition 37

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

Re: user-manual: patch proposals and questions

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

Fwd: user-manual: patch proposals and questions

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

Investment Proposal

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

Re: [PATCH v2 2/2] git-svn: allow empty email-address in authors-prog and authors-file

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,

Re: [PATCH v2 0/3] git worktree prune improvements

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

Re: [PATCH v2 3/3] worktree prune: improve prune logic when worktree is moved

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, >

Re: [PATCH v2 2/3] worktree: delete dead code

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

Re: Draft of Git Rev News edition 37

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

[GSoC] Regarding "Convert scripts to builtins"

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

Re: [PATCH v2 0/2] git-svn: --author-prog improvements

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

Re: [PATCH v2 0/2] git-svn: --author-prog improvements

No comments on this one?

HELLO

-- 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

Re: feature-request: git "cp" like there is git mv.

* 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

Re: [ANNOUNCE] git-sizer: compute various size-related metrics for your Git repository

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

Re: [PATCH] Makefile: detect compiler and enable more warnings in DEVELOPER=1

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

Draft of Git Rev News edition 37

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

Websites & Web Based Applications

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

Re: [PATCH] Makefile: detect compiler and enable more warnings in DEVELOPER=1

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

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

Re: [PATCH v6 00/11] nd/pack-objects-pack-struct updates

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

Re: [PATCH v6 09/11] pack-objects: shrink size field in struct object_entry

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".

[PATCH v6 06/11] pack-objects: move in_pack out of struct object_entry

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

[PATCH v6 08/11] pack-objects: shrink z_delta_size field in struct object_entry

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

[PATCH v6 04/11] pack-objects: use bitfield for object_entry::depth

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 ---

[PATCH v6 09/11] pack-objects: shrink size field in struct object_entry

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

[PATCH v6 05/11] pack-objects: move in_pack_pos out of struct object_entry

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 ++-

[PATCH v6 10/11] pack-objects: shrink delta_size field in struct object_entry

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

[PATCH v6 11/11] pack-objects: reorder members to shrink struct object_entry

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

[PATCH v6 07/11] pack-objects: refer to delta objects by index instead of pointer

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

[PATCH v6 03/11] pack-objects: use bitfield for object_entry::dfs_state

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

[PATCH v6 02/11] pack-objects: turn type and in_pack_type to bitfields

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

[PATCH v6 00/11] nd/pack-objects-pack-struct updates

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 ---

[PATCH v6 01/11] pack-objects: a bit of document about struct object_entry

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 +

Re: [PATCH v6 07/14] commit-graph: implement 'git-commit-graph write'

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

NICE TO MEET YOU,

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

Re: [PATCH] Makefile: detect compiler and enable more warnings in DEVELOPER=1

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

Re: [PATCH] Makefile: detect compiler and enable more warnings in DEVELOPER=1

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 >>

Re: [PATCH] Makefile: detect compiler and enable more warnings in DEVELOPER=1

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

Re: [PATCH] Makefile: detect compiler and enable more warnings in DEVELOPER=1

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

Re: [PATCH] Makefile: detect compiler and enable more warnings in DEVELOPER=1

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

Re: [PATCH] Makefile: detect compiler and enable more warnings in DEVELOPER=1

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 > >>

Re: [PATCH] Makefile: detect compiler and enable more warnings in DEVELOPER=1

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

Re: [PATCH] Makefile: detect compiler and enable more warnings in DEVELOPER=1

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

Re: [PATCH v5 11/11] pack-objects.h: reorder members to shrink struct object_entry

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

Re: [PATCH 04/36] t/helper: merge test-lazy-init-name-hash into test-tool

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

Re: Why does pack-objects use so much memory on incremental packing?

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

Re: [PATCH 04/36] t/helper: merge test-lazy-init-name-hash into test-tool

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

Re: [PATCH v5 09/11] pack-objects: shrink size field in struct object_entry

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

[PATCH] Makefile: detect compiler and enable more warnings in DEVELOPER=1

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

Re: [PATCH v11 06/10] convert: add 'working-tree-encoding' attribute

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 >