[RFC] Amend commit messages

[Didly]

On Thu, Feb 24, 2011 at 8:19 PM, Jason Harris <jason at jasonfharris.com>wrote:

>
> On Feb 24, 2011, at 7:39 PM, timeless wrote:
>
> > On Thu, Feb 24, 2011 at 8:19 PM, Jason Harris <jason at jasonfharris.com>
> wrote:
> >> Shouldn't the history editing tools then be better here? Which is the
> real issue. The immutability of history is not really what you care about
> here it seems like... :)
> >
> > history editing doesn't help if you only find out history isn't ok
> > after you push to another host because some other client pulled from
> > that host and complained to someone. it's already partially out in the
> > wild.
> >
> > picture:
> >
> > <manager> - <anal-bot>
> > |               |
> > <dev> - <internal-dvcs> - <publisher> - <public-dvcs>
> >                |
> > <other-dev>
> >
> > steps:
> > 1. dev pushes something to internal-dvcs.
> > 2. other-dev pulls from internal-dvcs
> > 3. anal-bot pulls from internal-dvcs
> > 4. anal-bot sends a report to manager
> > 5. manager sends a report to dev
> >
> > 6. dev cries
> >
> > 6-1. dev needs to do something to satisfy manager | anal-bot, but
> > <internal-dvcs> is append only.
> >
> > 7. publisher doesn't publish to <public-dvcs> until much later (or
> > never if ordered not to by manager because of anal-bot report).
> >
> > 6-2. If dev can fix commit message to satisfy <anal-bot>, then life is
> > better for dev.
> >
> > 7-1. if <publisher> can use |hg convert| to fold those messages later
> > before publishing to <public-dvcs>, then publication is more likely to
> > happen. the alternative is roughly an export of a single delivered
> > version (because of <anal-bot>/<manager>).
> >
> > Note that as there's a general mapping available to <publisher> for
> > <internal-dvcs> and <public-dvcs>, the fact that the changeset ids
> > don't match doesn't really bother anyone too much. If this didn't
> > happen, they'd still not match, but the tree topology wouldn't match
> > either (single commit dumps for an entire release).
>
> Well with that work flow, yep you are farily out of luck. Even so what
> happens if the problem is not just a commit message but say EOL wasn't
> correct. Then even with this extension you are still hosed. Or the anal-bot
> is some continuous integration server and has rejected the changes due to
> failing tests or something.
>
> In any case I would suggest changes to the workflow but you like would
> already change it if you could...
>
> Cheers,
>  Jas
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>

I think that fixing an invalid commit message is in fact harder than fixing
say a file with wrong EOL.To fix a file that is tracked by mercurial you can
fix it and commit, creating a new changeset. But you cannot fix a commit
message by making a new changeset!

Angel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110224/a900840e/attachment.htm>