Re: [git-users] git checkout crashes after server being updated to Debian X86_64

[Konstantin Khomoutov]

On Tue, 18 Oct 2016 07:56:31 -0700 (PDT)
Raffael Reichelt  wrote:

> I have a serious problem with git, After my provider had updated to a 
> X86_64 architecture git crashes with various memory-related errors.
> This is happening remote when pushing to the repository from my local
> machine as well as trying it on a shell on the server itself.
[...]
> git version 2.1.4
> on
> Linux infongp-de65 3.14.0-ui16196-uiabi1-infong-amd64 #1 SMP Debian 
> 3.14.73-2~ui80+4 (2016-07-13) x86_64 GNU/Linux

Please bring this on the main Git list (see [1]).
We here merely deal with usage issues but you appear to had hit
something serious.

1. https://gist.github.com/tfnico/4441562

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] git checkout crashes after server being updated to Debian X86_64

[Raffael Reichelt]

 

Hello! 


I have a serious problem with git, After my provider had updated to a 
X86_64 architecture git crashes with various memory-related errors. This is 
happening remote when pushing to the repository from my local machine as 
well as trying it on a shell on the server itself.


This are the error-messages:


fatal: Out of memory, realloc failed

fatal: recursion detected in die handler

fatal: recursion detected in die handler

or

fatal: unable to create threaded lstat

fatal: recursion detected in die handler

or

fatal: unable to create threaded lstat

