Hi @pmeunier, thanks for reaching out! Right now, I think there are two necessary steps before I’d consider the extension ready to publish on the Code marketplace.
The first is that I need to grit my teeth and get the less glamourous work over with to provide a better end user experience. It might all work properly out of the gate, but I need to test the extension with different environment setups to make sure that it won’t blow up when other people try to use it, as well as test how the extension handles different error cases that exist within Pijul itself.
The second thing is more feedback from actual Pijul users about their workflows and how well the extension accomodates them. This is a bit of a chicken and the egg problem since its hard to get feedback without a released product. I’ve built the extension around the way that I use Pijul, which has been almost entirely on the extension itself, but I have no idea if it’s the same way that other people do.
Beyond those two things, I think the extension is in a pretty great place at the moment. I don’t know if you’ve been able to build it and try it out for yourself, but I think that it is close to having a roughly equivalent feature set to the basic Git support that VS Code ships with. Recently I’ve been working on adding integration with remotes, but I’ve decided to shelve that for the time being since it seems like it might change with pijul/#243.
In terms of how the extension could be improved by changes to the Pijul CLI, more JSON interfaces would always be helpful. Right now the extension is completely reliant on fairly fragile regular expressions, so being able to directly consume JSON output would be fantastic for both the extension itself, and any other future Pijul tooling. That being said, I’ve already written regular expressions to consume the output of most of the commands so there’s certainly no rush to add new --json
flags.
One thing that I do have a real issue with which I think could be improved in Pijul itself is checking for untracked files. Right now I’m asking VS Code for a list of all the files in the open folder and its subfolders, applying my own .ignore
implementation (Which I don’t think handles all the cases correctly), and then comparing the list of files against the output of pijul ls
to determine which files are untracked. git status
shows the untracked files, so it would be great if Pijul could implement an equivalent to make my life a bit easier.
That was probably way more detail than you wanted, but I hope you and everyone else who reads this has a better idea of where the extension is at and how it could be improved.
One other nice-to-have thing that occurred to me recently would be a command which displays the state of a file under an arbitrary change. It’s something that most git extensions offer, being able to compare the current state of a file against any commit in the log. Obviously the git method can’t be directly applied to Pijul since it has a very different model, but it would be a very nice feature to have.
Maybe the command could show the state of a file under a specific change if all other non-dependent changes weren’t applied? I haven’t really dug into the specifics of how the change system works so I have no idea if this would be feasible.
Ok, I know it’s been a long time, but I’ve move a little bit on this: Pijul now has an untracked files iterator, which I just added, and which outputs json.
I just discovered this and got it installed, and am finding it already pretty great. pijul usability just took a big jump here! Thanks for working on it.
Hi! I’d love to see a usable release of this at roughly the same time as the beta. The beta is not very far: there are a few optimisations planned in Sanakirja (that’s a few days of work), and I also need to wrap up my implementation of tags, but it’s implemented and tested.
I wouldn’t mind providing an easy JSON interface to the command-line Pijul. There’s no rush, but if you can make a list of the things you need, I can promise to implement them.