[no subject]

ارسال از تلفن همراه Huawei من

What's cooking in git.git (Jul 2017, #06; Thu, 20)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. Tagging of -rc1 is delayed,

Re: [PATCH 21/28] commit_packed_refs(): use a staging file separate from the lockfile

Junio C Hamano wrote: > Michael Haggerty writes: >> We will want to be able to hold the lockfile for `packed-refs` even >> after we have activated the new values. So use a separate tempfile, >> `packed-refs.new`, as a place to stage the new contents of the >> `packed-refs`

Re: [PATCH v3 00/30] Create a reference backend for packed refs

+cc: dawalker, who reported the bug Stefan Beller wrote: > We have a user that reports: > > The issue is for users who have a mirrored repository, "git pack-refs" > now overwrites the .git/packed-refs symlink instead of following it and > replacing the file it points to. > > I suspect this

Re: [PATCH 21/28] commit_packed_refs(): use a staging file separate from the lockfile

Michael Haggerty writes: > We will want to be able to hold the lockfile for `packed-refs` even > after we have activated the new values. So use a separate tempfile, > `packed-refs.new`, as a place to stage the new contents of the > `packed-refs` file. For now this is all

Re: [PATCH v3 00/30] Create a reference backend for packed refs

On Wed, Jul 5, 2017 at 2:12 AM, Jeff King wrote: > On Sat, Jul 01, 2017 at 08:30:38PM +0200, Michael Haggerty wrote: > >> This is v3 of a patch series creating a `packed_ref_store` reference >> backend. Thanks to Peff and Junio for their comments about v2 [1]. >> >> Changes since

Re: [PATCH v2 00/10] tag: only respect `pager.tag` in list-mode

Martin Ågren writes: > This is the second version of "[PATCH 0/7] tag: more fine-grained > pager-configuration" [1]. That series introduced `pager.tag.list` to > address the fact that `pager.tag` can be useful with `git tag -l` but > actively hostile with `git tag -a`.

Re: Fwd: New Defects reported by Coverity Scan for git

René Scharfe writes: > We could remove that NULL check -- it's effectively just a shortcut. > But how would that improve safety? Well, if the array is unallocated > (NULL) and _num is greater than zero we'd get a segfault without it, > and thus would notice it. That check

Re: [PATCH] sha1_file: use access(), not lstat(), if possible

Jonathan Tan writes: > In sha1_loose_object_info(), use access() (indirectly invoked through > has_loose_object()) instead of lstat() if we do not need the on-disk > size, as it should be faster on Windows [1]. That sounds as if Windows is the only thing that matters.

Re: [PATCH v6 00/10] The final building block for a faster rebase -i

Johannes Schindelin writes: > Changes since v5: > > - replaced a get_sha1() call by a get_oid() call already. > > - adjusted to hashmap API changes Applying this to the tip of 'master' yields exactly the same result as merging the previous round js/rebase-i-final to

Re: [RFC PATCH v2 1/4] object: remove "used" field from struct object

Jonathan Tan writes: > The "used" field in struct object is only used by builtin/fsck. Remove > that field and modify builtin/fsck to use a flag instead. > > Signed-off-by: Jonathan Tan > --- > builtin/fsck.c | 24 ++-- >

Re: [RFC PATCH v2 4/4] sha1_file: support promised object hook

On Thu, 20 Jul 2017 16:58:16 -0400 Ben Peart wrote: > >> This is meant as a temporary measure to ensure that all Git commands > >> work in such a situation. Future patches will update some commands to > >> either tolerate promised objects (without invoking the hook) or be

Re: [RFC PATCH v2 2/4] promised-object, fsck: introduce promised objects

