Keeping track of the Author and Committer

[Martin Pool]

On 13/09/05, Stefan (metze) Metzmacher <metze at samba.org> wrote:
> Hi *,

Hi metze, and welcome.

> as it is possible to mutliple people to bzr push to a tree,
> I think it would be very usefull, to seperate the author of a changeset and the committer,
> as GIT does it, so if someone merge someoneelse's changes to a a tree, the committer should allways
> be the person who actually move the change set to the target branch, and the author should be the
> person who, wrote the code and does a bzr commit to his local branch. so if a changeset is moved
>  visists more than one branch until it reaches the master branch, the author is still the same in
> all branches, but the committer is (maybe different in each branch) and represents allways the
> committer to the specific branch...

It's an interesting idea.

bzr has two concepts for moving code into a tree: pull, and merge. 
Essentially a pull (or push) is where the revisions coming in are a
"perfect fit" on top of what was already on that branch, and a merge
is where there are parallel changes that need to be resolved.  Pull
doesn't generate any new information, and doesn't track who merged the
changes in.  In a merge, we can see both the original changes (with
their original author), plus the person who did the merge, and any
resolutions they made.  The merge generates essentially a "rolled-up
commit"; these can be nested to any level.

This is meant to let you keep track of both who wrote the original
thing, and who merged it (at various stages).  I think if you always
do merge, rather than pull, you'll get the desired behaviour.

(It is interesting to contemplate whether we should record who did a
pull and when...)

-- 
Martin