Re: [PATCH v2 5/5] ref-filter: get_ref_atom_value() error handling

2018-03-15 23:47 GMT+03:00 Martin Ågren : > I skimmed the first four patches of this v2. It seems that patches 1 and > 4 are identical to v2. Patches 2 and 3 have very straightforward changes > based on my earlier comments. Let's see what this patch is about. :-) Yes, you

Re: [PATCH v2 5/5] ref-filter: get_ref_atom_value() error handling

2018-03-16 0:01 GMT+03:00 Eric Sunshine : > On Thu, Mar 15, 2018 at 4:47 PM, Martin Ågren wrote: >> These are "real" errors and yield several more changes in the remainder. >> Ignoring those BUG-type messages at the beginning of this patch would >>

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

Hi Buga, Igor Djordjevic writes: > Hi Sergey, [...] >> As I said, putting myself on the user side, I'd prefer entirely separate >> first step of the algorithm, exactly as written, with its own conflict >> resolution, all running entirely the same way as it does

Re: [PATCH v2 3/5] ref-filter: change parsing function error handling

2018-03-16 1:48 GMT+03:00 Junio C Hamano : > Olga Telezhnaya writes: > >> Continue removing any printing from ref-filter formatting logic, >> so that it could be more general. > > Hmm. > >> Change the signature of parse_ref_filter_atom() by changing

URGENT BSINESS ASSISTANT NEEDED

Dear Friend You may be surprise to receive this mail since you don’t know me personally, but with due respect, trust and humility, I write to you this proposal. I am Mr. Rhaji Haid the son of MrTariq Haid of Darfur Sudan. It is indeed my pleasure to contact you for assistance of a business

Shipment delivery

See attached file for details

[PATCH] mergetools: enable tortoisemerge as difftool

TortoiseMerge/TortoiseGitMerge can also be used to view and edit file differences. This change allows configuring tortoisemerge not only as mergetool but as difftool as well. --- mergetools/tortoisemerge | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git

[PATCH v3 3/3] add -p: optimize line selection for short hunks

From: Phillip Wood If there are fewer than ten changes in a hunk then make spaces optional when selecting individual lines. This means that for short hunks one can just type 1-357 to stage lines 1, 2, 3, 5 & 7. Signed-off-by: Phillip Wood

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

From: Phillip Wood Since v2 I've updated the patches to use '-' instead of '^' to invert the selection to match the rest of add -i and clean -i. These patches build on top of the recount fixes in [1]. The commit message for the first patch describes the motivation:

[PATCH v3 2/3] add -p: allow line selection to be inverted

From: Phillip Wood If the list of lines to be selected begins with '-' select all the lines except the ones listed. Signed-off-by: Phillip Wood --- Notes: changes since v2: - use '-' to invert the selection instead of '^' to be

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

From: Phillip Wood When I end up editing hunks it is almost always because I want to stage a subset of the lines in the hunk. Doing this by editing the hunk is inconvenient and error prone (especially so if the patch is going to be reversed before being applied).

Hello

Hello, Can I trust and share this information with you?

Re: [PATCH v6 00/14] Serialized Git Commit Graph

On Fri, Mar 16, 2018 at 4:06 PM, Ævar Arnfjörð Bjarmason wrote: > I noticed that it takes a *long* time to generate the graph, on a bigger > repo I have it takes 20 minutes, and this is a repo where repack -A -d > itself takes 5-8 minutes, probably on the upper end of that with

Re: [PATCH v12 03/10] strbuf: add a case insensitive starts_with()

Morten Welinder writes: > You need to cast those arguments of tolower to (unsigned char). That's > arguably a bug of the language. Don't we do so in git-compat-util.h already?

Re: [PATCH v12 03/10] strbuf: add a case insensitive starts_with()

You need to cast those arguments of tolower to (unsigned char). That's arguably a bug of the language. Character values less than zero aren't valid for tolower, unless they happen to equal EOF in which case the tolower calls don't mean what you want them to mean. Per the man page: "If c is

