Is there an equivalent of `git status`?

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.

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?)

3 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.

2 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.

1 Like

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.

A graphical user interface would show certain basic information at a glance, always visible. A shell tool can’t, of course. git status solves that problem. A pijul status would be convenient to that effect as well:

  • current channel
  • remote repo
  • files that are not tracked
  • files that are changed but not added
  • files that are added but not recorded

git status also shows which commands should be used to undo such changes. It’s an important part of my workflow. The working directory, tree, and pristine carry a lot of state, and a status command would help people not to accidentally miss anything.

1 Like

Would it be better to discuss potential tooling that would benefit from a status-like command here, or in a topic dedicated to that tooling, and any feature requests it may generate? I’ve got something I want to work on inspired by cruft, but with pijul instead of git, and a somewhat different workflow. For this kind of automated, change the repo state tooling, it would be really helpful to have an equivalent of the command that cruft uses, git status --porcelain, which outputs a minimal list of filenames that don’t correspond to the state of the repository head, and are not ignored.

1 Like

That would be really helpful indeed. I’m not making much progress on this question at the moment, because I’m changing the backend in Pijul, and that is a massive job.

I just now put together that it’s probably a smaller conceptual leap to talk about Darcs interface features that sound useful (or have been useful, if you have Darcs experience). So, I think what I would like is some equivalent to darcs whatsnew --look-for-adds.

I had more I was going to say here, before I realized that I have some related issues about Pijul’s existing commands that I think should be discussed elsewhere. I’m not sure whether “here are these subcommands that I think should act differently” is best in a new thread here, on the Nest, in Zulip, or somewhere else.

2 Likes

More than the smaller leap, while it’s been a long time since I’ve used it given the prevalence of git, the darcs interface is simply excellent.

IIRC, darcs whatsnew is similar to git status.

I always do git status first, and then either git diff file or just git diff if there aren’t many files. But more often I just do an interactive git add -p instead of a diff and never use diff.
I guess, if diff and status are the same command, the default should be the short version, and the long version should require an additional flag (--long?)