Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unbury ignores file-arguments #69

Open
ibarland opened this issue Dec 18, 2024 · 3 comments
Open

unbury ignores file-arguments #69

ibarland opened this issue Dec 18, 2024 · 3 comments

Comments

@ibarland
Copy link

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
Copy link
Owner

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
Copy link
Owner

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

@MilesCranmer
Copy link
Owner

MilesCranmer commented Dec 18, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants