Since there is an option on the archive command to specify a state, it should be trivial to use the same logic to output a single file at a specified state. Darcs calls this show contents; Git calls this show. Breezy, Mercurial, and SVN call this cat.

I would call it show and perhaps rename the change command to show for discovery and to alleviate the ambiguity of change as a verb and noun.

Unlike these other tools, in Pijul this is far from easy to implement efficiently. I should definitely start my “light tags” idea, at least implement the core algorithms.

It doesn’t have to be efficient; it just needs to exist. Darcs has it, and Pijul already sort of has it as part of the archive command, so what is the big deal? Perhaps it is a flag or filter on archive?

You’re right, a command like that shouldn’t be too hard: just look at the state you want, prepare it in memory using a bunch of unrecords internally, and you’re done! This can definitely be done in <50 lines of code in Pijul itself (not Libpijul).

How do I test this? I see that you added a flag to fork, but I don’t see how the user extracts a file at a certain state.

Also, I just happened to see this because I was looking for it to reference in another discussion. Although I opened this, I was not notified by email of your change and close.

Definitely a bug in the Nest, thanks for notifying me.

Is this sending an email?

Yes, I got the email.

Can you tell me how your change for fork solves this issue? And how to test?

how about this?

Cool. Nothing changed, so I’ll have another look.

The change for fork solves the issue by letting you create another channel in a specific state: look in pijul log --state for the state you want, then fork to that state in a new channel.

With that answer, I don’t consider this issue solved. The user needs a single command to output a single file at a specified state.

Can you give an example of what you want?

As I said before:

I would call it show and perhaps rename the change command to show for discovery and to alleviate the ambiguity of change as a verb and noun.

Therefore, an example would be pijul show contents --state XYZ README.md

or pijul cat README.md --state XYZ

From Darcs:

darcs show contents [OPTION]... [FILE]...
Outputs a specific version of a file.

Options:
      --match=PATTERN       select a single patch matching PATTERN
  -p, --patch=REGEXP        select a single patch matching REGEXP
  -h, --hash=HASH           select a single patch with HASH
  -t, --tag=REGEXP          select tag matching REGEXP
  -n, --index=N             select one patch
      --repodir=DIRECTORY   specify the repository directory in which to run

Show contents can be used to display an earlier version of some file(s).
If you give show contents no version arguments, it displays the recorded
version of the file(s).

From Git (leaving out the zillions of options):

git show [<options>] [<object>...]
       Shows one or more objects (blobs, trees, tags and commits).

       For plain blobs, it shows the plain contents.

       For commits it shows the log message and textual diff. It also presents the merge commit
       in a special format as produced by git diff-tree --cc.

       For tags, it shows the tag message and the referenced objects.

       For trees, it shows the names (equivalent to git ls-tree with --name-only).

From Breezy:

Purpose: Write the contents of a file as of a given revision to standard output.
Usage:   brz cat FILENAME

Options:
  -d ARG, --directory=ARG
                        Branch to operate on, instead of working directory.
  --filters             Apply content filters to display the convenience form.
  --name-from-revision  The path name in the old tree.
  -q, --quiet           Only display errors and warnings.
  -r ARG, --revision=ARG

  If no revision is nominated, the last revision is used.
  
  Note: Take care to redirect standard output when using this command on a
  binary file.

So, the currently implemented solution requires these steps:

1. pijul log --state to find the state id
2. pijul fork --state <id> temp to create the temp(orary) state
3. pijul channel temp to obtain that state
4. view the file

Step 3 is only possible when there are no unrecorded changes: this is a serious limitation. (It also requires recreating all the files when only one is needed)

To show the diff viewer for a past change in the VS Code extension, it is necessary to view 2 past versions of the file (the one before the change, and the one after). This means that the procedure above would have to be done twice. The user may see an extra temporary channel appear in the list of channels during processing.

So, I favor the idea of a single command pijul show (as proposed above), which can be run even with unrecorded changes and without requiring a change of channel.

Umh, I have a simple idea to show diffs for a past change in VS Code: present the diff included in the text of the pijul change using diff2html. That should not be too difficult to implement in the VS Code extension, and does not require any change in pijul!

However, we won’t have the lines surrounding the lines changed in the files. To do this, we would need the functionality discussed above. But that can wait, I presume.