> On 27 Feb 2017, at 23:11, Jakub Narębski wrote:
>
> W dniu 27.02.2017 o 11:32, Lars Schneider pisze:
>>
>>> On 27 Feb 2017, at 10:58, Jeff King wrote:
>>>
>>> On Sun, Feb 26, 2017 at 07:48:16PM +0100, Lars Schneider wrote:
>>>
>>&
> On 27 Feb 2017, at 11:53, Jeff King wrote:
>
> On Mon, Feb 27, 2017 at 11:32:47AM +0100, Lars Schneider wrote:
>
>> ...
>
>>> From Git's side, the loop is something like:
>>>
>>> while (delayed_items > 0) {
>>> /* i
Hi,
I just got a report with the following output after a "git fetch" operation
using Git 2.11.0.windows.3 [1]:
remote: Counting objects: 5922, done.
remote: Compressing objects: 100% (14/14), done.
error: inflate: data stream error (unknown compression method)
error: unable to unpack 6acd8f279a8
> On 28 Mar 2017, at 00:35, Junio C Hamano wrote:
> ...
>
> * ls/filter-process-delayed (2017-03-06) 1 commit
> - convert: add "status=delayed" to filter process protocol
>
> What's the status of this one???
> cf.
I was about to send out a new round last Sunday but then
I discovered a problem
> On 24 Mar 2017, at 14:58, Nikita Kunevich wrote:
>
> Hello, git team. My name is Nikita Kunevich. I’m student of Belarusian State
> University of Informatics and Radioelectronics. I’d like to particapate in
> Google Summer of Code 2017 under git organization.
> I’m working on “Git CI Improve
> On 24 Mar 2017, at 12:48, Daniel Stenberg wrote:
>
> On Fri, 24 Mar 2017, Lars Schneider wrote:
>
>> Most Git developers work on Linux and they have no way to know if their
>> changes would break the Git for Windows build. Let's fix that by adding a
>> jo
ting-Concurrent-Builds
Signed-off-by: Lars Schneider
---
Hi,
I think I addressed all issues from the v1 review (see interdiff below)
with one exception. The script still uses bash instead of sh. Something
about this does not work in sh:
--output >(sed "$(printf '1s/^\xef\xbb\xbf
> On 23 Mar 2017, at 21:20, Jeff King wrote:
>
> On Thu, Mar 23, 2017 at 09:00:33PM +0100, Lars Schneider wrote:
>
>>> Ah, OK, that makes sense. So we would only have to worry about our _own_
>>> code accidentally disclosing it. But that should be easy to look fo
> On 23 Mar 2017, at 20:38, Jeff King wrote:
>
> On Thu, Mar 23, 2017 at 08:26:15PM +0100, Lars Schneider wrote:
>
>>> I think we do build against PRs now. E.g.:
>>>
>>> https://travis-ci.org/git/git/builds/213896051
>>>
>>> But it loo
> On 23 Mar 2017, at 20:30, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>> "[...] we do not provide these values to untrusted builds,
>> triggered by pull requests from another repository."
>>
>> See:
>> https://docs.travis-ci.c
> On 23 Mar 2017, at 20:17, Jeff King wrote:
>
> On Thu, Mar 23, 2017 at 12:12:15PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>>> For instance, if it's in the environment, can I push up a branch that
>>> does "set | grep GFW_CI_TOKEN", open a PR, and see it? I don't know the
>>>
> On 22 Mar 2017, at 20:29, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>> Therefore, we did the following:
>> * Johannes Schindelin set up a Visual Studio Team Services build
>> sponsored by Microsoft and made it accessible via an Azure Function
>>
> On 22 Mar 2017, at 16:49, Johannes Schindelin
> wrote:
>
> Hi Lars,
>
> On Wed, 22 Mar 2017, Lars Schneider wrote:
...
>> +
>> +gfwci () {
>> +curl \
>> +-H "Authentication: Bearer $TOKEN" \
>> +--s
Hi,
we rebased a branch using "--preserve-merges --interactive" and were
surprised that the operation reported success although it silently
omitted commits (Git 2.12 on Windows). A little search revealed that
these are likely known bugs [1]. Would it make sense to print an
appropriate warning
> On 21 Mar 2017, at 18:43, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>> Agreed. Would it be OK to store the "delayed" bit in the cache
>> entry itself? The extended ce_flags are stored on disk which is not
>> necessary I think. Would a new m
ting-Concurrent-Builds
Signed-off-by: Lars Schneider
---
Notes:
Base Ref: master
Web-Diff: https://github.com/larsxschneider/git/commit/322094c0a2
Checkout: git fetch https://github.com/larsxschneider/git travisci/win-v1
&& git checkout 322094c0a2
.travis.yml
> On 06 Mar 2017, at 22:08, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> On 04 Mar 2017, at 00:26, Junio C Hamano wrote:
>>>
>>>
>>> * ls/filter-process-delayed (2017-01-08) 1 commit
>>> . convert: add "status=delayed&
> On 17 Mar 2017, at 13:56, Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
>> Lars Schneider writes:
>>
>>> A quick bisect indicates that this patch might break
>>> t9807-git-p4-submit.sh 8 and 13. I haven't looked into
>>> it fu
> On 16 Mar 2017, at 06:50, Junio C Hamano wrote:
>
> "git name-rev" assigned a phony "far in the future" date to tips of
> refs that are not pointing at tag objects, and favored names based
> on a ref with the oldest date. This made it almost impossible for
> an unannotated tags and branches t
> On 17 Mar 2017, at 11:18, Lars Schneider wrote:
>
>
>> On 17 Mar 2017, at 03:22, Linus Torvalds
>> wrote:
>>
>> I think there's a semantic merge error and it clashes with
>> f18f816cb158 ("hash.h: move SHA-1 implementation selection into a
> On 17 Mar 2017, at 03:22, Linus Torvalds
> wrote:
>
> I think there's a semantic merge error and it clashes with
> f18f816cb158 ("hash.h: move SHA-1 implementation selection into a
> header file").
>
> Suggested possible merge resolution attached.
>
> Linus
>
Would it ma
build and test run on 32-bit Linux.
Let's do this (and take care of the Windows build later). This patch
asks Travis CI to install a Docker image with 32-bit libraries and then
goes on to build and test Git using this 32-bit setup.
Signed-off-by: Johannes Schindelin
Signed-off-by: Lars Schn
> On 02 Mar 2017, at 16:17, Ramsay Jones wrote:
>
>
>
> On 02/03/17 11:24, Johannes Schindelin wrote:
>> Hi Lars,
>>
>> On Thu, 2 Mar 2017, Lars Schneider wrote:
>>
> [snip]
>>> One thing that still bugs me: In the Linux32 environment pro
> On 04 Mar 2017, at 00:26, Junio C Hamano wrote:
>
>
> * ls/filter-process-delayed (2017-01-08) 1 commit
> . convert: add "status=delayed" to filter process protocol
>
> Ejected, as does not build when merged to 'pu'.
I send v2 [1] where I tried to address the points in your feedback [2].
v
> On 04 Mar 2017, at 05:11, Junio C Hamano wrote:
>
> On Fri, Mar 3, 2017 at 4:03 PM, Junio C Hamano wrote:
>>
>> I only recently started looking at Travis logs, so I cannot tell if
>> it is just a usual flake (e.g. some builds a few days ago seems to
>> have failed due to not being able to ch
build and test run on 32-bit Linux.
Let's do this (and take care of the Windows build later). This patch
asks Travis CI to install a Docker image with 32-bit libraries and then
goes on to build and test Git using this 32-bit setup.
Signed-off-by: Johannes Schindelin
Signed-off-by: Lars Schn
> On 02 Mar 2017, at 12:24, Johannes Schindelin
> wrote:
>
> Hi Lars,
>
> On Thu, 2 Mar 2017, Lars Schneider wrote:
>
>> The patch looks good to me in general but I want to propose the following
>> changes:
>
> I know you are using your script to gener
build and test run on 32-bit Linux.
Let's do this (and take care of the Windows build later). This patch
asks Travis CI to install a Docker image with 32-bit libraries and then
goes on to build and test Git using this 32-bit setup.
Signed-off-by: Johannes Schindelin
Signed-off-by: Lars Schn
> On 27 Feb 2017, at 10:58, Jeff King wrote:
>
> On Sun, Feb 26, 2017 at 07:48:16PM +0100, Lars Schneider wrote:
>
>> +If the request cannot be fulfilled within a reasonable amount of time
>> +then the filter can respond with a "delayed" status and a flush pac
ts only in `clone` (in unpack-trees.c) and `checkout` operations.
Signed-off-by: Lars Schneider
---
Hi,
in v1 Junio criticized the "convert.h" interface of this patch [1].
After talking to Peff I think I understand Junio's point and I would
like to get your feedback on the new app
> On 26 Feb 2017, at 03:09, Samuel Lijin wrote:
>
> On Sat, Feb 25, 2017 at 3:48 PM, Lars Schneider
> wrote:
>>
>>> On 24 Feb 2017, at 18:29, Samuel Lijin wrote:
>>>
>>> It's worth noting that there seems to be a weird issue with sc
> On 25 Feb 2017, at 23:31, Jeff King wrote:
>
> On Sat, Feb 25, 2017 at 10:48:52PM +0100, Lars Schneider wrote:
>
>>
>>> On 24 Feb 2017, at 18:29, Samuel Lijin wrote:
>>>
>>> Introduces the scan-build static code analysis tool from the Clang
> On 25 Feb 2017, at 00:06, Jeff King wrote:
>
> On Fri, Feb 24, 2017 at 11:47:46PM +0100, Jakub Narębski wrote:
>
>> I have just read on ArsTechnica[1] that while Git repository could be
>> corrupted (though this would require attackers to spend great amount
>> of resources creating their own
> On 24 Feb 2017, at 18:29, Samuel Lijin wrote:
>
> Introduces the scan-build static code analysis tool from the Clang
> project to all Travis CI builds. Installs clang (since scan-build
> needs clang as a dependency) to make this possible (on macOS, also
> updates PATH to allow scan-build to be
Hi,
I stumbled across the following today:
(1) git -c foo.bar="foobar" clone
--> uses the config temporarily
(2) git clone -c foo.bar="foobar"
--> uses the config and writes it to .git/config
This was introduced in 84054f7 ("clone: accept config options on the
command line") and it makes
> On 20 Feb 2017, at 10:58, Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
>> I still haven't queued any of the variants I posted (and I do not
>> think other people sent their own versions, either). I need to pick
>> one and queue, with a test or two. Perhaps after -rc2.
>>
>> Others
able is set to while the cmd is
> running. The code to do so however downcased in its entirety,
> which is wrong for a three-level ...
>
> The part needs to stay as-is.
>
> Reported-by: Lars Schneider
> Diagnosed-by: Jonathan Tan
> Signed-off-by: Junio C Hamano
&g
> On 14 Feb 2017, at 19:16, Martin-Louis Bright wrote:
[CC'ing Luke and George]
> hi!
>
> I am using git-p4.py to migrate a lot of medium and large Perforce
> depots into git. I almost exclusively go one way: from Perforce to
> git. I also frequently re-clone/re-migrate as the Perforce migra
The test creates a "super" directory that is not removed after the
test finished. This directory is not used in any subsequent tests and
should therefore be removed.
Signed-off-by: Lars Schneider
---
I just noticed that my bug report test does not run properly without this
patch:
htt
It looks like as if submodule configs ("submodule.*") for submodules
with upper case names are ignored. The test cases shows that skipping
a submodule during a recursive clone seems not to work.
Signed-off-by: Lars Schneider
---
I observed the bug on Windows, macOS, and Linux and a
> On 11 Feb 2017, at 14:58, René Scharfe wrote:
>
> Add a semantic patch for removing checks that cause free(3) to only be
> called with a NULL pointer, as that must be a programming mistake.
>
> Signed-off-by: Rene Scharfe
> ---
> No cases are found in master or next, but 1d263b93 (bisect--he
s were not
removed in a git-p4 cloned Git repository because the path names did not
match.
Fix this by moving the re-encoding to a place that affects "added" and
"removed" paths. Add a test to demonstrate the issue.
Signed-off-by: Lars Schneider
---
Hi,
unfortunately, I miss
> On 06 Feb 2017, at 20:10, Junio C Hamano wrote:
>
> Johannes Schindelin writes:
>
>> So I thought maybe the From: line (from the body, if available, otherwise
>> from the header) in conjunction with the "Date:" header would work.
>
> FYI, I use a post-applypatch hook to populate refs/notes/
> On 26 Jan 2017, at 10:14, Lars Schneider wrote:
>
>
>> On 25 Jan 2017, at 23:51, Junio C Hamano wrote:
>>
>> Jeff King writes:
>>
>>> I guess the way to dig would be to add a test that looks at the output
>>> of "type mv" or so
> On 25 Jan 2017, at 23:51, Junio C Hamano wrote:
>
> Jeff King writes:
>
>> I guess the way to dig would be to add a test that looks at the output
>> of "type mv" or something, push it to a Travis-hooked branch, and then
>> wait for the output
>
> Sounds tempting ;-)
Well, I tried that:
mv
> On 24 Jan 2017, at 14:27, Jeff King wrote:
>
> On Tue, Jan 24, 2017 at 11:04:21AM +0100, Lars Schneider wrote:
>
>> "fsck: prepare dummy objects for --connectivity-check" seems to
>> make t1450-fsck.sh fail on macOS with TravisCI:
>>
>> Ini
> On 24 Jan 2017, at 01:18, Junio C Hamano wrote:
>
> * jk/fsck-connectivity-check-fix (2017-01-17) 6 commits
> (merged to 'next' on 2017-01-23 at e8e9b76b84)
> + fsck: check HAS_OBJ more consistently
> + fsck: do not fallback "git fsck " to "git fsck"
> + fsck: tighten error-checks of "git fsc
> On 23 Jan 2017, at 20:38, Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
>> So you are worried about the case where somebody on a case
>> insensitive but case preserving system would do
>>
>> $ edit file.txt
>> $ edit .gitattributes
>> $ git add file.txt .gitattributes
>>
>> and
> On 23 Jan 2017, at 19:35, Junio C Hamano wrote:
>
> Dakota Hawkins writes:
>
>> Apologies for the delayed bump. I think because we're talking about
>> affecting the behavior of .gitattributes that it would be better to
>> have a distinct .gitattributes option, whether or not you also have a
> On 23 Jan 2017, at 19:22, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> Could you fast track the patch to `maint` if it works without trouble on
>> `next` (as it should!)?
>>
>> Notes:
>>Base Commit: 787f75f056 (master)
>
> I do not think there is any difference betwee
/homebrew-cask/pull/29180
[4] https://caskroom.github.io/
Signed-off-by: Lars Schneider
---
Hi,
this small update removes one more unnecessary line and makes the
formula name lower case (no functional reason - just looks better ;-).
@Junio: Do you prefer such a v2 as "--in-reply-to" t
> On 21 Jan 2017, at 13:02, George Vanburgh wrote:
>
> From: George Vanburgh
>
> When running git-p4 on Windows, with multiple git-p4.mapUser entries in
> git config - no user mappings are applied to the generated repository.
>
> Reproduction Steps:
>
> 1. Add multiple git-p4.mapUser entries
> On 09 Jan 2017, at 21:44, Stefan Beller wrote:
>
> On Mon, Nov 14, 2016 at 1:09 PM, Lars Schneider
> wrote:
>> Hi,
>>
>> Git always performs a clean/smudge filter on files in sequential order.
>> Sometimes a filter operation can take a noticeable amoun
> On 10 Jan 2017, at 23:11, Jakub Narębski wrote:
>
> W dniu 09.01.2017 o 00:42, Junio C Hamano pisze:
>> larsxschnei...@gmail.com writes:
>>> From: Lars Schneider
>>>
>>> Some `clean` / `smudge` filters might require a significant amount of
>
> On 10 Jan 2017, at 00:38, Taylor Blau wrote:
>
> I've been considering some alternative approaches in order to make the
> communication between Git and any extension that implements this protocol more
> intuitive.
>
> In particular, I'm considering alternatives to:
>
>> for each delayed
> On 08 Jan 2017, at 21:45, Eric Wong wrote:
>
> larsxschnei...@gmail.com wrote:
>> +++ b/t/t0021/rot13-filter.pl
>
>> +$DELAY{'test-delay1.r'} = 1;
>> +$DELAY{'test-delay3.r'} = 3;
>>
>> open my $debug, ">>", "rot13-filter.log" or die "cannot open log file: $!";
>>
>> @@ -166,6 +176,15 @@ wh
> On 08 Jan 2017, at 21:14, Torsten Bögershausen wrote:
>
> On Sun, Jan 08, 2017 at 08:17:36PM +0100, larsxschnei...@gmail.com wrote:
>> From: Lars Schneider
>>
>> Some `clean` / `smudge` filters might require a significant amount of
>> time to process a sin
> On 09 Jan 2017, at 00:42, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> Some `clean` / `smudge` filters might require a significant amount of
>> time to process a single blob. During this process the Git chec
> On 04 Jan 2017, at 09:08, Jeff King wrote:
>
> On Mon, Jan 02, 2017 at 05:03:57PM +0100, Johannes Schindelin wrote:
>
>> From: =?UTF-8?q?=EB=A7=88=EB=88=84=EC=97=98?=
>>
>> The `user-manual.txt` is designed as a `book` but the `Makefile` wants
>> to build it as an `article`. This seems to b
> On 28 Dec 2016, at 19:53, Jacob Keller wrote:
>
> On Tue, Dec 27, 2016 at 10:08 PM, Jeff King wrote:
>>
>> https://github.com/Autodesk/enterprise-config-for-git
>>
>> (with the disclaimer that I've never used it myself, so I have no
>> idea how good it is).
>>
>> I think you
> On 28 Dec 2016, at 00:11, Junio C Hamano wrote:
>
>
> * bw/realpath-wo-chdir (2016-12-22) 5 commits
> (merged to 'next' on 2016-12-22 at fea8fa870f)
> + real_path: canonicalize directory separators in root parts
> + real_path: have callers use real_pathdup and strbuf_realpath
> + real_path:
> On 29 Dec 2016, at 10:05, Igor Kushnir wrote:
>
> git-p4 crashes when used with a very old p4 client version
> that does not support the '-r ' option in its commands.
>
> Allow making git-p4 work with old p4 clients by setting git-p4.retries to 0.
>
> Alternatively git-p4.retries could be ma
> On 22 Dec 2016, at 23:18, Junio C Hamano wrote:
>
> 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
> On 13 Dec 2016, at 18:20, Christian Couder wrote:
>
> On Sat, Dec 3, 2016 at 7:47 PM, Lars Schneider
> wrote:
>>
>>> On 30 Nov 2016, at 22:04, Christian Couder
>>> wrote:
>>>
>>> Goal
>>>
>>>
>>> Git
> On 17 Dec 2016, at 15:28, Lars Schneider wrote:
>
>
>> On 16 Dec 2016, at 21:32, Ramsay Jones wrote:
>>
>> Hi Lars,
>>
>> For the last two days, I've noticed t0021.15 on the 'pu' branch has been
>> failing intermittently (we
> On 16 Dec 2016, at 21:32, Ramsay Jones wrote:
>
> Hi Lars,
>
> For the last two days, I've noticed t0021.15 on the 'pu' branch has been
> failing intermittently (well it fails with: 'make test >ptest-out', but
> when run by hand, it fails only say 1-in-6, 1-in-18, etc.).
>
> [yes, it's a bi
shes/debris_junk.FBX"
git commit -m "Move files properly to GitLFS"
git push
Afterwards you should be able to use the latest version of Git and GitLFS
without trouble.
Cheers,
Lars
PS: Top posting is not that popular in the Git community ;-)
>
> On 8 December 2016 at 13:57,
> On 08 Dec 2016, at 12:46, Nick Warr wrote:
>
> Using Git-2.11.0 with the latest git-lfs 1.5.2 (also tested with
> 1.5.3) cloning from our locally hosted gitlab CE server via HTTPS.
>
> When cloning a repo (large, 3.3 gig in git, 10.3 in LFS) for the
> first time the clone will finish the che
> On 04 Dec 2016, at 15:03, larsxschnei...@gmail.com wrote:
>
> From: Lars Schneider
Hi Junio,
if you decide to queue this patch and/or the "git-p4: fix empty file
processing for large file system backend GitLFS", please use my
signed-off address. I accidentally messed
> On 30 Nov 2016, at 22:04, Christian Couder wrote:
>
> Goal
>
>
> Git can store its objects only in the form of loose objects in
> separate files or packed objects in a pack file.
>
> To be able to better handle some kind of objects, for example big
> blobs, it would be nice if Git could
> On 15 Nov 2016, at 19:03, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> The filter itself would need to be aware of parallelism
>>> if it lives for multiple objects, right?
>>
>> Correct. This way Git doesn't need to deal with threadi
> On 17 Nov 2016, at 00:46, Junio C Hamano wrote:
>
> Jakub Narębski writes:
>
>>> I intend to implement this feature only for the new long running filter
>>> process protocol. OK with you?
>>
>> If I remember and understand it correctly, current version of long
>> running process protocol pr
> On 16 Nov 2016, at 19:15, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> * You'd need to rein in the maximum parallelism somehow, as you do
>>> not want to see hundreds of competing filter processes starting
>>> only to tell the main
On 15 Nov 2016, at 19:03, Junio C Hamano wrote:
> Lars Schneider writes:
>
>>> The filter itself would need to be aware of parallelism
>>> if it lives for multiple objects, right?
>>
>> Correct. This way Git doesn't need to deal with threading...
> On 15 Nov 2016, at 02:03, Eric Wong wrote:
>
> Lars Schneider wrote:
>> Hi,
>>
>> Git always performs a clean/smudge filter on files in sequential order.
>> Sometimes a filter operation can take a noticeable amount of time.
>> This blocks the e
> On 15 Nov 2016, at 13:07, Heiko Voigt wrote:
>
> On Fri, Nov 11, 2016 at 09:22:51AM +0100, Lars Schneider wrote:
>> To all macOS users on the list:
>> Does anyone execute the tests with GIT_TEST_HTTPD enabled successfully?
>
> Nope. The following tests fail for me
Hi,
Git always performs a clean/smudge filter on files in sequential order.
Sometimes a filter operation can take a noticeable amount of time.
This blocks the entire Git process.
I would like to give a filter process the possibility to answer Git with
"I got your request, I am processing it, ask
> On 13 Nov 2016, at 02:13, Junio C Hamano wrote:
>
> Johannes Schindelin writes:
>
>>> Thanks. Dscho, does this fix both of these issues to you?
>>
>> Apparently it does because the CI jobs for `master` and for `next` pass.
>
> OK, thanks for a quick confirmation.
>
>> The one for `pu` st
> On 11 Nov 2016, at 21:27, Jeff King wrote:
>
> On Fri, Nov 11, 2016 at 09:02:52PM +0100, Dennis Kaarsemaker wrote:
>
Are you sure about that? If I do:
echo url=https://example.com/repo.git |
git credential fill
I get prompted for a username and password.
>>>
>
> On 11 Nov 2016, at 22:22, Johannes Sixt wrote:
>
> Am 11.11.2016 um 22:07 schrieb Junio C Hamano:
>> Junio C Hamano writes:
>>
>>> OK, then let's have
>>>
>>> filter_git () {
>>> rm -f rot13-filter.log &&
>>> git "$@"
>>>...
>>>
>>> and call that
> On 11 Nov 2016, at 18:31, Lars Schneider wrote:
>
>>
>> On 11 Nov 2016, at 18:05, Lars Schneider wrote:
>>
>>
>>> On 11 Nov 2016, at 17:13, Johannes Schindelin
>>> wrote:
>>>
>>> Hi Junio,
>>>
>
> On 11 Nov 2016, at 18:05, Lars Schneider wrote:
>
>
>> On 11 Nov 2016, at 17:13, Johannes Schindelin
>> wrote:
>>
>> Hi Junio,
>>
>> On Thu, 10 Nov 2016, Junio C Hamano wrote:
>>
>>> Junio C Hamano writes:
>>>
>&g
> On 11 Nov 2016, at 17:13, Johannes Schindelin
> wrote:
>
> Hi Junio,
>
> On Thu, 10 Nov 2016, Junio C Hamano wrote:
>
>> Junio C Hamano writes:
>>
>>> I'll report back an updated schedule when able.
>>
>> I pushed some updates out on 'master' today.
>
> Which means that t0021 is now bro
On 11 Nov 2016, at 10:31, Jeff King wrote:
> On Fri, Nov 11, 2016 at 10:28:56AM +0100, Lars Schneider wrote:
>
>>> Yeah, that is the solution I was going to suggest. The credentials are
>>> totally orthogonal to the filters, and I would rather not shove them
>&g
On 10 Nov 2016, at 17:08, Jeff King wrote:
> On Thu, Nov 10, 2016 at 01:10:17PM +0100, Matthieu Moy wrote:
>
>> Lars Schneider writes:
>>
>>> I haven't looked at an implemenation approach at all. I wonder if this could
>>> be OK from a conceptio
On 11 Nov 2016, at 09:47, Jeff King wrote:
> On Fri, Nov 11, 2016 at 09:22:51AM +0100, Lars Schneider wrote:
>
>> There would be an alternative way to approach the problem:
>> Someone (GitHub?, BitBucket?, GitLab?, ...) could setup a bunch of webservers
>> with popular
On 10 Nov 2016, at 22:34, Junio C Hamano wrote:
> Lars Schneider writes:
>
>>> I've followed what was available at the public-inbox archive, but it
>>> is unclear what the conclusion was.
>>>
>>> For the first one your "how about"
On 10 Nov 2016, at 22:39, Johannes Schindelin
wrote:
> Hi Lars,
>
> On Wed, 9 Nov 2016, Lars Schneider wrote:
>
>> On 05 Nov 2016, at 10:50, Johannes Schindelin
>> wrote:
>>
>>> I finally got around to rebase the Windows-specific patches (which seem
On 10 Nov 2016, at 17:10, Jeff King wrote:
> On Thu, Nov 10, 2016 at 12:07:14PM +0100, Lars Schneider wrote:
>
>>> Using Apache in the tests has been the source of frequent portability
>>> problems and configuration headaches. I do wonder if we'd be better off
Hi,
we just implemented the first "real-world" user of the new clean/smudge
"filter protocol" interface (see "convert: add filter..process option"
edcc858 for details) and the results are fantastic. Filtering 12,000 files in
my artificial test repo is more than 60x faster (depending on the platfo
> On 10 Nov 2016, at 00:39, Junio C Hamano wrote:
>
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> Apple removed the OpenSSL header files in macOS and therefore Git does
>> not build out of the box on macOS anymore. See previous d
> On 07 Nov 2016, at 22:20, Jeff King wrote:
>
> On Sun, Nov 06, 2016 at 10:42:36PM +0100, Lars Schneider wrote:
>
>>> From: Lars Schneider
>>>
>>> TravisCI changed their default macOS image from 10.10 to 10.11 [1].
>>> Unfortunately the
On 05 Nov 2016, at 10:50, Johannes Schindelin
wrote:
> Dear Git users,
>
> I finally got around to rebase the Windows-specific patches (which seem to
> not make it upstream as fast as we get new ones) on top of upstream Git
> v2.11.0-rc0, and to bundle installers, portable Git and MinGit [*1*]
> On 09 Nov 2016, at 09:18, Torsten Bögershausen wrote:
>
> On 07.11.16 18:26, Jeff King wrote:
>> On Sun, Nov 06, 2016 at 08:35:04PM +0100, Lars Schneider wrote:
>>
>>> Good point. I think I found an even easier way to achieve the same.
>>>
> On 06 Nov 2016, at 20:31, Johannes Sixt wrote:
>
> Am 06.11.2016 um 16:45 schrieb Lars Schneider:
>>
>>> On 03 Nov 2016, at 21:22, Johannes Sixt wrote:
>>> This is a pure optimization that reduces the number of forks, which
>>> helps a bit on Window
> On 17 Oct 2016, at 02:25, larsxschnei...@gmail.com wrote:
>
> From: Lars Schneider
>
> TravisCI changed their default macOS image from 10.10 to 10.11 [1].
> Unfortunately the HTTPD tests do not run out of the box using the
> pre-installed Apache web server anymore. Ther
> On 17 Oct 2016, at 11:50, Jeff King wrote:
>
> On Sun, Oct 16, 2016 at 05:25:49PM -0700, larsxschnei...@gmail.com wrote:
>
>> From: Lars Schneider
>>
>> Apple removed the OpenSSL header files in macOS 10.11 and above. OpenSSL
>> was deprecated since mac
> On 03 Nov 2016, at 21:22, Johannes Sixt wrote:
>
> Instead of a pipeline with sed and a useless use of cat, return the
> unmodified text of wc -c from function file_size, but substitute the
> result with arithmetic expansion to get rid of the leading whitespace
> that some version of wc -c pri
> On 03 Nov 2016, at 21:12, Johannes Sixt wrote:
>
> Some versions of uniq -c write the count left-justified, other version
> write it right-justified. Be prepared for both kinds.
>
> Signed-off-by: Johannes Sixt
> ---
> Here it is as a proper patch.
>
> Am 03
> On 02 Nov 2016, at 19:23, Jeff King wrote:
>
> The rot13-filter.pl script calls methods on implicitly
> defined filehandles (STDOUT, and the result of an open()
> call). Prior to perl 5.13, these methods are not
> automatically loaded, and perl will complain with:
>
> Can't locate object me
501 - 600 of 1033 matches
Mail list logo
