Long term development external named branches and periodic merges from python
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have a question and I would rather have an answer instead of actually trying and getting myself in a messy situation. Let say we have the following scenario: 1. A programer clones hg.python.org. 2. Programer creates a named branch and start to develop a new feature. 3. She adds her repository&named branch to the bugtracker. 4. From time to time, she posts updates in the tracker using the "Create Patch" button. So far so good. Now, the question: 5. Development of the new feature is taking a long time, and python canonical version keeps moving forward. The clone+branch and the original python version are diverging. Eventually there are changes in python that the programmer would like in her version, so she does a "pull" and then a merge for the original python branch to her named branch. 6. What would be posted in the bug tracker when she does a new "Create Patch"?. Only her changes, her changes SINCE the merge, her changes plus merged changes or something else?. What if the programmer cherrypick changesets from the original python branch?. Thanks! :-). - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTs50H5lgi5GaxT1NAQJsTAP6AsUsLo2REdxxyVvPBDQ51GjZermCXD08 jOqKkKY9cre4OHx/+uZHEvO8j7RJ5X3o2/0Yl4OeDSTBDY8/eWINc9cgtuNqrJdW W27fu1+UTIpgl1oLh06P23ufOEWPWh90gsV6eiVnFlj7r+b3HkP7PNdZCmqU2+UW 92Ac9B1JOvU= =goYv -----END PGP SIGNATURE-----
Hi,
I have a question and I would rather have an answer instead of actually trying and getting myself in a messy situation. Clones are cheap, trying is cheap! <cheap wink>
Let say we have the following scenario:
1. A programer clones hg.python.org. 2. Programer creates a named branch and start to develop a new feature. 3. She adds her repository&named branch to the bugtracker. 4. From time to time, she posts updates in the tracker using the "Create Patch" button.
So far so good. Now, the question:
5. Development of the new feature is taking a long time, and python canonical version keeps moving forward. The clone+branch and the original python version are diverging. Eventually there are changes in python that the programmer would like in her version, so she does a "pull" and then a merge for the original python branch to her named branch. I do this all the time. I work on a fix-nnnn branch, and once a week for example I pull and merge the base branch. Sometimes there are no conflicts except Misc/NEWS, sometimes I have to adapt my code because of other people’s changes before I can commit the merge.
6. What would be posted in the bug tracker when she does a new "Create Patch"?. Only her changes, her changes SINCE the merge, her changes plus merged changes or something else?. The diff would be equivalent to “hg diff -r base” and would contain all the changes she did to add the bug fix or feature. Merging only makes sure that the computed diff does not appear to touch unrelated files, IOW that it applies cleanly. (Barring bugs in Mercurial-Roundup integration, we have a few of these in the metatracker.)
What if the programmer cherrypick changesets from the original python branch?. Then her branch will revert some changes done in the original branch. Therefore, cherry-picking is not a good idea.
Regards
I've never been able to get the Create Patch button to work reliably with my BitBucket repo, so I still just run "hg diff -r default" locally and upload the patch directly. It would be nice if I could just specify both the feature branch *and* the branch to diff against rather than having to work out why Roundup is guessing wrong... -- Nick Coghlan (via Gmail on Android, so likely to be more terse than usual)
Am 24.11.2011 21:55, schrieb Nick Coghlan:
I've never been able to get the Create Patch button to work reliably with my BitBucket repo, so I still just run "hg diff -r default" locally and upload the patch directly.
Please submit a bug report to the meta tracker.
It would be nice if I could just specify both the feature branch *and* the branch to diff against rather than having to work out why Roundup is guessing wrong...
Why would you not diff against the default branch? Regards, Martin
On 2011-11-24, at 21:55 , Nick Coghlan wrote:
I've never been able to get the Create Patch button to work reliably with my BitBucket repo, so I still just run "hg diff -r default" locally and upload the patch directly. Wouldn't it be simpler to just use MQ and upload the patch(es) from the series? Would be easier to keep in sync with the development tip too.
On Fri, Nov 25, 2011 at 7:23 AM, "Martin v. Löwis"
Am 24.11.2011 21:55, schrieb Nick Coghlan:
I've never been able to get the Create Patch button to work reliably with my BitBucket repo, so I still just run "hg diff -r default" locally and upload the patch directly.
Please submit a bug report to the meta tracker.
Done: http://psf.upfronthosting.co.za/roundup/meta/issue428
It would be nice if I could just specify both the feature branch *and* the branch to diff against rather than having to work out why Roundup is guessing wrong...
Why would you not diff against the default branch?
I usually do - the only case I have at the moment where diffing against a branch other than default sometimes make sense is the dependency from the PEP 380 branch on the dis.get_opinfo() feature branch (http://bugs.python.org/issue11682). In fact, I believe that's also the case that confuses the diff generator. My workflow in the repo is: - update default from hg.python.org/cpython - merge into get_opinfo branch from default - merge into pep380 branch from the get_opinfo branch So, after merging into the pep380 branch, "hg diff -r default" gives a full patch from default -> pep380 (including the dis module updates), while "hg diff -r get_opinfo" gives a patch that assumes the dis changes have already been applied separately. I'm now wondering if doing an explicit "hg merge default" before I do the merges from the get_opinfo branch in my sandbox might be enough to get the patch generator back on track... Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, Nov 25, 2011 at 7:46 AM, Xavier Morel
On 2011-11-24, at 21:55 , Nick Coghlan wrote:
I've never been able to get the Create Patch button to work reliably with my BitBucket repo, so I still just run "hg diff -r default" locally and upload the patch directly. Wouldn't it be simpler to just use MQ and upload the patch(es) from the series? Would be easier to keep in sync with the development tip too.
From my (admittedly limited) experience, using MQ means I can only effectively collaborate with other people also using MQ (e.g. the Roundup integration doesn't work if the only thing that is published on BitBucket is a patch queue). I'll stick with named branches until MQ becomes a builtin Hg feature that better integrates with other tools.
Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/11/11 18:08, Éric Araujo wrote:
I have a question and I would rather have an answer instead of actually trying and getting myself in a messy situation. Clones are cheap, trying is cheap! <cheap wink>
I would need to publish another repository online, and instruct the bug tracker to use it and create a patch, and play for the best or risk polluding the tracker. Maybe I would be hitting a corner case and be lucky this time, but not next time. Better to ask people that know better, I guess.
5. Development of the new feature is taking a long time, and python canonical version keeps moving forward. The clone+branch and the original python version are diverging. Eventually there are changes in python that the programmer would like in her version, so she does a "pull" and then a merge for the original python branch to her named branch. I do this all the time. I work on a fix-nnnn branch, and once a week for example I pull and merge the base branch. Sometimes there are no conflicts except Misc/NEWS, sometimes I have to adapt my code because of other people’s changes before I can commit the merge.
That is good, because that means your patch is always able to be applied to the original branch tip, and that you changes work with current work in the mainline. That is what I want to do, but I need to know that it is safe to do so (from the "Create Patch" perspective).
6. What would be posted in the bug tracker when she does a new "Create Patch"?. Only her changes, her changes SINCE the merge, her changes plus merged changes or something else?. The diff would be equivalent to “hg diff -r base” and would contain all the changes she did to add the bug fix or feature. Merging only makes sure that the computed diff does not appear to touch unrelated files, IOW that it applies cleanly. (Barring bugs in Mercurial-Roundup integration, we have a few of these in the metatracker.)
So you are saying that "Create patch" will ONLY get the differences in the development branch and not the changes brought in from the merge?. A "hg diff -r base" -as you indicate- should show all changes in the branch since creation, included the merges, if I understand it correctly. I don't want to include the merges, although I want their effect in my own work (like changing patch offset). That is, is that merge safe for "Create Patch"?. Your answer seems to indicate "yes", but I rather prefer an explicit "yes" that an "implicit" yes :). Python Zen! :). PS: Sorry if I am being blunt. My (lack of) social skills are legendary. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTs7/1Jlgi5GaxT1NAQJUDAQAhQi5e3utsVdOveO/3r1EDr/9BUTpB8Tb DxIe12HEt+KT33CJR+HGTt9OBqNGmVb4Q3h8lj3YIi7WdIXjc3CQ3+dO1NF1jTZO 0rt5EbEU99RAkgqOT0r3ziKy6MSSWhTuZlQy6pvcivEJet0GANiNqbdw6xFBETeZ a5m85Q793iU= =1Kg3 -----END PGP SIGNATURE-----
Nick Coghlan writes:
I'll stick with named branches until MQ becomes a builtin Hg feature that better integrates with other tools.
AFAIK MQ *is* considered to be a *stable, standard* part of Hg functionality that *happens* (for several reasons *not* including "it's not ready for Prime Time") to be packaged as an extension. If you want more/different functionality from it, you probably should file a feature request with the Mercurial developers.
Wouldn't it be simpler to just use MQ and upload the patch(es) from the series? MQ is a very powerful and useful tool, but its learning curve is steeper
Le 24/11/2011 22:46, Xavier Morel a écrit : than regular Mercurial, and it is not designed for long-term development. Rebasing patches is more fragile and less user-friendly than merging branches, and it’s also easier to corrupt your MQ patch queue than your Mercurial repo. I like Mercurial merges and I don’t like diffs of diffs, so I avoid MQ.
Would be easier to keep in sync with the development tip too. How so? With a regular clone you have to pull and merge regularly, with MQ you have to pull and rebase.
Regards
Le 25/11/2011 03:39, Jesus Cea a écrit :
On 24/11/11 18:08, Éric Araujo wrote:
I have a question and I would rather have an answer instead of actually trying and getting myself in a messy situation. Clones are cheap, trying is cheap! <cheap wink> [snip valid reasons for not trying] My reply was tongue-in-cheek :) FYI, it’s not considered pollution to use a tracker issue to test hooks or Mercurial integration (there’s even one issue entirely devoted to such tests, but I can’t find its number).
5. Development of the new feature is taking a long time, and python canonical version keeps moving forward. The clone+branch and the original python version are diverging. Eventually there are changes in python that the programmer would like in her version, so she does a "pull" and then a merge for the original python branch to her named branch. I do this all the time. I work on a fix-nnnn branch, and once a week for example I pull and merge the base branch. Sometimes there are no conflicts except Misc/NEWS, sometimes I have to adapt my code because of other people’s changes before I can commit the merge. That is good, because that means your patch is always able to be applied to the original branch tip, and that you changes work with current work in the mainline.
That is what I want to do, but I need to know that it is safe to do so (from the "Create Patch" perspective). I don’t understand “safe”.
6. What would be posted in the bug tracker when she does a new "Create Patch"?. Only her changes, her changes SINCE the merge, her changes plus merged changes or something else?. The diff would be equivalent to “hg diff -r base” and would contain all the changes she did to add the bug fix or feature. Merging only makes sure that the computed diff does not appear to touch unrelated files, IOW that it applies cleanly. (Barring bugs in Mercurial-Roundup integration, we have a few of these in the metatracker.) So you are saying that "Create patch" will ONLY get the differences in the development branch and not the changes brought in from the merge?. I don’t really understand how you understood what I said :( The merge brings in changes from default; when you diff your branch against default later, it will not show the changes brought by the merge, but it will apply cleanly on top of default.
Does this wording make sense? Regards
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26/11/11 17:30, Éric Araujo wrote:
That is what I want to do, but I need to know that it is safe to do so (from the "Create Patch" perspective). I don’t understand “safe”.
"Safe", in this context, means "when clicking 'create patch' the created patch ONLY includes my code in the development branch, EVEN if the branch merged-in the original mainline branch several times".
6. What would be posted in the bug tracker when she does a new "Create Patch"?. Only her changes, her changes SINCE the merge, her changes plus merged changes or something else?. The diff would be equivalent to “hg diff -r base” and would contain all the changes she did to add the bug fix or feature. Merging only makes sure that the computed diff does not appear to touch unrelated files, IOW that it applies cleanly. (Barring bugs in Mercurial-Roundup integration, we have a few of these in the metatracker.) So you are saying that "Create patch" will ONLY get the differences in the development branch and not the changes brought in from the merge?. I don’t really understand how you understood what I said :( The merge brings in changes from default; when you diff your branch against default later, it will not show the changes brought by the merge, but it will apply cleanly on top of default.
But I am not doing that diff, it is the tracker who is doing that diff. I agree that the following procedure would work. In fact it is the way I used to work, before publishing my repository and using "create patch" in the tracker: 1. Branch. 2. Develop in the branch. 3. Merge changes from mainline INTO the branch. 4. Jump to 2 as many times as needed. 5. When done: 5.1. Do a final merge from mainline to branch. 5.2. Do a DIFF from branch to mainline. After 5.2, the diff shows only the code I have patched in the branch. PERFECT. But I don't know if the tracker does that or not. Without the final merge, a diff between my branch and mainline tips will show my changes PLUS the "undoing" of any change in mainline that I didn't merge in my branch. Since "create patch" (in the tracker) doesn't compare against the tip of mainline (at least not in a trivial way), I guess it is comparing against the BASE of the branch. That is ok... as far as I don't merge changes from mainline to the branch. If so, when diffing the branch tip from the branch base it will show all changes in the branch, both my code and the code imported via merges. So, in this context, if the tracker "create patch" diff from BASE, it is not "safe" to merge changes from mainline to the branch, because if so "create patch" would include code not related to my work. I could try actually merging and clicking "create patch" but if the result is unpleasant my repository would be in a state "not compatible" with "create patch" tool in the tracker. I rather prefer to avoid that, if somebody knows the answer. If nobody can tell, experimentation would be the only option, although any experimental result would be suspicious because the hooks can be changes later or you are hitting any strange corner case. Another approach, that I am doing so far, is to avoid merging from mainline while developing in a branch, just in case. But I am hitting now a situation while there are changes in mainline that overlap my effort so I am quite forced to merge that code in, instead of dealing with a huge divergent code in a month. So, I have avoid to merge in the past and was happy, but I would need to merge now (changes from mainline) and I am unsure on what is going to happen with the "create patch" option in the tracker. Anybody knows the mercurial command used to implement "create patch"?. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTtMMPplgi5GaxT1NAQKzhQP8DzAql1PAJkyEROsWl8CgPpW9ie8jNM1V +K5jLx/dCukzFXrZ2Ba1Tu5IFYFZxH7Wj4rg4sQ47zlKBi6gQELgtGV+bCYPAEt/ WQo7uGUCj+xLmBKXuQQlXrl1pNl9XhlufTNXIzW34o7SPKMEQy7N7uUxpxgwV8JX KoJoYAbiH88= =9lYm -----END PGP SIGNATURE-----
On Mon, Nov 28, 2011 at 2:21 PM, Jesus Cea
Since "create patch" (in the tracker) doesn't compare against the tip of mainline (at least not in a trivial way), I guess it is comparing against the BASE of the branch. That is ok... as far as I don't merge changes from mainline to the branch. If so, when diffing the branch tip from the branch base it will show all changes in the branch, both my code and the code imported via merges.
So, in this context, if the tracker "create patch" diff from BASE, it is not "safe" to merge changes from mainline to the branch, because if so "create patch" would include code not related to my work.
No, "Create Patch" is smarter than that. What it does (or tries to do) is walk back through your branch history, trying to find the last point where you merged in a changeset that it recognises as coming from the main CPython repo. It then uses that revision of the CPython repo as the basis for the diff. So if you're just working on a feature branch, periodically pulling from hg.python.org/cpython and merging from default, then it should all work fine. Branches-of-branches (i.e. where you've merged from CPython via another named branch in your local repo) seems to confuse it though - I plan to change my workflow for those cases to merge each branch from the same version of default before merging from the other branch.
Anybody knows the mercurial command used to implement "create patch"?.
It's not a single command - it's a short script MvL wrote that uses the Mercurial API to traverse the branch history and find an appropriate revision to diff against. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/11/11 06:06, Nick Coghlan wrote:
So, in this context, if the tracker "create patch" diff from BASE, it is not "safe" to merge changes from mainline to the branch, because if so "create patch" would include code not related to my work.
No, "Create Patch" is smarter than that. What it does (or tries to do) is walk back through your branch history, trying to find the last point where you merged in a changeset that it recognises as coming from the main CPython repo. It then uses that revision of the CPython repo as the basis for the diff.
Oh, that sounds quite the right way. Clever.
So if you're just working on a feature branch, periodically pulling from hg.python.org/cpython and merging from default, then it should all work fine.
So, my original question is answered as "yes, you can merge in changes from mainline, and 'create patch' will work as it should". Good!!. Thanks!!!.
Anybody knows the mercurial command used to implement "create patch"?.
It's not a single command - it's a short script MvL wrote that uses the Mercurial API to traverse the branch history and find an appropriate revision to diff against.
Publish out somewhere would be useful, I guess. This is a problem I have found in a few other projects. I can see even a modifier for "hg diff" for a future mercurial version :-). Could be implemented as a command line command using "revsets"?. Propose a new revset to mercurial devels? - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTtPze5lgi5GaxT1NAQIT9gP+N4urbw7TgCWTa7EFZ4rjj7/o9f3aBq4I kYBnVZGmh98YqjHL0MzHhhu2a+G6pC/Zksf9CyIinPol4DJR8zGhBDIxo6SNIja+ QsSyQ7DhBWkSwKZAKqBNSdBBH0fu/DpdmNv6fP0s04Ju6sllvHAbEN/oj9zWqxWM KjAMzrgPcSA= =zViH -----END PGP SIGNATURE-----
It's published as part of the tracker repo, although I'm not sure exactly
where it lives.
--
Nick Coghlan (via Gmail on Android, so likely to be more terse than usual)
On Nov 29, 2011 6:50 AM, "Jesus Cea"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 28/11/11 06:06, Nick Coghlan wrote:
So, in this context, if the tracker "create patch" diff from BASE, it is not "safe" to merge changes from mainline to the branch, because if so "create patch" would include code not related to my work.
No, "Create Patch" is smarter than that. What it does (or tries to do) is walk back through your branch history, trying to find the last point where you merged in a changeset that it recognises as coming from the main CPython repo. It then uses that revision of the CPython repo as the basis for the diff.
Oh, that sounds quite the right way. Clever.
So if you're just working on a feature branch, periodically pulling from hg.python.org/cpython and merging from default, then it should all work fine.
So, my original question is answered as "yes, you can merge in changes from mainline, and 'create patch' will work as it should".
Good!!. Thanks!!!.
Anybody knows the mercurial command used to implement "create patch"?.
It's not a single command - it's a short script MvL wrote that uses the Mercurial API to traverse the branch history and find an appropriate revision to diff against.
Publish out somewhere would be useful, I guess. This is a problem I have found in a few other projects. I can see even a modifier for "hg diff" for a future mercurial version :-).
Could be implemented as a command line command using "revsets"?. Propose a new revset to mercurial devels?
- -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBTtPze5lgi5GaxT1NAQIT9gP+N4urbw7TgCWTa7EFZ4rjj7/o9f3aBq4I kYBnVZGmh98YqjHL0MzHhhu2a+G6pC/Zksf9CyIinPol4DJR8zGhBDIxo6SNIja+ QsSyQ7DhBWkSwKZAKqBNSdBBH0fu/DpdmNv6fP0s04Ju6sllvHAbEN/oj9zWqxWM KjAMzrgPcSA= =zViH -----END PGP SIGNATURE----- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
Nick Coghlan wrote:
So, in this context, if the tracker "create patch" diff from BASE, it is not "safe" to merge changes from mainline to the branch, because if so "create patch" would include code not related to my work.
No, "Create Patch" is smarter than that. What it does (or tries to do) is walk back through your branch history, trying to find the last point where you merged in a changeset that it recognises as coming from the main CPython repo. It then uses that revision of the CPython repo as the basis for the diff.
So if you're just working on a feature branch, periodically pulling from hg.python.org/cpython and merging from default, then it should all work fine.
Branches-of-branches (i.e. where you've merged from CPython via another named branch in your local repo) seems to confuse it though - I plan to change my workflow for those cases to merge each branch from the same version of default before merging from the other branch.
The ancestor() revset could help for the confusion: http://stackoverflow.com/a/6744163/639276 In this case, the user would have to be able to tell the branch against which he wants the diff. Petri
Could be implemented as a command line command using "revsets"?. Propose a new revset to mercurial devels?
It *is* implemented as a command line command using "revsets". The revset is max(ancestors(branch("%s")))-outgoing("%s")) where the first parameter is the branch that contains your changes, and the second one is the "path" of the repository you want to diff against. In English: find the most recent revision in the ancestry of your branch that is not an outgoing change wrt. the base repository. ancestors(branch(yours)) gives all revisions preceding your branches' tip, which will be your own changes, plus all changes from the "default" branch that have been merged into your branch (including the changes from where you originally forked the branch). Subtracting outgoing removes all changes that are not yet in cpython, leaving only the changes in your ancestry that come from cpython. max() then finds the most recent such change, which will be the "default" parent of your last merge, or the branch point if you haven't merged after branching. HTH, Martin
participants (7)
-
"Martin v. Löwis" -
Jesus Cea -
Nick Coghlan -
Petri Lehtinen -
Stephen J. Turnbull -
Xavier Morel -
Éric Araujo