-    blob_appendf(&title, "History of the file that is called ");
+    blob_appendf(&title, "History of: ");

That's now been changed to "History of file ". Thank you for the feedback.

(Yes, the word "file" is not strictly necessary, but it reads more nicely to my eyes that way.)

The original message reads fully as:

"History of the file that is called '%s' at check-in '%s'"

This was meant to highlight that the history is tied to the file-object/artifact which was named such at the time of the stated check-in. The same artifact may now have a different name or even being removed.

In contrast, the same name can be associated with altogether different file-object/artifact in other check-ins.

The revised message completely removes this nuance.

In contrast, the same name can be associated with altogether different file-object/artifact in other check-ins.

…and vice versa: the "same" file may go under different names following a rename.

I'm guessing the motivation behind this change is that the header text sizes are now larger at h1 and h2 under the new skin,¹ leaving less room for text on a single line, within a reasonable browser window width.

One option we have here is to accept this loss of nuance at the UI level, relegating it to expert knowledge. After all, the next level deeper is the "clade" concept, perhaps the single most complicated query backing Fossil, needing to have a new SQLite capability added to allow it to even run.

The other option would be to restore the note, but in a smaller font, on a second line. What would be really cute is if it did that only if it saw that the file changed names over its history, without which this proposed note is making a distinction where there is no difference.

---

1. ^{^} h3 is about the same, and the h4 and h5 levels weren't even defined under the old "default" skin, now called Étienne.

I'm guessing the motivation behind this change is that the header text sizes are now larger at h1 and h2 under the new skin,1 leaving less room for text on a single line, within a reasonable browser window width.

1. Partly to make long paths & file names stay on one line, yes.
2. Those words are superfluous IMHO. Can’t one only add files to a fossil repo? IMO Nothing is added with “is called” since that’s the whole point of a name, the name is what it’s called. And we know what it’s called at the point of the check-in because it’s on the page, along with the check-in hash.

It’s my view the other anon is asking for something different from what I did. And both can coexist.

In the wiki area¹, one sees ~ “History of zPageName”. Not “History of Wiki Page zPageName”. Maybe it should read “History of Wiki Page”. In the ticket area, tickets are tracked by their hash and when one visits /tkthistory all previous names (titles) of the ticket are shown. However, the <h2> does include the word “Ticket” which I don’t object to. I’m not upset Stephen chose to keep the word “file”.

---

I agree it would be nice to know if a file has been renamed at some point and another file has been added or renamed with the first’s original name.

For example:

You have two files: A.c & B.c Commit changes to both files. Rename A.c to A2.c Commit changes to A2.c Rename B.c to A.c Commit changes to A.c

I’m not exactly sure the use case for that, but don't doubt it can happen. If it was me, I’d include such changes in the commit messages.

My suggestion is similar to yours Warren, if seeing the history of the file’s name is significant, optionally add an asterisk, and beneath it, in a smaller size, include something like “Formerly Named” and show the previous names it’s had since it was first checked in.

The previous much longer verbiage didn’t give me any sense the file’s name could have changed. Also it seems to me to be not KISS to include verbiage on every file history page stating the file’s name could have changed at some point, or [insert other exceptions].

---

1. ^{^} src/wiki.c

Can’t one only add files to a fossil repo?

I'd prefer you that list examples of what you mean by such an open-ended question rather than guess.

I'll dare to speculate from your choice to reply to my prior message as asking whether renaming is a distinct operation supported by the Fossil file format? Yes, it is,¹ without which the "clade" query I linked to above would have no utility.

---

1. ^{^} …via the F card's old-name parameter.

I'd prefer you list examples of what you mean by such an open-ended question rather than guess.

Thank you. Not trying to waste time with vagaries. Perhaps I should have asked ~ what else besides a file can show up on /finfo? (I can scan but not understand everything finfo.c does.) I wasn't expecting /finfo to show “History of the directory...`”.

In my reading of lots of forum posts I came across one which sounded like only files could be committed, not folders. Let me search...aha, it was you! :-)

Perhaps I misunderstood. I am new to version control and fossil.

Now I see the topic you address seems to be checking out files versus directories only.

In my own limited use I’ve used -mv to rename files. I learned the hard way, I was used to file management using the OS, not fossil; I had to undo my changes using the OS and do them through fossil.

Do I personally want fossil to specifically track I renamed a file? Not now. Noting it in a commit message and being able to see the name/path change over time using /timeline and /dir is enough for me.

But I am not against the other anon who, I think, wants to track name changes.

Another way of summing up why I started this thread is captured in the last paragraph in your post #4. Which is what I tried to state after the “IMO” in my previous post in point #2.

Thank you for the link to that page. I will re-read it. I've scanned it in the past, hopefully more will stick this time. :-)

what else besides a file can show up on /finfo?

I get where you're coming from, but realize that /finfo isn't normative. Fossil tracks more than what appears there, and it is its durable data structures that matter here, not the current limitations of the UI. If /finfo someday gains the ability to show more info about renamed files, that will be lovely, but that addition would tell us nothing about whether Fossil ever had a limitation in this regard. At bottom, it doesn't. Someone merely has to write the code to expose this underlying truth in the UI.

Perhaps I misunderstood.

Nope, you got it.

What I was trying to get at in my prior reply is that there are other operations Fossil does track besides add and rename. It can work out when a file was deleted, when it gets/loses an EXEC bit, when it changes to/from a symlink…