create labels for versions

[embear]

Having a visual undotree is really useful. Many thanks for that!

Identifying a specific version still is hard. A really nice addition would be the ability to add a label to a certain version. This would make it possible to mark a specific version as some kind of "snapshot" for example as "last known working version".

I know that the undo feature of vim is not a VCS, but I think it would be nice to have such a feature.

[mbbill]

Actually I was thinking of this feature lately, one of my consideration is to make the mark persistent, but vim does not provide a way to store some meta data into persistent undo file and creating another file seems a bit ugly, so I'm still trying to find a better way.

[embear]

Another ugly possibility would be a global variable and storing it in the viminfo file. I think if the marks should be persistent a seprarate file would be the best.

[mbbill]

To end up with two undo files for a normal file is kind of inaccpetable. I'm still thinking of a better workaround.

[busimus]

This is a feature I really want to see implemented. Being able to mark a change with some simple metadata like "last known working version" would be very useful for me.

[tmillr]

I've had a couple ideas related to this as well, although mine have to do with marks or labels created automatically:

1. A visual label or mark marking the entry that the file was last opened on (is this the same thing as (Original)? or is (Original) simply the oldest node in the tree? Because if the undofile is persistent, then the entry that the file was opened on is not necessarily the oldest node.). This mark/label would optionally get updated or reset whenever the buffer is reloaded (e.g. with :e), or another mark could be used to distinguish reloads (although I imagine that this mark will usually mark the same entry that the file was initially opened on). This one requires some knowledge about Vim's inner working, but it probably wouldn't be too difficult to implement (if it isn't implemented already to some degree).

2. A visual mark or label marking the entry which matches the version of the file in HEAD. There could also be another mark for the index version for when the index differs from HEAD. These would both be complicated to implement however. It's possible that the file isn't even tracked by git (or it could be tracked, but not exist in HEAD). I think it'd also be possible that even though the file exists in HEAD, none of the undotree entries match HEAD. Also, you wouldn't be able to compare by simply looking at timestamps as the matching undotree entry and the git commit are practically guaranteed to have different timestamps (unless you somehow managed to create the commit at the exact time the change was made). File modification timestamps will almost never match undotree entry timestamps either.

Even though timestamps will almost never match exactly with commit timestamps, they still might be able to be leveraged heuristically to gain some extra insight (e.g. the first entry coming after each commit could be marked, and/or, this sort of heuristic - timestamps - could be used to cut down on how many diffs need to be done when trying to find a match against a commit). In order to improve the performance of this algo, only commits whose timestamp comes after the oldest undotree node would need to be examined[^1]; Additionally, any commits whose timestamp is later than the newest node would also be ignored. Now only a small handful of commits would need to be checked and matched against an entry (using timestamps again to narrow down the amount of entries to compare against).

I think that trying to integrate undotrees with git could potentially quickly become a mess however, particularly if you are using persistent undofiles that aren't tracked along with their respective files (e.g. think file renames, or multiple versions of a file from different branches all trying to consult and use the same undofile!). I think it's also theoretically possible that more than one undotree entry/node could match a commit, although, once again, you could use the timestamp to favor the node/entry with the closest timestamp to that of the commit's. You might also have to consider what happens if a file is changed (or, changed and then committed) while Vim is not running.

[^1]: But I'm not sure because it may be possible for a commit to come before it's undotree entry. Let's say you are using persistent undo and the file is changed and then committed outside of Vim. Then you open up the file in Vim (At this point, does a brand new undotree entry get created/added? Or, maybe Vim will recognize that the file has changed and no longer matches the undotree, and so will refuse to load its undo history? I'm not sure, I don't know Vim that well yet.)

[mbbill]

maybe Vim will recognize that the file has changed and no longer matches the undotree, and so will refuse to load its undo history?

Yes that's exactly what vim does