您最多选择25个主题 主题必须以字母或数字开头,可以包含连字符 (-),并且长度不得超过35个字符

AbstractFetchCommand.java 6.1KB

Capture non-progress side band #2 messages and put in result Any messages received on side band #2 that aren't scraped as a progress message into our ProgressMonitor are now forwarded to a buffer which is later included into the OperationResult object. Application callers can use this buffer to present the additional messages from the remote peer after the push or fetch operation has concluded. The smart push connections using the native send-pack/receive-pack protocol now request side-band-64k capability if it is available and forward any messages received through that channel onto this message buffer. This makes hook messages available over smart HTTP, or even over SSH. The SSH transport was modified to redirect the remote command's stderr stream into the message buffer, interleaved with any data received over side band #2. Due to buffering between these two different channels in the SSH channel mux itself the order of any writes between the two cannot be ensured, but it tries to stay close. The local fork transport was also modified to redirect the local receive-pack's stderr into the message buffer, rather than going to the invoking JVM's System.err. This gives applications a chance to log the local error messages, rather than needing to redirect their JVM's stderr before startup. To keep things simple, the application has to wait for the entire operation to complete before it can see the messages. This may be a downside if the user is trying to debug a remote hook that is blocking indefinitely, the user would need to abort the connection before they can inspect the message buffer in any sort of UI built on top of JGit. Change-Id: Ibc215f4569e63071da5b7e5c6674ce924ae39e11 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 年前
Capture non-progress side band #2 messages and put in result Any messages received on side band #2 that aren't scraped as a progress message into our ProgressMonitor are now forwarded to a buffer which is later included into the OperationResult object. Application callers can use this buffer to present the additional messages from the remote peer after the push or fetch operation has concluded. The smart push connections using the native send-pack/receive-pack protocol now request side-band-64k capability if it is available and forward any messages received through that channel onto this message buffer. This makes hook messages available over smart HTTP, or even over SSH. The SSH transport was modified to redirect the remote command's stderr stream into the message buffer, interleaved with any data received over side band #2. Due to buffering between these two different channels in the SSH channel mux itself the order of any writes between the two cannot be ensured, but it tries to stay close. The local fork transport was also modified to redirect the local receive-pack's stderr into the message buffer, rather than going to the invoking JVM's System.err. This gives applications a chance to log the local error messages, rather than needing to redirect their JVM's stderr before startup. To keep things simple, the application has to wait for the entire operation to complete before it can see the messages. This may be a downside if the user is trying to debug a remote hook that is blocking indefinitely, the user would need to abort the connection before they can inspect the message buffer in any sort of UI built on top of JGit. Change-Id: Ibc215f4569e63071da5b7e5c6674ce924ae39e11 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 年前
Capture non-progress side band #2 messages and put in result Any messages received on side band #2 that aren't scraped as a progress message into our ProgressMonitor are now forwarded to a buffer which is later included into the OperationResult object. Application callers can use this buffer to present the additional messages from the remote peer after the push or fetch operation has concluded. The smart push connections using the native send-pack/receive-pack protocol now request side-band-64k capability if it is available and forward any messages received through that channel onto this message buffer. This makes hook messages available over smart HTTP, or even over SSH. The SSH transport was modified to redirect the remote command's stderr stream into the message buffer, interleaved with any data received over side band #2. Due to buffering between these two different channels in the SSH channel mux itself the order of any writes between the two cannot be ensured, but it tries to stay close. The local fork transport was also modified to redirect the local receive-pack's stderr into the message buffer, rather than going to the invoking JVM's System.err. This gives applications a chance to log the local error messages, rather than needing to redirect their JVM's stderr before startup. To keep things simple, the application has to wait for the entire operation to complete before it can see the messages. This may be a downside if the user is trying to debug a remote hook that is blocking indefinitely, the user would need to abort the connection before they can inspect the message buffer in any sort of UI built on top of JGit. Change-Id: Ibc215f4569e63071da5b7e5c6674ce924ae39e11 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 年前
Capture non-progress side band #2 messages and put in result Any messages received on side band #2 that aren't scraped as a progress message into our ProgressMonitor are now forwarded to a buffer which is later included into the OperationResult object. Application callers can use this buffer to present the additional messages from the remote peer after the push or fetch operation has concluded. The smart push connections using the native send-pack/receive-pack protocol now request side-band-64k capability if it is available and forward any messages received through that channel onto this message buffer. This makes hook messages available over smart HTTP, or even over SSH. The SSH transport was modified to redirect the remote command's stderr stream into the message buffer, interleaved with any data received over side band #2. Due to buffering between these two different channels in the SSH channel mux itself the order of any writes between the two cannot be ensured, but it tries to stay close. The local fork transport was also modified to redirect the local receive-pack's stderr into the message buffer, rather than going to the invoking JVM's System.err. This gives applications a chance to log the local error messages, rather than needing to redirect their JVM's stderr before startup. To keep things simple, the application has to wait for the entire operation to complete before it can see the messages. This may be a downside if the user is trying to debug a remote hook that is blocking indefinitely, the user would need to abort the connection before they can inspect the message buffer in any sort of UI built on top of JGit. Change-Id: Ibc215f4569e63071da5b7e5c6674ce924ae39e11 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 年前
Capture non-progress side band #2 messages and put in result Any messages received on side band #2 that aren't scraped as a progress message into our ProgressMonitor are now forwarded to a buffer which is later included into the OperationResult object. Application callers can use this buffer to present the additional messages from the remote peer after the push or fetch operation has concluded. The smart push connections using the native send-pack/receive-pack protocol now request side-band-64k capability if it is available and forward any messages received through that channel onto this message buffer. This makes hook messages available over smart HTTP, or even over SSH. The SSH transport was modified to redirect the remote command's stderr stream into the message buffer, interleaved with any data received over side band #2. Due to buffering between these two different channels in the SSH channel mux itself the order of any writes between the two cannot be ensured, but it tries to stay close. The local fork transport was also modified to redirect the local receive-pack's stderr into the message buffer, rather than going to the invoking JVM's System.err. This gives applications a chance to log the local error messages, rather than needing to redirect their JVM's stderr before startup. To keep things simple, the application has to wait for the entire operation to complete before it can see the messages. This may be a downside if the user is trying to debug a remote hook that is blocking indefinitely, the user would need to abort the connection before they can inspect the message buffer in any sort of UI built on top of JGit. Change-Id: Ibc215f4569e63071da5b7e5c6674ce924ae39e11 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 年前
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190
  1. /*
  2. * Copyright (C) 2008, Charles O'Farrell <charleso@charleso.org>
  3. * Copyright (C) 2008-2010, Google Inc.
  4. * Copyright (C) 2008, Marek Zawirski <marek.zawirski@gmail.com>
  5. * Copyright (C) 2008, Shawn O. Pearce <spearce@spearce.org>
  6. * Copyright (C) 2010, Sasa Zivkov <sasa.zivkov@sap.com>
  7. * and other copyright owners as documented in the project's IP log.
  8. *
  9. * This program and the accompanying materials are made available
  10. * under the terms of the Eclipse Distribution License v1.0 which
  11. * accompanies this distribution, is reproduced below, and is
  12. * available at http://www.eclipse.org/org/documents/edl-v10.php
  13. *
  14. * All rights reserved.
  15. *
  16. * Redistribution and use in source and binary forms, with or
  17. * without modification, are permitted provided that the following
  18. * conditions are met:
  19. *
  20. * - Redistributions of source code must retain the above copyright
  21. * notice, this list of conditions and the following disclaimer.
  22. *
  23. * - Redistributions in binary form must reproduce the above
  24. * copyright notice, this list of conditions and the following
  25. * disclaimer in the documentation and/or other materials provided
  26. * with the distribution.
  27. *
  28. * - Neither the name of the Eclipse Foundation, Inc. nor the
  29. * names of its contributors may be used to endorse or promote
  30. * products derived from this software without specific prior
  31. * written permission.
  32. *
  33. * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
  34. * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
  35. * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
  36. * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  37. * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
  38. * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  39. * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
  40. * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
  41. * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
  42. * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
  43. * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  44. * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
  45. * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  46. */
  47. package org.eclipse.jgit.pgm;
  48. import java.io.IOException;
  49. import java.io.PrintWriter;
  50. import java.text.MessageFormat;
  51. import org.eclipse.jgit.lib.Constants;
  52. import org.eclipse.jgit.lib.ObjectId;
  53. import org.eclipse.jgit.lib.ObjectReader;
  54. import org.eclipse.jgit.lib.RefUpdate;
  55. import org.eclipse.jgit.transport.FetchResult;
  56. import org.eclipse.jgit.transport.TrackingRefUpdate;
  57. import org.eclipse.jgit.transport.Transport;
  58. import org.kohsuke.args4j.Option;
  59. abstract class AbstractFetchCommand extends TextBuiltin {
  60. @Option(name = "--verbose", aliases = { "-v" }, usage = "usage_beMoreVerbose")
  61. private boolean verbose;
  62. protected void showFetchResult(final Transport tn, final FetchResult r) {
  63. ObjectReader reader = db.newObjectReader();
  64. try {
  65. boolean shownURI = false;
  66. for (final TrackingRefUpdate u : r.getTrackingRefUpdates()) {
  67. if (!verbose && u.getResult() == RefUpdate.Result.NO_CHANGE)
  68. continue;
  69. final char type = shortTypeOf(u.getResult());
  70. final String longType = longTypeOf(reader, u);
  71. final String src = abbreviateRef(u.getRemoteName(), false);
  72. final String dst = abbreviateRef(u.getLocalName(), true);
  73. if (!shownURI) {
  74. out.format(CLIText.get().fromURI, tn.getURI());
  75. out.println();
  76. shownURI = true;
  77. }
  78. out.format(" %c %-17s %-10s -> %s", type, longType, src, dst);
  79. out.println();
  80. }
  81. } finally {
  82. reader.release();
  83. }
  84. showRemoteMessages(r.getMessages());
  85. }
  86. static void showRemoteMessages(String pkt) {
  87. PrintWriter writer = new PrintWriter(System.err);
  88. while (0 < pkt.length()) {
  89. final int lf = pkt.indexOf('\n');
  90. final int cr = pkt.indexOf('\r');
  91. final int s;
  92. if (0 <= lf && 0 <= cr)
  93. s = Math.min(lf, cr);
  94. else if (0 <= lf)
  95. s = lf;
  96. else if (0 <= cr)
  97. s = cr;
  98. else {
  99. writer.print(MessageFormat.format(CLIText.get().remoteMessage,
  100. pkt));
  101. writer.println();
  102. break;
  103. }
  104. if (pkt.charAt(s) == '\r') {
  105. writer.print(MessageFormat.format(CLIText.get().remoteMessage,
  106. pkt.substring(0, s)));
  107. writer.print('\r');
  108. } else {
  109. writer.print(MessageFormat.format(CLIText.get().remoteMessage,
  110. pkt.substring(0, s)));
  111. writer.println();
  112. }
  113. pkt = pkt.substring(s + 1);
  114. }
  115. writer.flush();
  116. }
  117. private String longTypeOf(ObjectReader reader, final TrackingRefUpdate u) {
  118. final RefUpdate.Result r = u.getResult();
  119. if (r == RefUpdate.Result.LOCK_FAILURE)
  120. return "[lock fail]";
  121. if (r == RefUpdate.Result.IO_FAILURE)
  122. return "[i/o error]";
  123. if (r == RefUpdate.Result.REJECTED)
  124. return "[rejected]";
  125. if (ObjectId.zeroId().equals(u.getNewObjectId()))
  126. return "[deleted]";
  127. if (r == RefUpdate.Result.NEW) {
  128. if (u.getRemoteName().startsWith(Constants.R_HEADS))
  129. return "[new branch]";
  130. else if (u.getLocalName().startsWith(Constants.R_TAGS))
  131. return "[new tag]";
  132. return "[new]";
  133. }
  134. if (r == RefUpdate.Result.FORCED) {
  135. final String aOld = safeAbbreviate(reader, u.getOldObjectId());
  136. final String aNew = safeAbbreviate(reader, u.getNewObjectId());
  137. return aOld + "..." + aNew;
  138. }
  139. if (r == RefUpdate.Result.FAST_FORWARD) {
  140. final String aOld = safeAbbreviate(reader, u.getOldObjectId());
  141. final String aNew = safeAbbreviate(reader, u.getNewObjectId());
  142. return aOld + ".." + aNew;
  143. }
  144. if (r == RefUpdate.Result.NO_CHANGE)
  145. return "[up to date]";
  146. return "[" + r.name() + "]";
  147. }
  148. private String safeAbbreviate(ObjectReader reader, ObjectId id) {
  149. try {
  150. return reader.abbreviate(id).name();
  151. } catch (IOException cannotAbbreviate) {
  152. return id.name();
  153. }
  154. }
  155. private static char shortTypeOf(final RefUpdate.Result r) {
  156. if (r == RefUpdate.Result.LOCK_FAILURE)
  157. return '!';
  158. if (r == RefUpdate.Result.IO_FAILURE)
  159. return '!';
  160. if (r == RefUpdate.Result.NEW)
  161. return '*';
  162. if (r == RefUpdate.Result.FORCED)
  163. return '+';
  164. if (r == RefUpdate.Result.FAST_FORWARD)
  165. return ' ';
  166. if (r == RefUpdate.Result.REJECTED)
  167. return '!';
  168. if (r == RefUpdate.Result.NO_CHANGE)
  169. return '=';
  170. return ' ';
  171. }
  172. }