fatal error messages with git-radar on local untracked branches

[michaeldfallen]

fatal error messages with git-radar on local untracked branches

[iiro]

Same problem here...

[hallzy]

Don't think I have the same problem with local untracked branches, but I did see this same error message yesterday when I made a new github repo.

I created the repo on github (repo is empty, no readme etc), I then cloned it. When I enter the repo this message appears, and continues to appear until I have pushed something.

Same similar in that it would be untracked until pushing, but I seem to only see it for new repos.

I am on Ubuntu

[hallzy]

I think I have pinpointed my problem, and perhaps it is similar for everyone else...

in radar-base.sh there are two git commands that cause my error to come up which are:

git rev-list --right-only --count ${remote_branch}...HEAD
git rev-list --left-only --count ${remote_branch}...HEAD

This command lists the commit objects in reverse chronological order...

The first one (right only) lists the commit objects in reverse order of HEAD in this case, and --left-only does the same but for whatever my ${remote_branch} happens to be... in this case, origin/master

I am guessing the error is because there are no objects in a new repo.

So if we are going to fix this, probably will need a check on the git commands to make sure there is actually something to read, or force an ignore of the error messages...

I noticed in some functions nearby that similar calls are appended by "2>/dev/null || printf '%s' "0""... If we do the same, this will probably go away (for me at least).

Maybe you can check if these are the same calls that are causing problems for you?

What also seems weird about the output you have provided is that the branch it displays is "./master...HEAD"... I have not seen a ./ in a branch before so this could be something else.

Question for the owner: is there a reason that the two calls mentioned above (in functions: commits_ahead_of_remote and commits_behind_of_remote) do not have 2>/dev/null appended, or is this something we can add easily (Just wondering if there is any actual reason that we would not want to add this).

NOTE: I tried appending the 2>/dev/null etc to those two lines mentioned, and the problem does go away for me

[michaeldfallen]

Yep, I think @hallzy has it. An empty repo causes this problem. Appending 2>/dev/null fixes.

@thomasdziedzic It should also fix your problem, though the remote reference seems screwy. Can you run the following commands:

> git config --get "branch. some-branch.merge"
> git config --get "branch. some-branch.remote"

(assuming your branch is called some-branch)

You should see ref/heads/some-branch as the merge and origin as the remote. If they aren't like that then that might be what's going on. Either a bad sed on git-radars part or a misconfigured remote on your repo?

[thomasdziedzic]

@michaeldfallen looks like the issue for me might be a misconfigured remote

both of the commands don't print out anything

$ git config --get "branch. some-branch.merge"
$ git config --get "branch. some-branch.remote"

do you have suggestions on how to fix this?

$ git remote -v
origin  [email protected]:Org/repo.git (fetch)
origin  [email protected]:Org/repo.git (push)

looks correct to me

[c5f]

@hallzy Your fix also solves #88 but in a seemingly error-squashing way. I am trying to figure out if I would like to be notified if one of my tracked branches gets deleted, and burying the error in the bitbucket doesn't leave much room for options there. Adding a check for tracked branches' existence and adding more emoji would be cool. 🎉🎊🐬🐳

This is totally up to @michaeldfallen, and I admit the consideration for error handling within a small utility like this may be overkill. radar-base.sh already uses /dev/null in several places (git grep -e \/dev\/null), so I am a-OK with closing #88 if the error is just buried.

---

@thomasdziedzic There should be no space between branch. and the branch name. You can also take a look inside your repository's .git/config file to see how each branch is setup. This is what your some-branch configuration should look like on a remote that is not misconfigured according to @michaeldfallen's comment:

[branch "some-branch"]
    remote = origin
    merge = refs/heads/some-branch

This function is responsible for retrieving remote branch information and fetches the remote information from your git configuration. Misconfigured branches would cause odd behavior in there.

[thomasdziedzic]

I got the following:

$ git checkout -b some-branch
Branch some-branch set up to track local branch master.
Switched to a new branch 'some-branch'

$ git config --get "branch.some-branch.merge"
refs/heads/master

$ git config --get "branch.some-branch.remote"
.

[michaeldfallen]

@thomasdziedzic sorry about that, I added a space by accident. Yeah that remote config doesn't look right. it should be a name of a remote. Not entirely sure how we fix this. Can you check that the branches are properly configured when you clone a different repo and run git checkout -b new-branch; git push -u origin new-branch?

[michaeldfallen]

@colinsf nice catch with the extra space. My mistake 😞.

[michaeldfallen]

@colinsf the "missing remote branch" indicator you mentioned is interesting. We have the upstream ⚡my-branch to do just that but it only seems to care if its not "set upstream". I suppose rather than squashing the error outputting that would be more informative to the user?

[c5f]

"Interesting" is about where I left off thinking about it as well. Maybe throw it into a future feature?