From ed4c47632fd6c43aa9284e9ae9bcb77a7ec2ec82 Mon Sep 17 00:00:00 2001 From: Campbell Barton Date: Thu, 19 Mar 2020 12:05:34 +1100 Subject: Cleanup: spelling --- source/blender/editors/undo/memfile_undo.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'source/blender/editors/undo') diff --git a/source/blender/editors/undo/memfile_undo.c b/source/blender/editors/undo/memfile_undo.c index 1ac4c031c8e..f9235938eb7 100644 --- a/source/blender/editors/undo/memfile_undo.c +++ b/source/blender/editors/undo/memfile_undo.c @@ -156,15 +156,15 @@ static void memfile_undosys_step_decode(struct bContext *C, * The only time we should have to force a complete redo is when current step is tagged as a * redo barrier. * If previous step was not a memfile one should not matter here, current data in old bmain - * should still always be valid for unchanged datat-blocks. */ + * should still always be valid for unchanged data-blocks. */ if (us_p->use_old_bmain_data == false) { use_old_bmain_data = false; } } else { /* Undo case. - * Here we do not care whether current step is an undo barrier, since we are comming from 'the - * future' we can still re-use old data. However, if *next* undo step + * Here we do not care whether current step is an undo barrier, since we are coming from + * 'the future' we can still re-use old data. However, if *next* undo step * (i.e. the one immediately in the future, the one we are coming from) * is a barrier, then we have to force a complete undo. * Note that non-memfile undo steps **should** not be an issue anymore, since we handle -- cgit v1.2.3