[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: Future of monotone
From: |
Bruce Stephens |
Subject: |
[Monotone-devel] Re: Future of monotone |
Date: |
Tue, 29 Jan 2008 12:34:28 +0000 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) |
"Julio M. Merino Vidal" <address@hidden> writes:
> On Jan 29, 2008, at 12:22 PM, Bruce Stephens wrote:
[...]
>> Having one person commit something that someone else authored is
>> routine (it's the way that most public git projects operate), and yes,
>> git distinguishes committer and author. Ordinarily the tools show the
>> author of commits. Quite separately, it's conventional to put lines
>> in commit messages like "Signed-off-by:", "Acked-by:", "Reviewed-by:"
>> to indicate various kinds of approval of a commit. (In git, the
>> commits (including the log messages) invoke the history DAG.)
>
> Which to me is wrong because you are then putting meta-data inside a
> free-form (commit message) field. We'd easily handle those with
> separate certs, being signer and author just a subset of them.
Sure, I'm not necessarily recommending it as an approach for monotone.
If git had something like certs, doubtless they'd be used for this
kind of information.
In practice it seems to work fine, though. commits aren't free-form,
there are headers which specify the tree (the manifest, I guess), the
parents, the author (and timestamp) and committer (and timestamp).
I guess those are the things that need to be accessed most often. As
far as I know there are no tools which do anything much
programmatically with Signed-off-by:, etc. Those things are intended
for occasional human use. (There are exceptions which do syntax
highlighting and so on.)
If monotone had a bundled cert containing the usual things (branch,
date, author, log message), then perhaps it would be sufficient for
*that* cert to have the extra "author" field, but for other more
special-case certs not to.
- Re: [Monotone-devel] Re: Future of monotone, (continued)
- Re: [Monotone-devel] Re: Future of monotone, Thomas Moschny, 2008/01/28
- Re: [Monotone-devel] Re: Future of monotone, Markus Schiltknecht, 2008/01/28
- Re: [Monotone-devel] Re: Future of monotone, Thomas Moschny, 2008/01/28
- [Monotone-devel] Re: Re: Future of monotone, Pavel Cahyna, 2008/01/28
- Re: [Monotone-devel] Re: Future of monotone, Thomas Keller, 2008/01/28
- Re: [Monotone-devel] Re: Future of monotone, Derek Scherger, 2008/01/28
- Re: [Monotone-devel] Re: Future of monotone, Nathaniel Smith, 2008/01/28
- Re: [Monotone-devel] Re: Future of monotone, Thomas Moschny, 2008/01/29
- [Monotone-devel] Re: Future of monotone, Bruce Stephens, 2008/01/29
- Re: [Monotone-devel] Re: Future of monotone, Julio M. Merino Vidal, 2008/01/29
- [Monotone-devel] Re: Future of monotone,
Bruce Stephens <=
- Re: [Monotone-devel] Re: Future of monotone, Julio M. Merino Vidal, 2008/01/29
- Re: [Monotone-devel] Re: Future of monotone, Markus Schiltknecht, 2008/01/29
- Re: [Monotone-devel] Re: Future of monotone, Nathaniel Smith, 2008/01/29
- Re: [Monotone-devel] Re: Future of monotone, Markus Schiltknecht, 2008/01/29
- RE: [Monotone-devel] Re: Future of monotone, Kelly F. Hickel, 2008/01/29
- Re: [Monotone-devel] Re: Future of monotone, Markus Schiltknecht, 2008/01/29
- [Monotone-devel] Re: Future of monotone, Bruce Stephens, 2008/01/28
- [Monotone-devel] Re: Future of monotone, Graydon Hoare, 2008/01/29
[Monotone-devel] Re: Future of monotone, Graydon Hoare, 2008/01/29
Re: [Monotone-devel] Future of monotone, Ulf Ochsenfahrt, 2008/01/28