allow to change author (name <e-mail>) and description in past commits

[hills]

"whoami" options allow to change autorhor's name and e-mail, but this is succesful only for future commits, not past commits. This behaviour is by desing or this can be changed?
For example, when I changed my e-mail, history of commits always show e-mail, that is out of date, and this information abondon its role; users that try to contact me will be confused.

The same problem: description of commits. When I make typing error, and my VCS is public accesible, and people will read my history of commits for years, i want just correct this few letters, nothing more.

Maybe there should be some new options to providing changes in past commits?

[John A Meinel (jameinel)]

There are a few other requests for modifying committed information (mostly for changing the commit log.)

At the moment, there are no plans to allow this, as it severely complicates the model in a distributed system.

However, you can use the 'rebase' plugin to regenerate your commits, with new committer information. But it requires generating a new history.

[khiltd (junkfrombzr-khiltd)]

In what way would this complicate the model? Why can't you simply generate a unique ID for each user who commits to a repository and then maintain a separate (versioned) table of users that maps these numeric IDs to localized names and email addresses which can be updated as needed? Obviously one user can choose to commit from multiple computers, so a means of replicating this ID would be required, but I can't imagine that being much more work than adding another agrument to 'whoami'.

Or even better, use keys instead of IDs. This would bring with it the added benefit of being able to run the faster smart server wide open, knowing that only specific users who have a Bazaar issued cert/cookie/key would be granted commit rights.

Not being able to update an email address is a pretty big strike against Bazaar in my book.

[Jelmer Vernooij (jelmer)]

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

khiltd wrote:
> In what way would this complicate the model? Why can't you simply
> generate a unique ID for each user who commits to a repository and then
> maintain a separate (versioned) table of users that maps these numeric
> IDs to localized names and email addresses which can be updated as
> needed? Obviously one user can choose to commit from multiple computers,
> so a means of replicating this ID would be required, but I can't imagine
> that being much more work than adding another agrument to 'whoami'.
That means you would have to have a (versioned) table that needs to be
distributed across computers and there would have to be a protocol
that can propagate the new identities associated with a particular id.

This sort of thing can be done, but it is nontrivial to implement and
there are lots of issues surrounding it - how do you tell who can
update the email address associated with a particular id, for example?
> Or even better, use keys instead of IDs. This would bring with it the
> added benefit of being able to run the faster smart server wide open,
> knowing that only specific users who have a Bazaar issued
> cert/cookie/key would be granted commit rights.
>
> Not being able to update an email address is a pretty big strike against
> Bazaar in my book.
None of the distributed version control systems support this AFAIK.

Cheers,

Jelmer

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

iQCVAwUBSDt3KQy0JeEGD2blAQLLRQP/Xrpm0aKPI4G6oMgraH0roqDMRw3XYsOf
iMKVcthDSxahfpEMR5+YH6OrjvfrDl49LW96H/E/ORhpwoK2xl2eYg79mekD8TJC
62dyvVqUPf2sm6PNyykXDVPSRxFuuHObX0r3F7eNLqt6fpUXRxDwdVKOKKmRJGeX
PwGFDZv0dyk=
=U+z7
-----END PGP SIGNATURE-----

[khiltd (junkfrombzr-khiltd)]

How do you tell who can update anything? Sorry, but that's a pretty weak excuse.

If the model makes this non-trivial then I say it's a poorly designed model.

[Steve (tooroot)]

Hi,

so if for example a commit message, email-address gets changed:

someone who pulls / merges from the changed repo won't simply retrieve the diff, but he will also retrieve the changed metadata. (in any revision back the whole history)
This wouldn't produce much overhead, since commit messages and e-mail-addresses are usually short. Of course one could deactivate/activate this behaviour with a command-line switch.

I really don't understand why this would complicate the model? There's a change in metadata, which gets transported the moment, where an update / pull / merge happens.

Cheers

[Dan Watkins (oddbloke)]

On Thu, 21 Aug 2008 11:51:15 -0000
Steve <email address hidden> wrote:
> I really don't understand why this would complicate the model?
> There's a change in metadata, which gets transported the moment,
> where an update / pull / merge happens.
When I pull or merge from a branch, how do I determine which of the
target and source branches metadata is more valid?

--
Daniel Watkins (Odd_Bloke)

[Robert Collins (lifeless)]

On Fri, 2008-08-22 at 03:35 +0000, Daniel Watkins wrote:
> On Thu, 21 Aug 2008 11:51:15 -0000
> Steve <email address hidden> wrote:
> > I really don't understand why this would complicate the model?
> > There's a change in metadata, which gets transported the moment,
> > where an update / pull / merge happens.
> When I pull or merge from a branch, how do I determine which of the
> target and source branches metadata is more valid?

Conceptually you have a timeline for each commit message. So you have a
timeline for the commit message of revision uuid XYZ. If we tie those
timelines to the timeline of a branch, then any lookup of a revision
will require a branch as starting point to determine the timeline we
used for its commit message. Alternatively if we manage each timeline
separately (e.g. by having a journal of metadata edits) we could advance
that journal, and when reading a particular revision if there are
multiple unresolved edits to the commit message inform the client and
let them choose.

In other words, this is doable, but it's significantly complex - we
should really document use cases and start broad outlines of what we
want/need using our in-tree documentation approach. Its too big for a
bug.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

[Guillaume Hain (zedtux)]

When do we will have this feature ?

[Jelmer Vernooij (jelmer)]

On 12/21/2011 04:57 PM, zedtux wrote:
> When do we will have this feature ?
I'm not sure. The canonical bazaar team isn't likely to have time for
this any time soon - there are still lots of other bugs / wishlist items
that have higher priority for us. One of us might work on it in our
spare time though, or a community contributor could hack on it. If
you're interested in working on it, we're happy to give pointers.

The recent work on feature flags, which will be in bzr 2.5, should help
if you would want to implement something like this in a plugin.

Cheers,

Jelmer