On Thu, 20 Jul 2017 15:58:51 -0400 Ben Peart wrote: > On 7/19/2017 8:21 PM, Jonathan Tan wrote: > > Currently, Git does not support repos with very large numbers of objects > > or repos that wish to minimize manipulation of certain blobs (for > > example, because they are

[PATCH v2] t: lib-gpg: flush gpg agent on startup

From: Santiago Torres When running gpg-relevant tests, a gpg-daemon is spawned for each GNUPGHOME used. This daemon may stay running after the test and cache file descriptors for the trash directories, even after the trash directory is removed. This leads to ENOENT errors when

Re: Handling of paths

2017-07-20 22:30 GMT+02:00 Junio C Hamano : > > I've read the function again and I think the attached patch covers > everything that ought to be a filename. > Your swift reaction is very much appreciated. With the background you gave I just started to to create a patch myself

Re: [RFC PATCH v2 4/4] sha1_file: support promised object hook

On 7/20/2017 2:23 PM, Stefan Beller wrote: On Wed, Jul 19, 2017 at 5:21 PM, Jonathan Tan wrote: Teach sha1_file to invoke a hook whenever an object is requested and unavailable but is promised. The hook is a shell command that can be configured through "git config";

Re: Handling of paths

On Thu, Jul 20, 2017 at 01:30:52PM -0700, Junio C Hamano wrote: > > I've read the function again and I think the attached patch covers > everything that ought to be a filename. > > By the way, to credit you, do you prefer your bloomberg or hashpling > address? The patch looks good to me. It's

Re: Binary files

Igor Djordjevic writes: > On 20/07/2017 09:41, Volodymyr Sendetskyi wrote: >> It is known, that git handles badly storing binary files in its >> repositories at all. >> This is especially about large files: even without any changes to >> these files, their copies are

Re: [PATCH 0/6] 2.14 RelNotes improvements

Ævar Arnfjörð Bjarmason writes: > Here's a few patches to improve the relnotes. I started just writing > 6/6 since I think (I don't care about the wording) that we should in > some way mention the items in the list in the 6/6 commit message. > > Along the way I noticed a few

Re: Fwd: New Defects reported by Coverity Scan for git

Am 18.07.2017 um 19:23 schrieb Junio C Hamano: > Stefan Beller writes: > >> I looked at this report for a while. My current understanding: >> * its detection was triggered by including rs/move-array, >>f331ab9d4c (use MOVE_ARRAY, 2017-07-15) >> * But it is harmless,

Re: Handling of paths

Charles Bailey writes: > On Thu, Jul 20, 2017 at 12:42:40PM -0700, Junio C Hamano wrote: >> Victor Toni writes: >> >> > What's unexpected is that paths used for sslKey or sslCert are treated >> > differently insofar as they are expected to be

NOTE

BCEAO BANK TOGO has agreed to wire USD$ 7,500.000.00,get in touch with me by my private email immediately: (myemailcham...@gmail.com)for more details

Re: [PATCH] t: lib-gpg: flush gpg agent on startup

> With that "run it but ignore the outcome even if we failed to.", we > do not have to worry about any of that ;-) Oh right! thanks for the suggestion! Let me re-roll... Thanks, -Santiago. signature.asc Description: PGP signature

Re: Handling of paths

On Thu, Jul 20, 2017 at 12:42:40PM -0700, Junio C Hamano wrote: > Victor Toni writes: > > > What's unexpected is that paths used for sslKey or sslCert are treated > > differently insofar as they are expected to be absolute. > > Relative paths (whether with or without "~")

Re: [PATCH] t: lib-gpg: flush gpg agent on startup

Santiago Torres writes: > This is the patch that stemmed from [1]. > > I tried to keep it simple and not noisy, alhtough it breaks the && > chain, it needs to be run right before the --import command. I also > decided to drop the switch chain in case that regression was to be >

Re: [RFC PATCH v2 2/4] promised-object, fsck: introduce promised objects

On 7/19/2017 8:21 PM, Jonathan Tan wrote: Currently, Git does not support repos with very large numbers of objects or repos that wish to minimize manipulation of certain blobs (for example, because they are very large) very well, even if the user operates mostly on part of the repo, because

Re: [GSoC][PATCH 5/8] submodule: port submodule subcommand 'sync' from shell to C

