> Make sure your source files are backed up, like in source control, or something. Tup is able to delete old files automatically, though it tries to prevent you from doing silly things like overwrite your hand-written C files. Still, it would suck if you got boned because tup has a bug or something. Hey, your hard disk can go at anytime, too.
This is unacceptable, no thanks, I build first (test) and then commit, not the other way around.
I agree with you about that statement, but why don’t you commit to an unstable branch? Why risk losing something or pass up having a better development history?
The way the warning is worded suggests that any invocation of tup has a risk of deleting your files, implying that to be entirely safe you should commit before every single build, which would be ludicrous.
git commit --amend, rebase with squash/fixup, etc. I easily make a dozen commits per hour, it's like undo on steroids and you can always clean it up later.
> Make sure your source files are backed up, like in source control, or something. Tup is able to delete old files automatically, though it tries to prevent you from doing silly things like overwrite your hand-written C files. Still, it would suck if you got boned because tup has a bug or something. Hey, your hard disk can go at anytime, too.
This is unacceptable, no thanks, I build first (test) and then commit, not the other way around.