confusing message about ignored files on add

i agree

This message could also say which files were ignored - user shouldn't be forced to find them manually.

You can run "bzr ignored" to find out what files are ignored. At one point we did print out the list of ignored files. However, for anyone who works with build results in tree (such as python .pyc files, or C/C++ .o files) you end up with hundreds of ignored files in the working directory. You *don't* want to see a list of all of those files every time you do 'bzr add'.

I agree with the wording fix, and we could even point the user towards 'bzr ignored' if we want to expand on it a little.

I didn't know about that command. Expanding the message with it would be a great solution :)

I'm inclined to hide it from the add output, and put better text in the help of add.

I ran into this bug today, the message is confusing, having bzr giving an hint about bzr ignored or why those have been ignored would be nicer

I am looking at re-wording this. Bzr with the -v verbose option does list the ignored files and why.

Something like this, but it seems far too much wafle somehow.
$bzr add
...snip
adding downloads/atomorun2008-1.0.tar/atomorun2008-1.0/src/derelict/opengl/extension/sgi/color_matrix.d
adding downloads/atomorun2008-1.0.tar/atomorun2008-1.0/src/derelict/opengl/extension/sgis/generate_mipmap.d
add completed
ignored 31 file(s).
If you wish to add ignored files, please add them explicitly by name. ("bzr ignored" gives a list)
$

Thanks for your patch, Jason. It looks like a correct way to improve the wording.

I do have doubts as to whether we should omit this message at the end of 'bzr add' at all, as opposed to just mentioning that ignored files will not be auto-added and pointing to 'bzr ignored' in 'bzr help add', especially because add -v will tell you about them. What do you think?

I mean to leave off all of this:

"add completed
ignored 31 file(s).
If you wish to add ignored files, please add them explicitly by name. ("bzr ignored" gives a list)"

I agree Martin, infact while I was developing the patch I realised that it was too verbose and indeed I mention the -v verbose option above that people may use if they are aware of it.

This is a "trivial" bug, therefore I propose it be resolved without futher ado by:

Adding a sentance or two to 'bzr help add', relating to ignored files. and, either;

(1) Exactly what you propose above Martin, to keep the add ouput "clean"

(2) Alternatively, I suggest:
Print only (if there are ignored files):
"Not adding 31 file(s) matched by ignore list."

The use case for this is that someone may want to add .obj, .o, .so or .lib files (and other patterns, normally ignored), but find (too much later) that they have not been added and wonder why it may be, unaware of the -v option. At least with a simple diagnostic message they are notified of such; and they have enough to go on to notice and to rectify the situation.

I am quite happy to submit another change on my branch that will implement either of these solutions. I leave the decision up to you Martin.

2009/3/26 Jason Spashett <email address hidden>:
> I agree Martin, infact while I was developing the patch I realised that
> it was too verbose and indeed I mention the -v verbose option above that
> people may use if they are aware of it.
>
> This is a "trivial" bug, therefore I propose it be resolved without
> futher ado by:
>
> Adding a sentance or two to 'bzr help add', relating to ignored files.
> and, either;
>
> (1) Exactly what you propose above Martin, to keep the add ouput "clean"
>
> (2) Alternatively, I suggest:
> Print only (if there are ignored files):
> "Not adding 31 file(s) matched by ignore list."
>
> The use case for this is that someone may want to add .obj, .o, .so or
> .lib files (and other patterns, normally ignored), but find (too much
> later) that they have not been added and wonder why it may be, unaware
> of the -v option. At least with a simple diagnostic message they are
> notified of such; and they have enough to go on to notice and to rectify
> the situation.
>
> I am quite happy to submit another change on my branch that will
> implement either of these solutions. I leave the decision up to you
> Martin.

I think I'd still go for number one, for a few reasons:

- In general, we don't print out the count of files touched or
ignored. (Maybe someone wants to go and add --count everywhere but at
the moment no.)

- If you do have any intentionally ignored files, as most nontrivial
trees do, the count is just noise. Are you going to notice that it's
31 when it should be 27? Probably not.

- We now have no ignores by default, unlike when this code was first
written. So if nothing's configured to be ignored, there shoud be no
surprises.

- commit still defaults to verbose so you do get a definite clue there
that the thing you may have expected to be added was not.

So, just pull it out.

--
Martin <http://launchpad.net/~mbp/>

On Thu, 2009-03-26 at 00:31 +0000, Martin Pool wrote:

> - If you do have any intentionally ignored files, as most nontrivial
> trees do, the count is just noise. Are you going to notice that it's
> 31 when it should be 27? Probably not.
>
> - We now have no ignores by default, unlike when this code was first
> written. So if nothing's configured to be ignored, there shoud be no
> surprises.

