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

[Martin Pool]

It sounds like Aaron would be ok if C and D are available under
seperate options and not on by default.

On 8/6/08, Robert Collins <robertc at robertcollins.net> wrote:
> 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>.
>


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