Maybe a feasible improve for next version of Sigil?

[RbnJrg]

Until I reach the final version of an epub, I'm going to generate three, four and even five checkpoints and sometimes I don't remember very well the differences between each one of them.
Would it be possible to have the possibility to associate some lines of text to each checkpoint so that the user can write down what characteristics each one has?

[DiapDealer]

I'm not opposed, in theory. I think it would be a handy feature myself. I just don't know how difficult it would be in practice. The checkpoint identifier is actually the github tag name. So we would probably have to get creative to have a "note" value that was associated with each github tag. Perhaps the commit message for the tag, or an annotated tag?

No promises, but I do like the notion.

[KevinH]

I had originally considered that, but in the end I wanted the creation of a Checkpoint to be just a single click and *not* require a more involved prompt for extra information. That said, the checkpoint manager could be modified to allow an extra Notes column. But using it would require intentionally running it to add the note or description *after* creating the checkpoint.

If someone has an idea of how to go about associating a note with the creation of a checkpoint without having to constantly prompt for it, I am all ears.

[Notjohn]

What's a checkpoint? A marker for something you want to return to?

[DiapDealer]

Originally Posted by KevinH

If someone has an idea of how to go about associating a note with the creation of a checkpoint without having to constantly prompt for it, I am all ears.

Maybe automatically slap a timestamp of some sort in the commit message or tag annotation when the checkpoint is created, and then have a way of optionally editing that commit message (via dulwich behind the scenes) using the checkpoint manager dialog?

That way, the date/time message could be helpful on it its own, and those who wanted, could change the commit message (or tag annotation) to something more relevant. Just spit-balling.

Another slightly out-there option might be to keep a tagname-to-description matrix in an untracked file stored in the repository itself (and included in a default .gitignore) that can be read and written to?

[DiapDealer]

Originally Posted by Notjohn

What's a checkpoint? A marker for something you want to return to?

It's a snapshot of the epub that can be restored and/or compared against the current (changed) version of the epub. The functionality is explained in the latest Sigil User Guide.

[RbnJrg]

Originally Posted by KevinH

If someone has an idea of how to go about associating a note with the creation of a checkpoint without having to constantly prompt for it, I am all ears.

That would be ok to me. So far, when I create a checkpoint, I only have a message in the status bar and nothing more. So, if in that moment appears a dialog asking me for entering a note, to me is a perfect solution. Of course, the text of that note, later, it should be visible in the checkpoint manager.

Another possibility would be, once I had create the checkpoint, to be able to go to checkpoint manager, and there, to have and space (a text field) where I can write something. Of that way, the user who want to write something can do it, and the user who doesn't want, do nothing, directly he doesn't open the checkpoint manager

[The_book]

I think git itself has annotated tag and lightweight tag. So we just need to add a new function to add "annotated tag", and write comment.

[The_book]

Originally Posted by KevinH

If someone has an idea of how to go about associating a note with the creation of a checkpoint without having to constantly prompt for it, I am all ears.

I think this is hard. But auto create checkpoint before/after file wide operation will be good, like replace all, reformat all,etc.

[BetterRed]

Originally Posted by KevinH

. . .

If someone has an idea of how to go about associating a note with the creation of a checkpoint without having to constantly prompt for it, I am all ears.

Could it be a Preference option: Prompt for checkpoint label: ☒

I use save as rather than checkpoint, because of a file name.

BR

[KevinH]

No auto checkpoints will be added. It is a single click to generate one. Only the user can judge when a full checkpoint is needed. Especially as the DryRun replace all allows you to verify correctness easily before large scale find/replace changes.

Annotated Tags with Tag messages are already being used by Checkpoints. The Tag message is autogenerated to keep things a single click.

So the only question is about prompting for every checkpoint or allow it only after the checkpoint in the manager if the user wants to add a different message.

I do not think prompting for every checkpoint is a good idea. It will just slow things down and is not actually needed. Each annotated tag already has time and date info. The manager will already show that info as well as a summary of files changed by each tag. Detailed compares can be done between any two tags to see specific changes if the file summary is not enough.

So if we decide to add this then I think it should be done by adding a message after the fact by selecting a tag. But I took a look at how that could be done as well.

There is already a gitignored .bookinfo file that keeps track of current repo head status. It could also keep a tag message history since dulwich does not support the git --edit switch on tags to allow updating the message. Using Tag delete and create does not work as the tag is always built from current HEAD which may differ from when the Tag was originally created. We could try manually editing the tag object in the dulwich object store but that will need to be tested to see if it is possible.

So there are problems to be overcome with both suggested approaches if we decide to do this.

[DiapDealer]

I agree with all of your main opinions: no prompting at checkpoint creation time (user opt-in or otherwise), and messages added after the fact by selecting a tag.

Now the only problem is figuring out how to accomplish it.

[DiapDealer]

You have way more experience with dulwich than I do, but doesn't porcelain's tag_create() have an "objectish" parameter that can be for something other than HEAD that a new tag should point to? I'm just wondering if we could point tags to commits upon creation. So that the original commit will still exist should we try a delete tag/recreate tag scenario. Again; just spitballing.

[KevinH]

It might be possible. As far as I remember, the Annotated Tag does just point to a separate commit. Deleting and recreating it will change the tag date and time unless we manually back fill it also.

From looking at the dulwich code I see that message is a slot in the Tag object. So I am wondering if we just get the Tag object from the object store using the tag name as key, then change only the message field and write it back with the exact same key to overwrite things in the object store.

Not sure if that is doable or not.

I may try and add an update_tag_message routine to repomanager.py to see if direct manipulation of an annotated tag message field is possible when I get some time tonight or tomorrow. If it works, we should be able to figure out a way for the manage repos dialog to add that field and allow it to be edited.

[KevinH]

From studying the dulwich code, direct manipulation of the message field of the object is not possible as the message forms part of the data that is hashed to create its id which is how the proper file is found.

Even tag_delete does not remove that annotated tag objects hash file, it just deletes the reference to it.

So changing an annotated tag message field directly is not possible, and using tag_delete and tag_create will just leave orphaned hash files in the repo.

Perhaps expanding the role of the .bookinfo file to keep a tag description for every tag is the right way to go here.