FEATURE REQ: group common commands under 'ls' instead of separate commands

[Martin Pool]

On 11/09/05, Kevin Smith <yarcs at qualitycode.com> wrote:
> Jan Hudec wrote:
> > No, it's not. Status does *NOT* list files---it summarizes changes! Status on
> > a clean checkout always produces an empty output. That's the way it's meant
> > and useful. In short, status talks about changes while inventory talks about
> > list of files.
> 
> The output from status is a list of files, which might be empty. If
> status listed anything other than files, then I would agree with you
> that it doesn't list files.

Actually in Aaron's code, it also gives a summary of what's been
merged in but not yet committed.  You can make an argument that
doesn't belong, but I think in terms of "what's happening here?" it
really does.

> Now, there's still a usability question of whether a given user task is
> done frequently enough that it deserves a separate command, even if it
> could be handled as an option to a different command. If I understand
> correctly, the current default behavior of bzr status is very similar to
> what bzr diff --short might do.

That is correct.  status shows a bit more information about unknown
files, can optionally can tell you about unknown/ignored/unchanged,
and probably in the future about merges.  But the "compare two trees"
functionality is the same.  In both cases the default is the last
commit and the working tree.

So "status" is a summary diff plus a bit more information.  The first
paragraph of "info" does a similar thing.

('tree' is a bzr term for something that's either a committed version
or a working directory.)

> Conceptually, I believe status and
> inventory are twins.

No, there's a big difference.  status and diff tell you about the
difference between two trees, inventory tells you the contents of
*one* tree.  So inventory can't tell you what was changed, because
"changed" implies changed compared to some other version.

> Just because tla treated inventories as something distinct doesn't mean
> they really are. 

The user experience for inventories is (and will be) very different to
tla.  You should never need to see them unless you're doing some kind
of scripting or extension.

> I now have some fear that the nature of bzr will change
> distinctly as tla folks join the team. One of the things I liked least
> about tla was its complexity, and one of the things I really like about
> bzr is its simplicity. I hope bzr retains its character.

I think it will stay simple, at least as long as I have anything to
say about it.

The value of the original proposal about removing those commands is,
to me, mostly that it tucks advanced commands away where new users
don't need to see them so much.

Somebody gave this recipe the other day; it's the kind of scripting
you can do in tla and I'd like to still support it.  It's not so easy
to do in, say, svn, because less stuff is exposed in the shell
interface.

 for f in $(seq 1 $(bzr revno)); do bzr log -r$((f+1)) > $f.patch; bzr
diff -r$f..$((f+1)) . >> $f; done

I think it's good that you can write that if you're the kind of person
who remembers what $(()) does in shell.  On the other hand, tla
clearly ...... did not have the kind of user interface we're aiming
for here.

-- 
Martin