bzr status

[David Ingamells]

David Cournapeau wrote:
> Ben Finney wrote:
>   
>> David Cournapeau <david at ar.media.kyoto-u.ac.jp> writes:
>>
>>   
>>     
>>> OTOH, the whole point of a relative status is that generally, when you
>>> are inside a tree, you don't care so much about files "above" you.
>>>     
>>>       
>> I don't find that to be the case at all. I find this attitude most
>> prevalent in people who use Subversion, where the limitations of the
>> system encourage arbitrary aggregation of directory trees that would
>> be better tracked separately.
>>   
>>     
>
> I may have phrased it poorly: I certainly did not mean that for a *given
> project*, you are always in a given subtree. But during development, it
> is certainly current to only care about a subdirectory for a *given
> period of time* (which may well change all the time, of course).
>
> I never thought about this before using git, but at least I largely
> prefer default view per subdirectory. It makes it easier to handle diff,
> blame, etc... Basically everytime you need to give a path, you have it
> from status. It is true that the git index (and not committing anything
> by default which is not in there) makes it even more natural, though.
>
> David
>
>   
I'm having a difficulty understanding why this debate is getting so hot 
and also a difficulty understanding what David C has said above.

David C, you seem to be arguing for status reporting only the files in 
or below your current directory (cwd), but they you say "Basically 
everytime you need to give a path, you have it ..." which, to me, is an 
argument for whole-branch status reports.

For the wider issue, maybe I'm a bit too much of a puritan, but my 
attitude is that if status gives a branch-wide report that lists too 
many files to be manageable then your updates are too large and you 
should be committing more often. If only a few files are reported then 
it should not matter that the whole branch is being reported. It would 
be easier to use conceptually (for me at least) to have bzr support a 
"bzr status ." to report just the sub-tree than to have status by 
default report sub-trees only and then to need support for a special 
switch like "bzr status --wholebranch".

On the initial subject of this thread (status should give paths relative 
to where you are), this argument is strongly supported by the 
fundamental concepts of Unix where the output from one command can be 
piped into another. An earlier message gave a weak example that someone 
then shot down, but there are many uses of pipes where there is no bzr 
command that replaces the piping e.g.

$ bzr add `bzr unknowns . | egrep 'html$'`

will avoid adding unknown files whose name does not end in "html".

The whole philosophy of Unix (and by transfer Linux too) is to only 
implement what is new and to use existing commands where possible. IMHO 
bzr should adhere to this principle - or at least not work against it.

David I