[patch] Use /etc/mailname if available

[Aaron Bentley]

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

Jan Hudec wrote:
> On Tue, Dec 20, 2005 at 23:05:57 -0500, James Blackwell wrote:
>>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.

Yes, I was pretty certain you meant that.

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

Yes, it's a good habit.  We have competing design goals of simplicity,
utility, tastefulness, and ease-of-use.  So we don't *always* want to
add the feature.  But it almost always provides new insights.

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

I don't believe that's the case.  I believe it's strictly for humans to
use.  You'd have to ask Martin, though.

> ... and for that purpose it can safely remain ...

As long as the username or hostname doesn't contain any private data...

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

It's definitely worth considering.  I think it means splitting the
revision data up differently from how we've been doing it;

Mutable:
committer
timestamp
timezone
message
properties?

Immutable:
revision_id
inventory_sha1
parents
properties?

> Well, it can still be used for purpose of revid generation. Bzr just can't
> try to extract it from there and consider it valid.

True, but bzr already treats it as an opaque string.

>>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.
> 
> 
> Yes. That's an interesting point.
> 
> One interesting idea would be to have this revision info (committer-id, log,
> tags etc) itself versioned.

This sounds like what Niemeyer did with tags.

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

iD8DBQFDqWdT0F+nu1YWqI0RAhLAAJoDG/2tcW9fLEJq+vBwmRA/qPOuRgCeNZby
YqYPnBnD4UrFppScd2rpxKk=
=0dak
-----END PGP SIGNATURE-----