-
-
Notifications
You must be signed in to change notification settings - Fork 27
Adjustments to GITFNS #2321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Adjustments to GITFNS #2321
Conversation
prc status is C if changes requested, prc comparison runs in its own process, initial changes for gwc to treat the clone as UNIX, not DSK, so branch-switching doesn't cause files from other branches to pile up.
On Linux Mint 22.1 Cinnamon I checked out this branch up to commit 301c4f7, ran
![]() The backtrace:
The
I use the apps sysout and I'm on nhb-rewrite-version-parser-v2/60e12da of Maiko. |
I notice that the branch it's working with is |
Yes, I may have gotten out of step during the MCCS PR delay. But I don't yet understand why it appears to fail only when it is working on the master side.
… On Oct 21, 2025, at 10:37 AM, Nick Briggs ***@***.***> wrote:
nbriggs
left a comment
(Interlisp/medley#2321)
<#2321 (comment)>
I notice that the branch it's working with is BRANCH2 "origin/fgh¬lfg-loadup", though the actual name is fgh_lfg-loadup -- notice the underscore (0x5F) vs logical not (0xC2AC). I'm guessing that the MCCS translations are somehow involved (unexpectedly missing, or unexpectedly present)
—
Reply to this email directly, view it on GitHub <#2321 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJNX4WG5XJIMR75JGE33YZVNVAVCNFSM6AAAAACJYALFB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMRYGE3DKMBYHE>.
You are receiving this because you authored the thread.
|
The low-level function is issuing a git command to retrieve the contents of a particular file, which it then stores in a local tmp/ file. It is called first to obtain the file from master, then to obtain the corresponding file from the pr. For this particular pr, PROCESS-COMMAND gets an error code 128 when it tries to retrieve the master but it gets a code 0 when it asks for the version of the file in the pr. Here are the actual (MCCS) command strings given to PROCESS-COMMAND: For the master file (fails): For the pr file (succeeds): Note the (MCCS) underscore (0,255) in the string passed to PROCESS-COMMAND for the pr but not for the master, so you would think that that one might fail. But streams on the SHELL-DEVICE default to :UTF-8, and that appears to be working as expected--it does seem to find the file. I don't understand why the master command fails just for this pr. Any ideas? |
I inserted the offending command in a terminal window, and finally got a helpful error message: the path scripts/loadup-app-setup.sh does not exist. So it the problem is probably at a higher level, where it is interpreting the ADD return from the difference function, not at the bottom character level. Another mystery: how did it ever work? |
That's a new file, it doesn't exist in master, so git is saying (try it in a Terminal in the medley directory)
and if we just look at what changed between the two branches --
So in one commit he added the files, then in the second commit he modified them. Did GITFNS get confused by the modification vs addition? |
This is what comes back from the call to GIT-BRANCH-DIFF in GIT-GET-DIFFERENT-FILES: This is based on the result of the ind-copies-harder command, which returns a file with lines So I don't see any residue of the modify commit. So suppose that it is correct that the modify is not relevant and the Add is the only thing it should pay attention to. Then what may be special about this particular pr is that the app-setup file exists only in that pr subdirectory and not in the master (because it was added). Since this pr has no other files in that subdirectory, the later attempt at enumeration sees a nonexistent directory and fails. |
Something is being too smart --
If you copy a file to a different name, the target name may well be a new file. I don't know that it's guaranteed to be new (it could be being replaced, I suppose) but... in this case it IS a new file based on a old file. |
On reflection, the most obvious approach would be for GITFNS to treat git-copy as a git-add of the target file. The comparison won't tell you where the new file came from (presumably git transfers the history on a copy?), but that's not relevant for the compare. The merge would do whatever it would do wrt history. That now behaves well in my working directory, and I can commit an updated GITFNS. But I think that, because of the underscore, it won't work for Frank's old pr until the MCCS filename pr gets approved and merged. |
prc status is C if changes requested, prc comparison runs in its own process, initial changes for gwc to treat the clone as UNIX, not DSK, so branch-switching doesn't cause files from other branches to pile up.