unbury ignores file-arguments

[ibarland]

rip --unbury myfile1 myfile2 restores the most-recently removed file, and ignores myfile1 myfile2.

Demo [excerpt]:

11:23 2600 typhoon:~/rip-demo > rip myFile1 myFile2
11:24 2601 typhoon:~/rip-demo > rip -u myFile1
Returned /var/folders/n0/q8x…3q0/T/graveyard-ibarland/Users/ibarland/rip-demo/myFile2 to /Users/ibarland/rip-demo/myFile2

Demo [full, w/ ]:

11:23 2597 typhoon:~ > mkdir rip-demo
11:23 2598 typhoon:~ > cd rip-demo
/Users/ibarland/rip-demo
11:23 2599 typhoon:~/rip-demo > touch myFile1 myFile2
11:23 2600 typhoon:~/rip-demo > rip myFile1 myFile2
11:24 2601 typhoon:~/rip-demo > rip -u myFile1
Returned /var/folders/n0/q8xr07117v9b9smm8f35y6bcm2x3q0/T/graveyard-ibarland/Users/ibarland/rip-demo/myFile2 to /Users/ibarland/rip-demo/myFile2
11:24 2602 typhoon:~/rip-demo > tail -2 `rip graveyard`/.record
2024-12-18T11:22:31.622112-05:00	/Users/ibarland/some-other-old-history-not-part-of-demo	/var/folders/n0/q8xr07117v9b9smm8f35y6bcm2x3q0/T/graveyard-ibarland/Users/ibarland/some-other-old-history-not-part-of-demo
2024-12-18T11:24:04.903094-05:00	/Users/ibarland/rip-demo/myFile1	/var/folders/n0/q8xr07117v9b9smm8f35y6bcm2x3q0/T/graveyard-ibarland/Users/ibarland/rip-demo/myFile1
11:24 2603 typhoon:~/rip-demo > rip --version
rip 0.9.0
11:24 2604 typhoon:~/rip-demo > which rip
/opt/homebrew/bin/rip
11:24 2605 typhoon:~/rip-demo > 

[MilesCranmer]

The syntax -u only accepts the graveyard path of the file, rather than the path within the current directory. So this should be instead:

rip -u $(rip graveyard -s)/myFile1

which should fix it.

Maybe we could make the behavior compute the graveyard path automatically though?

[MilesCranmer]

I guess we should also make it error if the requested file to unbury is not found.

[MilesCranmer]

P.S., part of the reason you need to provide the graveyard path explicitly is because you can have multiple files with the same name:

touch tmp
rip tmp
touch tmp
rip tmp

rip -u tmp
# Which `tmp` should be unburied?

The explicit interface (current approach) requires you to specify this via

rip -u $(rip graveyard -s)/tmp~1
# returns to `tmp` in current dir

But I can see this isn't as ergonomic. So maybe there's a better way.

[parkero]

Giving a filename and having it return another without acknowledgement does seem a little unintuitive to me as well. Here is one possible idea, attempting to be as least surprising as I can think of:

unbury the last deleted file, behavior unchanged

rip -u

conditionally unbury the file

rip -u <target>

• if <target> is explicitly a file located in $(rip graveyard -s) -- then the old syntax works as before
• otherwise, if one and only one version of <target> exists in the graveyard -s -- then unbury <target>
• if <target> does not exist -- do not restore any files, message on stderr that the <target> file does not exist; possibly appended with a seance of available files
• if multiple <target> versions exist (~1,~2, etc) -- print ambiguous filenames to stderr, possibly with dates. Advise user to use the explicit path when they run the command again.

Thoughts?

[MilesCranmer]

I think these are great ways to handle it!