Re: [PATCH v2] add -p: fix 2.17.0-rc* regression due to moved code

Ævar Arnfjörð Bjarmason writes: > diff --git a/git-add--interactive.perl b/git-add--interactive.perl > index d190469cd8..c1f52e457f 100755 > --- a/git-add--interactive.perl > +++ b/git-add--interactive.perl > @@ -1561,13 +1561,13 @@ sub patch_update_file { >

Re: Git Question

On Sat, Mar 31, 2018 at 09:06:53PM -0500, Mark Wartman wrote: > I saw this pretty exhaustive .gitignore list that a GitHub Help page > linked to: 9257657 . Are > these configurations from the list something one should install on the > User/global level,

Re: [OT] how does "git review --setup" figure out my username?

On Sat, Mar 31 2018, Robert P. J. Day wrote: > On Sat, 31 Mar 2018, Ævar Arnfjörð Bjarmason wrote: > >> On Sat, Mar 31, 2018 at 9:04 PM, Robert P. J. Day >> wrote: >> > >> > (technically not a git question, but i kind of need to know the >> > answer to this quickly as

Re: [OT] how does "git review --setup" figure out my username?

On Sat, 31 Mar 2018, Ævar Arnfjörð Bjarmason wrote: > On Sat, Mar 31, 2018 at 9:04 PM, Robert P. J. Day > wrote: > > > > (technically not a git question, but i kind of need to know the > > answer to this quickly as i'm writing some documentation and this is > >

Re: [OT] how does "git review --setup" figure out my username?

On Sat, Mar 31, 2018 at 9:04 PM, Robert P. J. Day wrote: > > (technically not a git question, but i kind of need to know the > answer to this quickly as i'm writing some documentation and this is > something i have to explain.) > > i cloned a repository (hyperledger

[OT] how does "git review --setup" figure out my username?

(technically not a git question, but i kind of need to know the answer to this quickly as i'm writing some documentation and this is something i have to explain.) i cloned a repository (hyperledger fabric) which has a top-level .gitreview file: [gerrit] host=gerrit.hyperledger.org

Re: [PATCH v3 0/3] add -p: select individual hunk lines

On Fri, Mar 30 2018, Phillip Wood wrote: > On 29/03/18 19:32, Junio C Hamano wrote: >> Phillip Wood writes: >> >>> From: Phillip Wood >>> >>> Since v2 I've updated the patches to use '-' instead of '^' to invert >>> the selection to match

Re: What's cooking in git.git (Mar 2018, #06; Fri, 30)

On Fri, Mar 30 2018, Junio C. Hamano wrote: > [...] > * jk/drop-ancient-curl (2017-08-09) 5 commits > - http: #error on too-old curl > - curl: remove ifdef'd code never used with curl >=7.19.4 > - http: drop support for curl < 7.19.4 > - http: drop support for curl < 7.16.0 > - http: drop

Re: [PATCH 4/3] Makefile: untangle DEVELOPER and -Werror

On Sat, Mar 31, 2018 at 6:40 PM, Ævar Arnfjörð Bjarmason wrote: > Change the DEVELOPER flag, and the newly added EAGER_DEVELOPER flag > which (approximately) enables -Wextra so that any combination of them > and -Werror can be set. > > I've long wanted to use DEVELOPER=1 in my

[PATCH] send-email: report host and port separately when calling git credential

When git-send-email uses git-credential to get SMTP password, it will communicate SMTP host and port (if both are provided) as a single entry ‘host=:’. This trips the ‘git-credential-store’ helper which expects those values as separate keys (‘host’ and ‘port’). Send the values as separate pieces

Re: [PATCH v2] add -p: fix 2.17.0-rc* regression due to moved code

On Sat, Mar 31 2018, Phillip Wood wrote: > On 31/03/18 13:50, Ævar Arnfjörð Bjarmason wrote: >> Fix a regression in 88f6ffc1c2 ("add -p: only bind search key if >> there's more than one hunk", 2018-02-13) which is present in >> 2.17.0-rc*, but not 2.16.0. >> >> In Perl, regex variables like $1

Re: [PATCH v4 2/5] stash: convert apply to builtin

On Thu, Mar 29, 2018 at 1:07 PM, Junio C Hamano wrote: > Joel Teichroeb writes: > >> +static int get_stash_info(struct stash_info *info, int argc, const char >> **argv) >> +{ > > So, this roughly corresponds to parse_flags_and_rev function, it seems. > >>

[PATCH 4/3] Makefile: untangle DEVELOPER and -Werror

Change the DEVELOPER flag, and the newly added EAGER_DEVELOPER flag which (approximately) enables -Wextra so that any combination of them and -Werror can be set. I've long wanted to use DEVELOPER=1 in my production builds, but on some old systems I still get warnings, and thus the build would

Re: [PATCH v2] add -p: fix 2.17.0-rc* regression due to moved code

On 31/03/18 13:50, Ævar Arnfjörð Bjarmason wrote: Fix a regression in 88f6ffc1c2 ("add -p: only bind search key if there's more than one hunk", 2018-02-13) which is present in 2.17.0-rc*, but not 2.16.0. In Perl, regex variables like $1 always refer to the last regex match. When the

Re: [PATCH v8 00/15] nd/pack-objects-pack-struct updates

On Sat, Mar 31 2018, Duy Nguyen wrote: > On Sat, Mar 31, 2018 at 1:36 PM, Ævar Arnfjörð Bjarmason > wrote: >>> +GIT_TEST_SPLIT_INDEX forces split-index mode on the whole test suite. >>> + >>> GIT_TEST_FULL_IN_PACK_ARRAY exercises the uncommon pack-objects code >>> path where

[PATCH v6 5/6] worktree: factor out dwim_branch function

Factor out a dwim_branch function, which takes care of the dwim'ery in 'git worktree add '. It's not too much code currently, but we're adding a new kind of dwim in a subsequent patch, at which point it makes more sense to have it as a separate function. Factor it out now to reduce the patch

[PATCH v6 6/6] worktree: teach "add" to check out existing branches

Currently 'git worktree add ' creates a new branch named after the basename of the path by default. If a branch with that name already exists, the command refuses to do anything, unless the '--force' option is given. However we can do a little better than that, and check the branch out if it is

[PATCH v6 4/6] worktree: be clearer when "add" dwim-ery kicks in

Currently there is no indication in the "git worktree add" output that a new branch was created. This would be especially useful information in the case where the dwim of "git worktree add " kicks in, as the user didn't explicitly ask for a new branch, but we create one for them. Print some

[PATCH v6 0/6] worktree: teach "add" to check out existing branches

Thanks Eric for the review of the last round. Previous rounds are at <20180121120208.12760-1-t.gumme...@gmail.com>, <20180204221305.28300-1-t.gumme...@gmail.com>, <20180317220830.30963-1-t.gumme...@gmail.com>, <2018031719.4940-1-t.gumme...@gmail.com> and

[PATCH v6 2/6] reset: introduce show-new-head-line option

Introduce a new --show-new-head-line command line option, that determines whether the "HEAD is now at ..." message is printed or not. It is enabled by default to preserve the current behaviour. It will be used in a subsequent commit to disable printing the "HEAD is now at ..." line in 'git

[PATCH v6 1/6] worktree: remove extra members from struct add_opts

There are two members of 'struct add_opts', which are only used inside the 'add()' function, but being part of 'struct add_opts' they are needlessly also passed to the 'add_worktree' function. Make them local to the 'add()' function to make it clearer where they are used. Signed-off-by: Thomas

[PATCH v6 3/6] worktree: improve message when creating a new worktree

Currently 'git worktree add' produces output like the following, when '--no-checkout' is not given: Preparing foo (identifier foo) HEAD is now at 26da330922 where the first line is written to stderr, and the second line coming from 'git reset --hard' is written to stdout, even though

I need your assistance in my investment project.

[PATCH v2] add -p: fix 2.17.0-rc* regression due to moved code

Fix a regression in 88f6ffc1c2 ("add -p: only bind search key if there's more than one hunk", 2018-02-13) which is present in 2.17.0-rc*, but not 2.16.0. In Perl, regex variables like $1 always refer to the last regex match. When the aforementioned change added a new regex match between the old

[PATCH] add -p: fix 2.17.0-rc* regression due to moved code

Fix a regression in 88f6ffc1c2 ("add -p: only bind search key if there's more than one hunk", 2018-02-13) which is present in 2.17.0-rc*, but not 2.16.0. In Perl regex variables like $1 always refer to the last regex match. When the added a new regex match between the old match and the code that

Re: [PATCH v8 00/15] nd/pack-objects-pack-struct updates

On Sat, Mar 31, 2018 at 1:36 PM, Ævar Arnfjörð Bjarmason wrote: >> +GIT_TEST_SPLIT_INDEX forces split-index mode on the whole test suite. >> + >> GIT_TEST_FULL_IN_PACK_ARRAY exercises the uncommon pack-objects code >> path where there are more than 1024 packs even if the

Re: [PATCH v8 00/15] nd/pack-objects-pack-struct updates

On Sat, Mar 31 2018, Nguyễn Thái Ngọc Duy wrote: I'm testing this and it looks good to me so far, aside from this: > - use git_env_*() instead of manually handling getenv() values > [...] > struct packed_git **mapping, *p; > - int cnt = 0, nr = 1 << OE_IN_PACK_BITS; > - > - if

Re: [PATCH v7 06/13] pack-objects: move in_pack out of struct object_entry

On Sat, Mar 31, 2018 at 06:20:07AM -0400, Jeff King wrote: > On Sat, Mar 31, 2018 at 06:51:10AM +0200, Duy Nguyen wrote: > > > >> +#define IN_PACK(obj) oe_in_pack(_pack, obj) > > > > > > How come this one gets a macro, but the earlier conversions don't? > > > > > > I guess the problem is that

Re: [PATCH v7 06/13] pack-objects: move in_pack out of struct object_entry

On Sat, Mar 31, 2018 at 06:51:10AM +0200, Duy Nguyen wrote: > >> +#define IN_PACK(obj) oe_in_pack(_pack, obj) > > > > How come this one gets a macro, but the earlier conversions don't? > > > > I guess the problem is that oe_in_pack() is defined in the generic > > pack-objects.h, but _pack is only

Re: [PATCH v7 08/13] pack-objects: shrink z_delta_size field in struct object_entry

On Sat, Mar 31, 2018 at 06:40:23AM +0200, Duy Nguyen wrote: > > Unlike the depth, I don't think there's any _inherent_ reason you > > couldn't throw, say, 1MB deltas into the cache (if you sized it large > > enough). But I doubt such deltas are really all that common. Here are > > the top 10 in

Re: [PATCH v7 10/13] pack-objects: clarify the use of object_entry::size

On Sat, Mar 31, 2018 at 06:35:40AM +0200, Duy Nguyen wrote: > On Fri, Mar 30, 2018 at 11:04 PM, Jeff King wrote: > > The subject says "clarify" so I was a little surprised to see code > > changes. It looks like we're just avoiding reassigning on top of the > > value repeatedly,

[PATCH v8 14/15] 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 on 64-bit systems, 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

[PATCH v8 08/15] 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 v8 00/15] nd/pack-objects-pack-struct updates

v8 changes - prefer BUG() over die() - do "1U <<" instead of "1 << " to avoid undefined behavior with signed shifting. - add more comments based on Jeff's feedback - plug a leak in try_delta() when delta_size is too large - be kind and set depth/cache_max_small_delta_size to max limit instead

[PATCH v8 09/15] 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 20 bits, so you can only cache 1MB deltas. Larger deltas must be recomputed at when the pack is written down. Signed-off-by: Nguyễn

[PATCH v8 13/15] pack-objects: shrink delta_size field in struct object_entry

Allowing a delta size of 64 bits is crazy. Shrink this field down to 20 bits with one overflow bit. If we find an existing delta larger than 1MB, 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. Note, since DELTA_SIZE() is

[PATCH v8 15/15] ci: exercise the whole test suite with uncommon code in pack-objects

Some recent optimizations have been added to pack-objects to reduce memory usage and some code paths are split into two: one for common use cases and one for rare ones. Make sure the rare cases are tested with Travis since it requires manual test configuration that is unlikely to be done by

[PATCH v8 11/15] pack-objects: clarify the use of object_entry::size

While this field most of the time contains the canonical object size, there is one case it does not: when we have found that the base object of the delta in question is also to be packed, we will very happily reuse the delta by copying it over instead of regenerating the new delta. "size" in this

[PATCH v8 10/15] pack-objects: don't check size when the object is bad

sha1_object_info() in check_objects() may fail to locate an object in the pack and return type OBJ_BAD. In that case, it will likely leave the "size" field untouched. We delay error handling until later in prepare_pack() though. Until then, do not touch "size" field. This field should contain the

[PATCH v8 03/15] 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 v8 01/15] t/README: mention about running the test suite in special modes

From: Duy Nguyen There are features that would benefit from running the whole test suite instead of just a few test cases written specifically for them. Split-index mode is one of them. Document it. This step is required because a few patches later, we will be introduce more

[PATCH v8 12/15] pack-objects: shrink size field in struct object_entry

It's very very rare that an uncompressed 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 31 bits and one overflow bit. If the

[PATCH v8 02/15] 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 +

[PATCH v8 07/15] 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 1k. Since we can't be sure people can never run into the situation where they have more than 1k pack

[PATCH v8 05/15] 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 v8 04/15] 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 7133baa63f..ebb6e034cb

[PATCH v8 06/15] 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 (like objects[], it is not freed, since we need it until the end of the process) Signed-off-by: Nguyễn Thái Ngọc Duy ---

Re: What's cooking in git.git (Mar 2018, #06; Fri, 30)

On Fri, Mar 30, 2018 at 10:38 PM, Junio C Hamano wrote: > * nd/repack-keep-pack (2018-03-26) 7 commits > - pack-objects: show some progress when counting kept objects > - gc --auto: exclude base pack if not enough mem to "repack -ad" > - gc: handle a corner case in

Re: [PATCH v7 12/13] pack-objects: shrink delta_size field in struct object_entry

On Fri, Mar 30, 2018 at 11:24 PM, Jeff King wrote: > How come this doesn't get a pdata->oe_delta_size_limit like we have > pdata->oe_size_limit? Would we want a matching > $GIT_TEST_OE_DELTA_SIZE_BITS to test it, too? Nope. This changes how the delta chain is formed (e.g. produces

Dear Customer

Bank Central Asia (BCA) Jakarta Indonesia Online Account Department. Monday-Friday 8.30am to 4.pm Dear Customer This is to inform you that we have confirmed the sum of USD$48 .800.000.00 from the Federal Reserve Board New York in order to setup an online account on your behalf, so you are

Re: Bad refspec messes up bundle.

Hi Johannes, With such a comprehensive reply, I would feel guilty not making a contribution now :) Be forewarned though, It's been about ten years since I wrote anything in `C`! I've cloned the `maint` branch, built the project, and added the test as you suggested - it's failing as expected.

TRADING ACCOUNT

Dear sir , I KELLY ALAN purchasing and sales manager of CFM INTERNATIONAL . Our Company specialised in Supplying computer hardware and Electronic .We want to extend our supplier list because of concurrency in prices on the international market We are seeking a supplier with whom we can to