Jonathan Nieder writes:
>> Do we care about the ancient layout that used symlinks to emulate
>> the more modern worktree one?
>
> I think we do care. In the context of people's changing workflows,
> "git worktree" is a relatively new tool. Breaking the older
> git-new-workdir (and tools that em
ارسال از تلفن همراه Huawei من
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, waitin
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` file. For now this is a
+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 s
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 done within
> `commit_pac
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 v2:
>>
>> * Delet
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`. Thanks to Junio, Peff and B
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 currently papers over
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. "It is
faster in general,
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 the tip of
'master' and then
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 ++--
> object.c | 1 -
> object.h | 2 +-
> 3
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 more
> >> efficient in i
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 very large) very well, e
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 attempting to
creat
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 just to see that you a
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"; this hook takes in a list
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 n
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 snapshotted on each commit. S
Æ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 more missing things.
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, because the scan logic doe
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 absolute.
>> > Relative paths (whether with or witho
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
> 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
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 "~") don't work.
>
> It appe
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
> introduced in the
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 Git
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 struct submodule *sub;
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
"sslcainfo" do use git_
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 *sub_origin_ur
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 error if we do not hav
Æ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 that has been more or
> 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 messa
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
> reposito
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 reg
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 result (they are
>
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
> writes (if successful) the
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 should be possible to automate a the
>> string replac
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
> operates mostly on part of the r
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 superproje
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 builtin/fsck to use a flag instead.
The patc
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 commit. So even
> repositor
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 g
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 -i".
--
Leah Neuk
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 attempting to
creat
Æ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 detail-level (i.e. "j
Æ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 assessment on one external
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 complex.
>
> I think we shouldn't go there beca
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
---
Documentation/RelNotes/2.14.0.txt | 3 +++
1 fil
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
---
Documentation/RelNotes/2.14.0.txt | 3
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(-)
diff --git a/Docume
> Æ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 would think.
Here'
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
---
Documentation/RelNotes/2.14.0.tx
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
---
Documentation/RelNotes/2.14.0.txt |
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 a/Documentation/RelNotes/2.14.0.txt
b
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 )
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 ⌨⬆ .
> At the moment, git
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 printi
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
of
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 with
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. :) Could you be a bit
mo
> 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 commit. So even
> repositorie
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
> 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 think Travis gi
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 a
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 commit. So even
> repositor
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 conta
67 matches
Mail list logo
