From 406026abba130be90e1a9824e4fb0a5d8eedd759 Mon Sep 17 00:00:00 2001 From: Campbell Barton Date: Wed, 18 Mar 2020 22:28:54 +1100 Subject: Cleanup: spelling --- source/blender/editors/undo/memfile_undo.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'source/blender/editors/undo/memfile_undo.c') diff --git a/source/blender/editors/undo/memfile_undo.c b/source/blender/editors/undo/memfile_undo.c index 312edab91b1..1ac4c031c8e 100644 --- a/source/blender/editors/undo/memfile_undo.c +++ b/source/blender/editors/undo/memfile_undo.c @@ -156,7 +156,7 @@ 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 dtat-blocks. */ + * should still always be valid for unchanged datat-blocks. */ if (us_p->use_old_bmain_data == false) { use_old_bmain_data = false; } @@ -164,9 +164,9 @@ static void memfile_undosys_step_decode(struct bContext *C, 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 (i.e. the one immédiately - * in the future, the one we are comming from) is a barrier, then we have to force a complete - * undo. + * 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 * fine-grained update flags now. */ -- cgit v1.2.3