I see occasional references to pijul status but my alpha 22 installed on a Mac seems to not have it. Is this Pijul command real or am I misunderstanding the references?
1 Like
pijul help gives you the list of commands. The equivalent status is probably diff.
So, I think status should be added back in, because diff, afaik, doesn’t give one very important piece of information, which is what things have not been added to the repo with pijul add. The old pijul status command used to tell us this. It would also tell us whether things needed to be recorded or not (if anything was modified)
5 Likes
Ok, so, I just checked, you added a pijul diff --short to do part of what I wanted, apparently.
I want to just mention that I hope the interface doesn’t get like git or other unix-like terminal programs where you have to use flags for a quadrillion things, because that’s quite honestly a very bad interface, imo.
I just don’t want to have to use a bunch of flags to do anything useful.
1 Like
Why do you think I didn’t reimplement the redundant status command?
I’m saying status should be reimplemented, because hiding a more common action under a flag is bad interface design, imo. diff is less useful than diff --short, and diff --short is used much more frequently than diff. I would either reverse the diff command so that it’s diff and diff --long, or put the pijul status command back. That’s just my personal preference though.
I just think default or frequent actions shouldn’t be using flags. They should be easily accessible. Flags should be for less common (or non-default) actions.
2 Likes
Let me clarify… I see why you made the choice, you don’t want a billion subcommands like git, so you want to reduce that by combining commands. I actually agree with this… but only partially.
I think this is not worth it for very frequent commands, like status. Overloading commands with a bunch of flags can get confusing, requires more to remember, and requires more typing, so they should be used for non-default or less used things. That’s basically all I’m saying.
So, the way I think about it is like a spectrum, where there’s two extremes on either end… a million flags with very few commands on one end, and a million commands with very little flags on the other. I think it’s best to be in the middle - common actions as commands, less-common stuff as flags. Also, sane defaults!
1 Like
If I may offer a way to cut the Gordian Baby in half, if there is an analog to git alias, such “very frequent commands hidden inside a flag” could be renamed easily, giving us the flexibility to use either approach.
1 Like
But that goes completely against sane defaults. People shouldn’t have to customize a billion things just to get something useable. Customization like this, again, should be kept for less-common stuff.
If we end up having a situation where when people install pijul the very first thing they do is alias for a status command, then that should tell you status really should be a builtin/default command.
Additionally, the status command can actually do more than diff --short (and I think it perhaps should do more).
1 Like
I think there should be a show command or status.
Most of the commands are verbs and they make sense.
The ones that don’t make sense are
log (which doesn’t log, but shows)
archive (which creates an archive, not archives the repo)
change (which doesn’t change anything, but shows something)
channel (which could be a verb, sort of)
remote (not a verb… maybe connect?)
5 Likes
In particular, there should be a concept of a staging area. At the moment you can only commit part of your changes by editing the undefined patch format on-the-fly. status is a good catch-all for “what’s going on” as well. On merges, rebases, pull-conflicts it tells you what state git is in and what you can/should do. diff doesn’t do any of that.
3 Likes
Indeed. The pj commands are counter-intuitively named.
One of pluses of Mercurial is how “intuitive” the commands are to most people.
Hi everyone, brand new user of pijul here. I do think that a status (or something similar) is fundamental. It is very helpful to have a command dedicated to know what the sate of the project is, in term of modified files or new ones (that are missed by diff --short). Actually one of the very first things that I tried to do after successfully downloading pijul (after recording a change) was trying to do pijul status.
Also, an interface like this with a stable output could be used to build a hint of the state of the project for the PS1 like we do in git.
2 Likes
My workflow is very simple via aliases in shell.
In general i dont care about commands.
alias pis='pijul diff --short'alias pin='pijul pull -a'- and so on;
I’m missing something, and maybe I just glazed over it in the discussion. Suppose I have a pijul repository, which contains some files that are neither tracked nor ignored. How do I get a list of such files?
1 Like
My two cents: git status is such a fundamental step in most users workflows, there really needs to be a default command / alias this.
I found the lack of this really annoying just after 5 minutes of trying things out.
Sure, I just added an alias, but this is one of the first commands that every user will look for.
Also: pijul diff --short is really not what I’m looking for, since it does not show new files or changes.
2 Likes
I don’t understand. If you like git status, how can this be “really not what you’re looking for”? It just seems we need to add a few features to it, not that git status is a completely different command.
Also, what do you mean when you say “it does not show changes”. I thought it only showed changes.
1 Like
Out of curiosity, how do you deal with lack of git status, since apparently there is currently no command to show untracked files?
I would probably forget adding new files all the time.
Do you just do a pijul add . and remove what is not relevant for a patch?
1 Like
It’s definitely a missing feature. I usually remember to add them right after I start a new file. But the issue hasn’t come up much in my own projects, so I have never been annoyed by it.
When you said it was a completely different thing from pijul diff -s, did you have a completely separate command in mind (such as pijul add . --dry-run)?
I phrased that poorly.
diff --short would be the same thing if it showed untracked files.
My concern is more about it being such an important command that it should probably have it’s own dedicated command.