[PATCH 6 of 6] commit: add option to amend the working dir parent

[Idan Kamara]

On Sun, Mar 11, 2012 at 11:27 PM, Matt Mackall <mpm at selenic.com> wrote:

> On Sun, 2012-03-11 at 23:18 +0200, Idan Kamara wrote:
> > On Thu, Mar 8, 2012 at 10:07 PM, Matt Mackall <mpm at selenic.com> wrote:
> >
> > > On Tue, 2012-03-06 at 18:44 +0200, Idan Kamara wrote:
> > > > +        # First, do a regular commit to record all changes in the
> > > working
> > > > +        # directory (if there are any)
> > > > +        node = cmdutil.commit(ui, repo, commitfunc, pats, opts)
> > > > +        ctx = repo[node]
> > > > +        base = old.p1()
> > > > +
> > > > +        # Participating changesets:
> > > > +        #
> > > > +        # node/ctx o - new (intermediate) commit that contains
> changes
> > > from
> > > > +        #          |   working dir to go into amending commit (or a
> > > workingctx
> > > > +        #          |   if there were no changes)
> > > > +        #          |
> > > > +        # old      o - changeset to amend
> > > > +        #          |
> > > > +        # base     o - parent of amending changeset
> > >
> > > This seems overcomplicated. Can't we simply do the equivalent of:
> > >
> > > debugsetparents <parents of commit to amend>
> > > commit -m <old commit message> # snapshot the current state
> > > strip -r <old commit>
> > >
> >
> > So I tried playing around with this approach. From what I see so far,
> > the second step isn't less complicated than what's going on right now.
> > What we'll need is probably on par with what qrefresh is doing (although
> > that code is probably outdated and can be done with fewer lines today).
> >
> > Looking at the disadvantages of what this patch does, I see:
> >
> > 1) hooks are called because an additional commit is made
> > 2) there are two code paths, one when we have changes in the wd
> > and one when we don't
> >
> > Both seem fixable to me. The question is if we have a compelling
> > reason to not go with this?
>
> No, though we should probably figure out how to refactor to share code
> with qrefresh/commit --amend/future command.
>

I'm not sure about qrefresh because it behaves quite differently
with e.g. matching files:

$ touch b
$ hg add b
$ hg qnew foo
$ echo b > b
$ hg qref -X b
$ hg st
A b

But commit --amend will:

$ touch b
$ hg add b
$ hg ci -m 'foo'
$ echo b > b
$ hg ci --amend -X b
nothing changed
$ hg st
M b


>
> Did you look into the copy code?
>

Yes, it seems that adding this before the first commit
does the trick:

cmdutil.duplicatecopies(repo, None, base.node()).


>
> >
> > >
> > > > +                # If old had a copy/move X -> Y and now we have Y
> -> Z,
> > > > +                # we want Z's rename to point to X
> > > > +                r = fctx.renamed()
> > > > +                if r:
> > > > +                    ofctx = old.filectx(r[0])
> > > > +                    rr = ofctx.renamed()
> > > > +                    if rr:
> > > > +                        fctx.renamed = lambda: rr
> > > > +                return fctx
> > >
> > > Please take a look at copies.pathcopies(), which will do the right
> thing
> > > for chaining the copies in old.p1 -> old -> current. Graft and rebase
> > > use the help function scmutil.duplicatecopies() to fixup the dirstate,
> > > which probably also applies here.
> > >
> > > --
> > > Mathematics is the supreme nostalgia of our time.
> > >
> > >
> > >
>
>
> --
> Mathematics is the supreme nostalgia of our time.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120311/6f59954a/attachment.html>