I often have to convert a repository, work locally with pijul and then create pull-request using git again. It would be really helpful if pijul would ignore .git by default. Because my repository will contain .pijul and .git to make it easy to transfer changes. If I forget to add .git to .ignore I would add .git if I do a pijul add -r .

I solved my problem using a workaround, but it might still be a valid change.

Q7CHND modifies the pijul init procedure to create a default .ignore file which (for now) contains:

.git
.DS_Store

H72JG6 is a feature idea; a --kind flag for languages/project types.

pijul init --kind=rust would add /target and Cargo.lock to the default .ignore in the same way cargo new does, --kind=node would add node_modules, etc.

I like the basic idea but find it a strangely complicated implementation. How a about the following? Ship pijul with a set of init handlers or “templates” which are shell scripts/binaries and can be called with pijul init --kind=<> or --template=<> or whatever. The user can copy/modify/add them in, e.g. ~/.config/pijul/templates and has her own/company-driven setup. Wouldn’t that be very neat, lightweight and extensible? Pijul already comes with a hook mechanism. So, it can be extended, maybe…

EDIT: Local copies in ~/ are meant in addition to a site-wide location.

@spacefrogg

Thanks for the feedback. The weird IGNORE_KINDS const was a cheap way to make a static key/value map. If this feature is added at some point, something nicer can be used that enforces other desirable properties (disallowing duplicate keys, error-reporting, warnings for near-misses, etc).

For the template idea, if the user is at the point where they’re adding their own script-like templates, what would motivate users to use a pijul template instead of writing an external (bash or whatever) script? Or is the idea to have like a curated set of scripts and a designated/consistent location for new ones?

I see, what you mean. Yes, maybe, one wants to have that…

Regarding templates: Yes, my intention was to ship a curated set of scripts. But as with that kind of functionality in general, it will never suite everybody. That’s why I was thinking of an external, file-based mechanism, which allows companies/distros to ship modified scripts system wide and an override mechanism in home to have modified scripts in a personal scope.

I like this idea! One way to use @spacefrogg’s feedback is to add an option in the global configuration, so that non-Rustacean users won’t have to send us a patch to extend the list of “ignored kinds”.

Just a minor comment on @ammkrn’s patches: the cases where you want to use the raw std::io::Write::write are usually pretty low-level, as these correspond to a single system call, and there is no guarantee that the entire byte vector is written. std::io::Write::write_all gives that guarantee.