It makes some sense. You don't want to accidentally make some of your edits on one version and some of them on the other version. That would mean that you end up with wrong data, and also have to slowly unwind your changes correctly, if you want to get back the original.

So you have to arbitrarily choose one and keep in your mind that that's the one to be edited. You could choose the 'bottom' one. But because object persistence is pervasive, you choose the 'new' one.

This is very closely related to a merge problem git can't solve which pijul can.

Bits have a colour, sure, but they have a(t least one) history as well, and that at least can be reasoned about mathematically.

The irrationality comes from the fact that I end up with exactly the same text file no matter what. My edit path (directed graph of atomic edits that arrive at the new file) can go many ways to the same result, but I find myself hating one path, and liking another. Even in the "good" path results in more keystrokes during editing. When I save my changes to git or svn or whatever, the new file will be the same regardless of edit path taken to create it. But during the editing operations, I had a nagging pull to make sure the characters I changed were from the copy.

A) why is this irrational, and if so, why is irrational sub-optimal given that the issue involves a non-(fully)-rational system (you)?

B) The habit seems very effective, why would you want to 'shake' a very efficient process?

C) DRY is an end-state which makes sense for (some) code. It is not at all clear that it makes sense for i.e. yaml config files, where it is expected that numerous items may have many similarities.

Sounds to me that by internalizing that bits are colored you have improved your engineering skills.

A, B) I'm not sure I did a good job illustrating with my example. But there are times when the new text needs to appear above the text I copied. In that case, I'll take extra effort to paste the section to edit above the existing, to make sure I'm editing the "new" text. Even if it takes a bit more effort to position my cursor above the copied text.

So in vim, I might yank an entire line and paste it immediately ("yyp"). This automatically pastes below the yanked line and positions the cursor on the new line. But let's say I want to make the edit above the existing. This situation is wrong. The new line was just pasted below the existing. Even though I'm looking at a pair of perfectly identical lines in the file, and could make my edit wherever I choose, I have this idea that one of those lines is the original and the other is the copy. And I don't want to edit the original. In other words, whether I "do it wrong" or "do it right", the end result will be bit-for-bit identical. But one of those edit paths bothers me and the other one doesn't.

So in the yanking and pasting process, I'll take the extra time to move my cursor above the copied line, then paste it in so as to preserve the "lineage" of the text.

This has nothing to do with version control or any other actual efficiencies. It's just my brain being weird. I don't gain any actual benefit, just a calm mind :)

C) Yeah, I was just heading off any nitpicks about my comment.