*** Error in `git': double free or corruption (fasttop): 0x00a8ade0 
***

fatal: recursion detected in die handler

Aborted


It’s obviously not a problem of the repository - happens with all of them. 
I think it is also not a question of size - happens with a 80M Repository 
as well as with a 500M one.


Any way: did a 


git fsck

Prüfe Objekt-Verzeichnisse: 100% (256/256), Fertig.

Prüfe Objekte: 100% (56305/56305), Fertig.


git gc --auto --prune=today —aggressive

git repack


Additionally I played around some config parameters  so my config now looks 
like:

[http]

postbuffer = 524288000

[pack]

threads = 1

deltaCacheSize = 128m

packSizeLimit = 128m

windowMemory = 128m

[core]

packedGitLimit = 128m

packedGitWindowSize = 128m

repositoryformatversion = 0

filemode = true

bare = true


I am running 

git version 2.1.4

 

on

Linux infongp-de65 3.14.0-ui16196-uiabi1-infong-amd64 #1 SMP Debian 
3.14.73-2~ui80+4 (2016-07-13) x86_64 GNU/Linux


Anyone out there to help me getting out of this trouble?


Regards,

Raffael

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Using git in an unusual way, need advice

[Konstantin Khomoutov]

On Tue, 18 Oct 2016 07:08:00 -0400
rhkra...@gmail.com wrote:

> I sent this and the next email to another list and didn't get any
> response-- I've partially resolved my issue (see next post), and I'm
> also beginning to understand that branches might also solve my issue
> (but patches see more straightforward.
> 
> I'm resending it here as I welcome comments and suggestions:
[...]

No, both of your original posts came where it was intended.
You can see all four your posts and my answer at [1].

1. https://groups.google.com/d/topic/git-users/iqYZw9Akkno/discussion

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: error: git-svn died of signal 11

[Sidney Souza]

After the process finish, send the result for me.

The best new is you need do this process once only.

On Saturday, October 15, 2016 at 8:11:44 PM UTC-3, Aleksey Tsalolikhin 
wrote:
>
> Hello,
>
> I'm trying to convert an SVN repository to Git with "git-svn" and it dies 
> with a seg fault.
>
> # git svn --version
> git-svn version 2.10.1 (svn 1.9.3)
> #
>
> I've narrowed the problem down to commit 18663 (and we have 22K revisions 
> in the SVN repo).
>
> # git svn clone -r 18663:18664  svn://myrepo.example.com/ 
> --authors-file=authors.txt --no-metadata --trunk=myproject/trunk 
> --tags=myproject/tags --branches=myproject/branches 
> file:///home/aleksey/scratch/myproject/
>
> The error is:
>
> Index mismatch: 314e2ca82dcac3fc7a31668974ec1bbfe2ba0904 != 
> 60995aa26b6d5fd5056d7c1c278ab9fac4f0fa72
> rereading 6edf00155e99771d6f8af9aeae5b2578a7f1db76
> A   file1
> A   file2
> A   file3
> ... [add a bunch more files]
> Ignoring path
> error: git-svn died of signal 11
> #
>
>
> Turn on GIT_TRACE:
>
> 22:37:17.322731 git.c:350   trace: built-in: git 'rev-list' 
> '--pretty=raw' '--reverse' 
> '6edf00155e99771d6f8af9aeae5b2578a7f1db76..refs/remotes/origin/JohnDeveloper' 
> '--'
> 22:37:17.323466 git.c:350   trace: built-in: git 'config' 
> '--get' 'svn-remote.svn.rewriteRoot'
> 22:37:17.325970 git.c:350   trace: built-in: git 'config' 
> '--get' 'svn-remote.svn.rewriteUUID'
> 22:37:17.331451 git.c:350   trace: built-in: git 'config' 
> '--get' 'svn-remote.svn.usesvmprops'
> 22:37:17.334047 git.c:350   trace: built-in: git 'config' 
> '--get' 'svn-remote.svn.nometadata'
> 22:37:17.336422 git.c:350   trace: built-in: git 'config' 
> '--bool' 'svn-remote.svn.nometadata'
> 22:37:17.339054 git.c:350   trace: built-in: git 'write-tree'
> 22:37:17.370642 git.c:350   trace: built-in: git 'cat-file' 
> 'commit' '6edf00155e99771d6f8af9aeae5b2578a7f1db76'
> Index mismatch: 314e2ca82dcac3fc7a31668974ec1bbfe2ba0904 != 
> 60995aa26b6d5fd5056d7c1c278ab9fac4f0fa72
> rereading 6edf00155e99771d6f8af9aeae5b2578a7f1db76
> 22:37:17.374140 git.c:350   trace: built-in: git 'read-tree' 
> '6edf00155e99771d6f8af9aeae5b2578a7f1db76'
> 22:37:17.448099 git.c:350   trace: built-in: git 'write-tree'
> 22:37:17.460106 git.c:350   trace: built-in: git 'config' 
> '--get' 'svn-remote.svn.followparent'
> 22:37:17.462909 git.c:350   trace: built-in: git 'config' 
> '--bool' '--get' 'svn.brokenSymlinkWorkaround'
> 22:37:17.465511 git.c:350   trace: built-in: git 'config' 
> '--get' 'svn-remote.svn.ignore-paths'
> 22:37:17.467963 git.c:350   trace: built-in: git 'config' 
> '--get' 'svn-remote.svn.include-paths'
> 22:37:17.470431 git.c:350   trace: built-in: git 'config' 
> '--get' '--bool' 'svn-remote.svn.preserve-empty-dirs'
> 22:37:17.472916 git.c:350   trace: built-in: git 'config' 
> '--get-all' 'svn-remote.svn.added-placeholder'
> 22:37:17.475974 git.c:350   trace: built-in: git 
> 'update-index' '-z' '--index-info'
> 22:37:17.476806 git.c:350   trace: built-in: git 'config' 
> '--get' 'svn.pathnameencoding'
> 22:37:17.479570 git.c:350   trace: built-in: git 'config' 
> 'svn-remote.svn.reposRoot' 'svn://myrepo.example.com'
> 22:37:17.506685 git.c:350   trace: built-in: git 'hash-object' 
> '-w' '--stdin-paths' '--no-filters'
> A   file1
> A   file2
> A   file3
>
>
> Again, the error was:
>
> Index mismatch: 314e2ca82dcac3fc7a31668974ec1bbfe2ba0904 != 
> 60995aa26b6d5fd5056d7c1c278ab9fac4f0fa72
> rereading 6edf00155e99771d6f8af9aeae5b2578a7f1db76
>
> 6edf is a commit object:
>
> # git cat-file -t 6edf00155e99771d6f8af9aeae5b2578a7f1db76
> commit
> #
>
> Its contents:
>
> # git cat-file -p 6edf00155e99771d6f8af9aeae5b2578a7f1db76
> tree 314e2ca82dcac3fc7a31668974ec1bbfe2ba0904
> parent ba36a400db2acdc441b3665428870a2d0ef48da6
> author [redacted]
> committer [redacted]
>
> [redacted]
> #
>
> Finally, the second object mentioned in the error does not exist:
>
> # git cat-file -t 60995aa26b6d5fd5056d7c1c278ab9fac4f0fa72
> fatal: git cat-file: could not get object info
> #
>
> Where did git get 6099?
>
> It wasn't from 6edf or 314e...
>
> # git cat-file -p 314e2ca82dcac3fc7a31668974ec1bbfe2ba0904
> 04 tree de2e3c37d310176d37316e29fafcc524f432a61b[redacted]
> 04 tree c87e8141209f655a9b21b251bdc52b7a17ace55d[redacted]
> 04 tree bb9b918e1f91adcfc04512b7ff2d5647104f654b[redacted]
> 04 tree ad127b602af7ff6de4e10fa391305966f72e53a7[redacted]
> 04 tree 458c21da5d8900f06df895c8ae8218693729cf07[redacted]
> 04 tree 0343c9b99e9e5266c53704fc8a53ae645945896c[redacted]
> #
>
> I tried adding -d switch to git-svn, and now it dies with SIGABRT rather 
> than SIGSEGV:
>
> Signal SEGV at 

[git-users] Re: Using git in an unusual way, need advice

[rhkramer]

The other post, previously sent to the wrong list:

On Sunday, October 16, 2016 09:39:41 PM rhkra...@gmail.com wrote:
> I am probably using git in an unusual way.

...

> But, I'm not sure how to handle further updates after I've made local
> changes to the source code.
> 
> The one approach I can think of is to create a patch file before I download
> the next update, then download and untar the next update, and then apply
> that patch file (while doing git adds and commits at the appropriate
> times, which I have to think about).
> 
> But the patch file approach seems rather cumbersome and un-git (and un-CMS)
> like--is there a better approach?

I've done / am doing more reading, and my approach is probably not as unusual 
as I thought, and I've found instructions on creating and applying patches to 
/ from git, so I'll probably be (close to) OK after I do some more reading.

[git-users] Using git in an unusual way, need advice

[rhkramer]

I sent this and the next email to another list and didn't get any response--
I've partially resolved my issue (see next post), and I'm also beginning to 
understand that branches might also solve my issue (but patches see more 
straightforward.

I'm resending it here as I welcome comments and suggestions:

Original email:

I am probably using git in an unusual way.

I want to do some development for a project that is managed by Mercurial 
(scite / scintilla), but, for the sake of learning git (and minimizing the 
need to learn anything else)  I want to use git for the work I do.

I've downloaded the source code as tarballs (which are available--I could also 
have downloaded the source code using Mercurial, but, as long as the tarballs 
are available, I'd prefer to do it using tarballs).

I originally downloaded version 3.66 of the source code, untarred it into a 
working directory, initialized a git repository, and then added and committed 
the source code to the git repository.

So far, I haven't actually made any changes to the source code.

Now version 3.70 is available, and I sort of repeated the process, that is, I 
untarred the new version into the working directory that I had previously 
created, then did a git status--it seemed to recognize the modified files, 
which 
I then added and committed.

So far, so good.

But, I'm not sure how to handle further updates after I've made local changes 
to the source code.

The one approach I can think of is to create a patch file before I download the 
next update, then download and untar the next update, and then apply that 
patch file (while doing git adds and commits at the appropriate times, which I 
have to think about).

But the patch file approach seems rather cumbersome and un-git (and un-CMS) 
like--is there a better approach?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.