Thread (11 messages) 11 messages, 2 authors, 2016-06-15

Re: [PATCH 2/7] Refactor of RefUpdate force to call common updateImpl instead of duplication

flat view

From: Shawn O. Pearce <hidden>
Date: 2016-06-15 22:45:09

Charles O'Farrell [off-list ref] wrote:
quoted hunk ↗ jump to hunk
@@ -266,31 +266,8 @@ public class RefUpdate {
 	 *             an unexpected IO error occurred while writing changes.
 	 */
 	public Result forceUpdate() throws IOException {
[clipped uinteresting deletions to show only the postimage]
quoted hunk ↗ jump to hunk
+		force = true;
+		return update();
 	}
 
 	/**
@@ -347,6 +324,12 @@ public class RefUpdate {
 			if (oldValue == null)
 				return store(lock, Result.NEW);
 
+			if (isForceUpdate()) {
+				if (oldValue.equals(newValue))
+					return Result.NO_CHANGE;
+				return store(lock, Result.FORCED);
+			}
+
 			newObj = walk.parseAny(newValue);
 			oldObj = walk.parseAny(oldValue);
 			if (newObj == oldObj)
@@ -355,13 +338,8 @@ public class RefUpdate {
 			if (newObj instanceof RevCommit && oldObj instanceof RevCommit) {
 				if (walk.isMergedInto((RevCommit) oldObj, (RevCommit) newObj))
 					return store(lock, Result.FAST_FORWARD);
-				if (isForceUpdate())
-					return store(lock, Result.FORCED);
-				return Result.REJECTED;
The problem with this change is that calls to just update() which
have isForceUpdate() true but actually turn out to be FAST_FORWARD
types of updates now report FORCED as the result.  We don't want
to always report FORCED if the application is using just update().

Its nice to know that the remote side didn't rewind since we last
saw them (for example).

-- 
Shawn.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help