EDIT: I now realized what I’m trying to achieve and why isn’t clear at all, please see my response below
As stated in the introduction thread, I really like how pijul works, and would like to contribute to the project. I played around and found a few things I would like to work on. As I don’t know if these changes make sense at all, I thought I’d better ask first!
You can think of this list as a combined feedback/discussion/wish list.
Implement pijul status
I don’t know about you, but I spend a lot of time switching tasks, and forgetting about things. Here are some examples of things I forget:
- what unstaged changes do I have
- what have I staged
- what branch / channel am I even working on
- have I pushed my changes
- what time is it again?
git status is my second most used command, behind
Implement pijul merge
It is very much critical, for at least these use cases:
- merging channels with a lot of changes in different areas, where hand-picking from the log is error-prone
- automating merge branch
- long running branches that need to be “rebased”. sometimes, a feature needs to be worked on for quite some time, and receives changes back from its base channel in order to still be relevant. These rebases sometimes involve hundreds of changes from the base channel.
It seems to me that what’s need is to run a diff on channel’s set of changes. I don’t think there currently are cached data structures available to do this? Here’s my take: prolly trees are a very good tool for the job. They are a probabilistic sorted shared data structure (like merkle trees) set where order of insertion / deletion does not matter. It was, I believe, first introduced in noms, a versioned database.
Make the output of various commands friendlier
- color the output of
- color the output of
- show change authors and line ranges in
- the naming of
pijul changeis very odd: it implies the command changes something, yet it shows a change. I legitimately had a very hard time finding it.
pijulis a bit long for a VCS binary name (It also felt slightly awkward to type at first, but that’s a locale dependant thing). I’d love to have
pjto be available by default.
- Even though the theoretical background of patches themselves is well documented, I didn’t find documentation about the software architecture of the project. That’s an issue, as new developers need to be able to navigate the code. A diagram of data and processes would be amazing too.
- Some subcommands have no available documentation, such as
I’ll definitely try to tackle some of these by myself!
What do you think?
Did I miss something?
Anyone wants to help me implement / implement one of these?