On Thu, Jul 20, 2017 at 12:36 PM, Prathamesh Chavan wrote: > Firstly, thanks for reviewing my patches. I have even checked out the > other reviews > and improvised the other patches according to reviews as well. > I had a few doubts about this one though. > >>> + const

Re: Handling of paths

Victor Toni writes: > What's unexpected is that paths used for sslKey or sslCert are treated > differently insofar as they are expected to be absolute. > Relative paths (whether with or without "~") don't work. Looking at http.c::http_options(), I see that "sslcapath" and

Re: [GSoC][PATCH 5/8] submodule: port submodule subcommand 'sync' from shell to C

Firstly, thanks for reviewing my patches. I have even checked out the other reviews and improvised the other patches according to reviews as well. I had a few doubts about this one though. >> + const struct submodule *sub; >> + char *sub_key, *remote_key; >> + char

Re: [RFC PATCH v2 2/4] promised-object, fsck: introduce promised objects

On Thu, 20 Jul 2017 11:07:29 -0700 Stefan Beller wrote: > > + if (fsck_promised_objects()) { > > + error("Errors found in promised object list"); > > + errors_found |= ERROR_PROMISED_OBJECT; > > + } > > This got me thinking: It is an

Re: [PATCH 6/6] RelNotes: add more notes about PCRE in 2.14

Ævar Arnfjörð Bjarmason writes: > We were missing any mention that: > > - PCRE is now faster with JIT > - That it's now faster than the other regex backends > - That therefore you might want to use it by default, but beware of >the incompatible syntax. Hmph. All of

Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility

> The use of "make pot" from the top-level is already described in > po/README, so the only thing that we need is something like this > change. I'll follow up this message with a sample output from the > updated process to ask others to sanity check the result (they are > tiny) in a separate

Re: Binary files

Hi Volodymyr, On 20/07/2017 09:41, Volodymyr Sendetskyi wrote: > It is known, that git handles badly storing binary files in its > repositories at all. > This is especially about large files: even without any changes to > these files, their copies are snapshotted on each commit. So even >

Re: [PATCH] l10n: de.po: update German translation

Hi Ralf, I think the following should be "hinzugefügt": #: builtin/add.c:288 -#, fuzzy msgid "warn when adding an embedded repository" -msgstr "ein Bare-Repository erstellen" +msgstr "warnen wenn eingebettetes Repository hingefügt wird" Everything else looks great! Thanks! Kind

Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility

Junio C Hamano writes: > The use of "make pot" from the top-level is already described in > po/README, so the only thing that we need is something like this > change. I'll follow up this message with a sample output from the > updated process to ask others to sanity check the

Re: [RFC PATCH v2 4/4] sha1_file: support promised object hook

On Wed, Jul 19, 2017 at 5:21 PM, Jonathan Tan wrote: > Teach sha1_file to invoke a hook whenever an object is requested and > unavailable but is promised. The hook is a shell command that can be > configured through "git config"; this hook takes in a list of hashes and >

Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility

Junio C Hamano writes: > Johannes Schindelin writes: > >> But there may be hope. Since the character sequence "PRItime" is highly >> unlikely to occur in Git's source code in any context other than the >> format to print/parse timestamp_t, it

Re: [RFC PATCH v2 2/4] promised-object, fsck: introduce promised objects

On Wed, Jul 19, 2017 at 5:21 PM, Jonathan Tan wrote: > Currently, Git does not support repos with very large numbers of objects > or repos that wish to minimize manipulation of certain blobs (for > example, because they are very large) very well, even if the user >

[PATCH v2 1/1] submodule--helper: teach push-check to handle HEAD

In 06bf4ad1d (push: propagate remote and refspec with --recurse-submodules) push was taught how to propagate a refspec down to submodules when the '--recurse-submodules' flag is given. The only refspecs that are allowed to be propagated are ones which name a ref which exists in both the

Re: [RFC PATCH v2 1/4] object: remove "used" field from struct object

On 7/19/2017 8:55 PM, Jonathan Tan wrote: On Wed, 19 Jul 2017 17:36:39 -0700 Stefan Beller wrote: On Wed, Jul 19, 2017 at 5:21 PM, Jonathan Tan wrote: The "used" field in struct object is only used by builtin/fsck. Remove that field and modify

