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

[Robert Collins]

On Wed, 2008-08-06 at 15:48 +1000, Martin Pool wrote:
> On Wed, Aug 6, 2008 at 3:21 PM, Robert Collins

> > 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


> 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.

The options are mutually inconsistent - we could say only one can be
given, or that one wins. I chose that one would win because that seems
nicer to folk using aliases (you can alias commit to commit -a, then
commit --strict will do what you want). Possibly better still is 'last
supplied option wins' but that needs framework support.

> > 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.

Ack.

> 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.

5158 is one, there may be others :).


> > 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?

I was thinking rm with no options. (We don't require 'bzr add --auto').

> 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.

The exception I created can tell you about all missing files, though I
only taught the commit code to find the first - it seemed stopping early
would be enough to get people looking.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080806/209f0d14/attachment.pgp