Our LOAN OFFER IS AVAILABLE- NOW- Contact us for more DETAILS//

Dear customer, We offer a loan on 3.5 APR, same day approval- For more information email us at -edward.henry.garn...@gmail.com We would like to finance your project, business loans and consolidation are all type of application are Welcome. We also do the financing of the car and the

Re: [PATCH 0/3] convert diff flags to be stored in a struct

On Sat, Oct 28, 2017 at 6:22 PM, Junio C Hamano wrote: >> Some thoughts: >> * We may want to do a follow on patch to convert all the flags from being in >>uppercase to lower case. > > If and only if we do not use macros to set/clr/test, this makes a > lot of sense.

Re: git rm VERY slow for directories with many files.

Junio C Hamano writes: > I wonder how fast "git diff-index --cached -r HEAD --", with the > same pathspec used for the problematic "git rm", runs in this same > 50,000 path project. > > If it runs in a reasonable time, one easy way out may be to revamp > the codepath to call

Re: [PATCH 2/3] revision.h: introduce blob/tree walking in order of the commits

Stefan Beller writes: > On Sat, Oct 28, 2017 at 8:22 PM, Stefan Beller wrote: > >> >> (Not making excuses, but...) I remembered some other senior members >> having such commit messages, so I felt like I had to step up my game. >> >>

Re: [PATCH 3/3] builtin/describe: describe blobs

