[PATCH 2 of 2] revert: print "nothing changed" warning and return 1 instead of aborting
Matt Mackall
mpm at selenic.com
Sat Jun 25 17:13:41 CDT 2011
On Sun, 2011-06-26 at 00:09 +0200, Adrian Buehlmann wrote:
> On 2011-06-25 23:00, Matt Mackall wrote:
> > On Fri, 2011-06-24 at 23:46 +0200, Adrian Buehlmann wrote:
> >> # HG changeset patch
> >> # User Adrian Buehlmann <adrian at cadifra.com>
> >> # Date 1308951253 -7200
> >> # Branch stable
> >> # Node ID c0d82d5f78df21b8f6af714353e3e5cc3687e276
> >> # Parent 82a960b76b4d8ebcfc997cf6e8caf77dde3a860f
> >> revert: print "nothing changed" warning and return 1 instead of aborting
> >
> > I've discussed this a bit with Kevin, and I'm now pretty sure it's
> > always wrong to run 'hg revert' with no args. Much like 'rm' (which
> > reports missing operand) or 'hg cat'. Thus I think we should always
> > abort, even if there is no work to do. And the error code here should be
> > 255.
> >
> > The question of what the right thing to do is with return codes in the
> > case where files ARE specified is a lot more subtle. Here's a quick
> > audit of all commands that have a nontrivial return code via
> > debugcomplete:
> >
> > "nothing to do":
> > bundle Returns 0 on success, 1 if no changes found.
> > commit Returns 0 on success, 1 if nothing changed.
> > push Returns 0 if push was successful, 1 if nothing to push.
> > rollback Returns 0 on success, 1 if no rollback data is available.
> > recover Returns 0 if successful, 1 if nothing to recover or verify fails.
> >
> > "no match":
> > grep Returns 0 if a match is found, 1 otherwise.
> > heads Returns 0 if matching heads are found, 1 if not.
> > locate Returns 0 if a match is found, 1 otherwise.
> > incoming Returns 0 if there are incoming changes, 1 otherwise.
> > outgoing Returns 0 if there are outgoing changes, 1 otherwise.
> >
> > "warnings, but otherwise successful":
> > remove Returns 0 on success, 1 if any warnings encountered.
> > (file not tracked, file is modified, file exists)
> >
> > "errors":
> > copy Returns 0 on success, 1 if errors are encountered.
> > merge Returns 0 on success, 1 if there are unresolved files.
> > pull Returns 0 on success, 1 if an update had unresolved files.
> > rename Returns 0 on success, 1 if errors are encountered.
> > resolve Returns 0 on success, 1 if any files fail a resolve attempt.
> > unbundle Returns 0 on success, 1 if an update has unresolved files.
> > update Returns 0 on success, 1 if there are unresolved files.
> > verify Returns 0 on success, 1 if errors are encountered.
> >
> >
> > I think we can usefully group the do-nothing cases in four different ways:
> >
> > "You asked me to DO or MAKE something, and there was nothing to do"
> > (commit, bundle, rollback)
> >
> > "You asked me to FIND something, and I couldn't find it"
> > (grep, locate, in, out, heads)
> >
> > "You asked me to DO 'all' or force something, and 'all' ended up being
> > none"
> > (add, revert -a, remove -f)
> >
> > "You asked me to GO to a state, and I was already there"
> > (update, revert)
> >
> > I claim that it's useful to return errors in the first two case, and
> > harmful in the last two.
> >
> > In particular, I think revert -a is saying "please clean any mess I may
> > have made". If there's no mess, we should simply say "ok, done!" rather
> > than say "uh, what mess?" because if the goal was to get to a clean
> > state, we have not failed and claiming to have failed is going to cause
> > more confusion for any tool that calls revert.
> >
> > Ok, so that addresses the exit code. That leaves the question: do we
> > really want a message? Again, my sense here is no. Compare:
> >
> > $ hg add
> > adding foo
> > adding bar
> > $ hg add foo # all files tracked, no need to complain
> > $
> >
> > $ hg up
> > 0 files updated, 0 files merged, 0 files removed, 0 files unresolved
> > $
> >
> > Here update shows the same stats it normally does, they just happen to
> > all be zeroed (the same as it would show if you jumped between identical
> > changesets on different branches).
> >
> > [I'm not really sure which categories push/pull should go into, but
> > that's another discussion]
>
> And what's the conclusion?
>
> You want to keep the status quo?
For these three facets of revert, yes.
--
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel
mailing list