Announcing git-cinnabar 0.1.0 (Was: Announcing a new (prototype) git-remote-hg tool)
Hi, Cinnabar is the common natural form in which mercury can be found on Earth. It contains mercury sulfide and its powder is used to make the vermillion pigment. What does that have to do with git? Hint: mercury. Git-cinnabar is a git remote helper to interact with mercurial repositories. It allows to clone, pull and push from/to mercurial remote repositories, using git. If you've already seen the original thread this message is spawned from, this is the same tool, with a new name, and two months worth of additional work and testing. Where git-cinnabar stands out compared to other similar tools is that it doesn't use a local mercurial clone under the hood (unlike all the existing other such tools), and is close to an order of magnitude faster to clone a repository like http://hg.mozilla.org/mozilla-central than the git-remote-hg tool that used to be shipped in contrib/. I won't claim it is exempt of problems and limitations, which is why it's not a 1.0. I'm however confident enough with its state to make the first official release. Code on https://github.com/glandium/git-cinnabar Cheers, Mike -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Announcing a new (prototype) git-remote-hg tool
Hi, I've (re)started work on a longstanding idea of mine of having a git tool talking the mercurial wire protocol directly. I'm now at a stage where the tool can clone and pull/fetch from mercurial. As it is a prototype, there are many things that it doesn't handle (like named branches, bookmarks, phases, obsolescence markers), but it currently transposes a complete mercurial dag to git and maintains metadata about the original mercurial data. Code on https://github.com/glandium/git-remote-hg It doesn't support push, but support for that should come in the coming weeks. More background on http://glandium.org/blog/?p=3382 This is meant to be a prototype, and will stay that way for now. It's a validation that this can actually work. Now that I have pull support I know I can make it push. I'm currently evaluating what the final tool would look like. I'm *very* tempted to implement it in C, based on core git code, because there are many things that this helper does that would be so much easier to do with direct access to git's guts. And that wouldn't require more dependencies than git currently has: it would just need curl and ssh, and git already uses both. If I were to go in that direction, would you consider integrating it in git core? If not, would you rather see git helpers to make this git-remote-hg helper more efficient? Cheers, Mike -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announcing a new (prototype) git-remote-hg tool
Mike Hommey wrote: I'm currently evaluating what the final tool would look like. I'm *very* tempted to implement it in C, based on core git code, because there are many things that this helper does that would be so much easier to do with direct access to git's guts. And that wouldn't require more dependencies than git currently has: it would just need curl and ssh, and git already uses both. If I were to go in that direction, would you consider integrating it in git core? Yes --- I would like this a lot. The general trend has been to carry fewer contrib-style tools in-tree, since the problem of discovering tools built on top of git is not as hard as it used to be. What you describe above seems to be a bit of an exception: - libgit.a in its current state evolves too quickly for it to be convenient for out-of-tree tools to use. cgit http://git.zx2c4.com/cgit/ uses git pinned to a particular version as a submodule to get around this, which is fussy and has bad implications for remembering to get security updates. - an in-tree user of libgit.a would be useful as a reference example to use to try to make libgit.a into be a better library internally (and eventually expose e.g. by merging with libgit2 as something outside tools can link to, I hope) - if it makes sense to help people using the current remote helper in contrib to migrate to this, it could be convenient for users In other words, although in the long term I would be happiest if libgit becomes good enough to let this project live in a separate tree and link to it, it's tempting to build this in-tree because we're not there yet. Some other alternatives: - using libgit2 https://libgit2.github.com/ - improving git plumbing (e.g., with new fast-import commands) or exposing a small library with a stable API for the tool's use I haven't thought it through carefully but at the moment I like the in-tree approach best. Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announcing a new (prototype) git-remote-hg tool
From: Mike Hommey m...@glandium.org Hi, I've (re)started work on a longstanding idea of mine of having a git tool talking the mercurial wire protocol directly. I'm now at a stage where the tool can clone and pull/fetch from mercurial. As it is a prototype, there are many things that it doesn't handle (like named branches, bookmarks, phases, obsolescence markers), but it currently transposes a complete mercurial dag to git and maintains metadata about the original mercurial data. Code on https://github.com/glandium/git-remote-hg It doesn't support push, but support for that should come in the coming weeks. More background on http://glandium.org/blog/?p=3382 This is meant to be a prototype, and will stay that way for now. It's a validation that this can actually work. Now that I have pull support I know I can make it push. I'm currently evaluating what the final tool would look like. I'm *very* tempted to implement it in C, based on core git code, because there are many things that this helper does that would be so much easier to do with direct access to git's guts. And that wouldn't require more dependencies than git currently has: it would just need curl and ssh, and git already uses both. If I were to go in that direction, would you consider integrating it in git core? If not, would you rather see git helpers to make this git-remote-hg helper more efficient? You may also be interested in https://felipec.wordpress.com/2013/08/26/whats-new-in-git-v1-8-4-remote-hg/ and https://github.com/felipec/git-remote-hg. Though Filipe's unique work style hasn't found favour locally. see also https://github.com/buchuki/gitifyhg/wiki/List-of-git-hg-bridges Philip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announcing a new (prototype) git-remote-hg tool
On Fri, Dec 05, 2014 at 02:13:19PM -0800, Jonathan Nieder wrote: Mike Hommey wrote: I'm currently evaluating what the final tool would look like. I'm *very* tempted to implement it in C, based on core git code, because there are many things that this helper does that would be so much easier to do with direct access to git's guts. And that wouldn't require more dependencies than git currently has: it would just need curl and ssh, and git already uses both. If I were to go in that direction, would you consider integrating it in git core? Yes --- I would like this a lot. I'm concerned that this tool will have drawbacks that Felipe's remote-hg does not. And I can well imagine that it may, as that tool builds on Mercurial's API, which will probably handle some corner cases differently. This isn't to disparage Mike's attempt; it will probably have some upsides, too. But given that the approaches are so different, it does not seem obvious to me that one will always be better than the other. One of the nice things about spinning remote-hg out of the core repo is that it means we do not have to endorse a particular implementation, and they can compete with each other on their merits. I would very much hate to see Felipe's remote-hg project wither and die just because another implementation becomes the de facto standard by being included in git.git. It's a proven tool, and this new thing is not yet. It's a shame that both squat on the name remote-hg, because it makes it difficult to tell the two apart. But of course that is the only way to make git clone hg::... work. Maybe we need a layer of indirection? :) - libgit.a in its current state evolves too quickly for it to be convenient for out-of-tree tools to use. cgit http://git.zx2c4.com/cgit/ uses git pinned to a particular version as a submodule to get around this, which is fussy and has bad implications for remembering to get security updates. I'm not sure that this approach is any better than carrying something in contrib/ in git.git. If I refactor a function in libgit.a, I notice breakage in the callers because it no longer compiles, or because I am thorough and look at the implications to git callers. I do _not_ want to be responsible for making sure that contrib/* still builds. That is the problem of the maintainer of the contrib/ project in question. That may sound a little selfish, but I think that is what it means to be in contrib, and not in the regular tree. So once you realize that is the burden of the contrib/ author to fix breakages, then the process is: git pull cd contrib/c-remote-hg make # oops, it broke fix fix fix That is not any different than: git submodule add git... git submodule update make # oops, it broke fix fix fix The hard part is not how you pull changes from the new git into your tree. It is the fact that upstream may be breaking the interface behind your back. And your best bet is to aggressively merge with upstream, rather than trying to track only occasional release versions. Of course, if you meant to _really_ carry it in-tree, not in contrib/, then none of that applies. But then I worry doubly about the endorsement issue. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announcing a new (prototype) git-remote-hg tool
Jeff King wrote: One of the nice things about spinning remote-hg out of the core repo is that it means we do not have to endorse a particular implementation, and they can compete with each other on their merits. True. [...] It's a shame that both squat on the name remote-hg, because it makes it difficult to tell the two apart. But of course that is the only way to make git clone hg::... work. Maybe we need a layer of indirection? :) If the helpers are roughly interchangeable (that is, if you can switch between fetching using each one into the same on-disk git repository), then picking one to symlink as git-remote-hg in your $PATH should be enough. If they don't have that level of interoperability, then there's an argument to be made that the URLs shouldn't be the same. Unfortunately url.*.insteadof rules are resolved at fetch time instead of being resolved once and the result recorded in .git/config. So yes, it seems like a way to have abbreviations for URLs (e.g., hg:: meaning hg+mh:: or hg+fc::) that get resolved at clone time would be useful. It's a layer of indirection we don't provide. :/ Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announcing a new (prototype) git-remote-hg tool
On Fri, Dec 05, 2014 at 05:59:30PM -0500, Jeff King wrote: On Fri, Dec 05, 2014 at 02:13:19PM -0800, Jonathan Nieder wrote: Mike Hommey wrote: I'm currently evaluating what the final tool would look like. I'm *very* tempted to implement it in C, based on core git code, because there are many things that this helper does that would be so much easier to do with direct access to git's guts. And that wouldn't require more dependencies than git currently has: it would just need curl and ssh, and git already uses both. If I were to go in that direction, would you consider integrating it in git core? Yes --- I would like this a lot. I'm concerned that this tool will have drawbacks that Felipe's remote-hg does not. And I can well imagine that it may, as that tool builds on Mercurial's API, which will probably handle some corner cases differently. FWIW, my tool only uses the mercurial code for the wire protocol. This can (and if I go the C route, will) be implemented without using mercurial code, it's really not a hard problem. This isn't to disparage Mike's attempt; it will probably have some upsides, too. But given that the approaches are so different, it does not seem obvious to me that one will always be better than the other. One of the nice things about spinning remote-hg out of the core repo is that it means we do not have to endorse a particular implementation, and they can compete with each other on their merits. I would very much hate to see Felipe's remote-hg project wither and die just because another implementation becomes the de facto standard by being included in git.git. It's a proven tool, and this new thing is not yet. Note that I'm only talking about an hypothetical long term goal. If there's not even a slim chance that this may end up in git core, or in the git.git repo, I'm not sure it's worth writing the tool in C at all, considering the burden for users. IOW, I'm only trying to assess if I should follow my temptation or not. But I can probably reassess after I actually get my prototype to do more than it does now. But maybe there are ways to make it work for users outside of git.git even if it's in C. I don't know. It's a shame that both squat on the name remote-hg, because it makes it difficult to tell the two apart. But of course that is the only way to make git clone hg::... work. Maybe we need a layer of indirection? :) Yeah, that's an unfortunate consequence of how remote helpers work. There are already two different git-remote-hgs (there's felipe's, and there's another one using hg-git under the hood) that I know of. I'm adding a third one. For what it's worth, none of the existing one is satisfying on repos the size of Mozilla's, and apparently noone at Mozilla uses them because of that. Add to that the disk space inefficiency of actually keeping a copy of the mercurial repo locally. The existing tools can likely be improved to scale better, but that wouldn't change the disk space problem. Mike -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announcing a new (prototype) git-remote-hg tool
On Fri, Dec 05, 2014 at 03:13:30PM -0800, Jonathan Nieder wrote: Jeff King wrote: One of the nice things about spinning remote-hg out of the core repo is that it means we do not have to endorse a particular implementation, and they can compete with each other on their merits. True. [...] It's a shame that both squat on the name remote-hg, because it makes it difficult to tell the two apart. But of course that is the only way to make git clone hg::... work. Maybe we need a layer of indirection? :) If the helpers are roughly interchangeable (that is, if you can switch between fetching using each one into the same on-disk git repository), then picking one to symlink as git-remote-hg in your $PATH should be enough. If they don't have that level of interoperability, then there's an argument to be made that the URLs shouldn't be the same. I don't think Felipe's and the one that uses hg-git under the hood are already interoperable. Mine is also different from both. They should all produce the same git trees. They don't produce the same commits. They also don't share the same metadata. Mike -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announcing a new (prototype) git-remote-hg tool
On Fri, Dec 05, 2014 at 03:13:30PM -0800, Jonathan Nieder wrote: It's a shame that both squat on the name remote-hg, because it makes it difficult to tell the two apart. But of course that is the only way to make git clone hg::... work. Maybe we need a layer of indirection? :) If the helpers are roughly interchangeable (that is, if you can switch between fetching using each one into the same on-disk git repository), then picking one to symlink as git-remote-hg in your $PATH should be enough. That may be enough. For the most part you do not need to agree with other members of the project on which implementation to use. My experience with import tools has been that either: 1. you are using them personally (because you do not like the upstream's choice of VCS and would prefer to transparently work in your favorite tool), or 2. there is a group of developers who want to use git, but somebody provides an unofficial git mirror. They do not have to agree on the tool, because they just use git directly from the mirror. So it is mostly a personal choice. But the two confusions I'd still anticipate are: a. It's difficult to even _talk_ about the tools, because the names are the same (so searching for tips on the tool, reporting bugs, etc, are harder than necessary). b. You may want different tools for different projects. If one tool is much more efficient, you may need it for a large repo (e.g., mozilla). But another tool may provide other features, and you would prefer it for smaller repos. This is largely speculation, though, and I do not actively use the tools myself. So I'd be happy to push off dealing with it until it itches enough for somebody to scratch. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Error using git-remote-hg
Le 12 mai 2014 à 21:37, Felipe Contreras felipe.contre...@gmail.com a écrit : Torsten Bögershausen wrote: I'm using git 1.9.3 on Mac OS X 10.9.2, with hg 3.0 installed with brew. It used to work before, on this same repository, since then git and hg were both upgraded. In short: The remote helper of Git 1.9.3 is not compatible with hg 3.0 You can eiher downgrade hg, or rebuild Git and cherry-pick this commit: No need to rebuild Git. You can also use the latest version: https://github.com/felipec/git-remote-hg Thanks Felipe and Torsten, just using the HEAD version of git-remote-hg solved the problem. Best regards, Charles-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Error using git-remote-hg
(Please use reply-all and don't snip the important stuff) On 2014-05-13 09.54, Charles Brossollet wrote: Le 12 mai 2014 à 21:37, Felipe Contreras felipe.contre...@gmail.com a écrit : Torsten Bögershausen wrote: I'm using git 1.9.3 on Mac OS X 10.9.2, with hg 3.0 installed with brew. It used to work before, on this same repository, since then git and hg were both upgraded. In short: The remote helper of Git 1.9.3 is not compatible with hg 3.0 You can eiher downgrade hg, or rebuild Git and cherry-pick this commit: No need to rebuild Git. You can also use the latest version: https://github.com/felipec/git-remote-hg Thanks Felipe and Torsten, just using the HEAD version of git-remote-hg solved the problem. Best regards, Charles-- I did some testing with Git 2.0-rc3 + 58aee0864adeeb5363f. The remote-helper tests for hg-git worked OK with both hg version 2.9 and 3.0 under both Mac OS and Linux. Should we consider 58aee086 to be included in Git 2.0 ? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Error using git-remote-hg
Hamano gits...@pobox.com
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 34cda02..8b02803 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -13,6 +13,7 @@
# $GIT_DIR/hg/origin/clone/.hg/.
from mercurial import hg, ui, bookmarks, context, encoding, node, error,
extensions, discovery, util
+from mercurial import changegroup
import re
import sys
@@ -985,7 +986,10 @@ def push_unsafe(repo, remote, parsed_refs, p_revs):
if not checkheads(repo, remote, p_revs):
return None
-cg = repo.getbundle('push', heads=list(p_revs), common=common)
+if check_version(3, 0):
+cg = changegroup.getbundle(repo, 'push', heads=list(p_revs),
common=common)
+else:
+cg = repo.getbundle('push', heads=list(p_revs), common=common)
unbundle = remote.capable('unbundle')
if unbundle:
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Error using git-remote-hg
Junio C Hamano wrote: It is time to catch regressions by asking wider audiences who do not normally follow Git development (i.e. those who are not the ones that follow 'master' and rebuild/install it once or twice a week for their daily use). And you have one of those regressions in Git v2.0. My understanding is that versions of remote-hg shipped with all versions of Git did not work with Hg 3.0, so 58aee08 is not a regression fix at all. Is working with Hg 3.0 at such a high priority that it makes it worth to slip the whole release schedule by a few weeks? I do not think so. It is in the contrib/ area, you don't need to slip the schedule for something that is not part of the core. Moreover, it *CANNOT POSSIBLY INTRODUCE REGRESSIONS*. I bet my reputation on that. Some time ago I asked you to trust my judgement and introduce changes late into a release, and I told you there wouldn't be any problems, and to trust me. If any problems arise I wouldn't be asking for something like that again. Well, I was right, there were no problems. And I'm right this time too, there would be no issues. But you don't care about reality and facts. You don't care about the intent behind the release-candidates rule, you would rather follow the rule blindly. Regarding the commit in question, I asked Felipe a question and never got a straight answer. Nor will you get one, because thanks to your stupid decision for which you still haven't provided a rationale, the git-remote-hg and git-remote-hg are no longer maintained in git.git. If you hadn't made such a move, you would have your answer, the fix would be properly explained, the regression fixed, and all your users would be happy that git-remote-hg and git-remote-bzr get distributed by default. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Error using git-remote-hg
On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote: Torsten Bögershausen tbo...@web.de writes: I did some testing with Git 2.0-rc3 + 58aee0864adeeb5363f. The remote-helper tests for hg-git worked OK with both hg version 2.9 and 3.0 under both Mac OS and Linux. Should we consider 58aee086 to be included in Git 2.0 ? So the answer to your question is an unambiguous no. It is a different matter if we want a change to allow us to operate with both older and newer version of mercurial in a release of Git in near future. The answer is a resounding yes, even if the solution may not be the exact 58aee0864 commit [*2*]. I think an update should eventurally go to the maintenance tracks of even older releases, perhaps maint-1.8.5 and upwards, after we merge it to 'master' in preparation for the feature release that comes after Git 2.0, which probably will be called 2.1 but do not quote me on that. Regarding the commit in question, I asked Felipe a question and never got a straight answer. Why do we import changegroup unconditionally, even though it is only used in the new codepath meant only for version 3.0 or higher, not inside the if block that decides if we need that module? It should not be, as it is not used outside of hg 3.0. In fact, what would be even better would be to test whether changegroup.getbundle is available, and then set a function like `getbundl()` to run either `changegroup.getbundl()` with the correct args, or `repo.getbundle()` as a fallback. changegroup is prefectly /okay/ to import unconditionally, though as you say it will never be used. We can also be even more explicit with what we import by doing something like:: try: from mercurial.changegroup import getbundle except ImportError: def getbundle(__empty__, **kwargs): return repo.getbundle(**kwargs) and then just calling:: cg = getbundle(repo, 'push', heads=list(p_revs), common=common) The `__empty__` arg is there because repo.getbundle uses a different number of arguments than the changegroup.getbundle function. It's a much cleaner solution than assuming that that will stay in changegroup, and not get moved back to repo in the future. Seems to be what you described in the second bit, though. If you would like I can submit a patch once I've finished running the tests on it, and possibly after having Felipe run it through his tests to be sure thta the 2.[7-9] series works as well, and maybe you would want to test it on other versions of mercurial that you are running alongside git. Just my 2 cents. I had a few more questions in mind that I didn't have a chance to ask, and the commit log message did not explain. Is the reason why this fix is needed is because repo stopped being a way to ask .getbundle() and in the new world order changegroup is the new way to ask .getbundle()? If the answer is yes, then asking are we with 3.0 or later---if so ask changegroup for .getbundle()?, which is this patch does, may not be the right condition to trigger the new codepath. Does repo know how to do .getbundle()? If not, import changegroup and ask that module to perform .getbundle() instead may be a way to base the decision on a more directly relevant condition. Answers to these questions, if they came, were meant to convince myself that the patch 58aee0864 is the best solution to the problem, but because I only got Of course it is not a mistake [*1*], seeing it did not lead to a productive discussion, I gave up. So I haven't even managed to convince myself that that commit is the best solution to the problem. I was really sad to see that, and didn't have time to really look at it because of work and other projects, but I hope this presents a better solution than the current patch. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpC7ZLGG4hd9.pgp Description: PGP signature
Re: Error using git-remote-hg
William Giokas wrote: On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote: Why do we import changegroup unconditionally, even though it is only used in the new codepath meant only for version 3.0 or higher, not inside the if block that decides if we need that module? changegroup is prefectly /okay/ to import unconditionally, though as you say it will never be used. As you say, it's perfectly OK. We can also be even more explicit with what we import by doing something like:: try: from mercurial.changegroup import getbundle except ImportError: def getbundle(__empty__, **kwargs): return repo.getbundle(**kwargs) We could try that, but that would assume we want to maintain getbundle() for the long run, and I personally don't want to do that. I would rather contact the Mercurial developers about ways in which the push() method can be improved so we don't need to have our own version. Hopefully after it's improved we wouldn't have to call getbundle(). Moreover, eventually there will be a Mercurial 4.0, even 5.0, and at some point we would want to remove the hacks for older versions. When we do so we would want the import to remain unconditionally, and remove the 'check_version(3, 0)' which is already helping to explain what the code is for without the need of comments. I was really sad to see that, and didn't have time to really look at it because of work and other projects, but I hope this presents a better solution than the current patch. Either way Junio doesn't maintain this code, I do. And it's not maintained in git.git, git's maintained out-of-tree (thanks to Junio's decisions). So please post your suggestions and patches to git...@googlegroups.com, and use the latest code at https://github.com/felipec/git-remote-hg. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Error using git-remote-hg
On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote: William Giokas wrote: On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote: Why do we import changegroup unconditionally, even though it is only used in the new codepath meant only for version 3.0 or higher, not inside the if block that decides if we need that module? changegroup is prefectly /okay/ to import unconditionally, though as you say it will never be used. As you say, it's perfectly OK. But wrong. Yes, it works, but it's not how it should be done when we have a code review such as this. It should simply not be done and makes no sense to do with an 'if check ver; else' kind of thing later in the application. We can also be even more explicit with what we import by doing something like:: try: from mercurial.changegroup import getbundle except ImportError: def getbundle(__empty__, **kwargs): return repo.getbundle(**kwargs) We could try that, but that would assume we want to maintain getbundle() for the long run, and I personally don't want to do that. I would rather contact the Mercurial developers about ways in which the push() method can be improved so we don't need to have our own version. Hopefully after it's improved we wouldn't have to call getbundle(). Assuming that mercurial 3.0 will not change, then this should never need to change. Changes in 'getbundle' upstream would require changes either way. Moreover, eventually there will be a Mercurial 4.0, even 5.0, and at some point we would want to remove the hacks for older versions. When we do so we would want the import to remain unconditionally, and remove the 'check_version(3, 0)' which is already helping to explain what the code is for without the need of comments. The same exact thing can be done with this. In fact, it would probably allow us to have better future-proofing with regards to new versions of mercurial, there would just be different try:except statements at the beginning. I was really sad to see that, and didn't have time to really look at it because of work and other projects, but I hope this presents a better solution than the current patch. Either way Junio doesn't maintain this code, I do. And it's not maintained in git.git, git's maintained out-of-tree (thanks to Junio's decisions). I still see it in git.git, and I will contribute this upstream for as long as it is in the tree. If you want to use the patch that I sent to this list, feel free. So please post your suggestions and patches to git...@googlegroups.com, and use the latest code at https://github.com/felipec/git-remote-hg. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgp_mLEPyhosF.pgp Description: PGP signature
Re: Error using git-remote-hg
William Giokas wrote:
On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
William Giokas wrote:
On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote:
Why do we import changegroup unconditionally, even though it
is only used in the new codepath meant only for version 3.0 or
higher, not inside the if block that decides if we need that
module?
changegroup is prefectly /okay/ to import unconditionally, though as you
say it will never be used.
As you say, it's perfectly OK.
But wrong. Yes, it works, but it's not how it should be done when we
have a code review such as this. It should simply not be done and makes
no sense to do with an 'if check ver; else' kind of thing later in the
application.
That's exactly how it should be done. Maybe this visualization helps
from mercurial import hg, ui, bookmarks, ...# for hg = 3.0
from mercurial import node, error, extensions, ... # for hg = 3.0
from mercurial import changegroup # for hg = 3.0
if check_version(3, 0):
cg = changegroup.getbundle(repo, 'push', ...# for hg = 3.0
else:
cg = repo.getbundle('push', heads=list(p_revs) # for hg 3.0
Eventually the code would become:
from mercurial import hg, ui, bookmarks, ...# for hg = 3.0
from mercurial import node, error, extensions, ... # for hg = 3.0
from mercurial import changegroup # for hg = 3.0
cg = changegroup.getbundle(repo, 'push', ...# for hg = 3.0
The fact that at some point 'import changegroup' was not needed is
irrelevant.
Primarily we want to support the current version of Mercurial.
Secondarily we want to support older versions. That's why we add the
repo.getbundle() code (ass an addendum to the core part).
We can also be even more explicit with what we import by doing something
like::
try:
from mercurial.changegroup import getbundle
except ImportError:
def getbundle(__empty__, **kwargs):
return repo.getbundle(**kwargs)
We could try that, but that would assume we want to maintain getbundle()
for the long run, and I personally don't want to do that. I would rather
contact the Mercurial developers about ways in which the push() method
can be improved so we don't need to have our own version. Hopefully
after it's improved we wouldn't have to call getbundle().
Assuming that mercurial 3.0 will not change, then this should never
need to change.
But it should. Otherwise the code will keep having more and more hacks
and it will become less and less maintainable.
That's why we don't have code for hg 1.0; because it would require too
many hacks, and nobody cared anyway.
Just like nobody cares about hg 1.0, eventually nobody will care about
hg 2.0.
Changes in 'getbundle' upstream would require changes either way.
I doubt we will see any more changes in getbundle, at least not until
4.0, and hopefully by then we wouldn't be using it anyway. I am willing
to bet we won't see those changes.
Moreover, eventually there will be a Mercurial 4.0, even 5.0, and at
some point we would want to remove the hacks for older versions. When we
do so we would want the import to remain unconditionally, and remove the
'check_version(3, 0)' which is already helping to explain what the code
is for without the need of comments.
The same exact thing can be done with this. In fact, it would probably
allow us to have better future-proofing with regards to new versions of
mercurial, there would just be different try:except statements at the
beginning.
No, your code doesn't show that this is for versiosn = 3.0,
'check_version(3, 0)' does.
Plus, when we remove this code my version makes it straight forward:
-if check_version(3, 0):
-cg = changegroup.getbundle(repo, 'push', ...
-else:
-cg = repo.getbundle('push', heads=list(p_revs), ...
+cg = changegroup.getbundle(repo, 'push', ...
Not so with your code:
-
-try:
-from mercurial.changegroup import getbundle
-
-except ImportError:
-def getbundle(__empty__, **kwargs):
-return repo.getbundle(**kwargs)
+from mercurial import getbundle
import re
import sys
@@ -1036,7 +1030,7 @@ def push_unsafe(repo, remote, ...
if not checkheads(repo, remote, p_revs):
return None
-cg = getbundle(repo, 'push', heads=list(p_revs), ...
+cg = changegroup.getbundle(repo, 'push', ...
I was really sad to see that, and didn't have time to really look at it
because of work and other projects, but I hope this presents a better
solution than the current patch.
Either way Junio doesn't maintain this code, I do. And it's not
maintained in git.git, git's maintained out-of-tree (thanks to Junio's
decisions).
I still see it in git.git, and I will contribute this upstream for as
long as it is in the tree.
And what happens when it's eventually removed?
If you
Re: Error using git-remote-hg
On Tue, May 13, 2014 at 03:24:51PM -0500, Felipe Contreras wrote:
William Giokas wrote:
On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
As you say, it's perfectly OK.
But wrong. Yes, it works, but it's not how it should be done when we
have a code review such as this. It should simply not be done and makes
no sense to do with an 'if check ver; else' kind of thing later in the
application.
That's exactly how it should be done. Maybe this visualization helps
from mercurial import hg, ui, bookmarks, ...# for hg = 3.0
from mercurial import node, error, extensions, ... # for hg = 3.0
from mercurial import changegroup # for hg = 3.0
if check_version(3, 0):
cg = changegroup.getbundle(repo, 'push', ...# for hg = 3.0
else:
cg = repo.getbundle('push', heads=list(p_revs) # for hg 3.0
Eventually the code would become:
from mercurial import hg, ui, bookmarks, ...# for hg = 3.0
from mercurial import node, error, extensions, ... # for hg = 3.0
from mercurial import changegroup # for hg = 3.0
cg = changegroup.getbundle(repo, 'push', ...# for hg = 3.0
No, the way that it's going to change is that the import statements will
change, not the 'if:else' things. It would work exactly the same with
this, however the things that are used only in a specific version for
this are stated up front. Maybe this visualization helps for what I have
set up::
from mercurial import ...# for all hg
try:
from mercurial.changegroup import getbundle # for hg with
# changegroup.getbundle,
# regardless of version
except ImportError: # for hg from before the
def getbundle(__empty__, **kwargs): # move to changegroup
return repo.getbundle(**kwargs)
...
cg = getbundle(...)
When we eventually remove support for mercurial that uses
repo.getbundle:
from mercurial import changegroup, ... # for all hg
...
cg = changegroup.getbundle(...)
That should make sense. You could even just remove the try: and except:
bits and just to 'from mercurial.changegroup import getbundle' and not
mess with the meat of the code at all.
The fact that at some point 'import changegroup' was not needed is
irrelevant.
Primarily we want to support the current version of Mercurial.
Secondarily we want to support older versions. That's why we add the
repo.getbundle() code (as an addendum to the core part).
So I use arch myself, and I am very used to the 'rolling release' model
that it employs. I do agree that we should concentrate support for the
latest release, but for a project like git the other versions of hg
cannot be ignored, as this project is used on so many different systems.
We could try that, but that would assume we want to maintain getbundle()
for the long run, and I personally don't want to do that. I would rather
contact the Mercurial developers about ways in which the push() method
can be improved so we don't need to have our own version. Hopefully
after it's improved we wouldn't have to call getbundle().
Assuming that mercurial 3.0 will not change, then this should never
need to change.
But it should. Otherwise the code will keep having more and more hacks
and it will become less and less maintainable.
That's why we don't have code for hg 1.0; because it would require too
many hacks, and nobody cared anyway.
Just like nobody cares about hg 1.0, eventually nobody will care about
hg 2.0.
Yes, it can change. Eventually hg 2.0 will be defunct and no one will
use it, but what happens if they go back to the old 2.0 style for
getbundle in hg 4.0? We're already good. What if they switch it back in
4.1? This works for all of those conditions, and doesn't do anything if
we're able to get mercurial.changegroup.getbundle.
Changes in 'getbundle' upstream would require changes either way.
I doubt we will see any more changes in getbundle, at least not until
4.0, and hopefully by then we wouldn't be using it anyway. I am willing
to bet we won't see those changes.
Moreover, eventually there will be a Mercurial 4.0, even 5.0, and at
some point we would want to remove the hacks for older versions. When we
do so we would want the import to remain unconditionally, and remove the
'check_version(3, 0)' which is already helping to explain what the code
is for without the need of comments.
The same exact thing can be done with this. In fact, it would probably
allow us to have better future-proofing with regards to new versions of
mercurial, there would just be different try:except statements at the
beginning.
No, your code doesn't show that this is for versiosn = 3.0,
'check_version(3, 0)' does.
That's the whole point. This did
Re: Error using git-remote-hg
William Giokas wrote:
On Tue, May 13, 2014 at 03:24:51PM -0500, Felipe Contreras wrote:
William Giokas wrote:
On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
As you say, it's perfectly OK.
But wrong. Yes, it works, but it's not how it should be done when we
have a code review such as this. It should simply not be done and makes
no sense to do with an 'if check ver; else' kind of thing later in the
application.
That's exactly how it should be done. Maybe this visualization helps
from mercurial import hg, ui, bookmarks, ...# for hg = 3.0
from mercurial import node, error, extensions, ... # for hg = 3.0
from mercurial import changegroup # for hg = 3.0
if check_version(3, 0):
cg = changegroup.getbundle(repo, 'push', ...# for hg = 3.0
else:
cg = repo.getbundle('push', heads=list(p_revs) # for hg 3.0
Eventually the code would become:
from mercurial import hg, ui, bookmarks, ...# for hg = 3.0
from mercurial import node, error, extensions, ... # for hg = 3.0
from mercurial import changegroup # for hg = 3.0
cg = changegroup.getbundle(repo, 'push', ...# for hg = 3.0
No, the way that it's going to change is that the import statements will
change, not the 'if:else' things. It would work exactly the same with
this, however the things that are used only in a specific version for
this are stated up front. Maybe this visualization helps for what I have
set up::
from mercurial import ...# for all hg
try:
from mercurial.changegroup import getbundle # for hg with
# changegroup.getbundle,
# regardless of version
This would make sense if in our eyse all versions of Mercurial were
the same, and we would want the code to work optimally for all of them
forever.
But that's not the case. The current version of Mercurial is more
important, the fact that we have one unnecessary import in older
versions is not of consequence because eventually the won't be
supported.
When we eventually remove support for mercurial that uses
repo.getbundle:
from mercurial import changegroup, ... # for all hg
...
cg = changegroup.getbundle(...)
And the diff from my version to the final version is smaller.
The fact that at some point 'import changegroup' was not needed is
irrelevant.
Primarily we want to support the current version of Mercurial.
Secondarily we want to support older versions. That's why we add the
repo.getbundle() code (as an addendum to the core part).
So I use arch myself, and I am very used to the 'rolling release' model
that it employs. I do agree that we should concentrate support for the
latest release, but for a project like git the other versions of hg
cannot be ignored, as this project is used on so many different systems.
Older versions are not ignored, they are supported. It's just not worth
tainting the code to avoid an 'import'.
We could try that, but that would assume we want to maintain getbundle()
for the long run, and I personally don't want to do that. I would rather
contact the Mercurial developers about ways in which the push() method
can be improved so we don't need to have our own version. Hopefully
after it's improved we wouldn't have to call getbundle().
Assuming that mercurial 3.0 will not change, then this should never
need to change.
But it should. Otherwise the code will keep having more and more hacks
and it will become less and less maintainable.
That's why we don't have code for hg 1.0; because it would require too
many hacks, and nobody cared anyway.
Just like nobody cares about hg 1.0, eventually nobody will care about
hg 2.0.
Yes, it can change. Eventually hg 2.0 will be defunct and no one will
use it, but what happens if they go back to the old 2.0 style for
getbundle in hg 4.0?
Then you can tell me I was wrong and we go back to your version. But
that's not going to happen.
And even if it does, we still would need to fix the code.
We're already good. What if they switch it back in
4.1? This works for all of those conditions, and doesn't do anything if
we're able to get mercurial.changegroup.getbundle.
Every method can change, we can't have wrappers for all of them.
In reality few of them do. And we deal with them on a case by case
basis.
There's no need to worry about the unlikely, especially since there
isn't much difference between the likely and unlikely; we are still
going to need to fix the code.
Changes in 'getbundle' upstream would require changes either way.
I doubt we will see any more changes in getbundle, at least not until
4.0, and hopefully by then we wouldn't be using it anyway. I am willing
to bet we won't see those changes.
Re: Should git-remote-hg/bzr be part of the core?
Linus Torvalds wrote: On May 12, 2014 8:35 AM, Felipe Contreras felipe.contre...@gmail.com wrote: This move is already under way, but suddenly Junio changed his mind. That suddenly wouldn't have anything to do with you being an ass and difficult as usual, arguing about everything and just generally being contrary? No, here's where the thread started (A): http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248167 Here I wasn't being an ass: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248186 Here I wasn't being an ass either: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248171 Neither here: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248146 Nor here: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248195 Nor here: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248205 Not an ass here: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248213 And not here either: http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248236 Then Junio *suddenly* changed his mind (B): http://thread.gmane.org/gmane.comp.version-control.git/247660/focus=248242 That is the sequence of mails (A..B) where I responded, and I wasn't an ass in eithe one of those, so whatever made Junio change his mind happened in that interum, and it wasn't me being an ass. I bet you made that statement without even botherting to read the thread. Go on, read the thread, tell where exactly me being an ass made Junio change his mind from A, to B. Nah, you wouldn't do that, backing up your claims take time, and you are not willing to spend time on this issue. Even if you were to try to back up your claim, you couldn't, becasue it's not true. It's much easier to just throw good sounding baseless claims and walk away. Felipe, stop this stupid blaming of everybody but yourself. Show me evidence that this decision was my fault. Junio certainly hasn't said so. You just have no idea what we are talking about. You make absolutely everything be this horrible disaster, you redefine words (regression) to be whatever you need/want them to be to be git-remote-hg and git-remote-bzr will likely break in Git v2.0 in certain situations where they wouldn't in v1.9, or v1.8. Call it whatever you want. I call that a regression. Seriously. Don't try to make this about Junio somehow being the problem. So Junio is perfect. Got it. If you don't have the time to actually read the rationale behind Junio's decision, how would you even know he made the right one? You are just blindly assuming he is right, and therefore he is not the problem. What if he was wrong? Nah, that's impossible. Right? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should git-remote-hg/bzr be part of the core?
Felipe Contreras wrote: Linus Torvalds wrote: Felipe, stop this stupid blaming of everybody but yourself. Show me evidence that this decision was my fault. Junio certainly hasn't said so. You just have no idea what we are talking about. Here, let me show you. Junio, can you answer these questions? 1) What is missing from git-remote-hg/bzr in order for them to be considered to be merged to the core? 2) If a different maintainer steps up, would you consider reconsider merging them to the core? 3) Is there any chance that in the future you would consider them after they are more mature, and/or perhaps with a different maintainer? Unless Junio changes his mind again, the answers to those questions should be clear already to the people following the discussion (i.e. not you). -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should git-remote-hg/bzr be part of the core?
On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Those arguments were discussed at length and I think their weight is on the side of not moving it. But there are two other (in my opinion, stronger) reasons for keeping git-remote-hg out of the core: 1. That subproject has not been maintained to the standards of the Git project; specifically, Git project standards include good commit messages and a willingness to engage with the community on a friendly and constructive way and to welcome feedback. Because of your confrontational and nit-picking style, Felipe, many people who have tried to help you improve your work are rebuffed and end up giving up out of frustration or exhaustion. Because of this, your commits do not benefit from the usual amount of help from the community and therefore their quality is not as high as required for commits to core Git. 2. Moving git-remote-hg into the core would require even *more* of your presence on the Git mailing list. But your very presence is detrimental to the rest of the community. You insult and frustrate people who are trying to help you. You attribute malign motivations to people who are trying to be scrupulously fair. You string out enormous threads of nit-picking, legalistic argumentativeness that have little to do with the real issues at hand. The last big Felipe eruption in the summer of 2013 caused an enormous amount of strife, wasted an inordinate amount of time of other community members, and caused at least one valued contributor to temporarily rage-quit the community. That episode only ended when Junio asked you to leave the community [1], which, thankfully, you did for a while. After you left, the atmosphere of the mailing list soon returned to its usual friendly, collegial, and efficient norm. Recently you returned to the mailing list. In my opinion everybody on the list, including especially Junio, interacted with you in a very polite and businesslike manner. I believe you were given an honest chance at a fresh start in the community. I wish you had taken it. The Git project could really benefit from the help of a skilled and energetic developer like you! But it didn't take long before you started the same theatrics again. And now again, dealing with your caustic attitude is wasting an order of magnitude more time of the other core developers than your contributions could possibly bring in benefits. For me, the conclusion is unfortunate but clear: Felipe Contreras is (by far) a net liability to the Git project. Specifically: * The Git project will progress faster without you because the other contributors will have to waste less time dealing with your antics. * The Git community will grow faster without you, because your presence will not cause existing contributors to withdraw and dissuade new contributors from joining. * The community will be a lot more pleasant without you. Therefore, I am happy that you have apparently decided to split git-remote-hg into a separate project. I wish you success with the project and I see no reason that it shouldn't continue to be successful. But I am glad that I will not have to interact with you anymore. [...] Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will? Being the leader of your own valuable open-source project is nothing like jail. It is an opportunity for you to shine in an environment that is more suited to your personality. Given the huge amount of work I've put in these remote helpers, and the fact that Junio said since day 1 he wanted these in the core[5] (and I was operating under that assumption), I think the demotion back to the contrib area (and therefore out-of-tree) should be made carefully, and not from one day to he next as it happened. None of the work was wasted. git-remote-hg can live on. This email is written in sorrow, not in anger. Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, the whole balance would change entirely, and any software project would be happy to have you. With all my heart I truly wish you the best in your future endeavors. Michael [1] http://article.gmane.org/gmane.comp.version-control.git/227750 -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should git-remote-hg/bzr be part of the core?
2014-05-12 10:12 GMT+02:00 Felipe Contreras felipe.contre...@gmail.com: Felipe Contreras wrote: Linus Torvalds wrote: Felipe, stop this stupid blaming of everybody but yourself. Show me evidence that this decision was my fault. Junio certainly hasn't said so. You just have no idea what we are talking about. Here, let me show you. I suspect Linus had a reason not to include the mailing lists in the first place and make a huge public discussion, but instead wrote to you personally. I guess this is just Linus desire not to waste the time of everybody as he learned that these discussions are fruitless sometimes. Junio C Hamano wrote [in another thread]: I would not mind asking the others, as your discussion tactic seems to be repeated voices start sounding like a chorus, and a chorus is project concensus. Those who are observing from the sideline, please raise your hand if you think the three-line Clarification Felipe gave us is a fair and accurate clarification. Anybody? I also do not mind seeing hands raised of those who do not agree, even though I already know that they would be a silent majority. I think Junio is behaving very professional unlike you, Felipe. This includes being polite and very patient. Also this includes weighting different reasons to make informed rational decisions. Git being a project widely used and people trusting it for their work needs to have high quality and cannot go left today and go right tomorrow, but most of the decisions are done long-term. Felipe, this may be the reason, why you think nothing changes. It's just slower than you'd like, but with more thoughts weighted. Junio, I think you're doing an awesome job in maintaining Git and leading the community. Stefan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should git-remote-hg/bzr be part of the core?
Michael, Thank you for writing this, I have to see I agree completely. As a mostly lurker on this list, I tend to skip any thread Felipe is participating in, as it tends to quickly spiral out of control. This is also the main reason for me not to actively participate a bit more, I prefer reasonable discussions over fighting. On ma, 2014-05-12 at 11:42 +0200, Michael Haggerty wrote: On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Those arguments were discussed at length and I think their weight is on the side of not moving it. But there are two other (in my opinion, stronger) reasons for keeping git-remote-hg out of the core: 1. That subproject has not been maintained to the standards of the Git project; specifically, Git project standards include good commit messages and a willingness to engage with the community on a friendly and constructive way and to welcome feedback. Because of your confrontational and nit-picking style, Felipe, many people who have tried to help you improve your work are rebuffed and end up giving up out of frustration or exhaustion. Because of this, your commits do not benefit from the usual amount of help from the community and therefore their quality is not as high as required for commits to core Git. 2. Moving git-remote-hg into the core would require even *more* of your presence on the Git mailing list. But your very presence is detrimental to the rest of the community. You insult and frustrate people who are trying to help you. You attribute malign motivations to people who are trying to be scrupulously fair. You string out enormous threads of nit-picking, legalistic argumentativeness that have little to do with the real issues at hand. The last big Felipe eruption in the summer of 2013 caused an enormous amount of strife, wasted an inordinate amount of time of other community members, and caused at least one valued contributor to temporarily rage-quit the community. That episode only ended when Junio asked you to leave the community [1], which, thankfully, you did for a while. After you left, the atmosphere of the mailing list soon returned to its usual friendly, collegial, and efficient norm. Recently you returned to the mailing list. In my opinion everybody on the list, including especially Junio, interacted with you in a very polite and businesslike manner. I believe you were given an honest chance at a fresh start in the community. I wish you had taken it. The Git project could really benefit from the help of a skilled and energetic developer like you! But it didn't take long before you started the same theatrics again. And now again, dealing with your caustic attitude is wasting an order of magnitude more time of the other core developers than your contributions could possibly bring in benefits. For me, the conclusion is unfortunate but clear: Felipe Contreras is (by far) a net liability to the Git project. Specifically: * The Git project will progress faster without you because the other contributors will have to waste less time dealing with your antics. * The Git community will grow faster without you, because your presence will not cause existing contributors to withdraw and dissuade new contributors from joining. * The community will be a lot more pleasant without you. Therefore, I am happy that you have apparently decided to split git-remote-hg into a separate project. I wish you success with the project and I see no reason that it shouldn't continue to be successful. But I am glad that I will not have to interact with you anymore. [...] Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will? Being the leader of your own valuable open-source project is nothing like jail. It is an opportunity for you to shine in an environment that is more suited to your personality. Given the huge amount of work I've put in these remote helpers, and the fact that Junio said since day 1 he wanted these in the core[5] (and I was operating under that assumption), I think the demotion back to the contrib area (and therefore out-of-tree) should be made carefully, and not from one day to he next as it happened. None of the work was wasted. git-remote-hg can live on. This email is written in sorrow, not in anger. Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, the whole balance would change entirely, and any software project would be happy to have you. With all my heart I truly wish you
Re: Should git-remote-hg/bzr be part of the core?
Michael Haggerty wrote: On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Saying you agree with Junio is content-free. You have to say *why* you agree. You mention there are good technical arguments against the graduation of the tools. Surely if you have analyzed those arguments enough to form an opinion aligned with Junio's, it should be easy to provide a short summary of those good technical arguments. Can you do that? 1. That subproject has not been maintained to the standards of the Git project; The quality of the subjproject has not been called into question, stop taiting the discussion with red herrings. 2. Moving git-remote-hg into the core would require even *more* of your presence on the Git mailing list. That's not true. I sent my patches at my own pace, it doesn't matter if they are in contrib or in the core, I would have kept sending them at the same pace. I have addressed all issues and responded to all questions as if they were already part of the core, which is why they have more quality than other tools already in the core. I only stopped doing that when Junio changed the direction we had since day one. Also a red herring. [...] Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will? Being the leader of your own valuable open-source project is nothing like jail. It is an opportunity for you to shine in an environment that is more suited to your personality. Don't be ridiculous. There is no out-of-tree tool that could possibly compete in popularity against core tools. If you think being out-of-tree is not a negative, lets throw out git-archimport, git-quiltimport, git-p4, git-cvs, git-svn. Let us give them an opportunity to shine. You know that those tools do better in the core, and you know git-remote-hg/bzr would do better in the core. Don't act as if you didn't. This email is written in sorrow, not in anger. Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, the whole balance would change entirely, and any software project would be happy to have you. With all my heart I truly wish you the best in your future endeavors. Let's see how sincere you are in your sentiment. I'll reply to you personally about the points that I consider to be red herrings and ad hominem attacks so we don't taint the dicussion. If you don't reply I'll know you were not being sincere. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should git-remote-hg/bzr be part of the core?
Michael Haggerty mhag...@alum.mit.edu writes: This email is written in sorrow, not in anger. Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, [...] I think that's where you are mistaken. We are not talking about a lack of effort here. It is just not spent conducively. -- David Kastrup -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should git-remote-hg/bzr be part of the core?
On 05/12/2014 12:37 PM, Felipe Contreras wrote: Michael Haggerty wrote: On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Saying you agree with Junio is content-free. You have to say *why* you agree. Actually, I don't have to, not even if you tell me to. And anyway, I think the small technical advantages/disadvantages of the possible different locations for git-remote-hg are dwarfed by the social considerations so I think dwelling on technical considerations would sidetrack this discussion. [...] 1. That subproject has not been maintained to the standards of the Git project; The quality of the subjproject has not been called into question, stop taiting the discussion with red herrings. On the contrary. I just called the quality of the subproject into question, and I stated exactly which aspects of its quality I find to be inadequate in the text that you omitted from your response: [...] specifically, Git project standards include good commit messages and a willingness to engage with the community on a friendly and constructive way and to welcome feedback. Because of your confrontational and nit-picking style, Felipe, many people who have tried to help you improve your work are rebuffed and end up giving up out of frustration or exhaustion. Because of this, your commits do not benefit from the usual amount of help from the community and therefore their quality is not as high as required for commits to core Git. Commit quality very definitely includes the quality of log messages and the quality of the discussion on the mailing list that can inform people working on those areas of the code in the future. 2. Moving git-remote-hg into the core would require even *more* of your presence on the Git mailing list. That's not true. I sent my patches at my own pace, it doesn't matter if they are in contrib or in the core, I would have kept sending them at the same pace. I have addressed all issues and responded to all questions as if they were already part of the core, which is why they have more quality than other tools already in the core. I only stopped doing that when Junio changed the direction we had since day one. Also a red herring. OK, maybe you are technically correct there. There is indeed a difference between and =. Let me amend my claim: 2. Moving git-remote-hg into the core would require you to continue your presence on the Git mailing list. [...] Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will? Being the leader of your own valuable open-source project is nothing like jail. It is an opportunity for you to shine in an environment that is more suited to your personality. Don't be ridiculous. There is no out-of-tree tool that could possibly compete in popularity against core tools. I never made that claim. I claimed that it was nothing like jail, and I stand by that claim. I also think that the Git community is a place unsuited to someone with your personality, and that you might truly shine more in an independent project. If you think being out-of-tree is not a negative, lets throw out git-archimport, git-quiltimport, git-p4, git-cvs, git-svn. Let us give them an opportunity to shine. In my opinion, the technical issues for moving importers are not overwhelming. Therefore, I don't have a strong opinion about the future of these other tools, because their presence in the Git tree is not coupled to the continued presence of a problematic subproject maintainer. You know that those tools do better in the core, and you know git-remote-hg/bzr would do better in the core. Don't act as if you didn't. I maintain cvs2svn/cvs2git outside of the Git core. In fact, one of cvs2git's competitors, git cvsimport *is* in Git core. Nevertheless, users have no problem finding cvs2git, and I think it's safe to say that its reputation exceeds that of git cvsimport, even though some people accidentally use git cvsimport out of laziness. People who need to do a conversion from A to B only have to Google for A B and they will find the best conversion tools pretty easily. If the tools are packaged for their OS then they are just an apt-get install away from happiness. And given that tools like cvs2git or git-remote-hg, don't even need to be compiled, users can install them pretty easily themselves. This email is written in sorrow, not in anger. Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, the whole balance would change entirely, and any software project would be happy
Re: Should git-remote-hg/bzr be part of the core?
Stefan Beller wrote: 2014-05-12 10:12 GMT+02:00 Felipe Contreras felipe.contre...@gmail.com: Felipe Contreras wrote: Linus Torvalds wrote: Felipe, stop this stupid blaming of everybody but yourself. Show me evidence that this decision was my fault. Junio certainly hasn't said so. You just have no idea what we are talking about. Here, let me show you. I suspect Linus had a reason not to include the mailing lists in the first place Huh? He did include the mailing lists in the first place[1]. Either something is wrong with the mailing list, or somebody is removing the mails. You can see the full thread in the git-fc mailing list, and there you can see the git ml is included in all the mails, including the one you just sent, where you included the git ml, and it doesn't show in the archives. and make a huge public discussion, but instead wrote to you personally. I guess this is just Linus desire not to waste the time of everybody as he learned that these discussions are fruitless sometimes. Don't you agree that including transparent bridges for Mercurial and Bazaar distributed by default would be benefitial to the project? If a discussion could potentially lead to them being included, I'd say that wouldn't be fruitless, but it's *precisely* what our end users would like us to be discussing right now. Junio C Hamano wrote [in another thread]: I would not mind asking the others, as your discussion tactic seems to be repeated voices start sounding like a chorus, and a chorus is project concensus. Those who are observing from the sideline, please raise your hand if you think the three-line Clarification Felipe gave us is a fair and accurate clarification. Anybody? I also do not mind seeing hands raised of those who do not agree, even though I already know that they would be a silent majority. I think Junio is behaving very professional unlike you, Felipe. This includes being polite and very patient. Also this includes weighting different reasons to make informed rational decisions. Where is he weighting the different reasons? I've asked him multiple times to provide those reasons. He mensions there's one, but he doesn't say which one it is. If I haven't see this reason, how do you know he is weighing different ones? Git being a project widely used and people trusting it for their work needs to have high quality and cannot go left today and go right tomorrow, but most of the decisions are done long-term. Yes. What is right, and what is left in this example? Presumably going right would be to include these tools in the core, but that would imply that he plans to go left in the future. But he hasn't said that. So what makes you think the project would go left in the future? Felipe, this may be the reason, why you think nothing changes. It's just slower than you'd like, but with more thoughts weighted. Really? I'll issue the same challenge I've issued to many people. Name a single important change in Git (was one way before, it's another way now) that has happened in the last 5 years. And by important I mean for starters users noticed it. You won't be able to, because nothing ever changes. Junio, I think you're doing an awesome job in maintaining Git and leading the community. Maintaining, yes, but leading? Leading it where? [1] https://groups.google.com/forum/#!original/git-fc/Clhss-fXS2k/9UtiilJ2WQ4J -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should git-remote-hg/bzr be part of the core?
Michael Haggerty wrote: On 05/12/2014 12:37 PM, Felipe Contreras wrote: Michael Haggerty wrote: On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Saying you agree with Junio is content-free. You have to say *why* you agree. Actually, I don't have to, Then there's no point in reading what else you have to say. Whatever reasons you might have to agree with Junio are known only to you, thus your agreement is opaque and meaningless. The quality of the subjproject has not been called into question, stop taiting the discussion with red herrings. On the contrary. I just called the quality of the subproject into question, and I stated exactly which aspects of its quality I find to be inadequate in the text that you omitted from your response: I'll wait until somebody else calls into question the quality. Preferably somebody who backs up his claims with evidence. OK, maybe you are technically correct there. There is indeed a difference between and =. Let me amend my claim: 2. Moving git-remote-hg into the core would require you to continue your presence on the Git mailing list. That is another red herring. Moving them back to the contrib/ area which is what Junio proposed would also require my presence on the list. Is that what you want? And there's the transport helper, and bash completion, and the zsh completion. [...] Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will? Being the leader of your own valuable open-source project is nothing like jail. It is an opportunity for you to shine in an environment that is more suited to your personality. Don't be ridiculous. There is no out-of-tree tool that could possibly compete in popularity against core tools. I never made that claim. I claimed that it was nothing like jail, and I stand by that claim. In the context of the Git project what is the *worst* thing the maintainer can do to a piece of code but delete it? So I think you are right, the jail analogy is not correct; it's *execution*. You know that those tools do better in the core, and you know git-remote-hg/bzr would do better in the core. Don't act as if you didn't. People who need to do a conversion from A to B only have to Google for A B and they will find the best conversion tools pretty easily. Let's test that hypothesis: Google: how to conver mercurial to git * Convert Mercurial project to Git - Stack Overflow (NOPE) * Converting a Mercurial repository to Git (YEAP: one among many) Oh, but would you look at that: This script will actually be shipping with git at some point, which gives it some credibility in my book. * frej/fast-export · GitHub (NOPE) * Hg-Git Mercurial Plugin (NOPE) * Converting Hg repositories to Git (NOPE) * Converting from Mercurial to Git - Hivelogic (NOPE) * Converting Repositories From Git to Mercurial (NOPE) * hg-fast-export: convert Mercurial repositories (NOPE) * Converting Mercurial (Hg) to Git Repository on Mac (NOPE) * Bitbucket: Converting Hg repositories to Git (NOPE) So pretty much hypoethesis failed. That fact that you would even think people would quickly find about git-remote-hg shows exactly how detached you are from the problem. If the tools are packaged for their OS then they are just an apt-get install away from happiness. Oh, they are packaged already (as part of Git). Moving them out-of-tree will make it much more difficult for users to find them, and install them. It will take time for them to be packaged, if it happens at all. Let's see how sincere you are in your sentiment. I'll reply to you personally about the points that I consider to be red herrings and ad hominem attacks so we don't taint the dicussion. If you don't reply I'll know you were not being sincere. Jumping at your every demand is not a prerequisite for being sincere. I spent a lot of time writing that mail. Not sincere it is then. -- Felipe Contreras-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should git-remote-hg/bzr be part of the core?
Paolo Ciarrocchi wrote: On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty mhag...@alum.mit.eduwrote: Felipe, you seem to have so much potential. If you would put as much effort in conducting social interactions as you do in coding, the whole balance would change entirely, and any software project would be happy to have you. With all my heart I truly wish you the best in your future endeavors. I really *love* this paragraph. Felipe, you are a brilliant developer and you put a lot of work trying to improve GIT. Thanks. While I agree with you the this project is managed in a bit conservative way Only a bit? I don't think I've been involed in a more conservative open source project. you should really improve how you communicate with other developers, it's such a pity your contributions are some times not included in git.git just because of your attitude. But that's a theory. You don't *know* that they would have been included had I used a different attitude. In fact, people have contacted me privately saying similar things, and I'll give you the same challenge I gave them. If you think a different attitude would get my patches in, how about *you* write the commit messages and the discussions for one of my stuck patch series. I'll send the mails as if I had written the content. If you are right, the different attitude would make the patches land in no time. I still think it's not right for patches to be rejected simply because of attitude, but I would accept you were right. But I think you already know that won't happen, the patches still won't get in, not because of the attitude, but because of what they are trying to do: change things. So if I *know* certain feature would be useful for Git users, I've listened to all the comments, and addressed all the problems, why would I give up on those patches? Why would I work on something more boring that won't benefit users as much but would have higher chances of getting in? I'm doing this on my own free time, I can choose to do whatever I want, in whatever way I want, so no, I'll keep working on what I think is important. If you really think the patches can be accepted with a different attitude, by all means, let's do the experiment and find out. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should git-remote-hg/bzr be part of the core?
Felipe Contreras felipe.contre...@gmail.com writes: Michael Haggerty wrote: On 05/12/2014 12:37 PM, Felipe Contreras wrote: Michael Haggerty wrote: On 05/12/2014 01:34 AM, Felipe Contreras wrote: Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Saying you agree with Junio is content-free. You have to say *why* you agree. Actually, I don't have to, Then there's no point in reading what else you have to say. Whatever reasons you might have to agree with Junio are known only to you, thus your agreement is opaque and meaningless. Let me spell it out for you. Michael states I agree with Junio. There are good technical arguments for and against moving git-remote-hg out of contrib. Since there are arguments for both sides, the decision boils down to a judgment call. Michael states that he condones the choice Junio made, based on the reasoning he gave. Does that mean that he examined the choice with equal detail and remembers every detail? No. In such a decision, both technical expertise as well as trust based on a past record factor in. The quality of the subjproject has not been called into question, stop taiting the discussion with red herrings. On the contrary. I just called the quality of the subproject into question, and I stated exactly which aspects of its quality I find to be inadequate in the text that you omitted from your response: I'll wait until somebody else calls into question the quality. Preferably somebody who backs up his claims with evidence. The evidence for the toxicity of dealing with subprojects maintained by you is all over the mailing list. You are obviously blind to it yourself. Feel free to print out a few salient threads where you argue in favor of your points and ask someone you trust about his impression about how you come across. Let's see how sincere you are in your sentiment. I'll reply to you personally about the points that I consider to be red herrings and ad hominem attacks so we don't taint the dicussion. If you don't reply I'll know you were not being sincere. Jumping at your every demand is not a prerequisite for being sincere. I spent a lot of time writing that mail. Not sincere it is then. That kind of exchange is what you should show some of your personal friends and ask them whether it will likely lead to the desired understanding and ultimately reaction in the reader. Because that is what communication is about. Of course, one can try bypassing understanding and directly aim for a particular reaction: that is being manipulative. You are hardly in danger of being manipulative: that would require a basic understanding of people. So all you can really aim for is understanding: presenting your best case. Forget about rhetorics and the like: you suck at them, and a technical audience is easily annoyed by them even when they are employed well. And if a calm presentation does not lead others to the same conclusion that you would draw, deal with the consequences. Throwing tantrums will only bias people against you when you have the next case to present. -- David Kastrup -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should git-remote-hg/bzr be part of the core?
On 05/12/2014 02:29 PM, Felipe Contreras wrote: Michael Haggerty wrote: [...] 2. Moving git-remote-hg into the core would require you to continue your presence on the Git mailing list. That is another red herring. Moving them back to the contrib/ area which is what Junio proposed would also require my presence on the list. Is that what you want? No, actually my preference is that git-remote-hg be separated from the Git project altogether, for the reasons that I stated earlier. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should git-remote-hg/bzr be part of the core?
On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Paolo Ciarrocchi wrote: On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty mhag...@alum.mit.eduwrote: While I agree with you the this project is managed in a bit conservative way Only a bit? I don't think I've been involed in a more conservative open source project. you should really improve how you communicate with other developers, it's such a pity your contributions are some times not included in git.git just because of your attitude. But that's a theory. You don't *know* that they would have been included had I used a different attitude. Well, you could at least try to act and communicate differently. In fact, people have contacted me privately saying similar things, and I'll give you the same challenge I gave them. If you think a different attitude would get my patches in, how about *you* write the commit messages and the discussions for one of my stuck patch series. I'll send the mails as if I had written the content. No, sorry but I'm NOT interested in lying to git community. Ciao, -- Paolo -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Error using git-remote-hg
Hello,
I have the following error while pushing to an hg repository though the remote
translator:
$ git remote -v
origin hg::ssh://charles...@hg.code.sf.net/u/charlesb05/lapdogapi (push)
origin hg::ssh://charles...@hg.code.sf.net/u/charlesb05/lapdogapi (fetch)
$ git push origin
Password:
searching for changes
no changes found
searching for changes
Traceback (most recent call last):
File /usr/local/bin/git-remote-hg, line 1254, in module
sys.exit(main(sys.argv))
File /usr/local/bin/git-remote-hg, line 1238, in main
do_export(parser)
File /usr/local/bin/git-remote-hg, line 1119, in do_export
if not push(parser.repo, peer, parsed_refs, p_revs):
File /usr/local/bin/git-remote-hg, line 1007, in push
ret = push_unsafe(repo, remote, parsed_refs, p_revs)
File /usr/local/bin/git-remote-hg, line 984, in push_unsafe
cg = repo.getbundle('push', heads=list(p_revs), common=common)
File /usr/local/lib/python2.7/site-packages/mercurial/repoview.py, line
217, in __getattr__
return getattr(self._unfilteredrepo, attr)
AttributeError: 'localrepository' object has no attribute 'getbundle'
I'm using git 1.9.3 on Mac OS X 10.9.2, with hg 3.0 installed with brew.
It used to work before, on this same repository, since then git and hg were
both upgraded.
Thanks for help,
—-
Charles
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should git-remote-hg/bzr be part of the core?
2014-05-12 15:45 GMT+02:00 Paolo Ciarrocchi paolo.ciarroc...@gmail.com: No, sorry but I'm NOT interested in lying to git community. It's not lying. See the Helped-By: lines in git.git commits. Often the help was formulating a correct and easy-to-understand commit message. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should git-remote-hg/bzr be part of the core?
Paolo Ciarrocchi wrote: On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Paolo Ciarrocchi wrote: On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty mhag...@alum.mit.eduwrote: While I agree with you the this project is managed in a bit conservative way Only a bit? I don't think I've been involed in a more conservative open source project. you should really improve how you communicate with other developers, it's such a pity your contributions are some times not included in git.git just because of your attitude. But that's a theory. You don't *know* that they would have been included had I used a different attitude. Well, you could at least try to act and communicate differently. I have, it doesn't make a difference. In fact, people have contacted me privately saying similar things, and I'll give you the same challenge I gave them. If you think a different attitude would get my patches in, how about *you* write the commit messages and the discussions for one of my stuck patch series. I'll send the mails as if I had written the content. No, sorry but I'm NOT interested in lying to git community. Yeah, that's what I thought. I know what the result of such experiment would be though. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Should git-remote-hg/bzr be part of the core?
Michael Haggerty wrote: On 05/12/2014 02:29 PM, Felipe Contreras wrote: Michael Haggerty wrote: [...] 2. Moving git-remote-hg into the core would require you to continue your presence on the Git mailing list. That is another red herring. Moving them back to the contrib/ area which is what Junio proposed would also require my presence on the list. Is that what you want? No, actually my preference is that git-remote-hg be separated from the Git project altogether, for the reasons that I stated earlier. Exactly. So your point 2. is completely irrelevant to the contrb/ vs. core debate. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Error using git-remote-hg
I'm using git 1.9.3 on Mac OS X 10.9.2, with hg 3.0 installed with brew. It used to work before, on this same repository, since then git and hg were both upgraded. In short: The remote helper of Git 1.9.3 is not compatible with hg 3.0 You can eiher downgrade hg, or rebuild Git and cherry-pick this commit: commit 58aee0864adeeb5363f2a06728596f9c9315811f Author: Felipe Contreras felipe.contre...@gmail.com Date: Sat May 3 21:16:54 2014 -0500 remote-hg: add support for hg v3.0 HTH /Torsten -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Error using git-remote-hg
Torsten Bögershausen wrote: I'm using git 1.9.3 on Mac OS X 10.9.2, with hg 3.0 installed with brew. It used to work before, on this same repository, since then git and hg were both upgraded. In short: The remote helper of Git 1.9.3 is not compatible with hg 3.0 You can eiher downgrade hg, or rebuild Git and cherry-pick this commit: No need to rebuild Git. You can also use the latest version: https://github.com/felipec/git-remote-hg -- Felipe Contreras-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Should git-remote-hg/bzr be part of the core?
Hi, Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind. I have repeatedly asked him to clarify what argument changed his mind, but he hasn't done so. Hopefully he will do that in this thread, but I'll jump ahead and assume it's this one by John Keeping[2]: I do not want to end up in a situation where an update to Git is blocked by a distribution because git-remote-hg is not updated to support newer versions of Mercurial sufficiently quickly; this previously happened in Gentoo due to git-svn and meant that was stuck on 1.7.8 until 1.7.13 was released [X]. Now, I feel I addressed this argument at length, specially in this thread [3], but I'll try to provide a summary of the strongest arguments against: 1) We can make the tests optional, say 't/optional'. So if they don't pass, the build of Git is not broken. Additionally, distributions might prefer to run test-essential if they don't want to run these optional tests. 2) There's already continuous integration builds[4] to make sure all the possible incoming changes in Mercurial are detected early on. 3) There has been a *single* case where a new Mercurial (3.0) broke things. This is due to the fact of how I implemented certain functionality due to limitations in Mercurial's API. Mercurial authors can be contacted to improve the API and minimize the possibility of it happening again. Given these arguments, I don't see how moving git-remote-hg to the core could possibly cause any problems, and I don't understand why Junio would think otherwise. Even if such a breakage causes a problem to the whole Git, it would make sense to demote these tools *when* such a problem comes (which I argue it won't). Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will? Given the huge amount of work I've put in these remote helpers, and the fact that Junio said since day 1 he wanted these in the core[5] (and I was operating under that assumption), I think the demotion back to the contrib area (and therefore out-of-tree) should be made carefully, and not from one day to he next as it happened. Thoughts? [1] http://article.gmane.org/gmane.comp.version-control.git/248676 [2] http://article.gmane.org/gmane.comp.version-control.git/248167 [3] http://article.gmane.org/gmane.comp.version-control.git/248683 [4] https://travis-ci.org/felipec/git [5] http://article.gmane.org/gmane.comp.version-control.git/220277 -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] git-remote-hg 0.2
Hi, git-remote-hg is a bidirectional bridge between Git and Mercurial. It is production-ready, has been widely tested, and was previously part of git.git. Junio C Hamano has retracted from his previous statements where he wanted these tools to become part of the Git core and distributed by default. It is obviously production ready so it doesn't belong in contrib/ either. Since there's no path forward, it has been split into a separate out-of-tree project. This will hurt our users, but it's better than having dubious prospects of when and how these tools will be part of the core, if such a thing was even possible to begin with. Changes from v1.9 upstream: * Add manpage * Fix regression that will become active in Git v2.0 * Do not fail on invalid bookmarks * Skip multiple heads (hg has such a thing) * Ported tests from gitifyhg * Add support for Mercurial v3.0 * Fixes for failed imports If you use ArchLinux, you can use the package I wrote[1]. Enjoy :) https://github.com/felipec/git-remote-hg Daniel Liew (1): Use internal clone's hgrc Felipe Contreras (22): Reorganize tests Add README build: add install target doc: add manpage Always normalize paths Fix parsing of custom committer Update to 'public' phase when pushing Store marks only on success Properly detect missing contexts test: split into setup test remote-hg: make sure we omit multiple heads Simplify hg-git regex Add more tests test: dd file operation tests test: trivial cleanups and fixes Add support for hg v3.0 test: trivial style cleanups test: fix redirection style travis: add initial configuration readme: fix link location test: add missing redirection Use python2 instead of python Max Horn (1): Do not fail on invalid bookmarks [1] https://aur.archlinux.org/packages/git-remote-hg/ -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] remote-helpers: add documentation for git-remote-hg/bzr
Mostly copied from my personal github wiki. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Documentation/git-remote-bzr.txt | 74 Documentation/git-remote-hg.txt | 121 +++ 2 files changed, 195 insertions(+) create mode 100644 Documentation/git-remote-bzr.txt create mode 100644 Documentation/git-remote-hg.txt diff --git a/Documentation/git-remote-bzr.txt b/Documentation/git-remote-bzr.txt new file mode 100644 index 000..b211e7f --- /dev/null +++ b/Documentation/git-remote-bzr.txt @@ -0,0 +1,74 @@ +git-remote-bzr(1) + + +NAME + +git-remote-bzr - bidirectional bridge between Git and Bazaar + + +SYNOPSIS + +[verse] +'git clone' bzr::bzr repository + + +DESCRIPTION +--- + +This tool allows you to transparently clone, fetch and push to and from Bazaar +repositories as if they were Git ones. + +To use it you simply need to use the 'bzr::' prefix when specifying a remote URL +(e.g. when cloning). + + +EXAMPLE +--- +-- +git clone bzr::lp:ubuntu/hello +-- + + +NOTES +- + +Remember to run `git gc --aggressive` after cloning a repository, specially if +it's a big one. Otherwise lots of space will be wasted. + +The oldest version of Bazaar supported is 2.0. Older versions are not tested. + +Branches vs. repositories +~ + +Bazaar's UI can clone only branches, but a repository can contain multiple +branches, and 'git-remote-bzr' can clone both. + +For example, to clone a branch: + +- +git clone bzr::bzr://bzr.savannah.gnu.org/emacs/trunk emacs-trunk +- + +And to clone the whole repository: + +- +git clone bzr::bzr://bzr.savannah.gnu.org/emacs emacs +- + +The second command would clone all the branches contained in the emacs +repository, however, it's possible to specify only certain branches: + +- +git config remote-bzr.branches 'trunk, xwindow' +- + +Some remotes don't support listing the branches contained in the repository, in +which cases you need to manually specify the branches, and while you can +specify the configuration in the clone command, you might find this easier: + +- +git init emacs +git remote add origin bzr::bzr://bzr.savannah.gnu.org/emacs +git config remote-bzr.branches 'trunk, xwindow' +git fetch +- diff --git a/Documentation/git-remote-hg.txt b/Documentation/git-remote-hg.txt new file mode 100644 index 000..0cceb76 --- /dev/null +++ b/Documentation/git-remote-hg.txt @@ -0,0 +1,121 @@ +git-remote-hg(1) + + +NAME + +git-remote-hg - bidirectional bridge between Git and Mercurial + + +SYNOPSIS + +[verse] +'git clone' hg::hg repository + + +DESCRIPTION +--- + +This tool allows you to transparently clone, fetch and push to and from Mercurial +repositories as if they were Git ones. + +To use it you simply need to use the 'hg::' prefix when specifying a remote URL +(e.g. when cloning). + + +EXAMPLE +--- + +$ git clone hg::http://selenic.com/repo/hello + + + +CONFIGURATION +- + +If you want to see Mercurial revisions as Git commit notes: + +-- +% git config core.notesRef refs/notes/hg +-- + +If you are not interested in Mercurial permanent and global branches (aka. commit labels): + +-- +% git config --global remote-hg.track-branches false +-- + +With this configuration, the 'branches/foo' refs won't appear. + +If you want the equivalent of `hg clone --insecure`: + +-- +% git config --global remote-hg.insecure true +-- + +If you want 'git-remote-hg' to be compatible with 'hg-git', and generate exactly the same commits: + +-- +% git config --global remote-hg.hg-git-compat true +-- + +NOTES +- + +Remember to run `git gc --aggressive` after cloning a repository, specially if +it's a big one. Otherwise lots of space will be wasted. + +The oldest version of Mercurial supported is 1.9. For the most part 1.8 works, +but you might experience some issues. + +Pushing branches + + +To push a Mercurial named branch, you need to use the branches/ prefix: + +-- +% git checkout branches/next +# do stuff +% git push origin branches/next +-- + +All the pushed commits will receive the next Mercurial named branch. + +*Note*: Make sure you don't have +remote
[PATCH 6/8] git-remote-hg: use internal clone's hgrc
From: Daniel Liew delcyp...@gmail.com
Use the hgrc configuration file in the internal mercurial repository in
addition to the other system wide hgrc files. This is done by using the
'ui' object from the 'repository' object which will have loaded the
repository hgrc file if it exists.
Signed-off-by: Dan Liew delcyp...@gmail.com
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
git-remote-hg.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-remote-hg.py b/git-remote-hg.py
index 1972f7f..cd3d79e 100755
--- a/git-remote-hg.py
+++ b/git-remote-hg.py
@@ -422,7 +422,7 @@ def get_repo(url, alias):
repo = hg.repository(myui, local_path)
try:
-peer = hg.peer(myui, {}, url)
+peer = hg.peer(repo.ui, {}, url)
except:
die('Repository error')
repo.pull(peer, heads=None, force=True)
--
1.9.2+fc1.3.gade8541
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-remote-hg : Enable use of, $GIT_DIR/hg/origin/clone/.hg/hgrc
Delcypher wrote:
What is the problem you are trying to solve?
The problem I was trying to solve is I wanted my authentication
details to be in a hgrc local to the repository.
The problem is git-remote-hg will parse
``.git/hg/origin/clone/.hg/hgrc`` but will ignore any settings in it
(this seems a little silly).
You can see that git-remote-hg parses this by placing invalid syntax
in the file.
Is there a way to test that this
code is working correctly?
The effects are much more obvious if you use a mercurial repository
that uses https and then you try to push to it with authentication
details in ``.git/hg/origin/clone/.hg/hgrc``. For example
[auth]
cc.prefix = hg.codeplex.com
cc.username = USERNAME
cc.password = PASSWORD
cc.schemes = https
pushing will fail because the authorisation details get completely
ignored and you will get an exception raised with a stack trace like
this...
Traceback (most recent call last):
File /home/dsl11/dev/git-remote-hg/git-remote-hg, line 1254, in module
sys.exit(main(sys.argv))
File /home/dsl11/dev/git-remote-hg/git-remote-hg, line 1238, in main
do_export(parser)
File /home/dsl11/dev/git-remote-hg/git-remote-hg, line 1119, in do_export
if not push(parser.repo, peer, parsed_refs, p_revs):
File /home/dsl11/dev/git-remote-hg/git-remote-hg, line 1007, in push
ret = push_unsafe(repo, remote, parsed_refs, p_revs)
File /home/dsl11/dev/git-remote-hg/git-remote-hg, line 990, in push_unsafe
return remote.unbundle(cg, remoteheads, 'push')
File /usr/lib/python2.7/site-packages/mercurial/wireproto.py, line
308, in unbundle
ret, output = self._callpush(unbundle, cg, heads=heads)
File /usr/lib/python2.7/site-packages/mercurial/httppeer.py, line
201, in _callpush
r = self._call(cmd, data=fp, headers=headers, **args)
File /usr/lib/python2.7/site-packages/mercurial/httppeer.py, line
171, in _call
fp = self._callstream(cmd, **args)
File /usr/lib/python2.7/site-packages/mercurial/httppeer.py, line
118, in _callstream
resp = self.urlopener.open(req)
File /usr/lib/python2.7/urllib2.py, line 410, in open
response = meth(req, response)
File /usr/lib/python2.7/urllib2.py, line 523, in http_response
'http', request, response, code, msg, hdrs)
File /usr/lib/python2.7/urllib2.py, line 442, in error
result = self._call_chain(*args)
File /usr/lib/python2.7/urllib2.py, line 382, in _call_chain
result = func(*args)
File /usr/lib/python2.7/urllib2.py, line 897, in http_error_401
url, req, headers)
File /usr/lib/python2.7/site-packages/mercurial/url.py, line 436,
in http_error_auth_reqed
self, auth_header, host, req, headers)
File /usr/lib/python2.7/urllib2.py, line 872, in http_error_auth_reqed
response = self.retry_http_basic_auth(host, req, realm)
File /usr/lib/python2.7/urllib2.py, line 878, in retry_http_basic_auth
user, pw = self.passwd.find_user_password(realm, host)
File /usr/lib/python2.7/site-packages/mercurial/url.py, line 36,
in find_user_password
raise util.Abort(_('http authorization required'))
mercurial.error.Abort: http authorization required
However, if you don't have a repository to hand you could also do the
following to observe the settings in the repository's hgrc being
respected
1. Clone a repository
$ git clone hg::https://hg.codeplex.com/boogie
2. Add setting to ``.git/hg/origin/clone/.hg/hgrc``
[ui]
quiet = True
3. With the current of git-remote-hg, when you do a pull you see
$ git pull
searching for changes
no changes found
Already up-to-date.
You can see that quiet is **not** being respected. If use my patch
to git-remote-hg and run again you see
$ git pull
Already up-to-date.
which shows quiet being respected.
This is what I get:
% git pull
/tmp/boogie[master] nysa
searching for changes
no changes found
Already up-to-date.
% cat .git/hg/origin/clone/.hg/hgrc EOF
[ui]
quiet = True
EOF
% git pull
/tmp/boogie[master] nysa
Already up-to-date.
So clearly there is something different on my side.
What version of Mercurial are you using?
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-remote-hg : Enable use of, $GIT_DIR/hg/origin/clone/.hg/hgrc
What version of Mercurial are you using? $ hg --version Mercurial Distributed SCM (version 2.9.2) (see http://mercurial.selenic.com for more information) Copyright (C) 2005-2014 Matt Mackall and others This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-remote-hg : Enable use of, $GIT_DIR/hg/origin/clone/.hg/hgrc
Delcypher wrote: What version of Mercurial are you using? $ hg --version Mercurial Distributed SCM (version 2.9.2) Same as me. And which version of git-remote-hg are you using? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-remote-hg : Enable use of, $GIT_DIR/hg/origin/clone/.hg/hgrc
Same as me. And which version of git-remote-hg are you using? I'm using the version that ships with git 1.9.2 I've taken a look and it seems I made a mistake, sorry. It seems that [ui] quiet = True is being respected when placed in ``.git/hg/origin/clone/.hg/hgrc`` with the un patched version of git-remote-hg. But it is still the case that authentication details are being ignored when present in ``.git/hg/origin/clone/.hg/hgrc`` i.e. something like the following is ignored. [auth] cc.prefix = hg.codeplex.com cc.username = USERNAME # Eurgh fixme this shouldn't live here. cc.password = PWD cc.schemes = https and pushing fails. An easy way of duplicating this is forking a project on codeplex (e.g. [1]), cloning that respository, making a trivial commit and then trying to push that commit to your fork. When I try this pushing fails because the authentication details are being ignored in ``.git/hg/origin/clone/.hg/hgrc``. Applying my patch (or your improved version using repo.ui instead of repo._unfilteredrepo.ui) fixes this for me. [1] https://boogie.codeplex.com/SourceControl/latest -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-remote-hg : Enable use of, $GIT_DIR/hg/origin/clone/.hg/hgrc
Delcypher wrote: Same as me. And which version of git-remote-hg are you using? I'm using the version that ships with git 1.9.2 I've taken a look and it seems I made a mistake, sorry. It seems that [ui] quiet = True is being respected when placed in ``.git/hg/origin/clone/.hg/hgrc`` with the un patched version of git-remote-hg. But it is still the case that authentication details are being ignored when present in ``.git/hg/origin/clone/.hg/hgrc`` i.e. something like the following is ignored. [auth] cc.prefix = hg.codeplex.com cc.username = USERNAME # Eurgh fixme this shouldn't live here. cc.password = PWD cc.schemes = https I see now, I've taken the patch with repo.ui and applied on my repo: https://github.com/felipec/git/commit/ee17fe1cf80d5196be382ebbbcb1a24c05e61658 If Junio wants to take that he can add my s-o-b. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-remote-hg : Enable use of, $GIT_DIR/hg/origin/clone/.hg/hgrc
I see now, I've taken the patch with repo.ui and applied on my repo: https://github.com/felipec/git/commit/ee17fe1cf80d5196be382ebbbcb1a24c05e61658 Thanks. It might be helpful to catch the exception raised if https authentication details are missing so that a more user friendly error message can be presented. I considered doing this but I wasn't entirely sure how to correctly do any necessary clean up. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-remote-hg : Enable use of, $GIT_DIR/hg/origin/clone/.hg/hgrc
What is the problem you are trying to solve?
The problem I was trying to solve is I wanted my authentication
details to be in a hgrc local to the repository.
The problem is git-remote-hg will parse
``.git/hg/origin/clone/.hg/hgrc`` but will ignore any settings in it
(this seems a little silly).
You can see that git-remote-hg parses this by placing invalid syntax
in the file.
Is there a way to test that this
code is working correctly?
The effects are much more obvious if you use a mercurial repository
that uses https and then you try to push to it with authentication
details in ``.git/hg/origin/clone/.hg/hgrc``. For example
[auth]
cc.prefix = hg.codeplex.com
cc.username = USERNAME
cc.password = PASSWORD
cc.schemes = https
pushing will fail because the authorisation details get completely
ignored and you will get an exception raised with a stack trace like
this...
Traceback (most recent call last):
File /home/dsl11/dev/git-remote-hg/git-remote-hg, line 1254, in module
sys.exit(main(sys.argv))
File /home/dsl11/dev/git-remote-hg/git-remote-hg, line 1238, in main
do_export(parser)
File /home/dsl11/dev/git-remote-hg/git-remote-hg, line 1119, in do_export
if not push(parser.repo, peer, parsed_refs, p_revs):
File /home/dsl11/dev/git-remote-hg/git-remote-hg, line 1007, in push
ret = push_unsafe(repo, remote, parsed_refs, p_revs)
File /home/dsl11/dev/git-remote-hg/git-remote-hg, line 990, in push_unsafe
return remote.unbundle(cg, remoteheads, 'push')
File /usr/lib/python2.7/site-packages/mercurial/wireproto.py, line
308, in unbundle
ret, output = self._callpush(unbundle, cg, heads=heads)
File /usr/lib/python2.7/site-packages/mercurial/httppeer.py, line
201, in _callpush
r = self._call(cmd, data=fp, headers=headers, **args)
File /usr/lib/python2.7/site-packages/mercurial/httppeer.py, line
171, in _call
fp = self._callstream(cmd, **args)
File /usr/lib/python2.7/site-packages/mercurial/httppeer.py, line
118, in _callstream
resp = self.urlopener.open(req)
File /usr/lib/python2.7/urllib2.py, line 410, in open
response = meth(req, response)
File /usr/lib/python2.7/urllib2.py, line 523, in http_response
'http', request, response, code, msg, hdrs)
File /usr/lib/python2.7/urllib2.py, line 442, in error
result = self._call_chain(*args)
File /usr/lib/python2.7/urllib2.py, line 382, in _call_chain
result = func(*args)
File /usr/lib/python2.7/urllib2.py, line 897, in http_error_401
url, req, headers)
File /usr/lib/python2.7/site-packages/mercurial/url.py, line 436,
in http_error_auth_reqed
self, auth_header, host, req, headers)
File /usr/lib/python2.7/urllib2.py, line 872, in http_error_auth_reqed
response = self.retry_http_basic_auth(host, req, realm)
File /usr/lib/python2.7/urllib2.py, line 878, in retry_http_basic_auth
user, pw = self.passwd.find_user_password(realm, host)
File /usr/lib/python2.7/site-packages/mercurial/url.py, line 36,
in find_user_password
raise util.Abort(_('http authorization required'))
mercurial.error.Abort: http authorization required
However, if you don't have a repository to hand you could also do the
following to observe the settings in the repository's hgrc being
respected
1. Clone a repository
$ git clone hg::https://hg.codeplex.com/boogie
2. Add setting to ``.git/hg/origin/clone/.hg/hgrc``
[ui]
quiet = True
3. With the current of git-remote-hg, when you do a pull you see
$ git pull
searching for changes
no changes found
Already up-to-date.
You can see that quiet is **not** being respected. If use my patch
to git-remote-hg and run again you see
$ git pull
Already up-to-date.
which shows quiet being respected.
Prior to this patch the mercurial repository's hgrc file was ignored
which I consider to be a bug.
It might be, although the internal repository is not supposed to be used by
the
user.
Signed-off-by: Dan Liew delcyp...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index eb89ef6..451842a 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -421,7 +421,7 @@ def get_repo(url, alias):
repo = hg.repository(myui, local_path)
try:
-peer = hg.peer(myui, {}, url)
+peer = hg.peer(repo._unfilteredrepo.ui, {}, url)
Why not repo.unfiltered.ui? Or just repo.ui.
using repo.unfiltered.ui makes git-remote-hg return ERROR: Repository error
Using repo.ui works correctly. I simply did not know that was there
because I was debugging using PyDev in Eclipse and I could only find a
ui object in repo.unfiltered.ui. PyDev does not show repo.ui but it
clearly works so using repo.ui is probably better than
repo._unfilteredrepo.ui
Thanks,
Dan Liew.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message
RE: git-remote-hg
Christophe wrote: I am using git-remote-hg to access to projects on bitbucket. I can clone the master branch fine and push to it. I also see hg branches as remotes/origin/branches/«branch». However, if I create a local branch branches/x and want to push it to remotes/origin/branches/x, it gets pushed to the remote master (aka default) branch. Which version of the script and Git are you using? If I do `git push origin branches/test` it works fine, I can see the branch in bitbucket. What is the recommended way of working with multiple branches when interacting with a remote hg repository? My recommendation is to avoid them (I don't see the point of them), but they should work. -- Felipe Contreras-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-remote-hg : Enable use of, $GIT_DIR/hg/origin/clone/.hg/hgrc
ping.
On 21 February 2014 15:17, Daniel Liew delcyp...@gmail.com wrote:
git-remote-hg : Enable use of, $GIT_DIR/hg/origin/clone/.hg/hgrc
Use the hgrc configuration file in the internal mercurial repository in
addition to the other system wide hgrc files. This is done by using the
'ui' object from the 'repository' object which will have loaded the
repository hgrc file if it exists.
Prior to this patch the mercurial repository's hgrc file was ignored
which I consider to be a bug.
Signed-off-by: Dan Liew delcyp...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index eb89ef6..451842a 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -421,7 +421,7 @@ def get_repo(url, alias):
repo = hg.repository(myui, local_path)
try:
-peer = hg.peer(myui, {}, url)
+peer = hg.peer(repo._unfilteredrepo.ui, {}, url)
except:
die('Repository error')
repo.pull(peer, heads=None, force=True)
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-remote-hg : Enable use of, $GIT_DIR/hg/origin/clone/.hg/hgrc
git-remote-hg : Enable use of, $GIT_DIR/hg/origin/clone/.hg/hgrc
Use the hgrc configuration file in the internal mercurial repository in
addition to the other system wide hgrc files. This is done by using the
'ui' object from the 'repository' object which will have loaded the
repository hgrc file if it exists.
Prior to this patch the mercurial repository's hgrc file was ignored
which I consider to be a bug.
Signed-off-by: Dan Liew delcyp...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index eb89ef6..451842a 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -421,7 +421,7 @@ def get_repo(url, alias):
repo = hg.repository(myui, local_path)
try:
-peer = hg.peer(myui, {}, url)
+peer = hg.peer(repo._unfilteredrepo.ui, {}, url)
except:
die('Repository error')
repo.pull(peer, heads=None, force=True)
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git-remote-hg
Hi, I am using git-remote-hg to access to projects on bitbucket. I can clone the master branch fine and push to it. I also see hg branches as remotes/origin/branches/«branch». However, if I create a local branch branches/x and want to push it to remotes/origin/branches/x, it gets pushed to the remote master (aka default) branch. What is the recommended way of working with multiple branches when interacting with a remote hg repository? Best, C. P.S. The remote helper also prints many lines like: error: Object 4a83cec050af8749b3eacc9da9b216350bb86c07 already has a mark -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-remote-hg: Fix . at end of ref
Any Mercurial tag/branch/bookmark that ended with a period would be
rejected by fast-import. The repository could be cloned, but any
further fetch would fail.
Use a similar trick to the space handling, but only when the period is
at the end of the ref.
Probably need a more general solution to this problem.
Signed-off-by: Brian Gernhardt br...@gernhardtsoftware.com
---
contrib/remote-helpers/git-remote-hg | 2 ++
1 file changed, 2 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 0194c67..7fa6cd7 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -78,9 +78,11 @@ def hgbin(n):
return node.bin(n)
def hgref(ref):
+ref = re.sub('_\._$', '.', ref)
return ref.replace('___', ' ')
def gitref(ref):
+ref = re.sub('\.$', '_._', ref)
return ref.replace(' ', '___')
def check_version(*check):
--
1.8.3.1.636.g893104c
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-remote-hg: set stdout to binary mode on win32
Felipe Contreras felipe.contre...@gmail.com writes:
Sorry Amit, I assumed this patch made it to the list, but I just
realized it didn't; it doesn't allow HTML, and mails and silently
dropped (I hate that).
So I'm sending it so the list can see it:
It seems OK for me, but I would like to try it, and so far I haven't
managed to access Mercurial libraries at all from python scripts in
Windows. What steps did you follow?
Thanks for keeping an eye on this part of the system. It seems that
having an extra -rc cycle turned out to be not so bad an idea.
On Mon, Jan 28, 2013 at 4:13 PM, Amit Bakshi ambak...@gmail.com wrote:
git clone hangs on windows (msysgit/cygwin), and
file.write would return errno 22 inside of mercurial's
windows.winstdout wrapper class. This patch sets
stdout's mode to binary, fixing both issues.
---
contrib/remote-helpers/git-remote-hg | 21 +
1 file changed, 21 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 328c2dc..95f4c1f 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -62,6 +62,24 @@ def get_config(config):
output, _ = process.communicate()
return output
+#
+# On Windows (msysgit/cygwin) have to set stdout to binary
+# mode (_O_BINARY is 32768). Otherwise clone hangs, and pushing
+# to remote fails when doing a write to mercurial's wrapper
+# windows.winstdout wrapper class.
+#
+def set_binmode(fd):
+try:
+if sys.platform == win32:
+import msvcrt
+msvcrt.setmode(fd, os.O_BINARY)
+elif sys.platform == 'cygwin':
+import ctypes
+msvcrt = ctypes.CDLL('msvcrt.dll')
+msvcrt._setmode(fd, 32768) # On Cygwin os.O_BINARY is different
+except OSError:
+pass
+
class Marks:
def __init__(self, path):
@@ -764,6 +782,9 @@ def main(args):
else:
is_tmp = False
+if sys.platform in ['win32','cygwin']:
+set_binmode(sys.stdout.fileno())
+
gitdir = os.environ['GIT_DIR']
dirname = os.path.join(gitdir, 'hg', alias)
branches = {}
--
1.8.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-remote-hg: set stdout to binary mode on win32
On Mon, Jan 28, 2013 at 4:13 PM, Amit Bakshi ambak...@gmail.com wrote:
git clone hangs on windows (msysgit/cygwin), and
file.write would return errno 22 inside of mercurial's
windows.winstdout wrapper class. This patch sets
stdout's mode to binary, fixing both issues.
---
contrib/remote-helpers/git-remote-hg | 21 +
1 file changed, 21 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 328c2dc..95f4c1f 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -62,6 +62,24 @@ def get_config(config):
output, _ = process.communicate()
return output
+#
+# On Windows (msysgit/cygwin) have to set stdout to binary
+# mode (_O_BINARY is 32768). Otherwise clone hangs, and pushing
+# to remote fails when doing a write to mercurial's wrapper
+# windows.winstdout wrapper class.
+#
+def set_binmode(fd):
+try:
+if sys.platform == win32:
+import msvcrt
+msvcrt.setmode(fd, os.O_BINARY)
+elif sys.platform == 'cygwin':
+import ctypes
+msvcrt = ctypes.CDLL('msvcrt.dll')
+msvcrt._setmode(fd, 32768) # On Cygwin os.O_BINARY is different
+except OSError:
+pass
I tried many things, and it seems it's true that we need to set the
binary mode in Windows, but it seemed to work fine cygwin. I saw in
many places the workaround for 'win32', but I didn't find the one for
'cygwin'. Where did you find it? Did you test in cygwin? Is it needed
there?
Cheers.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: User experience: git-remote-hg
[+CC: Felipe, the author and maintainer of the script] Samuel Chase wrote: I just used git-remote-hg to convert a small hg repository. It worked perfectly. We'll be happy to address any deficiencies/ warts you find in everyday usage. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-remote-hg: set stdout to binary mode on win32
Hi,
Sorry Amit, I assumed this patch made it to the list, but I just
realized it didn't; it doesn't allow HTML, and mails and silently
dropped (I hate that).
So I'm sending it so the list can see it:
It seems OK for me, but I would like to try it, and so far I haven't
managed to access Mercurial libraries at all from python scripts in
Windows. What steps did you follow?
On Mon, Jan 28, 2013 at 4:13 PM, Amit Bakshi ambak...@gmail.com wrote:
git clone hangs on windows (msysgit/cygwin), and
file.write would return errno 22 inside of mercurial's
windows.winstdout wrapper class. This patch sets
stdout's mode to binary, fixing both issues.
---
contrib/remote-helpers/git-remote-hg | 21 +
1 file changed, 21 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 328c2dc..95f4c1f 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -62,6 +62,24 @@ def get_config(config):
output, _ = process.communicate()
return output
+#
+# On Windows (msysgit/cygwin) have to set stdout to binary
+# mode (_O_BINARY is 32768). Otherwise clone hangs, and pushing
+# to remote fails when doing a write to mercurial's wrapper
+# windows.winstdout wrapper class.
+#
+def set_binmode(fd):
+try:
+if sys.platform == win32:
+import msvcrt
+msvcrt.setmode(fd, os.O_BINARY)
+elif sys.platform == 'cygwin':
+import ctypes
+msvcrt = ctypes.CDLL('msvcrt.dll')
+msvcrt._setmode(fd, 32768) # On Cygwin os.O_BINARY is different
+except OSError:
+pass
+
class Marks:
def __init__(self, path):
@@ -764,6 +782,9 @@ def main(args):
else:
is_tmp = False
+if sys.platform in ['win32','cygwin']:
+set_binmode(sys.stdout.fileno())
+
gitdir = os.environ['GIT_DIR']
dirname = os.path.join(gitdir, 'hg', alias)
branches = {}
--
1.8.1
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
gitifyhg vs. git-remote-hg
Hi, In a recent e-mail[1] it was suggested that gitifyhg and git-remote-hg had many differences, and that some users might be best served by using gitifyhg. While that e-mail was answered properly, I would like to point out what are the actual differences that affect users, not the ones that are particular to the state of the code this week, but rather the ones that are inherent due to the design and/or development process. First of all, it's worth mentioning that much of the code of gitifyhg was simply copied from git-remote-hg. One example is the get_filechanges() function which was introduced in v6 of the initial patch series[2], after extensive profiling. The gitifyhg developers simply copied the function without mentioning where it came from. And like this one, there are numerous examples. == Code changes == In terms of design, they are vastly similar (not surprising since gitifyhg is based on remote-hg), however remote-hg tries to have a minimal code-base, avoid hacks, and tries to minimize and isolate changes to avoid regressions -- as is typical for git.git code --, whereas gitifyhg tries to introduce features as soon as possible, and fix the possible issues later on. A succint example is the introduction of a custom function to write tags: https://github.com/buchuki/gitifyhg/commit/9a89296 Then the inevitable fixes come (some after a major version was released): https://github.com/buchuki/gitifyhg/commit/8cd638b https://github.com/buchuki/gitifyhg/commit/1ce980a https://github.com/buchuki/gitifyhg/commit/885dd84 Contrast with the single commit in remote-hg, which is simpler, cleaner, passes the same tests, and still, it's not merged, nor on the queue (it's on the 'next' branch): https://github.com/felipec/git/commit/b565809 == Development practices == Each patch of remote-hg is reviewed in the git.git mailing list before being merged to the mainline, the stages are: fc/remote/hg-next - fc/master (patch review) - pu - next - master. On the other hand, gitifyhg doesn't have patch review through a mailing list[4], nor different development branches; everything is committed to 'master'. Features are important for users, but more important than features is that what used to work continues to work, and in the same way, and remote-hg's practices help to achieve that. == Testing == It's impossible to test all Mercurial repositories, or even a significant chunk of them, which is why it's a good idea to rely on the testing and gathered tricks of other conversion projects. By far the most widely used tool is hg-git, which already has a decent test cases, it makes sense then to use these tests cases and make sure that the output of a conversion tool matches the one of hg-git, and that's exactly what remote-hg does. gitifyhg has continuous testing, but it's more important to have the right tests. == Features == All the features of gitifyhg have been implemented in remote-hg, with the exception of push rollback. However, this feature is not needed if only certain commits are pushed; this way there's no need to rollback the previous commits that failed; they would be simply ignored for the next push. Here are the commits that implement them: Notes: https://github.com/felipec/git/commit/e7234dc Noteids (SHA-1): https://github.com/felipec/git/commit/663704d Changing alias: https://github.com/felipec/git/commit/316c330 The first two will be merged, but the last one won't; we can choose either the alias or the URL as a unique identifier, and choosing the alias makes more sense. This means as a user, there's no reason to use gitifyhg, since the same features are available in remote-hg. And as a developer, one can simply pick these missing patches (one?) and maintain a friendly fork. To make sure that remote-hg can indeed act like gitifyhg for all intents and purposes I created a branch to do so: https://github.com/felipec/git/tree/fc/remote/hg-gitifyhg-compat The changes are minimal: contrib/remote-helpers/git-remote-hg | 57 ++--- 1 file changed, 34 insertions(+), 23 deletions(-) After these patches, gitifyhg's test suite passes **all** the tests (except a trivial one). == Minor differences == What follows are some tedious comparisons between both test suites, and an explanation about the difference. = remote-hg = == cloning with branches == -next -refs/heads/next +zero +refs/heads/master remote-hg closes the current branch (next), gitifyhg doesn't. == cloning with bookmarks == -feature-a -refs/heads/feature-a +zero +refs/heads/master remote-hg closes the current bookmark (feature-a), gitifyhg doesn't. == authors == H G Wells we...@example.com -test unknown -test t...@example.com +test +test t...@example.com (comment) Unknown t...@example.com name t...@example.com name t...@example.com -test unknown +test test t...@example.com test t...@example.com -test unknown
