GITFNS GIT-MAKE-PROJECT requires a non-NIL WORKINGPATH when documentation says optional

[nbriggs]

Having checked out loops into /Users/briggs/Projects/loops, doing

(GIT-MAKE-PROJECT "LOOPS" "{dsk}<Users>briggs>Projects>loops")

produces an error, "Can't find the working directory for LOOPS".

The documentation says "WORKINGPATH is optionally the local path to ...", and "When the project has a WORKINGPATH ..."

[rmkaplan]

Yes, that’s fixed in the GITFNS PR that hasn’t yet been approved.

On Jul 13, 2022, at 1:06 PM, Nick Briggs @.***> wrote:

Having checked out loops into /Users/briggs/Projects/loops, doing

(GIT-MAKE-PROJECT "LOOPS" "{dsk}<Users>briggs>Projects>loops") produces an error, "Can't find the working directory for LOOPS".

The documentation says "WORKINGPATH is optionally the local path to ...", and "When the project has a WORKINGPATH ..."

— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/831, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJJZ6QM7XJXEGUFBY6DVT4OVHANCNFSM53P5F6MQ. You are receiving this because you are subscribed to this thread.

[nbriggs]

It's not mentioned in the notes for either of the two open PRs.

[nbriggs]

Do these PRs also fix prc move-files LOOPS failing with Unknown branch origin/move-files when

briggs@macrobiotic loops % git branch -r
  origin/HEAD -> origin/main
  origin/fix-loopsbackwards-src
  origin/fix-loopsuid-again
  origin/loops-cleanup-1
  origin/loops-sources-with-compiled
  origin/main
  origin/more-temp
  origin/move-files
  origin/remove-outdated-DFASLs
  origin/update-gauge-dfasls

after saying "Comparing all Medley subdirectories of origin/move-files and origin/master", when there is no origin/master in the loops repo and there IS an origin/move-files.

[rmkaplan]

I think the master-main thing was intended to be fixed in one of the previous versions, the glitch fixed in the current PR is because the previous calculation of the mainbranch was being done at the wrong time. Now it is done when you ask for it, not when you create the project. (I hope)

On Jul 13, 2022, at 1:26 PM, Nick Briggs @.***> wrote:

Do these PRs also fix prc move-files LOOPS failing with Unknown branch origin/move-files when

@.*** loops % git branch -r origin/HEAD -> origin/main origin/fix-loopsbackwards-src origin/fix-loopsuid-again origin/loops-cleanup-1 origin/loops-sources-with-compiled origin/main origin/more-temp origin/move-files origin/remove-outdated-DFASLs origin/update-gauge-dfasls after saying "Comparing all Medley subdirectories of origin/move-files and origin/master", when there is no origin/master in the loops repo and there IS an origin/move-files.

— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/831#issuecomment-1183644607, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJKULTFYVUVXTD7AOXLVT4RALANCNFSM53P5F6MQ. You are receiving this because you commented.

[nbriggs]

For the failing prc it seems to think it's working in the medley repo instead of the loops repo, even though I did

(GIT-MAKE-PROJECT "LOOPS" "{dsk}<Users>briggs>Projects>loops" "{dsk}/tmp")

and passed LOOPS as the second argument to prc.

[nbriggs]

Related, I think: doing bbc origin/move-files origin/main LOOPS ends up in GIT-BRANCH-EXISTS? with

BRANCH     origin/move-files
NOERROR   NIL
PROJECT   (GIT-PROJECT MEDLEY {GMEDLEY} NIL ...)

instead of the LOOPS project. Also, it doesn't seem to matter if it's LOOPS or (LOOPS) it gets the same result, and it doesn't seem to care if the project has ever been defined -- it just uses the MEDLEY project.

[rmkaplan]

Try it with an atom and not a string: (GIT-MAKE-PROJECT ‘LOOPS …)

LMK

On Jul 13, 2022, at 1:39 PM, Nick Briggs @.***> wrote:

For the failing prc it seems to think it's working in the medley repo instead of the loops repo, even though I did

(GIT-MAKE-PROJECT "LOOPS" "{dsk}<Users>briggs>Projects>loops" "{dsk}/tmp") and passed LOOPS as the second argument to prc.

— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/831#issuecomment-1183656024, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJO4Q6DBCT373RQOKJTVT4SRLANCNFSM53P5F6MQ. You are receiving this because you commented.

[nbriggs]

Atom or string doesn't make a difference, still goes for the MEDLEY project. GIT-PROJECTS has only the LOOPS project defined, but GIT-DEFAULT-PROJECT is 'MEDLEY. Changing GIT-DEFAULT-PROJECT to 'LOOPS lets it get further, but then bbc origin/move-files origin/main LOOPS dies because it has decided that the origin/main branch it should be looking at is called origin/HEAD -> origin/main which indeed is part of the git branch output, but it's showing that origin/HEAD is the same as origin/main and origin/main comes later in the list.

[rmkaplan]

Hmm, with my (current) GITFNS, I tried

prc LOOPS draft

It showed me 2 PR’s, I chose move-files, and it said it was doing all subdirectories of origin/move-files and origin/main. Is there something that I should be doing to deal with the HEAD issue?

But it then eventually went into the process-stream hang before it completed. The only reason I’m reading from the process stream is to detect whether there was an error (the last command in the sequence is always "echo COMPLETE”). And I’m trying to read that only if the error stream is empty.

Is there a way for me just to read the exit code of the process, instead of reading the stream?

Or, instead of trying to read the completion-token, would it be safe just to detect a potential error by the fact that the error stream was nonempty, and avoid ever reading the process stream?

On Jul 13, 2022, at 2:17 PM, Nick Briggs @.***> wrote:

Atom or string doesn't make a difference, still goes for the MEDLEY project. GIT-PROJECTS has only the LOOPS project defined, but GIT-DEFAULT-PROJECT is 'MEDLEY. Changing GIT-DEFAULT-PROJECT to 'LOOPS lets it get further, but then bbc origin/move-files origin/main LOOPS dies because it has decided that the origin/main branch it should be looking at is called origin/HEAD -> origin/main which indeed is part of the git branch output, but it's showing that origin/HEAD is the same as origin/main and origin/main comes later in the list.

— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/831#issuecomment-1183687045, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJO7WFTF7N3TCBQYGC3VT4W5PANCNFSM53P5F6MQ. You are receiving this because you commented.

[nbriggs]

GITFNS.TEDIT says the syntax for "prc" is

prc (branch) (DRAFT) (projectname)

This compares the files in branch against the files in the main branch of the project

So that's not the correct syntax?

[rmkaplan]

That’s also the correct syntax. I think I look around to try to make sense of it in whatever order (probably because I couldn’t remember—DWIM).

On Jul 13, 2022, at 4:24 PM, Nick Briggs @.***> wrote:

GITFNS.TEDIT says the syntax for "prc" is

prc (branch) (DRAFT) (projectname)

This compares the files in branch against the files in the main branch of the project So that's not the correct syntax?

— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/831#issuecomment-1183777283, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJPVAKZF3FSEJHSSFADVT5F3PANCNFSM53P5F6MQ. You are receiving this because you commented.

[masinter]

long conversation, I can't tell what the status is. Reopen or new issue if there's still something to do.