[RFC] Amend commit messages
didlybom at gmail.com
Thu Feb 24 13:59:17 CST 2011
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>
> >> 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...
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mercurial-devel