3 ms·
The use cases define whether pijul is sufficient for your needs. For bisecting to find a bug, it seems you could easily bisect along a history of patches. Maybe
by h0l0cube 3y ago
The use cases define whether pijul is sufficient for your needs. For bisecting to find a bug, it seems you could easily bisect along a history of patches. Maybe there are patches that may alter the history that haven’t yet been merged, but that’s really an agreement between you and your collaborators that they should commit often. A similar constraint is required if you need to tag a commit for a release (where a snapshot can have meaningful implications for legal compliance, reproducible builds etc.)
- est31 3y ago> it seems you could easily bisect along a history of patches. I've explained why this doesn't work in my comment above. Both a history of patches and bisect halting at the state of a specific patch are not things pijul supports: patches are only diffs so don't have "repo state", and are ordered only after their strict dependencies, i.e. those patches whose lines they modify.
- h0l0cube 3y agoYou could still isolate the changes that cause a problem, and it would still be reversing state in chronological order, but there might not be a one-for-one mapping between builds and the history, because the history can change upon merge. Though it's perhaps possible to freeze a channel for each build version, but I'll concede that seems like a hack.