exit status 141 from git-svn

Hi

I have init'ed a git repository with git svn init.

Now I'm using git svn fetch, but it stops after just a few files/revisions. The exit status is 141.

What does this 141 want to tell me?

Thanks Frederik Hohlfeld

Frederik Hohlfeld <frederik.hohlfeld <at> gmail.com> writes:

No one?

Both git svn clone and git svn fetch stop after just a dozen or so revisions and only continue after calling the command again. For yet another few revisions.

I'd like to get a clue what's happening. A git problem? A svn problem?

Current Git Windows version.

Thanks Frederik Hohlfeld

Frederik Hohlfeld venit, vidit, dixit 24.06.2008 21:24:

That seems to be the first piece of information you're giving regarding your environment and setup. Giving more may result in getting more answers. (I grepped for 141 in the source after your first posting) Maybe you can cut'n'paste the actual output of git svn fetch? What's the command line you're using, where's the svn repo?

Michael

Michael J Gruber <michaeljgruber+gmane <at> fastmail.fm> writes:

Sorry, but I don't see any interesting piece of information in the output. I've just assumed that exit status 141 had a well-defined meaning, different from 140, 15 and 999.

The subversion repo is company-internal and cannot be accessed from the outside.

The output (with modified strings to mask out the file names) is:

M a/b/c/d M a/b/c/d M a/b/c/d M a/b/c/d M a/b/c/d M a/b/c/d M a/b/c/d M a/b/c/d M a/b/c/d r4934 = abcdefghi[...]jklmnopq (trunk)

Nothing more. I haven't found a verbose switch for "fetch", either.

Thanks for reading Frederik Hohlfeld

On Mon, Jun 23, 2008 at 15:00:41 +0000, Frederik Hohlfeld wrote:

Sorry for late reply. I just noticed your message after returning from holiday *and* getting time to try to catch up with the list. Hope a reply might still be useful.

Unix trivia: When process dies from a signal, it's return status (as returned by wait/waitpid(2) is signal_number * 256. However when bourne/POSIX shell sees this, it will convert it to 128 + signal_number.

Now 141 - 128 = 13 and signal 13 is SIGPIPE. Process gets a SIGPIPE when it's writing to a pipe (or socket) and it gets closed on the reading end, so it sounds like a bad redirection somewhere. Aren't you by chance redirecting the output to less and than quitting that without first scrolling to the bottom?

(That would be the most situation where process gets SIGPIPE -- and the very reason why SIGPIPE exists, so that simple commands (like cat) are simply stopped when nobody is interested in their output anymore).