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

Robert Collins robertc at robertcollins.net
Wed Aug 6 06:21:15 BST 2008

On Wed, 2008-08-06 at 00:43 -0400, Aaron Bentley wrote:
> Hash: SHA1
> Robert Collins wrote:
> > On Tue, 2008-08-05 at 07:59 -0400, Aaron Bentley wrote:
> > 
> >> Am I correctly understanding that this patch takes away the ability to
> >> have auto-delete without auto-add?
> >>
> >> If so, DO NOT WANT.
> > 
> > Yes, it does. 
> > 
> > Why is auto-delete better/safer than auto-add?
> - - I often have files in my tree temporarily that I do not want to add

Many users run with --strict turned on all the time, which means that
all such files are ones they want to add. I don't dispute that you use
bzr this way, but I don't have the sense that this is the most common
way to work. I think a much more common failure mode is 'failed-to-add'
rather than 'added-to-much'. (Also note that in both failures bzr offers
simple recovery mechanisms).

> - - the standard mv command would cause a delete and add, which is a bad
> failure mode

Yes, and it causes this when in both auto-delete and auto-add-and-delete
modes! (In fact its worse in the former because the file gets deleted
and not added).

> - - I have much stronger control over which files are deleted from my tree
> than which files are added to my tree.

This is an interesting point. It implies to me that you never feel safe
just running 'bzr add', which I do all the time (its one of the things I
love about bzr that it just works).

> > Also, assuming that it makes sense to allow automatic add (I believe it
> > does), how to present this - what options/flags etc should we have.
> I don't necessarily agree that it makes sense.  Maybe for scripting.  I
> guess --auto-add would work.  But for scripting, "bzr add && bzr commit"
> is sufficient.

sure its sufficient, but then so is 'bzr rm && bzr commit' for tracking
missing files (given a small tweak to rm to behave analogously to add
when no parameters are given). we've had this bug open for nearly three
years - I think we have enough user data to decide what to do about it

FWIW hg has 'commit -A' which does exactly what my patch does with -a.

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

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.

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/e25c231d/attachment.pgp 

More information about the bazaar mailing list