#4 `subbash/prompt`: No commits yet on master

I’ve recently created a new git repo from terminal and haven’t yet committed anything.

My (our? ;)) prompt in this case looks like this (I’ve included the command that fails to show the branch name, which is master):

[ 7.48pm]0 ts@ts-kubuntu:[bg:3] [No ]?28 ~/docs/ofcl/otto/cv
$ git status --porcelain -b
## No commits yet on master...origin/master [gone]
?? .editorconfig
# Some other files removed from this output

I could create a new PR, however, I’ve got no idea what is the best solution for this.

Following https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-check-ref-format.html rule 4), one option might be to modify the grep -oP '^## \K([a-zA-Z0-9_-]+)(?=.*)')" (I did some refactoring yesterday) on line 127 to anchor against a leading ^##.* (has a space) and an ending \.{3,}.*$. I'll tinker with this a bit, as this seems the best solution for matching the branch in both usecases that I can think of at the moment.

This should be fixed by commit 708d77c

I might not get your fix, however it outputs an empty srring with exit code 1. Here’s how to reproduce it:

$ mkdir aaa
$ cd aaa
$ git init
# This last command outputs nothing with exit code 1
$ git status --porcelain -b 2>/dev/null | tr '\n' ':' | \
  grep -oP '^##.* \K([a-zA-Z0-9_-]+)(?=\.{3,}.*$)'

Anyway, this grep command interests me: could you tell me what it does? What is the \K for? Does it do some replacement? What does exactly do the last part ((?=\.{3,}.*$))? I see you used Pearl regexp, however, I’ve never used it and have no idea how it changes grep’s behaviour in comparison with the pure GNU grep.

The \K removes/drops/deletes all content in the match prior to the \K. It deals with some limitations of regex lookbehind

The (?=) is used to match, but not return what was matched in it. It is part of regex lookahead.

If I was using gawk, I would skip both as I could just use a capture group and use the contents of the capture group. I chose not to use gawk as I want the prompt to work in almost every environment it could be dropped in. Doing some further testing, I should have realized that the -P is a GNU flag... so now I'll probably need to roll back some of that change. sigh

Thank you for the explanation. :)

so now I'll probably need to roll back some of that change.

Is the reason for the (possible) revert the compatibility (‘I want the prompt to work in almost every environment it could be dropped in.’) or that you use different brand grep?

The revert will be for posix command compatibility on most environments. Grep's -P flag does not appear to be posix. I will make sure that I address the bug, it just will not be as succinct of a oneliner.

I'm currently leaning towards a posix:
awk 'match($0,/ [a-zA-Z0-9_-]+\.{3,}/) {print substr($0,RSTART+1,RLENGTH-4)}'

The RSTART+1 chops off the space from the result, while the RLENGTH-4 chops off the periods (3) and the offset from RSTART (1).

EDIT: BAH! this might still be a gawk-ism (not posix) EDIT2: ok, I just need to not use brace expansion. \.\.\. instead of the \.{3,}

Both the original issue and the posix issue should be fixed with commit 18ed7efdcc.

Currently, I’m out of reach of my computer, therefore I couldn’t test it with the repo I encountered the issue first. However, I’ve tested it in Termux. The message does not have to have elipsis:

# When there are no files added to the repo
$ git status --porcelain -b 2>/dev/null | tr '\n' ':'
## No commits yet on master:

$ touch sss
# When there is new file
$ git status --porcelain -b 2>/dev/null | tr '\n' ':'                                                           
## No commits yet on master:?? sss:

I guess I'll try to stop over thinking, an use a git command that does the right job: git rev-parse --abbrev-ref HEAD 2>/dev/null.

Sorry, had been basing my tests off the string you had given, and had not thought to actually test against a new repo. This will say 'HEAD' in a freshly init'ed repo.

At this point I'm probably going to redo the whole git section of the prompt to use git status --porcelain=2 -b 2>/dev/null, which will be easier to regex.

yawn ok, I think that the porcelain v2 refactoring might have allowed everything aside from a HEAD detach to be ok :)

Thought I guess I should consider adding a prompt output for Added, Deleted, Renamed, and Copied. (the first two of which seem the more useful)

(1) Current command (git status --porcelain=2 -b 2>/dev/null | tr '\n' ':' | awk 'match($0,/# branch.head [^ :]+/) {print substr($0,RSTART+14,RLENGTH-14)}') works as expected.

(2) If you renamed GBra to GBranch and GCol to GColor, don’t you should rename all other vars with similar name pattern (like GDel)?

(3) By prompt output for Added, Deleted, Renamed, and Copied you mean what? Added where—to current working dir or stage or commit? (etc)

Btw, I’m glad you have time like all day to deal with this issue. :)

For 2) I am considering a slight adjustment to the color codes, so I didn't bother changing the variables yet.

For 3) all Modified/Untracked/Deleted/Renamed/Copied statuses are pre-commit (at least as I understand). You can see https://git-scm.com/docs/git-status for more info.

(3) I see. Your terminology confused me. :) … The files/folders can be (using official terminalogy):

• untracked,
• staged (probably corresponding to your added; sometimes also called cached),
• modified,
• deleted,
• renamed.

They cannot be copied (as a status). When you copy a file or dir, the new file/dir becomes untracked.