On Sat, Oct 28, 2017 at 10:32 AM, Johannes Schindelin wrote: > Hi Stefan, > > On Fri, 27 Oct 2017, Stefan Beller wrote: > >> Sometimes users are given a hash of an object and they want to identify >> it further (ex.: Use verify-pack to find the largest blobs, but what

Re: [PATCH 2/3] revision.h: introduce blob/tree walking in order of the commits

On Sat, Oct 28, 2017 at 8:22 PM, Stefan Beller wrote: > > (Not making excuses, but...) I remembered some other senior members > having such commit messages, so I felt like I had to step up my game. > >

Re: [PATCH 2/3] revision.h: introduce blob/tree walking in order of the commits

On Sat, Oct 28, 2017 at 10:20 AM, Johannes Schindelin wrote: > Hi Stefan, > > On Fri, 27 Oct 2017, Stefan Beller wrote: > >> This will be useful shortly. > > Something tells me that I will hate you in the future when I read this > commit message and lack the context

Re: [PATCH 1/3] list-objects.c: factor out traverse_trees_and_blobs

On Sat, Oct 28, 2017 at 10:15 AM, Johannes Schindelin wrote: > Hi Stefan, > > [I was intrigued enough by your work to postpone to later this coming week > reading the What's cooking email in favor of reviewing your patch series.] > > On Fri, 27 Oct 2017, Stefan Beller

[GIT PULL] l10n updates for 2.15.0 round 2 with Catalan updates

Hi Junio, Please pull this last time l10n update for Git 2.15.0. It contains squash merge of [PR#267][1] and [PR#268][2]. The following changes since commit 1165e3c317b51a3f47afe1a5762b92cac695fe5c: Merge branch 'jx/zh_CN-proposed' of github.com:jiangxin/git (2017-10-24 10:11:48 +0800) are

Re: [PATCH 3/3] diff: convert flags to be stored in bitfields

Brandon Williams writes: > We have have reached the limit of the number of flags that can be stored s/have have/have/; but bit #9 is unused. "We cannot add many more flags even if we wanted to" would be more flexible and does not take this change hostage to whatever topic

Re: [PATCH v2 3/4] Integrate hash algorithm support with repo setup

On Sat, Oct 28, 2017 at 2:12 PM, brian m. carlson wrote: > In future versions of Git, we plan to support an additional hash > algorithm. Integrate the enumeration of hash algorithms with repository > setup, and store a pointer to the enumerated data in struct

Re: [PATCH v2 2/4] Add structure representing hash algorithm

On Sat, Oct 28, 2017 at 2:12 PM, brian m. carlson wrote: > Since in the future we want to support an additional hash algorithm, add > a structure that represents a hash algorithm and all the data that must > go along with it. Add a constant to allow easy enumeration

Re: [PATCH 2/3] reset: use DIFF_OPT_SET macro to set a diff flag

Brandon Williams writes: > Instead of explicitly setting the 'DIFF_OPT_OVERRIDE_SUBMODULE_CONFIG' > flag, use the 'DIFF_OPT_SET' macro. > > Signed-off-by: Brandon Williams > --- Looks good. It's not like one of 1/3 and 2/3 could be a good idea while the

Re: [PATCH 0/3] convert diff flags to be stored in a struct

Brandon Williams writes: > There has be some desire to add additional flags to the diff machineery > (https://public-inbox.org/git/20171024000931.14814-1-sbel...@google.com/) but > due to the limits of the number of bits in an unsigned int on some systems we > can't add any

Re: git rm VERY slow for directories with many files.

"brian m. carlson" writes: >> Looking at an optimized profile, all the time seems to be spent in >> “get_tree_entry” — I assume there is some huge object representing the >> directory which is being re-expanded for each file? > > Yes, there's a tree object that

Re: [PATCH 4/6] t0021/rot13-filter: add packet_initialize()

Lars Schneider writes: > BTW: I am using this little snippet to apply patches from the mailing: > > PATCH=$(curl -L --silent > https://public-inbox.org/git/xmqqr2tpcn6g@gitster.mtv.corp.google.com/raw); > > ((printf '%s' "$PATCH" | git am -3) || (git am

Re: [PATCH 1/2] t1404: add a bunch of tests of D/F conflicts

"brian m. carlson" writes: > There is discussion in the Austin Group issue tracker about adding this > feature to POSIX, but it's gotten bogged down over lexical versus > dynamic scoping. Everyone agrees that it's a desirable feature, though. > ... In short,

Re: [RFC] protocol version 2

From: "Brandon Williams" Sent: Friday, October 20, 2017 6:18 PM Objective === Replace Git's current wire protocol with a simpler, less wasteful protocol that can evolve over time. Capability Advertisement -- A server which decides to

Re: [PATCH 3/3] builtin/describe: describe blobs

On Sat, Oct 28, 2017 at 10:32 AM, Johannes Schindelin wrote: > Hi Stefan, > > > Nicely done, sir! > > I wonder whether it would make sense to extend this to tree objects while > we are at it, but maybe that's an easy up-for-grabs. > > Thank you very much! > Dscho I'd

Re: [PATCH] rebase: exec leaks GIT_DIR to environment

On Sat, Oct 28, 2017 at 9:00 AM, Johannes Schindelin wrote: > Hi Jake, > > On Fri, 27 Oct 2017, Jacob Keller wrote: > >> From: Jacob Keller >> >> I noticed a failure with git rebase interactive mode which causes "exec" >> commands to be run

Re: git rm VERY slow for directories with many files.

On Sat, Oct 28, 2017 at 05:02:02PM +, Christopher Jefferson wrote: > I stupidly added a directory with many files ( ~450,000 ) to git, and want to > delete them — later I plan to rebase/squash various commits to remove the > files from the history altogether. > > However, ‘git rm’ is VERY

git rm VERY slow for directories with many files.

I stupidly added a directory with many files ( ~450,000 ) to git, and want to delete them — later I plan to rebase/squash various commits to remove the files from the history altogether. However, ‘git rm’ is VERY slow. For example, in a directory with 10,000 files (on a Mac), git v2.14.2 Git

[PATCH v2 0/4] Hash Abstraction

This is a series proposing a basic abstraction for hash functions. As we get closer to converting the remainder of the codebase to use struct object_id, we should think about the design we want our hash function abstraction to take. This series is a proposal for one idea. Input on any aspect of

[PATCH v2 4/4] Switch empty tree and blob lookups to use hash abstraction

Switch the uses of empty_tree_oid and empty_blob_oid to use the current_hash abstraction that represents the current hash algorithm in use. Signed-off-by: brian m. carlson --- builtin/am.c | 2 +- builtin/checkout.c | 2 +- builtin/diff.c | 2 +-

[PATCH v2 3/4] Integrate hash algorithm support with repo setup

In future versions of Git, we plan to support an additional hash algorithm. Integrate the enumeration of hash algorithms with repository setup, and store a pointer to the enumerated data in struct repository. Of course, we currently only support SHA-1, so hard-code this value in

[PATCH v2 1/4] setup: expose enumerated repo info

We enumerate several different items as part of struct repository_format, but then actually set up those values using the global variables we've initialized from them. Instead, let's pass a pointer to the structure down to the code where we enumerate these values, so we can later on use those

[PATCH v2 2/4] Add structure representing hash algorithm

Since in the future we want to support an additional hash algorithm, add a structure that represents a hash algorithm and all the data that must go along with it. Add a constant to allow easy enumeration of hash algorithms. Implement function typedefs to create an abstract API that can be used

RE: STILL WAITING FOR YOUR RESPONSE

Hello, Did you received my previous message? Regards.

Re: How to re-merge paths differently?

From: "Philip Oakley" From: "Sergey Organov" Is there anything like this: $ git merge b [... lot of conflicts ...] $ git re-merge -X ours -- x/ # Leaves 0 conflicts in x/ $ git re-merge -X theirs -- y/ # Leaves 0 conflicts in y/ [... resolve the

Re: How to re-merge paths differently?

From: "Sergey Organov" Is there anything like this: $ git merge b [... lot of conflicts ...] $ git re-merge -X ours -- x/ # Leaves 0 conflicts in x/ $ git re-merge -X theirs -- y/ # Leaves 0 conflicts in y/ [... resolve the rest of conflicts manually ...] $ git commit

Re: [PATCH 3/3] builtin/describe: describe blobs

Hi Stefan, On Fri, 27 Oct 2017, Stefan Beller wrote: > Sometimes users are given a hash of an object and they want to identify > it further (ex.: Use verify-pack to find the largest blobs, but what are > these? or [1]) > > The best identification of a blob hash is done via a its path at a >

Re: [PATCH 2/3] revision.h: introduce blob/tree walking in order of the commits

Hi Stefan, On Fri, 27 Oct 2017, Stefan Beller wrote: > This will be useful shortly. Something tells me that I will hate you in the future when I read this commit message and lack the context (e.g. when blaming, where I cannot see the child commits let alone the comment in the Merge commit).

Re: [PATCH] tag: add tag.gpgSign config option to force all tags be GPG-signed

On Thu, Oct 26, 2017 at 02:33:37PM -0700, Jonathan Nieder wrote: > Now I'm even more curious. > > I don't think we have the full picture to understand whether this > change is needed. When adding a configuration item, we need to be > able to explain to users what the configuration item is for,

Re: [PATCH 1/3] list-objects.c: factor out traverse_trees_and_blobs

Hi Stefan, [I was intrigued enough by your work to postpone to later this coming week reading the What's cooking email in favor of reviewing your patch series.] On Fri, 27 Oct 2017, Stefan Beller wrote: > With traverse_trees_and_blobs factored out of the main traverse function, > the next patch

Re: What's cooking in git.git (Oct 2017, #06; Fri, 27)

On Fri, 2017-10-27 at 17:32 +0900, Junio C Hamano wrote: > * jc/branch-name-sanity (2017-10-14) 3 commits > (merged to 'next' on 2017-10-16 at 174646d1c3) > + branch: forbid refs/heads/HEAD > + branch: split validate_new_branchname() into two > + branch: streamline "attr_only" handling in

[BUG] Incosistent repository state when trying to rename HEAD in the middle of a rebase

I just noticed this recently while trying to see if a recent change [1] that disallowed the possibility of creating HEAD also allowed renaming branches named "HEAD" that were created using previous versions that allowed it. Unfortunately (or fortunately (?)), I was in the middle of an interactive

Re: [git-for-windows] Git for Windows v2.15.0-rc prerelease, was Re: [ANNOUNCE] Git v2.15.0-rc2

> On 28 Oct 2017, at 18:40, Johannes Schindelin > wrote: > > Hi Lars, > > On Fri, 27 Oct 2017, Lars Schneider wrote: > >>> On 27 Oct 2017, at 14:11, Lars Schneider wrote: >>> On 21 Oct 2017, at 00:22, Johannes Schindelin

Re: [PATCH 1/2] t1404: add a bunch of tests of D/F conflicts

On Wed, Oct 25, 2017 at 11:32:51PM -0700, Jeff King wrote: > On Wed, Oct 25, 2017 at 10:03:09AM +0200, Michael Haggerty wrote: > > > > Yeah. It's supported by dash and many other shells, but we do try to > > > avoid it[1]. I think in this case we could just drop it (but keep > > > setting the

Re: [git-for-windows] Git for Windows v2.15.0-rc prerelease, was Re: [ANNOUNCE] Git v2.15.0-rc2

Hi Lars, On Fri, 27 Oct 2017, Lars Schneider wrote: > > On 27 Oct 2017, at 14:11, Lars Schneider wrote: > > > >> On 21 Oct 2017, at 00:22, Johannes Schindelin > >> wrote: > >> > >> [cutting linux-kernel] > >> > >> On Fri, 20 Oct 2017,

Re: [RFC PATCH 0/3] git-describe ?

Hi Stefan, On Fri, 27 Oct 2017, Stefan Beller wrote: > Occasionally a user is given an object hash from a blob as an error message > or other output (e.g. [1]). > > It would be useful to get a further description of such a blob, such as > the (commit, path) tuple where this blob was introduced.

Re: [PATCH] rebase: exec leaks GIT_DIR to environment

Hi Jake, On Fri, 27 Oct 2017, Jacob Keller wrote: > From: Jacob Keller > > I noticed a failure with git rebase interactive mode which causes "exec" > commands to be run with GIT_DIR set. When GIT_DIR is in the environment, > then any command which results in running a

Re: [PATCH] cherry-pick: add --keep-existing-origin option

On 28 October 2017 at 22:21, Kevin Daudt wrote: > > On Sat, Oct 28, 2017 at 08:04:40PM +0800, Anthony Wong wrote: > > When cherry-picking from a commit whose commit message already > > contains the "(cherry picked from commit ...)" line, this option will > > not add another one.

Re: [PATCH 4/6] t0021/rot13-filter: add packet_initialize()

> On 27 Oct 2017, at 04:57, Junio C Hamano wrote: > > Junio C Hamano writes: > >> It is fine to leave the original code broken at this step while we >> purely move the lines around, and hopefully this will be corrected >> in a later step in the series (I

Re: Rules for backup discussion

Hi Jason, On 28/10/2017 14:49, Jason Pyeron wrote: > I would like to efficiently backup my project directories. > > I am thinking that the backup of a git enabled project should only backup the > following sets of files: > > Files under .git/ > The results of git clean -ndx > The results of

Re: [PATCH] cherry-pick: add --keep-existing-origin option

On Sat, Oct 28, 2017 at 08:04:40PM +0800, Anthony Wong wrote: > When cherry-picking from a commit whose commit message already > contains the "(cherry picked from commit ...)" line, this option will > not add another one. This is useful when you are cherry-picking from a > bunch of commits, some

Rules for backup discussion

I would like to efficiently backup my project directories. I am thinking that the backup of a git enabled project should only backup the following sets of files: Files under .git/ The results of git clean -ndx The results of git status Does this make sense? Is there a less expensive way to

[PATCH] cherry-pick: add --keep-existing-origin option

When cherry-picking from a commit whose commit message already contains the "(cherry picked from commit ...)" line, this option will not add another one. This is useful when you are cherry-picking from a bunch of commits, some are cherry-picks and already contains the upstream hash but some do

Wildcards with git rm

git rm doesn't seem to be very useful without the use of shell wildcards, especially with the use of a .gitignore file. If a .gitignore file is used, the git rm command does not consider the .gitignore file, and errs out when an ignored file is present. In my opinion, git rm should take

[PATCH 7/7] refs: rename constant `REF_ISPRUNING` to `REF_IS_PRUNING`

Underscores are cheap, and help readability. Signed-off-by: Michael Haggerty --- refs/files-backend.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/refs/files-backend.c b/refs/files-backend.c index 71e088e811..bb10b715a8 100644 ---

[PATCH 0/7] Tidy up the constants related to ref_update::flags

Nothing earth-shattering here; just cleaning up some internal details that have bothered me for a while: * Make it clearer which flag values the packed backend might confront. * Reduce the visibility of the constants that are only relevant to the files backend. The most notable of these is

[PATCH 1/7] files_transaction_prepare(): don't leak flags to packed transaction

The files backend uses `ref_update::flags` for several internal flags. But those flags have no meaning to the packed backend. So when adding updates for the packed-refs transaction, only use flags that make sense to the packed backend. `REF_NODEREF` is part of the public interface, and it's

[PATCH 6/7] refs: rename constant `REF_NODEREF` to `REF_NO_DEREF`

Even after working with this code for years, I still see this constant name as "ref node ref". Rename it to make it's meaning clearer. Signed-off-by: Michael Haggerty --- builtin/am.c | 2 +- builtin/branch.c | 2 +- builtin/checkout.c | 2 +-

[PATCH 5/7] refs: tidy up and adjust visibility of the `ref_update` flags

The constants used for `ref_update::flags` were rather disorganized: * The definitions in `refs.h` were not close to the functions that used them. * Maybe constants were defined in `refs-internal.h`, making them visible to the whole refs module, when in fact they only made sense for the

[PATCH 2/7] prune_ref(): call `ref_transaction_add_update()` directly

`prune_ref()` needs to use the `REF_ISPRUNING` flag, but we want to make that flag private to the files backend. So instead of calling `ref_transaction_delete()`, which is a public function and therefore shouldn't allow the `REF_ISPRUNING` flag, change `prune_ref()` to call

[PATCH 4/7] ref_transaction_add_update(): remove a check

We want to make `REF_ISPRUNING` internal to the files backend. For this to be possible, `ref_transaction_add_update()` mustn't know about it. So move the check that `REF_ISPRUNING` is only used with `REF_NODEREF` from this function to `files_transaction_prepare()`. Signed-off-by: Michael Haggerty

[PATCH 3/7] ref_transaction_update(): die on disallowed flags

Callers shouldn't be passing disallowed flags into `ref_transaction_update()`. So instead of masking them off, treat it as a bug if any are set. Signed-off-by: Michael Haggerty --- refs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/refs.c b/refs.c

[PATCH v2 1/2] t1409: check that `packed-refs` is not rewritten unnecessarily

There is no need to rewrite the `packed-refs` file except for the case that we are deleting a reference that has a packed version. Verify that `packed-refs` is not rewritten when it shouldn't be. In fact, two of these tests fail: * A new (empty) `packed-refs` file is created when deleting any

[PATCH v2 0/2] Avoid rewriting "packed-refs" unnecessarily

This reroll make some logically small changes to v1 [1] that are textually very big: * Invert the sense of `is_packed_transaction_noop()` and rename it to `is_packed_transaction_needed()`. This makes the logic easier to follow and document. * Add a big comment to that function, describing

[PATCH v2 2/2] files-backend: don't rewrite the `packed-refs` file unnecessarily

Even when we are deleting references, we needn't overwrite the `packed-refs` file if the references that we are deleting only exist as loose references. Implement this optimization as follows: * Add a function `is_packed_transaction_needed()`, which checks whether a given packed-refs

Re: grep vs git grep performance?

On Fri, Oct 27 2017, Joe Perches jotted: > On Sat, 2017-10-28 at 00:11 +0200, Ævar Arnfjörð Bjarmason wrote: >> On Fri, Oct 27 2017, Joe Perches jotted: > [] >> > git grep performance has already been >> > quite successfully improved. >> >> ...and I have WIP patches to use the PCRE engine for