Why do `pijul add` and `pijul remove` exist?

I am new to Pijul and have only used Git before.

In Git you need to stage changes before you can commit them with git add. In Pijul changes seem to automatically be “staged” and instead you select what you want to record in the interactive pijul record process.

Why do I have to call pijul add and pijul remove when creating or deleting files when there is also a .ignore file with which Pijul should know which files to track/untrack automatically?

Git adds files to staging for commit.
Pijul adds paths to the tree being tracked.
Perhaps it should be track and untrack instead of add and remove.
The .gitignore file will cause a warning if your add command conflicts.
I don’t know if the Pijul .ignore file will do the same, or silently ignore.
Using an ignore list makes it easier to ensure that build output is not put into the repo, but it would be cumbersome to have to edit that list all the time if that were the only way to control the repo.

2 Likes

I acknowledge that forcing the user to use a .ignore file is not desirable.
I do however think that something should be changed about the current situation.
It seems quite cumbersome having to track each newly created file. Not to mention it would not be obvious in any way if you forgot to track a newly created file unless you compared pijul ls and ls before every pijul record (clarification: I mean in case there are a lot of changes. Of course you will notice if you only added a new file and changed another). Deleting a file seems to require two commands as well. Untracking it and actually removing it.
The .ignore file feels quite useless as well. If you have to manually add every file you want to track why don’t just not track the files in question. Why would an extra .ignore file be needed.

A good compromise might be having a newly created file be tracked automatically unless it is on the .ignore list but still allowing the user to untrack it with pijul remove and untracking deleted files automatically. But then I am not sure this could be implemented in a good way without any surprising edge cases.

Hi! Are you aware of pijul diff -S? It shows untracked files. I’m not a big fan of doing anything automatically, but that shouldn’t be hard to add as an option to pijul record, or an external command.

Controlling file tracking via a black/white list is not generally manageable. To be efficient, these lists allow for globbing, yet, in the real world they would need countless of exceptions whether you start with inclusion or exclusion patterns. And the sheer length and (non-)structure makes it impossible to judge a priori if a certain file is currently included/excluded and why.

It would be a nightmare to constantly chase your .ignore file just because it always presents you new files to commit that you are just not interested in. So, an imperative approach to inclusion/exclusion is the only practical way, with a support for .ignore files reducing the noise.

git add does two things to an untracked file. It does git add -N to mark the file “to be tracked”, and stages its contents for the next commit. The same goes for git rm. It does git rm --cached to mark the file “to no longer be tracked” and removes it. While it is normally correct to add the file for the next commit, it may be a nuissance to remove a file from the worktree when you inadvertently added it with git add and just want to undo that.
Still, changing the status of “un-/tracking” a file is done in the same way and with similarly named commands in both, git and pijul. Pijul is “purer” in a way in that its add/remove commands do only change the tracking state.

You’re right, though, that the defaults and alternatives to pijul’s commands may be a bit off. pijul diff should, maybe show untracked files by default. Better yet, pijul diff -s should have its own pijul status command, because you (at least I) really want to visualise your worktree status often.

Also pijul remove could remove the file from disk or provide a pijul remove --file/force option to do that for you. As it is, pijul add/remove are misnomers and should be named pijul track/untrack, because that is literally their only function. It would also make it clear that you don’t have to pijul track a file before each record but only once, when you want pijul to start to track it. pijul untrack --rm/remove would become a natural opposite of pijul track.

2 Likes

+1000 for a status command! I just don’t think of diff that way and don’t like having to remember command options.

+1. I have pjs (pijul status) aliased to pijul diff -s.

[semi-related: anyone for a pj executable rename!]

Remember that git add is not only for copying things from the working directory to the staging area, but also for adding files to the set of tracked files. The latter functionality seems to correspond exactly to the functionality of pijul add.