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

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> On Wed, 2008-08-06 at 00:43 -0400, Aaron Bentley wrote:
>> Robert Collins wrote:
>>> 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 have commit aliased to commit --strict.  This does not mean that any
files present in my directory when I commit are files I want to add.  It
means that the files should not be there in their current status.  They
should be deleted, ignored or added.  IME, I delete such files more
often than I add them.

However, sometimes I have files in my tree that I do not want to commit,
yet I want to commit the other contents of the tree.  So I use commit
- --no-strict.  I very much do not want that to cause those files to be
auto-added.

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

IME, most unknown files in my tree are deleted, not added, when I go to
commit.

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

With auto-delete, you can always revert or uncommit.  When you auto-add
something inappropriate, you have to put a genie back in its bottle.

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

It doesn't just work.  I would add all sorts of junk if I did that.
.moved files, .orig files, .callgrind files.

I always run "bzr status" before "bzr add".

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

Yes, but I don't think that auto-remove is suitable only for scripting,
so there's no point discussing options that are suitable only for scripting.

> we've had this bug open for nearly three
> years - I think we have enough user data to decide what to do about it
> now.

I think we've had this bug open long enough to conclude that users don't
really want it to be fixed.  I can't remember the last time someone
asked me for this.

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

That's worth very little to me.  I'm not complaining about the presence
of -a, I'm complaining about the lack of --auto-remove.

> C) unknown files are added with the new option.
> D) missing files are deleted with the new option

> Folk that run with --strict at the moment are more likely to find C) useful

Not this --strict user.  When I commit --no-strict, it's because
- - I have an unknown file in my tree
- - I don't want to commit the unknown file
- - I do want to commit other changes.

If I have commit aliased to "commit --strict -a", then "commit
- --no-strict" will cause the file to be added and committed.  This is the
exact opposite of my desire.

> 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 think that would be a terrible default.  Things would get committed by
accident and not noticed.  You'd increase your risk of
- - exposing secrets by committing confidential files
- - exploding the size of the repository by accidentally committing ISOs.

It's easier to notice when something is missing than when something is
inappropriately present.  This is because missing items tend to prevent
the software from working.

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

If you insist on breaking bzr for newbies, at least make it possible for
experienced users to fix it.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFImUH10F+nu1YWqI0RAj7PAJ40npMzYg4WF97yswY/uQIQuQTVQQCfSzlF
03+w8yiW/5cAgcgNumfh7kQ=
=I0GY
-----END PGP SIGNATURE-----