Re: Binary files

On Thu, Jul 20, 2017 at 12:41 AM, Volodymyr Sendetskyi wrote: > It is known, that git handles badly storing binary files in its > repositories at all. > This is especially about large files: even without any changes to > these files, their copies are snapshotted on each

Re: [PATCH] t: lib-gpg: flush gpg agent on startup

This is the patch that stemmed from [1]. I tried to keep it simple and not noisy, alhtough it breaks the && chain, it needs to be run right before the --import command. I also decided to drop the switch chain in case that regression was to be introduced in the future in other versions (hopefully

Re: --interactive mode: readline support ⌨⬆

Marcel Partap writes: > Dear git devs, > wouldn't it be great to have the power of readline added to the power > of git interactive commands? Yes, rlwrap will do the job, but still. > Or am I missing something obvious? Am using debian's 2.11.0-2 ... Just use "rlwrap git clean

[PATCH] t: lib-gpg: flush gpg agent on startup

From: Santiago Torres When running gpg-relevant tests, a gpg-daemon is spawned for each GNUPGHOME used. This daemon may stay running after the test and cache file descriptors for the trash directories, even after the trash directory is removed. This leads to ENOENT errors when

Re: [PATCH 5/6] RelNotes: remove duplicate mention of PCRE v2

Ævar Arnfjörð Bjarmason writes: > That we can link to PCRE v2 is already covered above in "Backward > compatibility notes and other notable changes", no need to mention it > twice. This is actually deliberate, as I'd prefer to have a description that is written at the same

Re: [PATCH 4/6] RelNotes: mention that PCRE v2 exposes the same syntax

Ævar Arnfjörð Bjarmason writes: > For someone not familiar with PCRE or having read its own > documentation this isn't obvious, let's explicitly mention it so > package maintainers won't fear upgrading least they break things for > their users. If packagers trust our

Re: Reducing redundant build at Travis?

Lars Schneider writes: >> On 14 Jul 2017, at 17:32, Jeff King wrote: >> >> I don't know if Travis's cache storage is up to that challenge. We could >> probably build such a lock on top of third-party storage, but things are >> rapidly getting more

[PATCH 4/6] RelNotes: mention that PCRE v2 exposes the same syntax

For someone not familiar with PCRE or having read its own documentation this isn't obvious, let's explicitly mention it so package maintainers won't fear upgrading least they break things for their users. Signed-off-by: Ævar Arnfjörð Bjarmason ---

[PATCH 2/6] RelNotes: mention "log: make --regexp-ignore-case work with --perl-regexp"

To inform users that they can use --regexp-ignore-case now, and that existing scripts which relied on that + PCRE may be buggy. See 9e3cbc59d5 ("log: make --regexp-ignore-case work with --perl-regexp", 2017-05-20). Signed-off-by: Ævar Arnfjörð Bjarmason ---

[PATCH 5/6] RelNotes: remove duplicate mention of PCRE v2

That we can link to PCRE v2 is already covered above in "Backward compatibility notes and other notable changes", no need to mention it twice. Signed-off-by: Ævar Arnfjörð Bjarmason --- Documentation/RelNotes/2.14.0.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)

[PATCH 0/6] 2.14 RelNotes improvements

> Ævar Arnfjörð Bjarmason writes: > >> On Thu, Jul 13 2017, Junio C. Hamano jotted: >> >> Proposed improvements for the release notes (is this a good way to >> propose RelNotes changes?) > > Thanks. You could also throw a patch just like any bugfix/update > to documentation, I

[PATCH 1/6] RelNotes: mention "log: add -P as a synonym for --perl-regexp"

To inform users that they can use the short form now. See 7531a2dd87 ("log: add -P as a synonym for --perl-regexp", 2017-05-25). Signed-off-by: Ævar Arnfjörð Bjarmason --- Documentation/RelNotes/2.14.0.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH 3/6] RelNotes: mention "sha1dc: optionally use sha1collisiondetection as a submodule"

