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?
I see occasional references to
pijul help gives you the list of commands. The equivalent
status is probably
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)
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.
Why do you think I didn’t reimplement the redundant
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 --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.
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!
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.
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).
I think there should be a
show command or
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
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.
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
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.
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?
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.
pijul diff --short is really not what I’m looking for, since it does not show new files or changes.
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.
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?
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.