[MERGE] internal glob expansion for all commands on win32 and for invocations from the test suite

[Kuno Meyer]

On 11.08.2007 11:20, Alexander Belchenko wrote:
> bb:comment
> 
> Your current code is not directory recursive, as I could see.
> I.e. when I run
> bzr di *.c *.h
> I got diff only for files in root directory.
> How to force recursive behavior?
> 
> Per example, let's imagine I have many changed files
> in several nested directories:
> 
> a.txt
> e.c
> e.h
> dir/b.txt
> dir/f.c
> dir/f.h
> dir/subdir/c.txt
> dir/subdir/subsubdir/d.txt
> 
> How can I see diff for *.txt files above?
> 
> When I run
> bzr di *.txt
> I got diff only for a.txt
> 
> When I run
> bzr di */*.txt
> I got diff only for b.txt
> 
> So, current code does not handle well deep nested directories.
> May be because of my misunderstanding of globs.
> But anyway in this case I'd rather bb:abstain than bb:approve.
> 
> BTW, if I run
> bzr st *.txt
> or
> bzr di *.txt
> 
> Also, I get error if no txt files in my root directory:
> 
> $ bzr st *.txt */*.txt
> bzr: ERROR: Path(s) do not exist: "*.txt"
> 
> Why? Even if I have not such files in current directory,
> why bzr should return me error? I'd rather expect it
> silently ignore, i.e. pattern search should return
> empty list of not found files. But instead bzr blame
> me about my pattern "*.txt".

Basically, you are commenting that the current implementation (which has 
the same semantics as the expansion performed by Unix shells) does not 
fit with the Windows platform.

This may be a reasonable request, but it is not part of this patch. This 
patch is about providing the existing implementation to other commands 
than just 'add', and to provide it to invocations from the test suite.

If we shall change the glob expansion semantics on Windows (and I am 
willing to implement it, if there is a broad consent), then please 
outside of this patch, and not before a discussion and with the 
commitment and the approval of the specs of at least two Bazaar core 
developers.

Until then, I have to state that this patch does what it says, does not 
break any previously working functionality, does not add any new 
functionality that does conflict with the existing implementation, and 
has therefore nothing that prevents it from being applied to bzr.dev.

Kuno