9 ms·

> doesn't accept wildcards I could be misremembering, but isn't it the shell's job to expand the wildcard?

chrismorgan 5y ago
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.
- maccard 5y ago
  Yep I am on windows using command prompt!
maccard 5y ago
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!
- deleted 5y ago
  [deleted]
- pmeunier 5y ago
  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.
  - maccard 5y ago
    That's a fair point, and I got hung up on the 1.0 label rather than the beta label. I've adjusted my comment accordingly!
  - sam_lowry_ 5y ago
    To differentiate from git, pijul should focus on its core features, not on arcane command line functionality. After all, you do not know how pijul will find its success. Maybe command line will end up not being used at all one day. Remember Java? It was touted as a language for web applets first.
    - chriswarbo 5y ago
      Java was designed for set-top boxes. It later transitioned to web applets. Then to web servers.
    - IshKebab 5y ago
      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.
      - morelisp 5y ago
        > 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.
        webmaven 5y ago
        > > 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/ 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?
  - nextaccountic 5y ago
    He's on Windows; https://news.ycombinator.com/item?id=29993842 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. Pijul could of course just not support Windows, but maybe one could just use a glob one liner https://docs.rs/glob/latest/glob/ https://docs.rs/glob/latest/glob/
- minroot 5y ago
kadoban 5y ago
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.
alkonaut 5y ago
Posix shell do it. Any cross platform tool must handle it per platform. On Windows you can e.g. call a OS function.
- sam_lowry_ 5y ago
  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.
  - alkonaut 5y ago
    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.
  - WorldMaker 5y ago
    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.

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.

maccard 5y ago
Yep I am on windows using command prompt!

maccard 5y ago

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!

deleted 5y ago
[deleted]
pmeunier 5y ago
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.
- maccard 5y ago
  That's a fair point, and I got hung up on the 1.0 label rather than the beta label. I've adjusted my comment accordingly!
- sam_lowry_ 5y ago
  To differentiate from git, pijul should focus on its core features, not on arcane command line functionality. After all, you do not know how pijul will find its success. Maybe command line will end up not being used at all one day. Remember Java? It was touted as a language for web applets first.
  - chriswarbo 5y ago
    Java was designed for set-top boxes. It later transitioned to web applets. Then to web servers.
  - IshKebab 5y ago
    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.
    - morelisp 5y ago
      > 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.
      - webmaven 5y ago
        > > 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/ 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?
- nextaccountic 5y ago
  He's on Windows; https://news.ycombinator.com/item?id=29993842 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. Pijul could of course just not support Windows, but maybe one could just use a glob one liner https://docs.rs/glob/latest/glob/ https://docs.rs/glob/latest/glob/
minroot 5y ago

kadoban 5y ago

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.

alkonaut 5y ago

Posix shell do it. Any cross platform tool must handle it per platform. On Windows you can e.g. call a OS function.

sam_lowry_ 5y ago
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.
- alkonaut 5y ago
  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.
- WorldMaker 5y ago
  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.