[PATCH 0 of 2 Re-grafted on tip] Replacing transplant by graft
André Sintzoff
André Sintzoff
# User André Sintzoff <andre.s...@gmail.com>
# Date 1337190984 -7200
# Branch stable
# Node ID 7e6487a5ca3d388327e2ab8ddc77d62f0eb85929
# Parent f2df2069c59bb8c5fd4872a1a8022ddfe09bfa39
graft: add basic support of graft core command
No options are currently supported. Mainly, it is only a remplacement
of the current transplant extension integration in TortoiseHg.
In the context menus, graft items are added before transplant ones.
diff --git a/tortoisehg/hgqt/repowidget.py b/tortoisehg/hgqt/repowidget.py
--- a/tortoisehg/hgqt/repowidget.py
+++ b/tortoisehg/hgqt/repowidget.py
@@ -1257,6 +1257,9 @@
functools.partial(self.changePhase, pnum))
entry(menu)
+ entry(menu, None, fixed, _('Graft to local'), None,
+ self.graftRevisions)
+
entry(menu, 'transplant', fixed, _('Transplant to local'), 'hg-transplant',
self.transplantRevisions)
@@ -1424,7 +1427,9 @@
(_('Compress History...'), compressDlg, 'hg-compress'),
(None, None, None),
(_('Goto common ancestor'), gotoAncestor, 'hg-merge'),
- (_('Similar revisions...'), self.matchRevision, 'view-filter')
+ (_('Similar revisions...'), self.matchRevision, 'view-filter'),
+ (None, None, None),
+ (_('Graft Selected to local'), self.graftRevisions, None),
):
if name is None:
menu.addSeparator()
@@ -1436,7 +1441,6 @@
menu.addAction(a)
if 'transplant' in self.repo.extensions():
- menu.addSeparator()
a = QAction(_('Transplant Selected to local'), self)
a.setIcon(qtlib.getmenuicon('hg-transplant'))
a.triggered.connect(self.transplantRevisions)
@@ -1510,6 +1514,8 @@
(_('Email Selected...'), emailSel, 'mail-forward'),
(None, None, None),
(_('Similar revisions...'), self.matchRevision, 'view-filter'),
+ (None, None, None),
+ (_('Graft Selected to local'), self.graftRevisions, None),
):
if name is None:
menu.addSeparator()
@@ -1521,7 +1527,6 @@
menu.addAction(a)
if 'transplant' in self.repo.extensions():
- menu.addSeparator()
a = QAction(_('Transplant Selected to local'), self)
a.setIcon(qtlib.getmenuicon('hg-transplant'))
a.triggered.connect(self.transplantRevisions)
@@ -1740,6 +1745,12 @@
cmdline.append(str(rev))
self.runCommand(cmdline)
+ def graftRevisions(self):
+ cmdline = ['graft', '--repository', self.repo.root]
+ for rev in self.repoview.selectedRevisions():
+ cmdline.append(str(rev))
+ self.runCommand(cmdline)
+
def backoutToRevision(self):
dlg = backout.BackoutDialog(self.rev, self.repo, self)
dlg.finished.connect(dlg.deleteLater)
André Sintzoff
# Branch stable
# Node ID d12c8718eb83269d1bd8e81382a7e7cba10374c2
# Parent 7e6487a5ca3d388327e2ab8ddc77d62f0eb85929
repowidget: remove transplant context menu items as replaced by graft
diff --git a/tortoisehg/hgqt/repowidget.py b/tortoisehg/hgqt/repowidget.py
--- a/tortoisehg/hgqt/repowidget.py
+++ b/tortoisehg/hgqt/repowidget.py
@@ -1260,9 +1260,6 @@
entry(menu, None, fixed, _('Graft to local'), None,
self.graftRevisions)
- entry(menu, 'transplant', fixed, _('Transplant to local'), 'hg-transplant',
- self.transplantRevisions)
-
if 'mq' in exs or 'rebase' in exs:
submenu = menu.addMenu(_('Modify history'))
entry(submenu, 'mq', qgoto, _('Unapply patch (QGoto parent)'), 'hg-qgoto',
@@ -1440,12 +1437,6 @@
a.triggered.connect(cb)
menu.addAction(a)
- if 'transplant' in self.repo.extensions():
- a = QAction(_('Transplant Selected to local'), self)
- a.setIcon(qtlib.getmenuicon('hg-transplant'))
- a.triggered.connect(self.transplantRevisions)
- menu.addAction(a)
-
if 'reviewboard' in self.repo.extensions():
menu.addSeparator()
a = QAction(_('Post Selected to Review Board...'), self)
@@ -1526,12 +1517,6 @@
a.triggered.connect(cb)
menu.addAction(a)
- if 'transplant' in self.repo.extensions():
- a = QAction(_('Transplant Selected to local'), self)
- a.setIcon(qtlib.getmenuicon('hg-transplant'))
- a.triggered.connect(self.transplantRevisions)
- menu.addAction(a)
-
if 'reviewboard' in self.repo.extensions():
a = QAction(_('Post Selected to Review Board...'), self)
a.triggered.connect(self.sendToReviewBoard)
@@ -1739,12 +1724,6 @@
dlg.finished.connect(dlg.deleteLater)
dlg.exec_()
- def transplantRevisions(self):
- cmdline = ['transplant', '--repository', self.repo.root]
- for rev in self.repoview.selectedRevisions():
- cmdline.append(str(rev))
- self.runCommand(cmdline)
-
def graftRevisions(self):
cmdline = ['graft', '--repository', self.repo.root]
for rev in self.repoview.selectedRevisions():
Steve Borho
> # HG changeset patch
> # User André Sintzoff <andre.s...@gmail.com>
> # Date 1337190984 -7200
> # Branch stable
> # Node ID 7e6487a5ca3d388327e2ab8ddc77d62f0eb85929
> # Parent f2df2069c59bb8c5fd4872a1a8022ddfe09bfa39
> graft: add basic support of graft core command
>
> No options are currently supported. Mainly, it is only a remplacement
> of the current transplant extension integration in TortoiseHg.
>
> In the context menus, graft items are added before transplant ones.
Steve Borho
Steve Borho
> # User André Sintzoff <andre.s...@gmail.com>
> # Date 1337192277 -7200
> # Branch stable
> # Node ID d12c8718eb83269d1bd8e81382a7e7cba10374c2
> # Parent 7e6487a5ca3d388327e2ab8ddc77d62f0eb85929
> repowidget: remove transplant context menu items as replaced by graft
Steve Borho
Angel Ezquerra
> On Sat, Jun 9, 2012 at 4:48 AM, André Sintzoff <andre.s...@gmail.com> wrote:
>> # HG changeset patch
>> # User André Sintzoff <andre.s...@gmail.com>
>> # Date 1337190984 -7200
>> # Branch stable
>> # Node ID 7e6487a5ca3d388327e2ab8ddc77d62f0eb85929
>> # Parent f2df2069c59bb8c5fd4872a1a8022ddfe09bfa39
>> graft: add basic support of graft core command
>>
>> No options are currently supported. Mainly, it is only a remplacement
>> of the current transplant extension integration in TortoiseHg.
>>
>> In the context menus, graft items are added before transplant ones.
>
> Queued for stable, this can be a stand-in until we have a proper dialog for it.
(other than not being done) some thought that it would be best to base
it on the merge dialog instead. Any opinion on that?
Cheers,
Angel
Andreas Tscharner
>> Queued for stable, this can be a stand-in until we have a proper dialog for it.
>
> I send a proposal for a graft dialog, based on the rebase dialog but
> (other than not being done) some thought that it would be best to base
> it on the merge dialog instead. Any opinion on that?
merge dialog :-)
Personally I do not care on what dialog it is based, but we finally seem
to switch to a DVCS in the company from SVN. We use
grafting/cherry-picking (SVN: merging single revisions) a lot and a
dialog that looks familiar would help to use Mercurial (a few people
prefer git).
Best regards
Andreas
--
Andreas Tscharner sterne...@gmail.com
------------------------------------------------------------------------
Der entscheidende Vorteil eines Chats gegenueber einem normalen Telefon-
anruf ist der, dass ersterer langsamer geht und mehr kostet (fuer den
lebenswichtigen Austausch von Informationen wie "hya folks", "C U
l8er" und ":-)") ... Aus Murphy's Computergesetzen
Steve Borho
<sterne...@gmail.com> wrote:
> On 10.06.2012 17:26, Angel Ezquerra wrote:
>>>
>>> Queued for stable, this can be a stand-in until we have a proper dialog
>>> for it.
>>
>>
>> I send a proposal for a graft dialog, based on the rebase dialog but
>> (other than not being done) some thought that it would be best to base
>> it on the merge dialog instead. Any opinion on that?
>
>
> Actually, it was only me who thought it was better to base it on the merge
> dialog :-)
> Personally I do not care on what dialog it is based, but we finally seem to
> switch to a DVCS in the company from SVN. We use grafting/cherry-picking
> (SVN: merging single revisions) a lot and a dialog that looks familiar would
> help to use Mercurial (a few people prefer git).
merge with one of the parents lopped off (detached), followed by a
strip of the original changes.
Graft seems to do mostly the same thing as rebase, except it doesn't
strip the original change.
So basing the graft dialog on the rebase dialog makes a lot of sense.
The only negative is that I've never fallen in love with that dialog
and always meant to re-implement it as a QWizard.
--
Steve Borho
Yuya Nishihara
> On Sun, Jun 10, 2012 at 11:50 AM, Andreas Tscharner
> <sterne...@gmail.com> wrote:
> > On 10.06.2012 17:26, Angel Ezquerra wrote:
> >>>
> >>> Queued for stable, this can be a stand-in until we have a proper dialog
> >>> for it.
> >>
> >>
> >> I send a proposal for a graft dialog, based on the rebase dialog but
> >> (other than not being done) some thought that it would be best to base
> >> it on the merge dialog instead. Any opinion on that?
> >
> >
> > Actually, it was only me who thought it was better to base it on the merge
> > dialog :-)
> > Personally I do not care on what dialog it is based, but we finally seem to
> > switch to a DVCS in the company from SVN. We use grafting/cherry-picking
> > (SVN: merging single revisions) a lot and a dialog that looks familiar would
> > help to use Mercurial (a few people prefer git).
>
> The way these things are implemented, rebase is essentially a repeated
> merge with one of the parents lopped off (detached), followed by a
> strip of the original changes.
>
> Graft seems to do mostly the same thing as rebase, except it doesn't
> strip the original change.
two parents, it cannot do 3-way merge by "hg resolve" after conflict.
It makes ResolveDialog mostly useless for graft.
Steve Borho
> On Sun, 10 Jun 2012 14:19:20 -0500, Steve Borho wrote:
>> On Sun, Jun 10, 2012 at 11:50 AM, Andreas Tscharner
>> <sterne...@gmail.com> wrote:
>> > On 10.06.2012 17:26, Angel Ezquerra wrote:
>> >>>
>> >>> Queued for stable, this can be a stand-in until we have a proper dialog
>> >>> for it.
>> >>
>> >>
>> >> I send a proposal for a graft dialog, based on the rebase dialog but
>> >> (other than not being done) some thought that it would be best to base
>> >> it on the merge dialog instead. Any opinion on that?
>> >
>> >
>> > Actually, it was only me who thought it was better to base it on the merge
>> > dialog :-)
>> > Personally I do not care on what dialog it is based, but we finally seem to
>> > switch to a DVCS in the company from SVN. We use grafting/cherry-picking
>> > (SVN: merging single revisions) a lot and a dialog that looks familiar would
>> > help to use Mercurial (a few people prefer git).
>>
>> The way these things are implemented, rebase is essentially a repeated
>> merge with one of the parents lopped off (detached), followed by a
>> strip of the original changes.
>>
>> Graft seems to do mostly the same thing as rebase, except it doesn't
>> strip the original change.
>
> IIRC, as "graft" does not change dirstate to merging state, i.e. having
> two parents, it cannot do 3-way merge by "hg resolve" after conflict.
> It makes ResolveDialog mostly useless for graft.
a core command that would ignore what is perhaps hg's most important
feature, the ability to iteratively merge changes between branches.
These stack-overflow conversations say otherwise:
http://stackoverflow.com/questions/8009632/graft-vs-transplant
http://stackoverflow.com/questions/9598704/consequences-of-using-graft-in-mercurial
The docs also talk about resolving conflicts when the graft is
interrupted so that it can be re-continued (just like rebase)
http://pvdevtools.readthedocs.org/en/latest/devel/vcs/mercurial/commands/graft.html
I haven't looked at the code, but it sure smells like a rebase
--
Steve Borho
Andreas Tscharner
[snip]
>> two parents, it cannot do 3-way merge by "hg resolve" after conflict.
>> It makes ResolveDialog mostly useless for graft.
>
> It doesn't? That's surprising to me. I don't see why Matt would add
> a core command that would ignore what is perhaps hg's most important
> feature, the ability to iteratively merge changes between branches.
You resolve any conflicts and continue the graft with -c
Angel Ezquerra
Angel
Yuya Nishihara
> On 12.06.2012 10:19, Steve Borho wrote:
> [snip]
> >> IIRC, as "graft" does not change dirstate to merging state, i.e. having
> >> two parents, it cannot do 3-way merge by "hg resolve" after conflict.
> >> It makes ResolveDialog mostly useless for graft.
> >
> > It doesn't? That's surprising to me. I don't see why Matt would add
> > a core command that would ignore what is perhaps hg's most important
> > feature, the ability to iteratively merge changes between branches.
>
> I think that's what the --continue option (in graft) is for.
> You resolve any conflicts and continue the graft with -c
"resolve" (by merge tool) does not work.
"graft" invokes mergemod.update() with tricked ancestor, ctx.p1(),
and drops the second parent immediately even if it conflicted
(probably because it isn't a real merge.)
http://selenic.com/repo/hg/file/2255950e1f76/mercurial/commands.py#l2744
http://thread.gmane.org/gmane.comp.version-control.mercurial.general/30330/focus=30336
But "resolve" needs the second parent in order to know the merge target.
http://selenic.com/repo/hg/file/2255950e1f76/mercurial/commands.py#l4840
So I thought it wouldn't work.
Regards,
Angel Ezquerra
Angel
Yuya Nishihara
http://bz.selenic.com/show_bug.cgi?id=3498
We'll need to fix this in order to add fully-functional graft dialog.
Regards,
Angel Ezquerra
which was to base the graft dialog on the rebase dialog, right?
BTW, Yuya, are you looking into this on the mercurial side? Or do you
know if Idan is looking into it?
Angel
Andreas Tscharner
[snip]
> which was to base the graft dialog on the rebase dialog, right?
Maybe you want to coordinate with Steve. He said he does not love the
current rebase dialog, so he might suddenly come up with a new one... ;-)
Best regards
Andreas
--
Andreas Tscharner <sterne...@gmail.com>
----------------------------------------------------------------------
-- Call in "Alien: Resurrection"
Yuya Nishihara
> which was to base the graft dialog on the rebase dialog, right?
> BTW, Yuya, are you looking into this on the mercurial side? Or do you
> know if Idan is looking into it?
Regards,
Angel Ezquerra
I looked for graft on the hg repo and the name that came up most often was Idan.
Angel
Steve Borho
<sterne...@gmail.com> wrote:
> On 15.06.2012 13:37, Angel Ezquerra wrote:
>
> [snip]
>
>> In the mean time I think we can move forward with the original plan,
>> which was to base the graft dialog on the rebase dialog, right?
>
>
> Yes, the faster we have a solution the better.
> Maybe you want to coordinate with Steve. He said he does not love the
> current rebase dialog, so he might suddenly come up with a new one... ;-)
I'm fine if this is based on the current rebase dialog.
--
Steve Borho