Actually... we write a default list to ~/.bazaar. So its not true that
we have no ignores by default.

FWIW.

Rob

fix from jspashett sent to pqm

For Bug #76616

I think the wrong change might have been merged in from my branch
( https://code.launchpad.net/~jspashett/bzr/76616_ignored_on_add_confusing ). 4028 has been merged in instead of the change
you proposed (and I agree with) and I re-implemented in change: 4031 - 4032

Rob asked me to check out the bad merge claims.

I've tried investigating them, but I keep getting format errors, so I'm moving this back down to fix committed.

On Fri, 2009-06-12 at 02:16 +0000, Jonathan Lange wrote:
> Rob asked me to check out the bad merge claims.
>
> I've tried investigating them, but I keep getting format errors, so I'm
> moving this back down to fix committed.

Format errors?

Robert Collins wrote:
> On Fri, 2009-06-12 at 02:16 +0000, Jonathan Lange wrote:
>
>> Rob asked me to check out the bad merge claims.
>>
>> I've tried investigating them, but I keep getting format errors, so I'm
>> moving this back down to fix committed.
>>
>
> Format errors?
>
>
It looks like the wrong revision was approved as far as I can tell, but
it's quite possibly some mistake I have made in the processes. The
revision merged into the trunk was my first attempt as it were and not
the preferred version agreed with Martin Pool, so somewhere along the
line the 'old' attempt was approved instead of the new one I guess.

Yes, format errors.

jml@truth:~/src/bzr/trunk$ bzr info
Lightweight checkout (format: 1.6 or 1.6.1-rich-root or 1.9 or 1.9-rich-root or dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack)
Location:
  light checkout root: .
   checkout of branch: /home/jml/repos/bzr/bzr.dev
    shared repository: /home/jml/repos/bzr

Related branches:
  public branch: http://bazaar-vcs.org/bzr/bzr.dev
    push branch: lp:~jml/bzr/bzr.dev
  parent branch: http://bazaar-vcs.org/bzr/bzr.dev/
  submit branch: /home/jml/repos/bzr/bzr.dev

Format:
       control: Meta directory format 1
  working tree: Working tree format 4
        branch: Branch format 7
    repository: Packs 6 (uses btree indexes, requires bzr 1.9)

In the working tree:
      1054 unchanged
         0 modified
         0 added
         0 removed
         0 renamed
         0 unknown
       665 ignored
        83 versioned subdirectories

Branch history:
      4439 revisions
      1449 days old
   first revision: Sun 2005-06-26 16:55:27 -0500
  latest revision: Fri 2009-06-12 10:42:07 +0100

Repository:
     25288 revisions
jml@truth:~/src/bzr/trunk$ cd ..
jml@truth:~/src/bzr$ bzr cbranch lp:~jspashett/bzr/76616_ignored_on_add_confusing
bzr: ERROR: KnitPackRepository('file:///home/jml/repos/bzr/.bzr/repository/')
is not compatible with
RemoteRepository(bzr+ssh://bazaar.launchpad.net/%7Ejspashett/bzr/76616_ignored_on_add_confusing/.bzr/)
different rich-root support
HPSS calls: 10 (0 vfs) SmartSSHClientMedium(connected=False, username=u'jml', host='bazaar.launchpad.net', port=None)
jml@truth:~/src/bzr$

On Mon, 2009-06-15 at 00:56 +0000, Jonathan Lange wrote:
> bzr cbranch lp:~jspashett/bzr/76616_ignored_on_add_confusing
> bzr: ERROR:
> KnitPackRepository('file:///home/jml/repos/bzr/.bzr/repository/')
> is not compatible with
> RemoteRepository(bzr+ssh://bazaar.launchpad.net/%
> 7Ejspashett/bzr/76616_ignored_on_add_confusing/.bzr/)
> different rich-root support
> HPSS calls: 10 (0 vfs) SmartSSHClientMedium(connected=False,
> username=u'jml', host='bazaar.launchpad.net', port=None)
> jml@truth:~/src/bzr$

bzr info
http://bazaar.launchpad.net/~jspashett/bzr/76616_ignored_on_add_confusing
Repository branch (format: rich-root-pack)
...

Looks like jspashett has upgraded their branch to rich root, which stops
anyone that hasn't migrated yet working with it.

You should be able to do a 'bzr diff -r x..y' from the branch to get a
plain diff and apply it.

-Rob

Updated merge sent to pqm, it will be post 1.18.