[darcs-devel] darcs patch: Add a 'commit' command stub. (and 10 more)

[Eric Y. Kow]

Ok.  I'm also going to push in the commit stub and issue386 patch
unless somebody complains.

The consistency issue
----------------------
The first is important because we want darcs the users interface to
retain its inherent user-friendliness and second is important because we
want darcs Do The Right Thing.

> > I don't really like the idea of making --author different from
> > $EMAIL or $DARCS_EMAIL or _darcs/prefs/author.  It's sort of
> > a surprising behavior.

At a glance, one would think that the amend-record command should only
override something if you supply a flag to do so.  For example, if you
do not supply (-m), we do not change the patch name.

On the other hand, $DARCS_EMAIL, etc are also supposed to behave as an
implicit --author, only to be overrriden by the --author flag.  So we
should behave the same way.  I think being consistent with implicit
--author trumps being consistent with non-intervention, at least from a
UI standpoint (so agree with David).

The 'consistent' behaviour would thus be
 1. Grab from --author
 2. If not available, grab from $DARCS_EMAIL etc
 3. If not available, grab from the patch (what else?)

As an alternative to #2 and #3 with a prompt 'Change the author of this
patch?'  If no (the default?), we grab from the patch, if yes we check
for DARCS_EMAIL, etc and failing that, ask the user.  Seems like a
somewhat unprincipled approach, but it avoids us having to introduce a
--replace-author / --do-not-replace-author flag (ugh!)

The use-of-amend issue
----------------------
> > It'll change the default behavior of darcs if we
> > change this, but I am thinking that if I amend-record your patch, perhaps
> > by default darcs ought to change me to the author.  I suppose perhaps
> > that's less handy if a maintainer wants to amend-record to fix a conflict
> > or something minor (but wants to maintain attribution), but on the other
> > hand, it puts the blame for the amend-record in the right place, which is
> > good.

So here we have a different question.  Who is the right person to blame
if a patch gets amended?  I lean more towards Zachary's point of view,
although on the other hand, the advantage of changing the author is that
we actually *see* that the patch has been amended.

> The two main cases of amend record, as I see it, are:
> 
>     1) The author himself wants to fix something.  As you said, the
>        behavior won't matter in this case.
> 
>     2) The author sent the patch to someone else, who only wants to fix
>        a minor typo in the comment or in the code
> 
> If someone other than the original author were doing anything more than
> that, I'd think the proper thing to do would be to create a new
> replacement patch, not just amend-record the one he received.

-- 
Eric Kow                     http://www.loria.fr/~kow
PGP Key ID: 08AC04F9         Merci de corriger mon français.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-devel/attachments/20070728/acae3dc1/attachment.pgp