[patch] Use /etc/mailname if available

James Blackwell jblack at merconline.com
Wed Dec 21 04:05:57 GMT 2005


On Wed, Dec 21, 2005 at 02:42:03AM -0500, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> James Blackwell wrote:
> | I'm in favor of guessing even if wrong. Users don't seem to care much
> | about the committer field until they get into merging. Once they
> | get to that point they can fix it then.
> 
> I recently had a conversation with someone in IRC who wanted to edit his
> revisions because they had the wrong committer ID.  I told him 'No!
> That's forbidden by the model!'  And I got this sense of deja vu, as if
> I was still working on Arch.

When I said "fix it then" I meant for new revisions as old revisions tend
to fade (but not go away) from a log/annotate perspective. You do have me
leaning in your direction though; as more branches come online, more users
will ask for this.

One of my more recent habits is to turn questions like 'NO! You can't do
that!' into 'how could we do that?' questions. I think there is use in
trying that here; How can we turn "can't" into "can"?

I would suppose commiter id was was added to revision id as some sort of
collision avoidance for the random revids-- even if you and I both struck
the lottery and generated the same id, we still wouldn't have trouble
because we have different email addresses.

So.. what about taking commiter id out of the revid? Then, we could
consider making committer id mutable -- perhaps in the same way and tools
as we're hoping tag will end up being.  While we're at it, why not allow
for other neat mutable things? Changing committer ids, commit dates,
appending additional log messages (I would call these annotations, but the
word means something different).

Sure, there'd be a number of discussions about the merging of this
metadata, but this is the same converation that one would have with
revision tags as well.




> I think it's irritating, at the very least, for bzr to store
> likely-wrong information in perpetuity.  It doesn't seem fair to the
> user, who might be quite willing to correct it, given a warning.  And
> there have been situations in which I thought the committer ID was set
> correctly, but it was not.  Those bugged me.

Thats fair. The more I think about it though, the more I think that the
problem isn't that the wrong thing is set but the wrong thing is
immutable.

> | I frequently talk to random() person and open up with:
> |
> |   cd code; bzr init; bzr add; bzr commit -m"My code is controled"
> |
> | That's powerful when talking to cvs users that after 3 years _still_ can't
> | quite figure it out.
> 
> I dig that.  It's very nice to be able to say there's no step 4.  We
> could simply set it the first time out, and tell the user what we'd done.

I like the "there is no step 2" in "bzr init -m'Imported'" better.  I'd
like to discuss that some day.  I suspect that you have concerns with
default ignores or wanting to limit adds.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051220/604e60d2/attachment.pgp 


More information about the bazaar mailing list