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

Wed Aug 6 14:43:04 BST 2008

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

Aaron Bentley wrote:
| 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.

Sure, but that would only happen if you also supplied -a.

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

Interesting, I generally don't. Probably for two reasons:

1) echo ',,*' > ~/.bazaar/ignore
~   echo '*.callgrind' > ~/.bazaar/ignore

Yeah, I picked up the ,, practice from Arch. And you can call me names,
it is honestly pretty useful. "bzr echo test-data > ,,temp.txt" And then
I know it is default ignored.

2) I also tend to put stuff in "bzr foo --lsprof-file ../xxx.txt" rather
than in the current directory.

So certainly, it depends how "clean" you keep your trees. Some people
work with a lot of extra stuff in there, some people don't.

I certainly always use "bzr commit --strict" (aliased) and
*occasionally* use --no-strict. Though almost as often I do:

$ bzr commit some files
Strict failed
$ bzr add
$ bzr commit some files

It sort of depends on why the extra files are there. Often they are
extra test files, etc, that I'm excluding from the commit because they
are the *next* step, and I'm splitting up my work into logical chunks.

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

I agree that --auto-add-remove shouldn't be the default behavior, for a
variety of reasons. I *do* think that having "bzr add" and "bzr remove"
handle auto add/remove at appropriate times is reasonable, and having
"bzr commit --strict" abort on missing as well as unknowns is great.
I also like plain 'bzr commit' not commit the missing but not removed
changes.

I think with that in place, having "bzr add" auto-add all unknowns and
"bzr remove" auto-remove all unknowns is a very reasonable way to
structure it (so you can select auto-add *or* auto-remove). And then
having commit -A/-a effectively be "bzr add && bzr rm && bzr commit".

I wouldn't recommend that people alias "-a" to their default commit. I
*would* recommend "commit = commit --strict" and then to have "commit
- -a" override the --strict setting.
As Robert mentioned, we have a problem with "commit --strict -a" versus
"commit -a --strict". I'm willing to live with:
alias commit = commit --strict
bzr commit -a --no-strict

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiZqmgACgkQJdeBCYSNAAN3yACfQBcQiTOQTVCL3DjWL8F2SF02
jh8AoJrKF/0FuFeVEJBQLqUgVVK5ZyED
=JC9O
-----END PGP SIGNATURE-----