[issue16930] mention limitations and/or alternatives to hg graft

Brett Cannon added the comment: With the migration to git pending, this won't be worth the effort. -- nosy: +brett.cannon resolution: -> out of date status: open -> closed ___ Python tracker

[issue16930] mention limitations and/or alternatives to hg graft

Changes by Carol Willing willi...@willingconsulting.com: -- assignee: - willingc nosy: +willingc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16930 ___

[issue16930] mention limitations and/or alternatives to hg graft

Terry J. Reedy added the comment: 16.6 is just what I was suggesting. I had not read that far in the revised version. But I am glad I did to find out about auto-commit. There have been issues where I would not want that. (I will check to see if commit is really 'alwats' or if there is an

[issue16930] mention limitations and/or alternatives to hg graft

Ezio Melotti added the comment: (I will check to see if commit is really 'alwats' or if there is an option to not commit, as with import and merge.) There isn't AFAIK, but two tricks I use are: 1) hg diff -c tip to check the diff of what I just grafted; 2) hg rollback to rollback the

[issue16930] mention limitations and/or alternatives to hg graft

Chris Jerdonek added the comment: The first and/or main place that recommends hg graft should link to the section with more detail for cases where users experience problems with graft. I also agree that the section should mention the case-folding error. I'm using a pretty new version of hg

[issue16930] mention limitations and/or alternatives to hg graft

Chris Jerdonek added the comment: Why must we mention graft at all? I've never had a need for it. It seems simpler and just as effective to run `hg import` on the original patch. I think it's preferable that the steps we recommend to work on all systems. Then we won't have to worry about

[issue16930] mention limitations and/or alternatives to hg graft

Antoine Pitrou added the comment: Why must we mention graft at all? I've never had a need for it. It seems simpler and just as effective to run `hg import` on the original patch. `hg graft` actually works in some cases where `hg import` will fail, because grafting uses the merge logic (so,

[issue16930] mention limitations and/or alternatives to hg graft

Ezio Melotti added the comment: Also I often made changes on the patch I imported and applied on 2.7 (e.g. update Misc/NEWS). Reimporting the patch means that I would have to do it again, and both hg import --no-c url_of_the patch and hg export 2.7 | hg import - are more complicated than hg

[issue16930] mention limitations and/or alternatives to hg graft

Chris Jerdonek added the comment: If you start with a patch against 3.x, which is the normal case, why go to the trouble of grafting from the patch modified for 2.7? It seems you're just creating more trouble for yourself (introducing more conflicts you have to resolve, etc) when you already

[issue16930] mention limitations and/or alternatives to hg graft

Ezio Melotti added the comment: Because if the graft succeeds hg graft 2.7 does everything (including porting extra modifications that I made before committing on 2.7 and the commit on 3.2), if there are conflicts I just spend a few seconds more in kdiff3 to fix them. Reapplying the patch

[issue16930] mention limitations and/or alternatives to hg graft

Chris Jerdonek added the comment: Reapplying the patch means that I have to do import + commit at least, and possibly reapply manually changes that I've already done on 2.7. Since 2.7 is more different from 3.2 than is 3.4, it seems more likely that grafting from 2.7 to 3.x will result in

[issue16930] mention limitations and/or alternatives to hg graft

Terry J. Reedy added the comment: As a member of the devguide target audience, I think for this the devguide should give alternatives with brief pluses and minuses. After importing and applying a patch to the earliest applicable 2.x or 3.x, move it to the other series with graft (new,

[issue16930] mention limitations and/or alternatives to hg graft

Ezio Melotti added the comment: I think for this the devguide should give alternatives with brief pluses and minuses. Something like http://docs.python.org/devguide/committing.html#porting-changesets-between-the-two-major-python-versions-2-x-and-3-x ? :) --

[issue16930] mention limitations and/or alternatives to hg graft

Antoine Pitrou added the comment: To clarify my original comment, I got an error about ConfigParser.py/configparser.py even when that file was not part of the change. Would you mind reporting a Mercurial bug then? (http://bz.selenic.com/) As for mentioning it in the devguide, I don't think

[issue16930] mention limitations and/or alternatives to hg graft

Ezio Melotti added the comment: http://docs.python.org/devguide/committing.html#porting-changesets-between-the-two-major-python-versions-2-x-and-3-x now mentions both hg graft and hg export|import. Do you think this is enough or should we add a link to

[issue16930] mention limitations and/or alternatives to hg graft

New submission from Chris Jerdonek: In various places, the devguide recommends `hg graft`, but it appears it might not be possible to use on some systems or in certain situations. For example, when I tried grafting a trivial change from 2.7 to 3.2 on Mac OS X, I got the following fatal

[issue16930] mention limitations and/or alternatives to hg graft

Changes by Ezio Melotti ezio.melo...@gmail.com: -- dependencies: +Update cloning guidelines in devguide stage: - needs patch type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16930

[issue16930] mention limitations and/or alternatives to hg graft

Ned Deily added the comment: Keep in mind that the issue isn't which operating system is used; it's whether the file system(s) on which the hg repo resides is (are) case-insensitive or case-sensitive. Most modern operating systems (including OS X) support both file system types and on Unix-y

[issue16930] mention limitations and/or alternatives to hg graft

Terry J. Reedy added the comment: Windows preserves case when writing a filename but ignores it when searching and opening filenames. IE, if I have tem.py and try to save TEM.py (from IDLE), it says 'tem.py exists, overwrite?'. So will or will not that be a problem for graft with 2.7/3.x

[issue16930] mention limitations and/or alternatives to hg graft

Chris Jerdonek added the comment: To clarify my original comment, I got an error about ConfigParser.py/configparser.py even when that file was not part of the change. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16930