Hi,
sorry for the delay...
On 22/04/16 01:11 AM, Jeff King wrote:
On Thu, Apr 14, 2016 at 10:59:57AM -0400, Eric Chamberland wrote:
just cloned a repo and it checked-out wihtout any error (with git 2.2.0) but
got come corrupted files (because I got some sdd failures).
Then, I get a git core
Hi,
just cloned a repo and it checked-out wihtout any error (with git 2.2.0)
but got come corrupted files (because I got some sdd failures).
Then, I get a git core dump when trying to "git status" into the repo
which have a "bad sector" on sdd drive (crypted partition).
I tried with git
Hi Junio,
On 03/07/2013 06:33 PM, Junio C Hamano wrote:
Eric Chamberland eric.chamberl...@giref.ulaval.ca writes:
What you want is a way to compute, given a set of tags (or refs in
general) and a set of branches (or another set of refs in general),
find the ones in the former that none
Hi,
On 01/23/2013 01:34 PM, Sébastien Boisvert wrote:
Hello,
Here is a patch (with git format-patch) that removes any timer if
NO_SETITIMER is set.
Even with the patch, I finally got an error... :-/
Here are the log (strace -f) of a clean execution and one with the error:
So, hum, do we have some sort of conclusion?
Shall it be a fix for git to get around that lustre behavior?
If something can be done in git it would be great: it is a *lot* easier
to change git than the lustre filesystem software for a cluster in
running in production mode... (words from
On 01/22/2013 05:14 PM, Thomas Rast wrote:
Eric Chamberland eric.chamberl...@giref.ulaval.ca writes:
So, hum, do we have some sort of conclusion?
Shall it be a fix for git to get around that lustre behavior?
If something can be done in git it would be great: it is a *lot*
easier to change
Hi,
It just happened again. Now I have the strace -f output gzipped here:
http://www.giref.ulaval.ca/~ericc/strace-f_git_error.txt.gz
thanks,
Eric
On 01/21/2013 08:29 AM, Erik Faye-Lund wrote:
On Fri, Jan 18, 2013 at 6:50 PM, Eric Chamberland
eric.chamberl...@giref.ulaval.ca wrote:
Good
On 01/21/2013 12:07 PM, Eric Chamberland wrote:
Hi,
It just happened again. Now I have the strace -f output gzipped here:
http://www.giref.ulaval.ca/~ericc/strace-f_git_error.txt.gz
I added the strace -f output when non error occurs...
http://www.giref.ulaval.ca/~ericc/strace
/strace/
-Original Message-
From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On
Behalf Of Maxime Boissonneault
Sent: Thursday, January 17, 2013 11:41 AM
To: Pyeron, Jason J CTR (US)
Cc: Eric Chamberland; Philippe Vaucher; git@vger.kernel.org; Sébastien
Boisvert
Subject: Re
object!
So now I am convinced that it is not a thread problem
I am kind of discouraged, we like to use git, but in this case we have
this error which seems unsolvable!
Anyone has a new idea?
Thanks,
Eric
On 01/09/2013 04:20 PM, Eric Chamberland wrote:
Hi Brian,
On 01/08/2013 11:11 AM
On 01/17/2013 09:23 AM, Philippe Vaucher wrote:
Anyone has a new idea?
Did you try Jeff King's code to confirm his idea?
Philippe
Yes I did, but it was running without any problem
I find that my test case is simple (fresh git clone then git gc in a
crontab), I bet anyone who has
Hi Brian,
On 01/08/2013 11:11 AM, Eric Chamberland wrote:
On 12/24/2012 10:11 AM, Brian J. Murrell wrote:
Have you tried adding a -q to the git command line to quiet down git's
feedback messages?
I moved to git 1.8.1 and added the -q to the command git gc but it
occured to return
On 12/24/2012 10:11 AM, Brian J. Murrell wrote:
Have you tried adding a -q to the git command line to quiet down git's
feedback messages?
Ok, I have modified my crontab to use -q and I will wait to see if the
problem occurs from now.
I discovered other oddities with using git on Lustre
Hi,
we are using git since may and all is working fine for all of us (almost
20 people) on our workstations. However, when we clone our repositories
to the cluster, only and only there
we are having many problems similiar to this post:
14 matches
Mail list logo
