From: Jeff King <hidden> Date: 2016-06-16 02:19:24
On Sun, May 15, 2016 at 04:29:36PM -0400, Chris B wrote:
Try it by making some changes to files and committing them, and then push.
It works fine for me when there is nothing to actually push, but not
so when there are commits to push.
In my example there were commits to push.
As you noted, my test was on Linux, so it's certainly possible that it's
Windows-specific. What protocol are you pushing over (e.g., http follows
a very different code path for progress)?
-Peff
I did not see in your example any commit. But if you say so.
I saw git init which would be a new repo.. don't know if it makes a difference.
It's pushing to HTTPS.
I can provide the real example tomorrow.
From: Jeff King <hidden> Date: 2016-06-16 02:19:24
On Sun, May 15, 2016 at 08:51:53PM -0400, Chris B wrote:
I did not see in your example any commit. But if you say so.
I didn't show the commit step. But you can see that I made two identical
pushes, one quiet and one not, and the non-quiet one actually pushed
commits and showed the progress meter.
That doesn't help with your problem, though...
I saw git init which would be a new repo.. don't know if it makes a difference.
It's pushing to HTTPS.
I repeated my test pushing over https, but it still seems to work as
expected with "-q". So perhaps it is just Windows-specific, or perhaps
there's something else going on.
-Peff
PS H:\test-ps\myrepo> "hi" >> whatever
PS H:\test-ps\myrepo> git add .
PS H:\test-ps\myrepo> git commit -m 'boo'
[test1 3cde450] boo
Committer: xxxxxxxxxxxxxxxx
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly. Run the
following command and follow the instructions in your editor to edit
your configuration file:
git config --global --edit
After doing this, you may fix the identity used for this commit with:
git commit --amend --reset-author
1 file changed, 0 insertions(+), 0 deletions(-)
PS H:\test-ps\myrepo> git push --quiet
git : remote:
At line:1 char:1
+ git push --quiet
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (remote: :String) [],
RemoteException
+ FullyQualifiedErrorId : NativeCommandError
remote: Analyzing objects... (3/3) (119 ms)
remote: Storing packfile... done (113 ms)
remote: Storing index... done (29 ms)
From: Johannes Schindelin <hidden> Date: 2016-06-16 02:19:24
Hi Chris,
could you please quote just the parts of the mail you are replying to, and
*not* top-post? It would be appreciated.
On Mon, 16 May 2016, Chris B wrote:
So it actually works, eh?
Could you please verify that this is a PowerShell-only problem by
performing a similar push in Git CMD and in Git Bash?
Ciao,
Johannes
So it actually works, eh?
Could you please verify that this is a PowerShell-only problem by
performing a similar push in Git CMD and in Git Bash?
I don't know much about PowerShell, but presumably it is responsible for
the first few lines.
But there is something else going on, too, which is those "remote:"
lines. Those are being relayed from the server by the git client. I
don't think it would be correct for the client to suppress them, even
with "--quiet", because the client side has no idea if they are progress
junk or critical error messages.
The client _does_ pass along the "quiet" flag to the server via the git
protocol, so it should be the server's responsibility to drop progress
output when it is present. The server side here is clearly not stock
git, from the content of those progress messages (some googling shows it
looks like whatever visualstudio.com is running, but I don't know what
that is). So either the server implementation doesn't support the
"quiet" protocol extension, or it is ignoring it. It might be worth
filing a bug with them.
-Peff
Once I included the whole email in my reply, but otherwise I deleted it all.
Anyway, it is not a Powershell thing. I tested on another repo on
GitHub and it worked as expected. So I guess indeed the problem lies
with Microsoft's implementation.
From: Johannes Schindelin <hidden> Date: 2016-06-16 02:19:24
Hi Chris,
On Mon, 16 May 2016, Chris B wrote:
Once I included the whole email in my reply, but otherwise I deleted it
all.
Both are bad practice. If you are considerate with the reader's time, this
consideration is typically reprocicated. So it is a good idea to save the
reader time by giving them the precise context they need.
Anyway, it is not a Powershell thing. I tested on another repo on
GitHub and it worked as expected. So I guess indeed the problem lies
with Microsoft's implementation.
This is *really* unclear.
What "Microsoft's implementation"??? Do you refer to VSTS, or do you refer
to Git for Windows, or PowerShell?
Please. To make it really simple for everybody involved, try to repeat as
closely as possible the same push from PowerShell, Git CMD and Git Bash.
We want to compare oranges to oranges.
FWIW You can repeat the same push by force-pushing the previous state
between re-runs. E.g.
git push myremote HEAD^:my-branch
git push myremote my-branch
Ciao,
Johannes
From: Jeff King <hidden> Date: 2016-06-16 02:19:24
On Mon, May 16, 2016 at 05:04:34PM +0200, Johannes Schindelin wrote:
quoted
Anyway, it is not a Powershell thing. I tested on another repo on
GitHub and it worked as expected. So I guess indeed the problem lies
with Microsoft's implementation.
This is *really* unclear.
What "Microsoft's implementation"??? Do you refer to VSTS, or do you refer
to Git for Windows, or PowerShell?
Please. To make it really simple for everybody involved, try to repeat as
closely as possible the same push from PowerShell, Git CMD and Git Bash.
We want to compare oranges to oranges.
I don't think there is much to debug there. According to
http://superuser.com/questions/213848/using-powershell-call-native-command-line-app-and-capture-stderr/462362#462362
and other sources, it looks like PowerShell is very picky about calling
programs which produce any output on stderr, and may in an error object.
So I think both Powershell and Git are working as advertised, it's just
that their behaviors are incompatible.
The "bug" is that the server is asking the client to write non-error
output to stderr, even though the client should have asked the server to
be quiet (though it would not hurt to check that it is doing so by
looking at the output of GIT_TRACE_PACKET).
-Peff
Once I included the whole email in my reply, but otherwise I deleted it
all.
Both are bad practice. If you are considerate with the reader's time, this
consideration is typically reprocicated. So it is a good idea to save the
reader time by giving them the precise context they need.
This is among a few reasons I don't understand why in 2016 we use mail
lists for this kind of stuff. First time I've had to deal with this
since the 1990's so I forgot how it works.
On Mon, May 16, 2016 at 11:17 AM, Jeff King [off-list ref] wrote:
On Mon, May 16, 2016 at 05:04:34PM +0200, Johannes Schindelin wrote:
quoted
quoted
Anyway, it is not a Powershell thing. I tested on another repo on
GitHub and it worked as expected. So I guess indeed the problem lies
with Microsoft's implementation.
This is *really* unclear.
What "Microsoft's implementation"??? Do you refer to VSTS, or do you refer
to Git for Windows, or PowerShell?
Please. To make it really simple for everybody involved, try to repeat as
closely as possible the same push from PowerShell, Git CMD and Git Bash.
We want to compare oranges to oranges.
As I was mentioning GitHub I assumed "Microsoft implementation" would
indicate their hosted Git service "Visual Studio Team Services".
I really didn't think there was anything else to provide. The feedback
lead me to test with Github and with that I verified that when the
remote was for Github it worked, but when the remote was VSTS it was
not.. and "not working" means not paying attention to "--quiet"
setting only with git push, while it does work for other commands such
as clone. (though I think I have to re-test with pull.)
The problem is not with Powershell (though how it handles seeing
output in STDERR is not anything I agree with). I was merely trying to
point out that 'git push --quiet' was not working until we realized it
was with VSTS.
This "ticket" if it exists as such in a maillist can be closed.
I think this accurately sums it up:
The "bug" is that the server is asking the client to write non-error
output to stderr, even though the client should have asked the server to
be quiet (though it would not hurt to check that it is doing so by
looking at the output of GIT_TRACE_PACKET).
-Peff