On POSIX shells, yes. But from the error message, maccard is on Windows, and Command Prompt doesn’t expand wildcards. (PowerShell, I have no idea.) Windows programs where wildcards are reasonable are expected to resolve them themselves.
Honestly as a user it doesn't matter, ~it's a bad look for a tool when it's biggest competition _does_ handle it.~ - I'm going to consider it a feature of the competition!
The goal of a beta version is to collect feedback, so thanks for that. However, that particular command worked in all the repositories I tried, so I'm really curious about what you are doing.
To differentiate from Git Pijul should focus on usability. Thats by far the main complaint people have about Git. Not many people care whether it is patch based or snapshot based. It's super hard to explain what the advantages of that are.
If Pijul has an easy to use interface like Mercurial did then that will massively help adoption.
> To differentiate from Git Pijul should focus on usability... If Pijul has an easy to use interface like Mercurial did then that will massively help adoption.
Mercurial is effectively dead (outside of Facebook?) now. If the goal is simply to grow a project, repeating the same mistake doesn't seem like a good idea.
I don't think the goal or differentiation of pijul is to be popular via good UI, though. If the theory of patches is good, it doesn't matter if pijul "wins" or not, as long as whatever does can integrate it. If the theory of patches is bad, I don't want pijul "winning" just because it has a good UI.
> > To differentiate from Git Pijul should focus on usability... If Pijul has an easy to use interface like Mercurial did then that will massively help adoption.
> I don't think the goal or differentiation of pijul is to be popular via good UI, though. If the theory of patches is good, it doesn't matter if pijul "wins" or not, as long as whatever does can integrate it. If the theory of patches is bad, I don't want pijul "winning" just because it has a good UI.
Note that usability and UI aren't synonymous. A big part of usability is the mental model that users build up in their heads. With Git, the naive mental model doesn't match what Git is doing behind the scenes at all, which is a big reason Git's command line syntax is considered arcane.
It is possible to stick a Git 'porcelain' on top that does match the naive user's mental model (eg. https://gitless.com/), but very few use them.
If Pijul's Theory of Patches has superior usability, part of that superiority is likely to be how easily users can internalize a mental model of it's operation (learnability). The UI can help or hinder that process with various affordances or lack thereof.
So, from your perspective, a 'good' UI would be one that reveals the Theory of Patches in a useful, learnable, usable way; and ought not be just some superficial gloss hiding away the internals from users. In that sense, surely 'winning' due to 'good UI' is a worthy goal to strive for?
I'm not writing a usability thesis here, I'm just using "good" to abbreviate the GP's "an easy to use interface like Mercurial".
I don't think a good UI would be contingent on it surfacing the theory of patches. It needs to surface productive workflows supported by the theory of patches. One way to do that is to teach it; another way to is build something else on top of it.
What I don't want is for pijul to become something I have to integrate into my toolbox just because the next semi-technical founder I sling for found it "easy" three years ago. I already had to deal with git taking over a) because it was fast, b) because github was easy.
> What I don't want is for pijul to become something I have to integrate into my toolbox just because the next semi-technical founder I sling for found it "easy" three years ago.
If Pijul becomes popular, somebody will inevitably make it easy to use, so on some level it doesn't matter exactly why Pijul becomes popular in the first place.
> If Pijul becomes popular, somebody will inevitably make it easy to use
That's exactly why it shouldn't become popular because it's easy-to-use.
If something becomes popular because it's efficient (git), or has some beautiful core logic (pijul), or because it supports well-integrated workflows (fossil), then it will eventually be that and easy-to-use.
If something becomes popular because it's easy-to-use but sucks in every other way, then we are stuck dealing with it for another 30 years.
My point was that regardless of why something becomes popular, some people will add it as a dependency solely because of the popularity, even when the original reason for that initial popularity ceases to be valid.
Are you saying that it was a mistake for Mercurial to make their software easy to use? That's a strange thought!
Mercurial didn't lose because it was too easy to use. It lost because it was too slow and because GitHub became too popular. Those are orthogonal issues.
He's on Windows; https://news.ycombinator.com/item?id=29993842 mentioned that Windows cmd doesn't expand * (like if it were quoted, on Linux) and thus it's expected that Windows CLI apps expand the * themselves.
MUST is a strong word. I would rather not have pijul handling wildcards in Command Prompt. After all, who uses Command Prompt nowadays, when WSL2 and PowerShell are available at the + button in Windows Terminal.
PowerShell doesn't expand wildcards by default either, because it also assumes that commands handle their own wildcards by default.
You can cobble together the expansion somewhat easily yourself with something like Resolve-Path in PowerShell, but PowerShell doesn't use a posix-like approach here with "native" commands either because Windows (and DOS) has always left wildcard handling to EXEs by default.
It’s a must if you consider the windows platform to only have the native windows shell(s).
I have no data, but I’d wager cmd is still much more widely used than either ps or wsl is.
Of course the dominance of windows on the desktop among developers is smaller than it is elsewhere, but it wouldn’t even surprise me if as many git users use cmd as any posix shell.
Usually, yes. With git specifically, I find that it's better when git expands the wildcards though (ie I quote them so the shell doesn't). This allows things like "git add *.py" which will work over the whole repo.
I could be misremembering, but isn't it the shell's job to expand the wildcard?