@durin42 Here's the implementation of this method we are using in Eden:
Dec 11 2017
Dec 7 2017
D1347 did not address the issue because we still want to subclass it in Eden. If you're curious, you can see exactly what we're doing in https://github.com/facebookexperimental/eden-hg/blob/master/eden/hg/eden/eden_dirstate_map.py.
Nov 13 2017
@durin42 The issue is that dirstatemap is doing so much "stuff" beyond just storage that Eden prefers to subclass it rather than copy/paste all of the business logic.
Nov 9 2017
Nov 3 2017
Oct 31 2017
What test verifies this behavior? Do we need a new one?
Oct 7 2017
Sep 15 2017
Sep 14 2017
Sep 9 2017
Sep 2 2017
Sep 1 2017
Remove bin/bash shebang as @quark says this should fix the FreeBSD issue and should generally be banned from integration tests.
Added integration test.
Aug 31 2017
Anything else I can do for this?
Aug 30 2017
Removed realpath in favor of $TESTTMP/editor.sh. Now hg init in the current directory instead of a subdirectory.
Address "don't export and assign at once" issue.
Added an integration test to verify editor filenames.
Aug 29 2017
Also, it looks like I would have to refactor ui.edit() quite a bit to create a unit test since the file name never escapes the method and that's what you would like me to verify, right?
@ryanmce I'm happy to write a test, but what do you want me to target: ui.edit() itself?
Remove extra dot in action for diff as caught by @ryanmce.
@durin42 Note that I substantially revised the commit message and test plan to reflect the changes.
Aug 28 2017
Changed format string to .%s.hg.txt.
Created optional action param as suggested by @durin42
@durin42 I believe we've come to a resolution on this thread that this is fine as-is, so are you OK to take this now?
@durin42 Sounds good: I'll work on cleaning this up.
Aug 24 2017
Aug 23 2017
@smf so are you OK with this patch as-is?
@smf As I put in the summary, I think this use of tempfile.mkstemp() is different than the others in the codebase because it uses the dir= argument to create a file in the working copy. As such, I'd argue that it's reasonable to consider it separately from the others.
@quark Rather than exposing the additional keyword argument now, why don't we wait until there is a compelling use-case to use something other than ~? As it stands, creating an API for this would just open things up to misuse.