On 09/27, Beyondhorizon Zheng wrote:
> [git issue] git am failed for patches of converting the file format of
> source codes from dos to unix
>
> Git version: git version 2.23.0
> Host PC: ubuntu 16.04.10
> Reporter: Shuang Zheng
>
> I have submitted a patch which co
[git issue] git am failed for patches of converting the file format of
source codes from dos to unix
Git version: git version 2.23.0
Host PC: ubuntu 16.04.10
Reporter: Shuang Zheng
I have submitted a patch which convert the file format of source file
from dos to unix with command:
dos2unix misc
On Fri, Jun 28, 2019 at 04:18:37PM +, Vanak, Ibrahim wrote:
> But HPUX Dev team have seen one significance difference, when they
> were triaging this issue, the ways GIT operations handled by 2 OSs: On
> linux, around 40 processes are spawned for handling a GIT operation
> whereas on HPUX only
day, June 18, 2019 10:45 PM
To: Vanak, Ibrahim ; Jeff King
Cc: git@vger.kernel.org
Subject: Re: GIT issue while cloning (fatal: pack is corrupted (SHA1 mismatch))
!!!
On 6/18/2019 10:31 AM, Vanak, Ibrahim wrote:
> Hello ALL again,
>
> Has anyone tested the performance of GIT on H
On 6/18/2019 10:31 AM, Vanak, Ibrahim wrote:
Hello ALL again,
Has anyone tested the performance of GIT on HP-UX platform? Can someone please
look into the issue we are seeing.
Thanks,
Ibrahim
You might try setting some of the GIT_TRACE* environment variables
listed in [1] on both your HP
sage-
From: Jeff King [mailto:p...@peff.net]
Sent: Thursday, May 30, 2019 5:28 PM
To: Vanak, Ibrahim
Cc: git@vger.kernel.org
Subject: Re: GIT issue while cloning (fatal: pack is corrupted (SHA1 mismatch))
!!!
On Wed, May 29, 2019 at 09:06:18AM +, Vanak, Ibrahim wrote:
> After cloning
May 30, 2019 5:28 PM
To: Vanak, Ibrahim
Cc: git@vger.kernel.org
Subject: Re: GIT issue while cloning (fatal: pack is corrupted (SHA1 mismatch))
!!!
On Wed, May 29, 2019 at 09:06:18AM +, Vanak, Ibrahim wrote:
> After cloning when I tried to checkout a branch on HPUX and Linux, I
On Wed, May 29, 2019 at 09:06:18AM +, Vanak, Ibrahim wrote:
> After cloning when I tried to checkout a branch on HPUX and Linux, I
> still significant time difference there as well even though network is
> not involve here. Do you suspect anything with HPUX OS? Do you have
> any mechanism to f
Message-
From: Vanak, Ibrahim
Sent: Wednesday, May 29, 2019 10:59 AM
To: Jeff King
Cc: git@vger.kernel.org
Subject: RE: GIT issue while cloning (fatal: pack is corrupted (SHA1 mismatch))
!!!
Hello Jeff,
Thanks again for the response.
I am not building GIT and also don't know either how to b
, May 29, 2019 3:00 AM
To: Vanak, Ibrahim
Cc: git@vger.kernel.org
Subject: Re: GIT issue while cloning (fatal: pack is corrupted (SHA1 mismatch))
!!!
On Tue, May 28, 2019 at 06:45:18PM +, Vanak, Ibrahim wrote:
> BUT still I have significant slowness(50 times slower than clone on
>
On Tue, May 28, 2019 at 06:45:18PM +, Vanak, Ibrahim wrote:
> BUT still I have significant slowness(50 times slower than clone on
> linux machine) while cloning. HPUX box is having very good H/W
> configuration and network is also stable.
>From your output:
> [hpux]
> Receiving objects: 100%
Thanks everyone for the inputs !!! upgrade of GIT to 2.21 worked.
BUT still I have significant slowness(50 times slower than clone on linux
machine) while cloning. HPUX box is having very good H/W configuration and
network is also stable.
Do you have any inputs on this.?
-Ibrahim
-Origina
Hi,
On Tue, 28 May 2019, Vanak, Ibrahim wrote:
> We are seeing issue with GIT 2.14 version.
You definitely want to upgrade ASAP. Not only is the issue that you
reported fixed, but two distinct vulnerabilities have been fixed since
v2.14.0. Your version is still vulnerable.
Ciao,
Johannes
On Tue, May 28 2019, Jeff King wrote:
> On Tue, May 28, 2019 at 09:10:12AM +, Vanak, Ibrahim wrote:
>
>> We are seeing issue with GIT 2.14 version. When we try to clone the
>> repos, it is taking HUGE amount of time on HPUX, whereas on the linux
>> machine with same network configuration, it
On Tue, May 28, 2019 at 09:10:12AM +, Vanak, Ibrahim wrote:
> We are seeing issue with GIT 2.14 version. When we try to clone the
> repos, it is taking HUGE amount of time on HPUX, whereas on the linux
> machine with same network configuration, it's getting cloned in less
> than mins. So we wa
Hello,
We are seeing issue with GIT 2.14 version. When we try to clone the repos, it
is taking HUGE amount of time on HPUX, whereas on the linux machine with same
network configuration, it's getting cloned in less than mins. So we want to
know has anyone reported this issue? What is the fix for
There is a problem on travis-ci with doing builds on Pull Requests
with multiple jobs. For each job it will build off the FETCH_HEAD. The
problem is that if the FETCH_HEAD changes while the build is running
(due to a commit), the subsequent jobs will build off the new
FETCH_HEAD. This results in lo
"xfswi...@163.com" writes:
> Hi,
> I met a issue when using git.
> I cannot delete the file by the commond 'git rm'.
> The file name is a little diff from common file.
> I accidentally named the file "filename\r", display such as filename^M. Then
> I commit the file by 'git add .'.
> After I f
Hi,
I met a issue when using git.
I cannot delete the file by the commond 'git rm'.
The file name is a little diff from common file.
I accidentally named the file "filename\r", display such as filename^M. Then I
commit the file by 'git add .'.
After I find this mistake, I remove the file, then t
W dniu 01.11.2016 o 19:11, Junio C Hamano pisze:
> Jeff King writes:
>> On Tue, Nov 01, 2016 at 10:28:57AM +, Halde, Faiz wrote:
>>
>>> I frequently use the following command to ignore changes done in a file
>>>
>>> git update-index --assume-unchanged somefile
>>>
>>> Now when I do a pull from
On Tue, Nov 1, 2016 at 2:23 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Tue, Nov 01, 2016 at 08:50:23PM -, Philip Oakley wrote:
>>
>>> > From "git help update-index":
>>> >
>>> > --[no-]assume-unchanged
>>> >When this flag is specified, the object names recorded for
>>> >
Jeff King writes:
> On Tue, Nov 01, 2016 at 08:50:23PM -, Philip Oakley wrote:
>
>> > From "git help update-index":
>> >
>> > --[no-]assume-unchanged
>> >When this flag is specified, the object names recorded for
>> >the paths are not updated. Instead, this option sets/unsets
>>
On Tue, Nov 01, 2016 at 08:50:23PM -, Philip Oakley wrote:
> > From "git help update-index":
> >
> > --[no-]assume-unchanged
> >When this flag is specified, the object names recorded for
> >the paths are not updated. Instead, this option sets/unsets
> >the "assume unchanged"
From: "Jeff King"
On Tue, Nov 01, 2016 at 10:28:57AM +, Halde, Faiz wrote:
I frequently use the following command to ignore changes done in a file
git update-index --assume-unchanged somefile
Now when I do a pull from my remote branch and say the file 'somefile'
was changed locally and i
Jeff King writes:
> On Tue, Nov 01, 2016 at 10:28:57AM +, Halde, Faiz wrote:
>
>> I frequently use the following command to ignore changes done in a file
>>
>> git update-index --assume-unchanged somefile
>>
>> Now when I do a pull from my remote branch and say the file 'somefile'
>> was ch
On Tue, Nov 01, 2016 at 10:28:57AM +, Halde, Faiz wrote:
> I frequently use the following command to ignore changes done in a file
>
> git update-index --assume-unchanged somefile
>
> Now when I do a pull from my remote branch and say the file 'somefile'
> was changed locally and in remote,
Hello Git
Not sure if this is a feature or a bug, but here it is.
I frequently use the following command to ignore changes done in a file
git update-index --assume-unchanged somefile
Now when I do a pull from my remote branch and say the file 'somefile' was
changed locally and in remote, git w
Le 2015-12-17 13:29, Stefan Beller a écrit :
On Thu, Dec 17, 2015 at 7:45 AM, PFDuc
wrote:
Hello,
first of all thank you for developping git !
I had an issue with a capital block in the folder name inside my git repo.
The folder in my local was named "Display" and the one at origin was named
On Thu, Dec 17, 2015 at 7:45 AM, PFDuc
wrote:
> Hello,
>
> first of all thank you for developping git !
>
> I had an issue with a capital block in the folder name inside my git repo.
> The folder in my local was named "Display" and the one at origin was named
> "display" resulting in error when im
Hello,
first of all thank you for developping git !
I had an issue with a capital block in the folder name inside my git
repo. The folder in my local was named "Display" and the one at origin
was named "display" resulting in error when importing python code from
this folder for users who got
On 09/19/2013 01:49 PM, Johannes Sixt wrote:
> Am 19.09.2013 15:39, schrieb Ralf Baechle:
>> The original patch that introduced the symlink with the \n is kernel
>> commit 3b29aa5ba204c62b3ec8f9f5b1ebd6e5d74f75d3 and is archived in
>> patchwork at http://patchwork.linux-mips.org/patch/5745/ The pa
Am 19.09.2013 15:39, schrieb Ralf Baechle:
> The original patch that introduced the symlink with the \n is kernel
> commit 3b29aa5ba204c62b3ec8f9f5b1ebd6e5d74f75d3 and is archived in
> patchwork at http://patchwork.linux-mips.org/patch/5745/ The patch
> file contains a \n at the end - but one woul
Ralf Baechle writes:
>> diff --git a/arch/mips/boot/dts/include/dt-bindings
>> b/arch/mips/boot/dts/include/dt-bindings
>> index 68ae388..08c00e4 12
>> --- a/arch/mips/boot/dts/include/dt-bindings
>> +++ b/arch/mips/boot/dts/include/dt-bindings
>> @@ -1 +1 @@
>> -../../../../../include/dt-bi
On Thu, Sep 19, 2013 at 06:39:08PM +0530, Madhavan Srinivasan wrote:
(Git folks, please read on.)
>Commit 3b29aa5ba204c created a symlink file in include/dt-bindings.
>Even though commit diff is fine, symlink is invalid.
>ls -lb shows a newline character at the end of the filename.
>
34 matches
Mail list logo
