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
untrack instead of
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.
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
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.
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
+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!]
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