Re: Help...!

On Fri, Mar 16, 2018 at 07:38:07PM +0530, JYOTIK MAYUR wrote: > i am working on a project that is git hosting website like GitHub. I > am a student so i don't know much on how to make a website like GitHub > so could please tell me what can be the appropriate steps to make a > website like

Re: [PATCH v6 00/14] Serialized Git Commit Graph

> On 14 Mar 2018, at 21:43, Junio C Hamano wrote: > > Derrick Stolee writes: > >> This v6 includes feedback around csum-file.c and the rename of hashclose() >> to finalize_hashfile(). These are the first two commits of the series, so >> they could be

Re: Why don't we symlink libexec/git-core/* to bin/git?

On Thu, Mar 15, 2018 at 6:16 PM, Johannes Schindelin wrote: > To add some interesting information to this: in MinGit (the light-weight > "Git for applications" we bundle to avoid adding a hefty 230MB to any > application that wants to bundle Git for Windows), we simply

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

What makes a Git repository unwieldy to work with and host? It turns out that the respository's on-disk size in gigabytes is only part of the story. From our experience at GitHub, repositories cause problems because of poor internal layout at least as often as because of their overall size. For

Re: [PATCH v6 00/14] Serialized Git Commit Graph

Johannes Schindelin writes: >> > Stolee, you definitely want to inspect those changes (`git log --check` >> > was introduced to show you whitespace problems). If all of those >> > whitespace issues are unintentional, you can fix them using `git rebase >> >

Re: [PATCH v2 3/5] gc --auto: exclude base pack if not enough mem to "repack -ad"

On Thu, Mar 15, 2018 at 8:21 PM, Ævar Arnfjörð Bjarmason wrote: > > On Thu, Mar 15 2018, Duy Nguyen jotted: > >> On Mon, Mar 12, 2018 at 8:30 PM, Ævar Arnfjörð Bjarmason >> wrote: >>> We already have pack.packSizeLimit, perhaps we could call this >>> e.g.

RE

I am Mr.Sheng Li Hung, from china I got your information while search for a reliable person, I have a very profitable business proposition for you and i can assure you that you will not regret been part of this mutual beneficial transaction after completion. Kindly get back to me for more details

CONTACT DHL OFFICE IMMEDIATELY FOR DELIVERY OF YOUR ATM MASTERCARD

Attention; Beneficiary, This is to official inform you that we have been having meetings for the past three (3) weeks which ended two days ago with MR. JIM YONG KIM the Former world bank president and other seven continent presidents on the congress we treated on solution to scam victim

Re: [PATCH v6 00/14] Serialized Git Commit Graph

On Wed, Mar 14 2018, Derrick Stolee jotted: > Hopefully this version is ready to merge. I have several follow-up topics > in mind to submit soon after, including: I've been doing some preliminary testing of this internally, all good so far, on a relatively small repo (~100k commits) I was using

Help...!

i am working on a project that is git hosting website like GitHub. I am a student so i don't know much on how to make a website like GitHub so could please tell me what can be the appropriate steps to make a website like that(mostly the server part).

Re: [PATCH 1/2] rebase: support --signoff with implicit rebase

Hi Phillip, On Thu, 15 Mar 2018, Phillip Wood wrote: > On 15/03/18 10:18, Johannes Schindelin wrote: > > > As I mentioned in my reply to Junio's comment, it'd be awesome if > > --interactive --signoff was supported (and likewise --merge > > --signoff), but it feels like an undue feature request

Re: [PATCH 3/3] Makefile: optionally symlink libexec/git-core binaries to bin/git

On Fri, Mar 16 2018, Johannes Schindelin jotted: > Hi Linus. > > On Thu, 15 Mar 2018, Linus Torvalds wrote: > >> We do end up still using the dashed form for certain things, but they >> are already special-cased (ie things like "git-receive-pack" and >> "git-shell" that very much get executed

Re: [ANNOUNCE] Git v2.17.0-rc0

Ævar Arnfjörð Bjarmason writes: > On Fri, Mar 16 2018, Junio C. Hamano jotted: > >> gitweb: hard-depend on the Digest::MD5 5.8 module > > I've just noticed this now, but while this module is in 5.8 RedHat's > butchered perl doesn't have it in the base system, thus this

getting fatal error trying to open git gui

I just installed git for windows 10 and am getting "git-gui: fatal error" "Cannot parse Git version string. When I execute "git version" in the command prompt I get Git version 2.16.2.windows.1 Everything else seems to be working. How can I get the gui to work? John

[PATCH] format-patch: use --compact-summary instead of --summary

For reviewers, a couple fewer lines from diffstat (either cover letter or patches) is a good thing because there's less to read. Signed-off-by: Nguyễn Thái Ngọc Duy --- I realize that rename percentage is lost with this change. I just hope that nobody cares about that, or

Re: [PATCH v2 2/2] stash push -u: don't create empty stash

On 03/15, Junio C Hamano wrote: > Thomas Gummerer writes: > > > no_changes () { > > git diff-index --quiet --cached HEAD --ignore-submodules -- "$@" && > > git diff-files --quiet --ignore-submodules -- "$@" && > > - (test -z "$untracked" || test -z

Re: Git "branch properties"-- thoughts?

>But for a generic branch like 'master', that arrangement would not >work well, I am afraid. You may have N copies of the same project, >where the 'master' branch of each is used to work on separate topic. >The focus of the 'master' branch of the overall project would be >quite different from

Re: [PATCH v6 00/14] Serialized Git Commit Graph

On Fri, Mar 16, 2018 at 7:33 PM, Junio C Hamano wrote: > SZEDER Gábor writes: > >> You should forget '--stdin-packs' and use '--stdin-commits' to generate >> the initial graph, it's much faster even without '--additive'[1]. See >> >> >>

Re: [PATCH v12 04/10] utf8: teach same_encoding() alternative UTF encoding names

Eric Sunshine writes: > However, I'm having a tough time imagining cases in which callers > would want same_encoding() to return true if both arguments are NULL, > but outright crash if only one is NULL (which is the behavior even > before this patch). In other words,

[PATCH v4 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 v4 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 v4 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 v4 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 13f6a44fb2..09f8b4ef3e

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

It's very very rare that an uncompressd 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 the

[PATCH v4 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 4GB of those objects because the array length, 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 v4 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

Re: [PATCH v6 00/14] Serialized Git Commit Graph

SZEDER Gábor writes: > You should forget '--stdin-packs' and use '--stdin-commits' to generate > the initial graph, it's much faster even without '--additive'[1]. See > > > https://public-inbox.org/git/CAM0VKj=wmkBNH=pscrztxfrc13rig1easw89q6ljansdjde...@mail.gmail.com/

Re: [PATCH v2 4/5] pack-objects: show some progress when counting kept objects

On Mon, Mar 12, 2018 at 7:32 PM, Ævar Arnfjörð Bjarmason wrote: > > On Tue, Mar 06 2018, Nguyễn Thái Ngọc Duy jotted: > >> We only show progress when there are new objects to be packed. But >> when --keep-pack is specified on the base pack, we will exclude most >> of objects.

Re: [ANNOUNCE] Git v2.17.0-rc0

Junio C Hamano writes: > I haven't wordsmithed it fully, but it should say something along > the lines of ... > > Documentation/RelNotes/2.16.0.txt | 10 ++ > 1 file changed, 10 insertions(+) Eh, of course the addition should go to 2.17 release notes ;-) I just

Re: [PATCH v12 04/10] utf8: teach same_encoding() alternative UTF encoding names

On Fri, Mar 16, 2018 at 1:50 PM, Junio C Hamano wrote: > Eric Sunshine writes: >> However, I'm having a tough time imagining cases in which callers >> would want same_encoding() to return true if both arguments are NULL, >> but outright crash if only

[PATCH 1/2] json_writer: new routines to create data in JSON format

From: Jeff Hostetler Add basic routines to generate data in JSON format. Signed-off-by: Jeff Hostetler --- Makefile | 1 + json-writer.c | 224 ++ json-writer.h | 120

[PATCH 0/2] routines to generate JSON data

From: Jeff Hostetler This patch series adds a set of utility routines to compose data in JSON format into a "struct strbuf". The resulting string can then be output by commands wanting to support a JSON output format. This is a stand alone patch. Nothing currently uses

Re: [PATCH v2 1/2] stash push: avoid printing errors

On 03/15, Marc Strapetz wrote: > On 14.03.2018 22:46, Thomas Gummerer wrote: > >Currently 'git stash push -u -- ' prints the following errors > >if only matches untracked files: > > > > fatal: pathspec 'untracked' did not match any files > > error: unrecognized input > > > >This is

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

Nguyễn Thái Ngọc Duy writes: > It's very very rare that an uncompressd 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. > >

Re: [PATCH v2 4/5] pack-objects: show some progress when counting kept objects

On Fri, Mar 16, 2018 at 8:14 PM, Duy Nguyen wrote: > On Mon, Mar 12, 2018 at 7:32 PM, Ævar Arnfjörð Bjarmason > wrote: >> >> On Tue, Mar 06 2018, Nguyễn Thái Ngọc Duy jotted: >> >>> We only show progress when there are new objects to be packed. But >>> when

RE: getting fatal error trying to open git gui

Got it figured out. Git gui must be ran as administrator. John -Original Message- From: Jonathan Nieder Sent: Friday, March 16, 2018 1:58 PM To: Briggs, John Cc: git@vger.kernel.org; git-for-wind...@googlegroups.com Subject: Re: getting fatal

[PATCH v2] travis-ci: enable more warnings on travis linux-gcc job

We have DEVELOPER config to enable more warnings, but since we can't set a fixed gcc version to all devs, that has to be a bit more conservative. On travis, we know almost exact version to be used (bumped to 6.x for more warnings), we could be more aggressive. Signed-off-by: Nguyễn Thái Ngọc Duy

[PATCH 2/2] json-writer: unit test

From: Jeff Hostetler Signed-off-by: Jeff Hostetler --- Makefile| 1 + t/helper/test-json-writer.c | 146 t/t0019-json-writer.sh | 10 +++ 3 files changed, 157 insertions(+)

Re: [PATCH v4 1/3] branch: introduce dont_fail parameter for branchname validation

On Friday 16 March 2018 01:57 AM, Junio C Hamano wrote: > Kaartic Sivaraam writes: > > So... I am not finding dont_fail that was mentioned on the title > anywhere else in the patch. Such lack of attention to detail is > a bit off-putting. > I'm absolutely sorry x-<

[PATCH v4 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 v4 00/11] nd/pack-objects-pack-struct updates

The most important change in v4 is it fixes a case where I failed to propagate an error condition to later code in 02/11. This results in new wrappers, oe_type() and oe_set_type(). This also reveals another extra object type, OBJ_NONE, that's also used by pack-objects. Other changes are comments

[PATCH v4 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 v4 11/11] pack-objects.h: 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).

[PATCH v4 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 | 44 1

Re: getting fatal error trying to open git gui

Hi, Briggs, John wrote: > I just installed git for windows 10 and am getting "git-gui: fatal error" > "Cannot parse Git version string. > > When I execute "git version" in the command prompt I get > Git version 2.16.2.windows.1 > > Everything else seems to be working. How can I get the gui to

Re: [PATCH v6 00/14] Serialized Git Commit Graph

On Fri, Mar 16, 2018 at 04:06:39PM -0400, Jeff King wrote: > > Furthermore, in order to look at an object it has to be zlib inflated > > first, and since commit objects tend to be much smaller than trees and > > especially blobs, there are a lot less bytes to inflate: > > > > $ grep ^commit

[PATCH v3 6/7] pack-objects: show some progress when counting kept objects

We only show progress when there are new objects to be packed. But when --keep-pack is specified on the base pack, we will exclude most of objects. This makes 'pack-objects' stay silent for a long time while the counting phase is going. Let's show some progress whenever we visit an object

[PATCH v3 0/7] nd/repack-keep-pack updates

This is not in mergeable state yet. But since there's lots of changes and I'm pretty sure there's still room for improvement when it comes to configuration and stuff, I'm posting it anyway to get the discussion continue. - --keep-pack does not imply --honor-pack-keep or --pack-kept-objects

[PATCH v3 1/7] repack: add --keep-pack option

We allow to keep existing packs by having companion .keep files. This is helpful when a pack is permanently kept. In the next patch, git-gc just wants to keep a pack temporarily, for one pack-objects run. git-gc can use --keep-pack for this use case. A note about why the pack_keep field cannot be

[PATCH v3 7/7] pack-objects: display progress in get_object_details()

This code is mostly about reading object headers, which is cheap. But when the number of objects is very large (e.g. 6.5M on linux-2.6.git) and the system is under memory pressure, this could take some time (86 seconds on my system). Show something during this time to let the user know

[PATCH v3 5/7] gc: handle a corner case in gc.bigPackThreshold

This config allows us to keep packs back if their size is larger than a limit. But if this N >= gc.autoPackLimit, we may have a problem. We are supposed to reduce the number of packs after a threshold because it affects performance. We could tell the user that they have incompatible

[PATCH v3 4/7] gc --auto: exclude base pack if not enough mem to "repack -ad"

pack-objects could be a big memory hog especially on large repos, everybody knows that. The suggestion to stick a .keep file on the giant base pack to avoid this problem is also known for a long time. Recent patches add an option to do just this, but it has to be either configured or activated

[PATCH v3 2/7] gc: add --keep-base-pack

This adds a new repack mode that combines everything into a secondary pack, leaving the largest/base pack alone. This could help reduce memory pressure. On linux-2.6.git, valgrind massif reports 1.6GB heap in "pack all" case, and 535MB in "pack all except the base pack" case. We save roughly 1GB

[PATCH v3 3/7] gc: detect base packs based on gc.bigPackThreshold config

The --keep-base-pack option is not very convenient to use because you need to tell gc to do this explicitly (and probably on just a few large repos). Add a config key that enables this mode when packs larger than a limit are found. Signed-off-by: Nguyễn Thái Ngọc Duy ---

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

On Fri, Mar 16 2018, Michael Haggerty jotted: > What makes a Git repository unwieldy to work with and host? It turns > out that the respository's on-disk size in gigabytes is only part of > the story. From our experience at GitHub, repositories cause problems > because of poor internal layout at

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

Nguyễn Thái Ngọc Duy writes: > 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

Re: [PATCH v6 00/14] Serialized Git Commit Graph

On Fri, Mar 16, 2018 at 08:48:49PM +0100, SZEDER Gábor wrote: > I came up with a different explanation back then: we are only interested > in commit objects when creating the commit graph, and only a small-ish > fraction of all objects are commit objects, so the "enumerate objects in > packfiles"

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

Nguyễn Thái Ngọc Duy writes: > 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 > --- >

Re: [PATCH v3 5/7] gc: handle a corner case in gc.bigPackThreshold

On Fri, Mar 16 2018, Nguyễn Thái Ngọc Duy jotted: > This config allows us to keep packs back if their size is larger > than a limit. But if this N >= gc.autoPackLimit, we may have a > problem. We are supposed to reduce the number of packs after a > threshold because it affects performance. > >

Re: [RFC PATCH] git-submodule.sh:cmd_update: if submodule branch exists, fetch that instead of default

On 03/08, Eddy Petrișor wrote: > 2018-03-06 22:21 GMT+02:00 Jonathan Nieder : > > > > (cc list snipped) > > Hi, > > > > Eddy Petrișor wrote: > > > > > Cc: [a lot of people] > > > > Can you say a little about how this cc list was created? E.g. should > > "git send-email" get a

[GSoC] parse: not show usage help when invalid id

patch for too chatty command when is invalid ex. git tag --contains It is possible to skip 'goto show_usage_error' when parse_long_opt fails? and return directly from there. Signed-off-by: Roger Solano --- parse-options.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v3 2/2] stash push -u: don't create empty stash

When introducing the stash push feature, and thus allowing users to pass in a pathspec to limit the files that would get stashed in df6bba0937 ("stash: teach 'push' (and 'create_stash') to honor pathspec", 2017-02-28), this developer missed one place where the pathspec should be passed in. Namely

Re: getting fatal error trying to open git gui

Briggs, John wrote: > Jonathan Nieder wrote: >> Briggs, John wrote: >>> I just installed git for windows 10 and am getting "git-gui: fatal >>> error" "Cannot parse Git version string. >>> >>> When I execute "git version" in the command prompt I get Git version >>> 2.16.2.windows.1 >>> >>>

RE: getting fatal error trying to open git gui

No, it was a fresh install. Plus file search reveals only one copy of the file. I also noticed that I cannot use the file properties to run as administrator. I must right-click on Git GUI and select "More >> Run as administrator" in the start menu. Even though I have "run as administrator"

Re: [PATCH v3 4/7] gc --auto: exclude base pack if not enough mem to "repack -ad"

On Fri, Mar 16 2018, Nguyễn Thái Ngọc Duy jotted: > + struct packed_git * p = find_base_packs(_pack, 0); Style nit: space after "*".

Re: [PATCH v3 2/7] gc: add --keep-base-pack

On Fri, Mar 16 2018, Nguyễn Thái Ngọc Duy jotted: > struct option builtin_gc_options[] = { > OPT__QUIET(, N_("suppress progress reporting")), > @@ -362,6 +390,8 @@ int cmd_gc(int argc, const char **argv, const char > *prefix) > OPT_BOOL(0, "aggressive", ,

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

Junio C Hamano writes: > Also, don't we want to use uintmax_t throughout the callchain? How > would the code in this series work when your ulong is 32-bit? My own answer to this question is "no conversion to uintmax_t, at least not in this series." As long as the original

Re: [PATCH] RelNotes: add details on Perl module changes

Todd Zullinger writes: > Document changes to core and non-core Perl module handling in 2.17. > ... > Maybe something like this? I had intended to suggest a note about > NO_PERL_CPAN_FALLBACKS as well, so that's included too. Thanks. A help like this in individual areas from

[PATCH v3 0/2] stash push -u -- fixes

Thanks Marc for catching the regression I almost introduced and Junio for the review of the second patch. Here's a re-roll that should fix the issues of v2. Interdiff below: diff --git a/git-stash.sh b/git-stash.sh index 7a4ec98f6b..dbedc7fb9f 100755 --- a/git-stash.sh +++ b/git-stash.sh @@

Re: getting fatal error trying to open git gui

On Fri, Mar 16, 2018 at 2:01 PM, Briggs, John wrote: > No, it was a fresh install. Plus file search reveals only one copy of the > file. > > I also noticed that I cannot use the file properties to run as administrator. > I must right-click on Git GUI and select "More >>

Re: [PATCH v2] travis-ci: enable more warnings on travis linux-gcc job

On Fri, Mar 16, 2018 at 08:33:55PM +0100, Nguyễn Thái Ngọc Duy wrote: > We have DEVELOPER config to enable more warnings, but since we can't set > a fixed gcc version to all devs, that has to be a bit more conservative. > On travis, we know almost exact version to be used (bumped to 6.x for >

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

On Fri, Mar 16, 2018 at 09:01:42PM +0100, Ævar Arnfjörð Bjarmason wrote: > Suggestion for a thing to add to it, I don't have the time on the Go > tuits: > > 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

Re: [PATCH] format-patch: use --compact-summary instead of --summary

Nguyễn Thái Ngọc Duy writes: > For reviewers, a couple fewer lines from diffstat (either cover letter > or patches) is a good thing because there's less to read. I can certainly accept that there may be some reviewers who share that view, but me personally, I would rather

[PATCH] RelNotes: add details on Perl module changes

Document changes to core and non-core Perl module handling in 2.17. --- Junio C Hamano writes: >> I haven't wordsmithed it fully, but it should say something along >> the lines of ... >> >> Documentation/RelNotes/2.16.0.txt | 10 ++ >> 1 file changed, 10 insertions(+)

Re: What's cooking in git.git (Mar 2018, #03; Wed, 14)

Hi, Junio C Hamano wrote: > Jonathan Tan writes: >> On Wed, 14 Mar 2018 18:34:49 -0700 >> Junio C Hamano wrote: >>> * sb/object-store (2018-03-05) 27 commits >> >> [snip list of commits] >> >>> (this branch is used by sb/packfiles-in-repository;

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

Nguyễn Thái Ngọc Duy writes: > These delta pointers always point to elements in the objects[] array > in packing_data struct. We can only hold maximum 4GB of those objects 4GB, as in "number of bytes"? Or "We can hold 4 billion or so of those objects"? > because the array

Re: [PATCH v3 3/7] gc: detect base packs based on gc.bigPackThreshold config

On Fri, Mar 16 2018, Nguyễn Thái Ngọc Duy jotted: Awesome, thanks for making this support N large packs. > +gc.bigPackThreshold:: > + If non-zero, all packs larger than this limit are kept when > + `git gc` is run. This is very similar to `--keep-base-pack` > + except that all packs

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

Nguyễn Thái Ngọc Duy writes: > 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

Re: What's cooking in git.git (Mar 2018, #03; Wed, 14)

On Wed, 14 Mar 2018 18:34:49 -0700 Junio C Hamano wrote: > * sb/object-store (2018-03-05) 27 commits [snip list of commits] > (this branch is used by sb/packfiles-in-repository; uses > nd/remove-ignore-env-field.) > > Refactoring the internal global data structure to

Re: [PATCH v3 1/2] stash push: avoid printing errors

Thomas Gummerer writes: > @@ -322,9 +322,12 @@ push_stash () { > > if test $# != 0 > then > - git add -u -- "$@" | > - git checkout-index -z --force --stdin This obviously is not something this patch

Re: [RFC PATCH] git-submodule.sh:cmd_update: if submodule branch exists, fetch that instead of default

On Fri, Mar 16, 2018 at 5:33 PM, Thomas Gummerer wrote: > Subject: [PATCH] SubmittingPatches: mention the git contacts command > > Instead of just mentioning 'git blame' and 'git shortlog', which make > it harder than necessary for new contributors to pick out the >

Re: What's cooking in git.git (Mar 2018, #03; Wed, 14)

Jonathan Tan writes: > On Wed, 14 Mar 2018 18:34:49 -0700 > Junio C Hamano wrote: > >> * sb/object-store (2018-03-05) 27 commits > > [snip list of commits] > >> (this branch is used by sb/packfiles-in-repository; uses >>

[PATCH v4 2/3] stash push: avoid printing errors

From: Thomas Gummerer 'git stash push -u -- ' prints the following errors if only matches untracked files: fatal: pathspec 'untracked' did not match any files error: unrecognized input This is because we first clean up the untracked files using 'git clean ', and

[PATCH v4 0/3] stash push -u -- fixes

Here is a preliminary fix for an earlier copy-pasto, plus two patches from your v3. I tried to reduce the nesting level by swapping the order of if/elif chain; please double check the logic to ensure I didn't make stupid mistakes while doing so. Junio C Hamano (1): stash: fix nonsense pipeline

[PATCH v4 1/3] stash: fix nonsense pipeline

An earlier change bba067d2 ("stash: don't delete untracked files that match pathspec", 2018-01-06) was made by taking a suggestion in a list discussion [1] but did not copy the suggested snippet correctly. And the bug was unnoticed during the review and slipped through. This fixes it. [1]

  1   2   >