PR updates

parser-typechecker/src/Unison/Codebase/Branch.hs

@@ -531,8 +531,7 @@ uncons :: Applicative m => Branch m -> m (Maybe (Branch0 m, Branch m))
 uncons (Branch b) = go <$> Causal.uncons b where
   go = over (_Just . _2) Branch
 
--- | Run a series of updates at specific locations efficiently, aggregating all changes
--- into a single causal step.
+-- | Run a series of updates at specific locations, aggregating all changes into a single causal step.
 stepManyAt ::
   forall m f.
   (Monad m, Foldable f) =>
@@ -545,8 +544,7 @@ stepManyAt actions startBranch =
     actionsIdentity :: [(Path, Branch0 m -> Identity (Branch0 m))]
     actionsIdentity = coerce (toList actions)
 
--- | Run a series of updates at specific locations efficiently, aggregating all changes
--- into a single causal step.
+-- | Run a series of updates at specific locations, aggregating all changes into a single causal step.
 stepManyAtM :: (Monad m, Monad n, Foldable f)
             => f (Path, Branch0 m -> n (Branch0 m)) -> Branch m -> n (Branch m)
 stepManyAtM actions startBranch =
@@ -647,9 +645,12 @@ batchUpdates actions =
 data ActionLocation = HereActions | ChildActions
   deriving Eq
 
--- | Efficiently perform updates over many locations within a branch.
--- All updates are performed over the current branch, all causal changes
--- must be performed in the updates themselves.
+-- | Batch many updates. This allows us to apply the updates while minimizing redundant traversals.
+-- Semantics of operations are preserved by ensuring that all updates will always see changes
+-- by updates before them in the list.
+--
+-- This method does not 'step' any branches on its own, all causal changes must be performed in the updates themselves,
+-- or this batch update must be provided to 'stepManyAt(M)'.
 batchUpdatesM ::
   forall m n f.
   (Monad m, Monad n, Foldable f) =>

unison-src/transcripts/child-namespace-history-merge.md

@@ -12,7 +12,7 @@ but I think we should at least notice if we change things by accident.
 .> builtins.merge
 ```
 
-```unison
+```unison:hide
 parent.top = "top"
 parent.child.thing = "parent.child.thing"
 ```
@@ -26,11 +26,10 @@ The child branch has a single history node representing the addition of `parent.
 
 If we add another thing to the child namespace it should add another history node.
 
-```unison
+```unison:hide
 parent.child.thing2 = "parent.child.thing2"
 ```
 
-
 ```ucm
 .> add
 .> history parent.child
@@ -44,7 +43,7 @@ Now we fork the parent namespace to make some changes.
 .> fork parent parent_fork
 ```
 
-```unison
+```unison:hide
 parent_fork.child.thing3 = "parent_fork.child.thing3"
 ```
 

unison-src/transcripts/child-namespace-history-merge.output.md

@@ -13,18 +13,6 @@ parent.top = "top"
 parent.child.thing = "parent.child.thing"
 ```
 
-```ucm
-
-  I found and typechecked these definitions in scratch.u. If you
-  do an `add` or `update`, here's how your codebase would
-  change:
-  
-    ⍟ These new definitions are ok to `add`:
-    
-      parent.child.thing : Text
-      parent.top         : Text
-
-```
 The child branch has a single history node representing the addition of `parent.child.thing`.
 
 ```ucm
@@ -51,17 +39,6 @@ If we add another thing to the child namespace it should add another history nod
 parent.child.thing2 = "parent.child.thing2"
 ```
 
-```ucm
-
-  I found and typechecked these definitions in scratch.u. If you
-  do an `add` or `update`, here's how your codebase would
-  change:
-  
-    ⍟ These new definitions are ok to `add`:
-    
-      parent.child.thing2 : Text
-
-```
 ```ucm
 .> add
 
@@ -97,17 +74,6 @@ Now we fork the parent namespace to make some changes.
 parent_fork.child.thing3 = "parent_fork.child.thing3"
 ```
 
-```ucm
-
-  I found and typechecked these definitions in scratch.u. If you
-  do an `add` or `update`, here's how your codebase would
-  change:
-  
-    ⍟ These new definitions are ok to `add`:
-    
-      parent_fork.child.thing3 : Text
-
-```
 ```ucm
 .> add