[PATCH] amend: support amending merge changesets (issue3778)
mpm at selenic.com
Fri Feb 8 16:23:04 CST 2013
On Fri, 2013-02-08 at 21:45 +0000, Brodie Rao wrote:
> On Fri, Feb 8, 2013 at 9:31 PM, Idan Kamara <idankk86 at gmail.com> wrote:
> > On Fri, Feb 8, 2013 at 11:14 PM, Brodie Rao <brodie at sf.io> wrote:
> >> # HG changeset patch
> >> # User Brodie Rao <brodie at sf.io>
> >> # Date 1360357714 0
> >> # Node ID ac4b064dde742fbdeaea4818569ca3d134ed92bf
> >> # Parent 2fefd1170bf269e26bb304553009f38e0117c342
> >> amend: support amending merge changesets (issue3778)
> > I haven't looked in depth at the tests you added (seems
> > like you're not testing conflicts?) but I'm surprised it works
> > with so little and trivial code added.
> I don't think a merge with content-level conflicts would be that
> different than what's tested now. A merge with manifest-level
> conflicts might be interesting though.
> > I recall Matt saying this is going to be quite tricky to get
> > right (I also believe I tried to do something close
> > to what you did here and saw it misbehave sometimes,
> > but I can't remember where exactly right now).
> If you don't handle the fact that ctx.files() can be totally wrong in
> a lot of merges (files that were changed aren't in the list, files
> that were merged but didn't have content-level changes are in the
> list, etc), I can see why you'd run into weird issues.
> But, accounting for that, I can't think of why this should be
> difficult to implement, but perhaps I'm overlooking something.
I think the particular issues I had in mind were to do with the nasty
business in localrepo._filecommit. We have to figure out which
file-level parent revisions to use for merged files and we can get
confused with merges involving copies especially.
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel