On November 4, 2018 6:26 PM, Junio C Hamano, wrote:
> Johannes Sixt writes:
>
> > Am 03.11.18 um 09:14 schrieb Carlo Arenas:
> >> On Fri, Nov 2, 2018 at 9:44 AM Johannes Sixt wrote:
> >>>
> >>> + timeout = elapsed >= orig_timeout ? 0 : (int)(orig_timeout -
> >>> + elapsed);
> >>
> >> nitpic
> -Original Message-
> From: git-ow...@vger.kernel.org On Behalf Of
> Junio C Hamano
> Sent: November 18, 2018 19:07
> To: Torsten Bögershausen
> Cc: Steven Penny ; git@vger.kernel.org
> Subject: Re: Cygwin Git with Windows paths
>
> Torsten Bögershausen writes:
>
> > And it may even b
On November 29, 2018 6:56, Mateusz Loskot wrote:
> On Thu, 29 Nov 2018 at 12:50, Stefanie Leisestreichler
> wrote:
> >
> > git tag -a 0.9.0
> > git push origin master
> >
> > In my local repository, when I run "git tag" it is showing me "0.9.0".
> >
> > Then I did (on box B)
> > git clone ssh://us
On December 2, 2018 8:26, Ævar Arnfjörð Bjarmason wrote:
>
> On Sat, Dec 01 2018, Cameron Boehmer wrote:
>
> > 1) add a new flag
> > -l, --local
> > Do not consult git config --global core.excludesFile in
> > determining what files git ignores. This is useful in conjunction with
> > -x/-X to
ven if your user is "git" in all cases above. It is a bit hacky but it is part
of the SSH spec and is supported by git and EGit (as of 5.x).
Cheers,
Randall
--
Randall S. Becker
Managing Director, Nexbridge Inc.
LinkedIn.com/in/randallbecker
+1.416.984.9826
I feel really bad asking this, and I should know the answer, and yet.
I have a binary file that needs to go into a repo intact (unchanged). I also
have a program that interprets the contents, like a textconv, that can
output the relevant portions of the file in whatever format I like - used
for di
> -Original Message-
> From: git-ow...@vger.kernel.org On Behalf
> Of Johannes Sixt
> Sent: September 12, 2018 4:48 PM
> To: Randall S. Becker
> Cc: git@vger.kernel.org
> Subject: Re: [Question] Signature calculation ignoring parts of binary files
>
> A
On September 12, 2018 4:54 PM, I wrote:
> On September 12, 2018 4:48 PM, Johannes Sixt wrote:
> > Am 12.09.18 um 21:16 schrieb Randall S. Becker:
> > > I feel really bad asking this, and I should know the answer, and yet.
> > >
> > > I have a binary file
On September 12, 2018 7:00 PM, Junio C Hamano wrote:
> "Randall S. Becker" writes:
>
> >> author is important to our process. My objective is to keep the
> >> original file 100% exact as supplied and then ignore any changes to
> >> the metadata th
On September 13, 2018 11:03 AM, Junio C Hamano wrote:
> "Randall S. Becker" writes:
>
> > The scenario is slightly different.
> > 1. Person A gives me a new binary file-1 with fingerprint A1. This
> > goes into git unchanged.
> > 2. Person B gives me bina
On September 13, 2018 1:52 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > "Randall S. Becker" writes:
> >
> >> The scenario is slightly different.
> >> 1. Person A gives me a new binary file-1 with fingerprint A1. This
> >> go
On September 17, 2018 9:55 AM Taylor Blau wrote:
> On Sun, Sep 16, 2018 at 04:55:13PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > In the hypothetical git-annex-like case (simplifying a bit for the
> > purposes this explanation), for every FILE in your tree you have a
> > corresponding FILE.lock file,
On September 17, 2018 11:58 AM, Taylor Blau wrote:
> On Mon, Sep 17, 2018 at 05:00:10PM +0200, Ævar Arnfjörð Bjarmason
> wrote:
> > > 2. Multi-file locks, e.g., "I need to lock file(s) X, Y, and Z
> > > together." This isn't possible in Git LFS today with the existing
"git
> > > lfs loc
Hi All,
Does anyone know whether it is practical to rework git-lfs under a language
other than "go"? GCC is not even close to being possible to port to my
NonStop platform (may have tried, some have died - joke - trying). I would
like to convert this directly to C or something more widely portabl
On September 17, 2018 3:28 PM, Jonathan Nieder wrote:
> Randall S. Becker wrote:
>
> > Does anyone know whether it is practical to rework git-lfs under a
> > language other than "go"? GCC is not even close to being possible to
> > port to my NonStop platform (may
On September 17, 2018 6:01 PM, Taylor Blau wrote:
> On Mon, Sep 17, 2018 at 05:55:55PM -0400, Randall S. Becker wrote:
> > On September 17, 2018 3:28 PM, Jonathan Nieder wrote:
> > > Randall S. Becker wrote:
> > >
> > > > Does anyone know whether it
On September 17, 2018 6:02 PM, Jonathan Nieder wrote:
> Randall S. Becker wrote:
> > On September 17, 2018 3:28 PM, Jonathan Nieder wrote:
> >> Randall S. Becker wrote:
>
> >>> Does anyone know whether it is practical to rework git-lfs under a
> >>> la
On September 23, 2018 1:29 PM, John Austin wrote:
> I've been putting together a prototype file-locking implementation for a
> system that plays better with git. What are everyone's thoughts on
> something like the following? I'm tentatively labeling this system git-sync or
> sync-server. There are
On September 23, 2018 3:54 PM, John Austin wrote:
> On Sun, Sep 23, 2018 at 10:57 AM Randall S. Becker
> wrote:
> > I would even like to help with your effort and have non-unixy platforms I'd
> like to do this on.
> > Having this separate from git LFS is an even be
On June 5, 2018 5:24 PM, Steve Heinz wrote:
> I am new to Git and have read quite a few articles on it.
> I am planning on setting up a remote repository on a windows 2012 R2
server
> and will access it via HTTPS.
> I am setting up a local repository on my desk top (others in my group will
do
> the
On June 14, 2018 11:15 AM, Jeff King wrote:
> On Thu, Jun 14, 2018 at 10:13:42AM +, brian m. carlson wrote:
>
> > > I know that other git server environments like github support that
> > > on client side by allowing tokens to be used as usernames in a BASIC
> > > authentication flow. We could
On July 19, 2018 6:46 PM, Junio wrote:
> Jeff King writes:
>
> > For enforcement, we can rely on the compiler and just introduce code
> > which breaks compilation when it sees these functions. This has a few
> > advantages:
> >
> > 1. We know it's run as part of a build cycle, so it's
> >
On February 6, 2019 12:15, Torsten Bögershausen wrote:
> To: Johannes Schindelin
> Cc: SZEDER Gábor ; Jeff King ;
> git@vger.kernel.org
> Subject: Re: t0025 flakey?
>
> On Wed, Feb 06, 2019 at 02:52:53PM +0100, Johannes Schindelin wrote:
> > Hi Gábor,
> >
> > On Wed, 6 Feb 2019, SZEDER Gábor wrot
On February 6, 2019 13:01, I wrote:
> On February 6, 2019 12:15, Torsten Bögershausen wrote:
> > To: Johannes Schindelin
> > Cc: SZEDER Gábor ; Jeff King ;
> > git@vger.kernel.org
> > Subject: Re: t0025 flakey?
> >
> > On Wed, Feb 06, 2019 at 02:52:53PM +0100, Johannes Schindelin wrote:
> > > Hi G
On February 7, 2019 18:57, SZEDER Gábor wrote:
> On Thu, Feb 07, 2019 at 11:58:08AM -0500, Randall S. Becker wrote:
> > > The NonStop port has traditionally had issues with t0025, which we
> > > tended to ignore because things did work. We wrote those off as bash
> > &g
Hi All,
We have a few new breakages on the NonStop port in 2.21.0-rc0. The first is in
t5403, as below:
/home/git/git/t/trash
directory.t5403-post-checkout-hook/clone3/.git/hooks/post-checkout: line 2:
$GIT_DIR/post-checkout.args: ambiguous redirect
not ok 8 - post-checkout hook is triggered b
On February 8, 2019 5:56, Johannes Schindelin wrote:
> To: Randall S. Becker
> Cc: 'Junio C Hamano' ; git@vger.kernel.org; 'Linux
> Kernel' ; git-packag...@googlegroups.com
> Subject: Re: [Breakage] Git v2.21.0-rc0 - t5403 (NonStop)
>
> Hi Randall,
>
Hi All,
t5318 is rather problematic and I have no good way to fix this. There is no
/dev/zero on the platform, and the corrupt_graph_and_verify hard-codes
if=/dev/zero, which is a linux-specific pseudo device. Please provide a more
platform independent way of testing this feature. Pretty much a
From: "Randall S. Becker"
The embedded blanks in the full path of the test git repository cased bash
to generate an ambugious redirect error.
Signed-off-by: Randall S. Becker
---
t/t5403-post-checkout-hook.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/
On February 8, 2019 6:10, SZEDER Gábor
> On Fri, Feb 08, 2019 at 05:48:27AM -0500, Randall S. Becker wrote:
> > We have a few new breakages on the NonStop port in 2.21.0-rc0. The first
> is in t5403, as below:
> >
> > /home/git/git/t/trash
> > directory.t5403-post-c
Hi All,
We have suddenly encountered a hung git-http-backend in t5562 in the NonStop
port. This is a new problem not seen before on the platform, surprisingly. I
am wondering whether this is a result of not actually having an apache2
server on-board. Is that a possibility and can that sub-test be
On February 8, 2019 11:51, Jeff King wrote:
> On Fri, Feb 08, 2019 at 06:08:33AM -0500, Randall S. Becker wrote:
>
> > t5318 is rather problematic and I have no good way to fix this. There
> > is no /dev/zero on the platform, and the corrupt_graph_and_verify
> > hard-code
On February 8, 2019 13:03, Jeff King wrote:
> To: Randall S. Becker
> Cc: 'Junio C Hamano' ; git@vger.kernel.org; 'Linux
> Kernel' ; git-packag...@googlegroups.com
> Subject: Re: [Breakage] Git v2.21.0-rc0 - t5318 (NonStop)
>
> On Fri, Feb 08, 2019 at 12:
On February 8, 2019 14:15, Jeff King wrote:
> On Fri, Feb 08, 2019 at 01:47:04PM -0500, Randall S. Becker wrote:
>
> > > Though I suspect we may be able to just find a solution that works
> > > everywhere, without having two different implementations. If we know
> >
From: "Randall S. Becker"
The corrupt_graph_and_verify method has been modified to use
truncate instead of the /dev/zero pseudo-device, which breaks on
platforms where the pseudo-device does not exist. truncate extends
files to a specified length filling with nulls, providing a simila
> -Original Message-
> From: Jeff King
> Sent: February 8, 2019 14:32
> To: Randall S. Becker
> Cc: 'Junio C Hamano' ; git@vger.kernel.org; 'Linux
> Kernel' ; git-packag...@googlegroups.com
> Subject: Re: [Breakage] Git v2.21.0-rc0 - t5318 (No
t1308 has me perplexed - this is an old breakage on the NonStop platform,
that I have just gotten around to checking with the new bash version we
have. When running sub-test 23, the following was reported:
Value not found for "foo.bar"
test_expect_code: command exited with 1, we wanted 2 test-tool
On February 8, 2019 16:01, Jeff King wrote:
> On Fri, Feb 08, 2019 at 03:38:05PM -0500, Randall S. Becker wrote:
>
> > > Exactly (if we even care about them being NULs; otherwise, we can
> > > omit the "tr" invocation).
> >
> > I'm a bit perplexe
From: "Randall S. Becker"
Replaced subtest 15 (CONTENT_LENGTH overflow ssite_t) use of /dev/zero
with yes and a translation of its result to a stream of NULL. This is
a more portable solution.
Signed-off-by: Randall S. Becker
---
t/t5562-http-backend-content-length.sh | 6
Please disregard this.. I left garbage inside.
> -Original Message-
> From: git-ow...@vger.kernel.org On Behalf
> Of randall.s.bec...@rogers.com
> Sent: February 8, 2019 16:59
> To: git@vger.kernel.org
> Cc: Randall S. Becker
> Subject: [Fix v1] t5562: remove de
From: "Randall S. Becker"
Replaced subtest 15 (CONTENT_LENGTH overflow ssite_t) use of /dev/zero
with yes and a translation of its result to a stream of NULL. This is
a more portable solution.
Signed-off-by: Randall S. Becker
---
t/t5562-http-backend-content-length.sh | 4 ++--
1 fi
On February 8, 2019 17:07, brian m. carlson wrote:
> On Fri, Feb 08, 2019 at 02:31:57PM -0500, Jeff King wrote:
> > > It is available AFAIK on Linux, POSIX, and Windows under Cygwin.
> > > That's more than /dev/zero has anyway. I have the patch ready if you
> > > want it.
> >
> > Is it POSIX? Certa
On February 8, 2019 17:19, brian m. carlson wrote:
> On Fri, Feb 08, 2019 at 05:12:43PM -0500, Randall S. Becker wrote:
> > I'm happy to modify the test (it is in one spot), to make a decision based
> on:
> > a) whether /dev/zero exists
> > b) whether the system is a
On February 8, 2019 17:35, Jeff King wrote:
> On Fri, Feb 08, 2019 at 05:12:43PM -0500, Randall S. Becker wrote:
> > On February 8, 2019 17:07, brian m. carlson wrote:
> > > On Fri, Feb 08, 2019 at 02:31:57PM -0500, Jeff King wrote:
> > > > > It is available A
On February 8, 2019 23:25, Jeff King wrote:
> On Fri, Feb 08, 2019 at 05:53:53PM -0500, Randall S. Becker wrote:
>
> > > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh index
> > > 92cf8f812c..4afab14431 100644
> > > --- a/t/test-lib-functions.sh
&g
On February 9, 2019 3:40, Johannes Sixt wrote:
> Am 09.02.19 um 05:24 schrieb Jeff King:
> > On Fri, Feb 08, 2019 at 05:53:53PM -0500, Randall S. Becker wrote:
> >
> >>> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh index
> >>> 92cf8f812c..4
On February 8, 2019 18:39, Junio C Hamano wrote:
> randall.s.bec...@rogers.com writes:
> > Replaced subtest 15 (CONTENT_LENGTH overflow ssite_t) use of /dev/zero
> > with yes and a translation of its result to a stream of NULL. This is
> > a more portable solution.
> >
&
From: "Randall S. Becker"
The default bash is now officially in /usr/coreutils/bin instead
of in /usr/local/bin. This version of bash is more stable and
recommended for all use as of the J06.22 and L18.02 operating
system revision levels. This new version provides more stability
of te
From: "Randall S. Becker"
The default bash is now officially in /usr/coreutils/bin instead
of in /usr/local/bin. This version of bash is more stable and
recommended for all use as of the J06.22 and L18.02 operating
system revision levels. This new version provides more stability
of te
On February 8, 2019 23:24, Jeff King wrote:
> On Fri, Feb 08, 2019 at 04:42:19PM -0500, Randall S. Becker wrote:
>
> > t1308 has me perplexed - this is an old breakage on the NonStop
> > platform, that I have just gotten around to checking with the new bash
> > version w
From: "Randall S. Becker"
This change removes the dependency on /dev/zero with an equivalent pipe of
deliberately NUL bytes. This allows tests to proceed where /dev/zero
does not exist.
Signed-off-by: Randall S. Becker
---
t/t5562-http-backend-content-length.sh | 4 ++--
1 file
From: "Randall S. Becker"
This is a candidate packages of fixes to remove dependence on /dev/zero
and replaces it with the generate_zero_bytes function in test-lib-functions.sh
Randall S. Becker (3):
test-lib-functions.sh: add generate_zero_bytes function
t5318: replace use of
From: "Randall S. Becker"
This change removes the dependency on /dev/zero with generate_zero_bytes
appending NUL values to blocks generating wrong signatures for test cases.
Signed-off-by: Randall S. Becker
---
t/t5318-commit-graph.sh | 2 +-
1 file changed, 1 insertion(+),
From: "Randall S. Becker"
t5318 and t5562 used /dev/zero, which is not portable. This function
provides both a fixed block of NUL bytes and an infinite stream of NULs.
Signed-off-by: Randall S. Becker
---
t/test-lib-functions.sh | 13 +
1 file changed, 13 insertions(+)
On February 9, 2019 13:25, Junio C Hamano wrote:
> Johannes Sixt writes:
>
> > How many bytes are needed here? yes() in test-lib.sh generates only 99
> > 'y', if I am not mistaken.
>
> I think we will not use "yes" in the end for this topic, which makes this
> comment totally irrelevant to the t
Hi All,
I found this while trying to track down a hang in t5562 - this isn't the
fix, but here it is something that could be considered a code-inspection. If
there have been random unexplained hangs when git runs as a daemon, this
might be the cause.
According to many systems (other than Linux),
On February 8, 2019 7:23, I wrote:
> We have suddenly encountered a hung git-http-backend in t5562 in the
> NonStop port. This is a new problem not seen before on the platform,
> surprisingly. I am wondering whether this is a result of not actually
having an
> apache2 server on-board. Is that a pos
On February 9, 2019 18:33, Jeff King wrote:
> On Sat, Feb 09, 2019 at 01:08:01PM -0500, Randall S. Becker wrote:
>
> > > It sounds like you might need to set FREAD_READS_DIRECTORIES in your
> > > config.mak.
> >
> > Setting FREAD_READS_DIRECTORIES = Unfortuna
From: "Randall S. Becker"
The NonStop platform needs this configuration item specified as
UnfortunatelyYes so that config directory files are correctly processed.
Signed-off-by: Randall S. Becker
---
config.mak.uname | 1 +
1 file changed, 1 insertion(+)
diff --git a/config.m
Hi All,
I tracked down a breakage in t1404 subtest 52. The line
test_i18ngrep "Unable to create $Q.*packed-refs.lock$Q: File exists" err
is correctly working, but is reporting a completion 1.
The verbose output, with diagnostics, is:
error: 'grep Unable to create '.*packed-refs.lock': File exi
On February 9, 2019 21:05, Eric Sunshine wrote:
> On Sat, Feb 9, 2019 at 1:59 PM wrote:
> > t5318 and t5562 used /dev/zero, which is not portable. This function
> > provides both a fixed block of NUL bytes and an infinite stream of NULs.
> >
> > Signed-off-by: Randall
On February 11, 2019 4:57, Duy Nguyen wrote:
> On Mon, Feb 11, 2019 at 2:09 AM Randall S. Becker
> wrote:
> >
> > Hi All,
> >
> > I tracked down a breakage in t1404 subtest 52. The line
> >
> > test_i18ngrep "Unable to create $Q.*packed-refs.lock$Q:
Hi All,
I have localized the hang in t5562 (previous thread) to the
invoke-with-content-length.pl script. At least on NonStop, what happens is
that the perl process hangs waiting for close($out) to complete whether
explicitly or implicitly (if the call is removed). The trace for the perl
process s
On February 11, 2019 15:57, Junio C Hamano wrote:
> "Randall S. Becker" writes:
>
> > Hi All,
> >
> > I found this while trying to track down a hang in t5562 - this isn't
> > the fix, but here it is something that could be considered a
> > cod
On February 11, 2019 16:07, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > On Mon, Feb 11, 2019 at 2:09 AM Randall S. Becker
> > wrote:
> >>
> >> Hi All,
> >>
> >> I tracked down a breakage in t1404 subtest 52. The line
> >>
&g
On February 11, 2019 21:59, Junio C Hamano wrote:
> "Randall S. Becker" writes:
>
> >> In any case, no matter what POSIX says, if clearing .revents before
> > calling
> >> poll() helps on platforms in the real world, the patch is worth
> >> taking
> -Original Message-
> From: Junio C Hamano On Behalf Of Junio C Hamano
> Sent: February 13, 2019 12:25
> To: Eric Sunshine
> Cc: randall.s.bec...@rogers.com; Git List ; Randall
S.
> Becker
> Subject: Re: [Patch v1 2/3] t5318: replace use of /dev/zero with
On February 13, 2019 12:41, Max Kirillov wrote:
> On Wed, Feb 13, 2019 at 10:16:26AM -0500, randall.s.bec...@rogers.com
> wrote:
> > On 2019-02-13, Max Kirillov, wrote:
> > As far as the unintended reuse of the output file, and issues with
> > pipes, yes, the NonStop is very sensitive to complex us
On February 13, 2019 16:01, Junio C Hamano wrote:
> "Randall S. Becker" writes:
>
> > My second attempt was to create the generate_zero_bytes function to
> > replace exactly what the second dd was doing but not user /dev/zero.
>
> Yes, and I think the pa
On February 13, 2019 22:33, Junio C Hamano wrote:
> A release candidate Git v2.21.0-rc1 is now available for testing at the usual
> places. It is comprised of 464 non-merge commits since v2.20.0, contributed
> by 60 people, 14 of which are new faces.
We are currently running through a full regres
e the lock. And
> > there, checking for just "Unable to create $Q.*packed-refs.lock" would
> > be sufficient.
>
> Yup.
>
> As this came from 6a2a7736 ("t1404: demonstrate two problems with
> reference transactions", 2017-09-08), that is as old
On February 14, 2019 16:33, Johannes Schindelin wrote:
> To: git@vger.kernel.org
> Cc: Randall Becker ; Junio C Hamano
>
> Subject: [PATCH 0/1] Fix hang in t5562, introduced in v2.21.0-rc1
>
> The last-minute patch to replace /dev/zero with a Perl script snippet broke
> the Linux part of the CI b
On February 14, 2019 16:37, Johannes Schindelin wrote:
> On Thu, 14 Feb 2019, Randall S. Becker wrote:
>
> > t5562 still hangs (blocking) - this breaks our CI pipeline since the
> > test hangs and we have no explanation of whether the hang is in git or
> > the tests.
>
On February 14, 2019 17:34, Max Kirillov wrote:
> On Thu, Feb 14, 2019 at 05:17:26PM -0500, Randall S. Becker wrote:
> > Unfortunately, subtest 13 still hangs on NonStop, even with this
> > patch, so our Pipeline still hangs. I'm glad it's better on Azure, but
> &
On February 14, 2019 17:39, Junio C Hamano wrote:
> To: Randall S. Becker
> Cc: 'Johannes Schindelin via GitGitGadget' ;
> git@vger.kernel.org; 'Max Kirillov'
> Subject: Re: [PATCH 0/1] Fix hang in t5562, introduced in v2.21.0-rc1
>
> "Randall S. Bec
On February 14, 2019 17:34, Max Kirillov wrote:
> To: Randall S. Becker
> Cc: 'Johannes Schindelin via GitGitGadget' ;
> git@vger.kernel.org; 'Junio C Hamano' ; 'Max Kirillov'
>
> Subject: Re: [PATCH 0/1] Fix hang in t5562, introduced in v2.21.0-rc1
On February 14, 2019 17:34, Max Kirillov wrote:
> To: Randall S. Becker
> Cc: 'Johannes Schindelin via GitGitGadget' ;
> git@vger.kernel.org; 'Junio C Hamano' ; 'Max Kirillov'
>
> Subject: Re: [PATCH 0/1] Fix hang in t5562, introduced in v2.21.0-rc1
On February 14, 2019 22:48, Max Kirillov wrote:
> To: Randall S. Becker
> Cc: 'Max Kirillov' ; 'Johannes Schindelin via
GitGitGadget'
> ; git@vger.kernel.org; 'Junio C Hamano'
>
> Subject: Re: [PATCH 0/1] Fix hang in t5562, introduced in v2.21.0-rc
On February 15, 2019 8:02, SZEDER Gábor wrote:
> To: Johannes Schindelin
> Cc: Randall S. Becker ; 'Junio C Hamano'
> ; git@vger.kernel.org; 'Max Kirillov'
>
> Subject: Re: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results)
>
> On Thu, Feb 14, 2019 at 10
209185930.5256-4-
> randall.s.bec...@rogers.com/
>
> Reported-by: Randall S. Becker
> Signed-off-by: Max Kirillov
> ---
> By the way, I don't think this requires such sofisticated fix. In the
success
> case the input would not be read at all.
> You could replace it with /dev/nul
On February 15, 2019 13:01, Junio C Hamano wrote:
> To: Randall S. Becker
> Cc: 'Max Kirillov' ; git@vger.kernel.org; 'Johannes
> Schindelin'
> Subject: Re: [PATCH] t5562: do not depend on /dev/zero
>
> "Randall S. Becker" writes:
>
>
On February 15, 2019 15:37, Max Kirillov wrote:
> On Fri, Feb 15, 2019 at 02:02:13PM +0100, SZEDER Gábor wrote:
> > I haven't yet seen that hang in the wild and couldn't reproduce it on
> > purpose, but there is definitely something fishy with t5562 even on
> > Linux and even without that perl gene
On February 15, 2019 8:50, I wrote:
> On February 15, 2019 8:02, SZEDER Gábor wrote:
> > To: Johannes Schindelin
> > Cc: Randall S. Becker ; 'Junio C Hamano'
> > ; git@vger.kernel.org; 'Max Kirillov'
> >
> > Subject: Re: [ANNOUNCE] Git v2.21
On February 16, 2019 3:27, Max Kirillov wrote:
> On Fri, Feb 15, 2019 at 04:13:15PM -0500, Randall S. Becker wrote:
> > Sadly, the fix does not change the results. In fact, it makes the hang
> > far more likely. Subtest 6,7,8 fails here, at close()
>
> Correct, I did not expe
y 16, 2019 3:27, Max Kirillov wrote:
> > On Fri, Feb 15, 2019 at 04:13:15PM -0500, Randall S. Becker wrote:
> > > Sadly, the fix does not change the results. In fact, it makes the
> > > hang far more likely. Subtest 6,7,8 fails here, at close()
> >
> > Correct,
On February 16, 2019 13:06, Junio C Hamano wrote:
> "Randall S. Becker" writes:
> > On February 16, 2019 3:27, Max Kirillov wrote:
> >> What you could try is
> >> https://public-inbox.org/git/20181124093719.10705-1-
> m...@max630.net/
> >> (I
On February 17, 2019 8:50, Joe Ranieri wrote:
> "git ls-files -m" can show deleted files, despite -d not having been
> specified.
> This is due to ls-files.c's show_files function calling lstat but not
> checking the
> return value before calling ie_modified with the uninitialized stat structure.
From: "Randall S. Becker"
The result from lstat, checking whether a file has been deleted, is now
included priot to calling id_modified when showing modified files. Prior
to this fix, it is possible that files that were deleted could show up
as being modified because the lstat
On February 17, 2019 12:05, Ramsay Jones wrote:
> On 17/02/2019 16:34, randall.s.bec...@rogers.com wrote:
> > From: "Randall S. Becker"
> >
> > The result from lstat, checking whether a file has been deleted, is
> > now included priot to calling id_modified w
On February 18, 2019 5:47, Senol Yazici
> I just stumbled over following page
>
> https://git-scm.com/about/distributed
>
> and was wondering if it is possible to
>
> - demilitarise that “dictator/lieutenant” thing and
> - de-religionise that “blessed” thing
>
> I did not had the feeling that g
On February 18, 2019 10:17, SZEDER Gábor wrote:
> To: Joe Ranieri
> Cc: git@vger.kernel.org
> Subject: Re: [BUG] ls-files showing deleted files (unchecked lstat return
> value)
>
> On Sun, Feb 17, 2019 at 08:49:39AM -0500, Joe Ranieri wrote:
> > "git ls-files -m" can show deleted files, despite -
On February 18, 2019 11:13, I wrote:
> To: 'Senol Yazici' ; git@vger.kernel.org
> Subject: RE: Delivery Status Notification (Failure)
>
> On February 18, 2019 5:47, Senol Yazici
> > I just stumbled over following page
> >
> > https://git-scm.com/about/distributed
> >
> > and was wondering if it is
On February 18, 2019 13:46, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > I have been wondering about the whole /dev/zero business. Although we
> > have b46221ff ("Merge branch 'rb/no-dev-zero-in-test'",
> > 2019-02-13) in 'master', "git grep /dev/zero t" has hits in
> > t/helper/test-sha
On February 18, 2019 15:25, Max Kirillov wrote:
> On Sat, Feb 16, 2019 at 10:57:52AM -0800, Junio C Hamano wrote:
> > I'm inclined to
> >
> > - keep b46221ff in 'master', not reverted.
>
> from the branch, cc95bc2025 "t5562: replace /dev/zero with a pipe from
> generate_zero_bytes" could be repla
On February 18, 2019 15:41, Johannes Schindelin wrote:
> On Thu, 14 Feb 2019, Randall S. Becker wrote:
>
> > On February 14, 2019 17:39, Junio C Hamano wrote:
> > > To: Randall S. Becker
> > > Cc: 'Johannes Schindelin via GitGitGadget' ;
> > > g
On February 18, 2019 15:50, Max Kirillov wrote:
> To: SZEDER Gábor ; git@vger.kernel.org
> Cc: Max Kirillov ; Johannes Schindelin
> ; Randall S. Becker
> ; 'Junio C Hamano'
> Subject: [PATCH] t5562: chunked sleep to avoid lost SIGCHILD
>
> If was found during stres
On February 18, 2019 15:47, I wrote:
> On February 18, 2019 15:41, Johannes Schindelin wrote:
> > On Thu, 14 Feb 2019, Randall S. Becker wrote:
> >
> > > On February 14, 2019 17:39, Junio C Hamano wrote:
> > > > To: Randall S. Becker
> > >
On February 18, 2019 15:41, Johannes Schindelin wrote:
> To: Randall S. Becker
> Cc: 'Junio C Hamano' ; 'Johannes Schindelin via
> GitGitGadget' ; git@vger.kernel.org; 'Max
Kirillov'
>
> Subject: RE: [PATCH 0/1] Fix hang in t5562, introduced in v2.
not reported as completed, and the overall build
fails,
> and there seem to no additional data except the log available.
>
> Have you or somebody else been investigating it or is there otherwise any
> information about those hangs?
The no-reuse hack made a big different
(https://publi
On February 19, 2019 18:29, Junio C Hamano wrote:
> A release candidate Git v2.21.0-rc2 is now available for testing at the usual
> places. It is comprised of 474 non-merge commits since v2.20.0, contributed
> by 61 people, 16 of which are new faces.
Thanks. t5562 works properly on NonStop (3 tes
101 - 200 of 443 matches
Mail list logo
