Tagger and push rejection

[mirvnillith]

Tagger was not set from git:settings (same as with committer previously) and I added detection of "Push rejected." in the push messages to fail the push (it's what we see in Stash when a server-side hook fails and for some reason the returned result does not trigger a fail by itself).

[yveszoundi]

I created issue #16 for this pull request.

I think that this will merge fine without a rebase this time. If you constantly reformat files, it can become difficult to see the changes, it's a non issue right now because the code base is small.

I think that it's worth investigating why GitTaskUtils.validateTrackingRefUpdates didn't catch the problem vs. trying to "grep" for a "known" and "potentially localized" string.

[yveszoundi]

I'll just merge this for now.

In your case what is the exit code of the hook? Maybe this impacts somehow the result? I haven't been "exposed" to "hooks" for a while, so it's difficult for me to validate without doing a full setup..

From the javadocs comment, I'm wondering if we cannot just check for empty messages and otherwise assume failure and log server-side messages, in addition to throwing an exception. The problem would be if the messages are just warnings that "may not have prevented" the success of the operation.

http://download.eclipse.org/jgit/docs/jgit-2.0.0.201206130900-r/apidocs/org/eclipse/jgit/transport/OperationResult.html#getMessages() "Get the additional messages, if any, returned by the remote process. These messages are most likely informational or error messages, sent by the remote peer, to help the end-user correct any problems that may have prevented the operation from completing successfully. "

What do you think about the above, for future improvements?

[mirvnillith]

Yeah, sorry about that. I have my Eclipse set up with format-on-save for my work projects. I'll see what I can do to make that less of a pain.

/jonas

Yves Zoundi skrev den 2015-05-18 17:15:

I created issue #16 https://github.com/rimerosolutions/ant-git-tasks/issues/16 for this pull request.

I think that this will merge fine without a rebase this time. If you constantly reformat files, it can become difficult to see the changes, it's a non issue right now because the code base is small.

I think that it's worth investigating why /GitTaskUtils.validateTrackingRefUpdates/ didn't catch the problem vs. trying to "grep" for a "known" and "potentially localized" string.

— Reply to this email directly or view it on GitHub https://github.com/rimerosolutions/ant-git-tasks/pull/15#issuecomment-103093599.

[mirvnillith]

I'll do some more detailed examination of the return result soon, this was for a quick automation we needed like yesterday and I'm not happy with it's arbitrariness.

/jonas

Yves Zoundi skrev den 2015-05-18 17:37:

I'll just merge this for now.

In your case what is the exit code of the hook? Maybe this impacts somehow the result? I haven't been "exposed" to "hooks" for a while, so it's difficult for me to validate without doing a full setup..

From the javadocs comment, I'm wondering if we cannot just check for empty messages and otherwise assume failure and log server-side messages, in addition to throwing an exception. The problem would be if the messages are just warnings that "may not have prevented" the success of the operation.

http://download.eclipse.org/jgit/docs/jgit-2.0.0.201206130900-r/apidocs/org/eclipse/jgit/transport/OperationResult.html#getMessages() "Get the additional messages, if any, returned by the remote process. These messages are most likely informational or error messages, sent by the remote peer, to help the end-user correct any problems that may have prevented the operation from completing successfully. "

What do you think about the above, for future improvements?

— Reply to this email directly or view it on GitHub https://github.com/rimerosolutions/ant-git-tasks/pull/15#issuecomment-103106700.

[yveszoundi]

Thanks Jonas,

I'll also do some testing on my side with virtual machines.