From 430e33e3dd666c76f1c9a354418fe8790d32f135 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 30 Sep 2019 13:53:50 -0400 Subject: [PATCH] comment --- ..._43bae1f11621232a9133cdef21d1f063._comment | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 doc/bugs/assistant_sometimes_does_not_merge_changes_from_remote/comment_1_43bae1f11621232a9133cdef21d1f063._comment diff --git a/doc/bugs/assistant_sometimes_does_not_merge_changes_from_remote/comment_1_43bae1f11621232a9133cdef21d1f063._comment b/doc/bugs/assistant_sometimes_does_not_merge_changes_from_remote/comment_1_43bae1f11621232a9133cdef21d1f063._comment new file mode 100644 index 0000000000..e8c59eac38 --- /dev/null +++ b/doc/bugs/assistant_sometimes_does_not_merge_changes_from_remote/comment_1_43bae1f11621232a9133cdef21d1f063._comment @@ -0,0 +1,19 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2019-09-30T17:41:23Z" + content=""" +It may be that git is not overwriting the file with its new content, but is +unlinking it and then writing the new content. If so, that could explain +the assistant's behavior, since it could notice the file has been deleted, +and might commit that before it notices it's been added back. + +I tried stracing git checkout, and it indeed does unlink +a modified file then it opens the file for write and writes out the new +content. Kind of surprising it's not more atomic. + +The nature of the assistant is that it's never going to be guaranteed to +always make commits that make logical sense in the same way that manually +committing will. It might be possible to improve this by having it delay +committing removals for some period of time. +"""]]