To note that merely cloning git.git without --recurse-submodules doesn't get you a full copy of the code anymore. See 5f6482d642 ("RelNotes: mention "log: make --regexp-ignore-case work with --perl-regexp"", 2017-07-20). Signed-off-by: Ævar Arnfjörð Bjarmason ---

[PATCH 6/6] RelNotes: add more notes about PCRE in 2.14

We were missing any mention that: - PCRE is now faster with JIT - That it's now faster than the other regex backends - That therefore you might want to use it by default, but beware of the incompatible syntax. Signed-off-by: Ævar Arnfjörð Bjarmason ---

Re: --interactive mode: readline support ⌨⬆

Haha, totally slipped by me that there exist two kinds of interactive mode. Not that I haven't used both... Sorry for overlooking/being to unspecific. #Regards/Marcel X )

Re: --interactive mode: readline support ⌨⬆

On 20 July 2017 at 11:20, Marcel Partap wrote: > So the readline library powers the advanced line editing capabilities behind > f.e. the bash or the ipython shell. Besides navigating with the cursor keys, > it provides a history function accessible by the up cursor key ⌨⬆ . >

Expected behavior of "git check-ignore"...

A StackOverflow user posted a question about how to reliably check whether a file would be ignored by "git add" and expected "git check-ignore" to return results that matched git add's behavior. It turns out that it doesn't. If there is a negation rule, we end up returning that exclude and

Dear Talented

Dear Talented, I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue sky Studio a Film Corporation Located in the United State, is Soliciting for the Right to use Your Photo/Face and Personality as One of the Semi -Major Role/ Character in our Upcoming ANIMATED Stereoscope 3D Movie-The Story

Re: --interactive mode: readline support ⌨⬆

Ok very good point Martin ; ) I nefariously hid one obvious use case as trailing emoji™ in the subject, but a better way to make a point is to properly explain. So the readline library powers the advanced line editing capabilities behind f.e. the bash or the ipython shell. Besides navigating

Re: --interactive mode: readline support ⌨⬆

On 20 July 2017 at 10:21, Marcel Partap wrote: > wouldn't it be great to have the power of readline added to the power of git > interactive commands? Yes, rlwrap will do the job, but still. > Or am I missing something obvious? Well maybe *I* am missing something obvious. :)

Re: Binary files

> On 20 Jul 2017, at 09:41, Volodymyr Sendetskyi wrote: > > It is known, that git handles badly storing binary files in its > repositories at all. > This is especially about large files: even without any changes to > these files, their copies are snapshotted on each

--interactive mode: readline support ⌨⬆

Dear git devs, wouldn't it be great to have the power of readline added to the power of git interactive commands? Yes, rlwrap will do the job, but still. Or am I missing something obvious? Am using debian's 2.11.0-2 ... #BestRegards/Marcel Partap

Re: Reducing redundant build at Travis?

> On 14 Jul 2017, at 17:32, Jeff King wrote: > > On Fri, Jul 14, 2017 at 07:54:16AM -0700, Junio C Hamano wrote: > >>> The "git test" script[1] uses this strategy with git-notes as the >>> storage, and I've found it quite useful. I don't think we can rely on >>> git-notes, but I

Re: Binary files

On Thu, Jul 20, 2017 at 10:41:48AM +0300, Volodymyr Sendetskyi wrote: > It is known, that git handles badly storing binary files in its > repositories at all. [...] > So the question is: why not implementing some feature, that would > somehow handle this problem? [...] Have you examined git-lfs

Re: Binary files

On Thu, Jul 20, 2017 at 12:41 AM, Volodymyr Sendetskyi wrote: > It is known, that git handles badly storing binary files in its > repositories at all. > This is especially about large files: even without any changes to > these files, their copies are snapshotted on each

Re: Binary files

It is known, that git handles badly storing binary files in its repositories at all. This is especially about large files: even without any changes to these files, their copies are snapshotted on each commit. So even repositories with a small amount of code can grove very fast in size if they