[MERGE] Implement the oft-discussed automatic-add-and-delete at commit time.

[Martin Pool]

On Wed, Aug 6, 2008 at 3:21 PM, Robert Collins
<robertc at robertcollins.net> wrote:
> Martin says:
> ---
> I'd like to see separate --auto-add and --auto-remove, and perhaps an
> --auto-add-remove == -A which turns them both on.
>
> Possibly commit should also print the names of unknown files as it
> skips them as a reminder that they're there?  I do fairly often forget
> to add new files, and then need to uncommit to put them in.
> ---
>
> I think there are several changes being made by my patch. Perhaps it
> will help to itemise them:
> A) missing files now cause --strict to error
> B) missing files now cause default commit to error
> C) unknown files are added with the new option.
> D) missing files are deleted with the new option
>
> I think A) is sensible; --strict is IMO about saying 'there should be no
> unexpected path changes to the tree', and both unknown and missing files
> count. It can be done separate from the rest of my patch.

I agree.

It looks like your tests say that -a --strict should fail, if any adds
or deletions are needed, so the -a is having no effect.  I don't see
how that is very useful.

> I think B) is useful in that it will prevent user confusion. I've lost
> track of the number of users wandering into #bzr confused by our
> implicit-delete behaviour.

I also agree with this.  Although addition and deletion don't have
precisely the same consequences, the inconsistency is strange.

Of course this is a change from what people are currently used to so
we have to make sure it's reasonably explained in the NEWS file, the
docs are updated, and the message you get together with the commit
help gives people a reasonable clue what to do.  I see you didn't
touch the docs, and I would expect this is described there, so we
should check it.

Incidentally I think there is a bug asking for this change - I mention
this just so you can link to and from the bug, as the existence of a
bug of course does not mean we can't (re)consider the impact.

> C) and D) are both useful to people. Folk that run with --strict at the
> moment are more likely to find C) useful (because they are accustomed to
> having 'bzr add' DTRT. nevertheless one of the things I know users like
> about hg is 'commit -A' which does what my patch does (and which
> arguably should be a default in that system, and in bzr too).
>
> I'm willing to make it possible to have C without D and vice versa, but
> rather than multiply the options to commit (what option would we use for
> rename detection?) I'd rather look at making sure that the auto-remove
> behaviour is also available outside of commit.

rm --auto or even plain rm with no options?

Other than as a transition from the current behavior I cannot think of
a good case where people would want one but not the other, especially
if they were available separately in other commands.

So with the behaviour Robert sketches here, default commit will give
you an error if there are added or removed files, as a kind of prompt
to think about what you want to do.  You would then run bzr st to see
what's happened.  (It might be nicer if bzr ci told you all the
problems?)  Then, you either add/mv/rm by hand, or maybe update the
ignore rules, or alternatively commit -a.

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