https://stackoverflow.com/questions/22491988
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFirst, your biggest problem here is a shell thing, which has little to do with git pull itself. Let's do something trivial:
$ echo foo | read msg; echo $msg
$
Why is $msg empty here? The answer has to do with pipelines, parsing, and sub-shells.
The basic syntax for shell commands is a series of "pipelines" separated by a series of semicolons and/or newlines. That is, given:
a | b; c
this parses much the same as:
(a | b); c
or exactly the same as:
a | b
c
Specifically, the b part is bound to the a part, and the c part comes later. Of course, adding explicit parentheses results in the use of a sub-shell, so you might realize instinctively that if the b part is a read command, the c part won't have the variable available, as the setting affects only the sub-shell, not the outer shell.
Alas, removing the parentheses does not help. It's true that this runs the a part in the main shell—but in order to read the output of the pipe, the b part is still run in a sub-shell. (In fact, absent some tricky optimizations, when you use the parentheses, the b part is run in a sub-sub-shell: a sub-shell of the explicitly-invoked sub-shell.)
This is why there is no way to access $msg after the piped-to part exits: the right hand side of any pipeline is always run in a sub-shell.
All is not quite lost: consider:
$ echo foo | { read msg; echo $msg; }
foo
$
The trick here is to run the entire sequence, using $msg, inside the sub-shell. (Parentheses also work and the syntax is slightly less clumsy: echo foo | (read msg; echo $msg).)
Let's go back to the original attempt, and see about patching that up, e.g.:
git pull origin master | { read msg; echo ${msg}; }
This will likely do the same thing:
First, rewinding head to replay your work on top of it...
error: git-pull died of signal 13
although the exact behavior depends on a lot of stuff. (In particular the "rewinding" message itself indicates that you have pull configured to run rebase, for instance.)
The signal 13 part tells us that git-pull is receiving a SIGPIPE error: writing on a broken pipe. What broken pipe could this be? The answer should be obvious as there is a pipe staring us in the face with the command itself:
git pull origin master | ...
A pipe "breaks" when the reader—the right hand side, read msg—exits before the writer (the LHS or git pull ...) is done, and the writer then writes something new. So this indicates that git pull is writing more than one line of output, because the read command reads one line and then exits (or, in the modified pipeline, reads one line, writes it to stdout, and then exits).
If you want to capture the output, you'll need to capture all of it:
git pull origin master | while read msg; do ...; done
for instance. (This no longer needs braces or parentheses as the while <list> do <list> done sequence parses as a single statement.) Or:
git pull origin master > /tmp/script.$$
which will allow you to read the contents of the capture file /tmp/script.$$1 in the original shell process.
The not currently on any branch status occurs because the rebase got interrupted in the middle (due to the broken-pipe error). Rebase works by leaving the branch temporarily, accumulating new commits on a new, anonymous (unnamed "not-on-a-branch") branch, and then moving the original branch label so that the new-and-anonymous branch is now named, and the previously-named branch is abandoned. Adding --quiet stops all the output, so that read msg waits for the entire git pull sequence to finish (after which the read fails because there is no output after all).
1This really should use mktemp; the above is for illustration only.
