Skip to main content

Repository & Activity Tracking

Use this guide when developers see missing development activity in the Portal or the IDE shows:

  • "You are working on files outside of tracked repositories for CodeTogether"
  • Activities are not appearing even though the repository is configured in the CodeTogether Portal

Symptoms and what they usually mean

"You are working on files outside of tracked repositories for CodeTogether"

CodeTogether cannot match the local cloned repository to a repository configured in the CodeTogether Portal.

Common causes:

  • The remote URL does not match what is configured in the Portal.
  • The repository was added in the Portal under a different team/project.
  • Git URL rewrite/alias rules change the effective remote URL (e.g., insteadOf).
  • The repo provider is not GitHub and URL normalization/secondary ID matching can fail more often.

Activities not appearing

This is usually caused by missing or mismatched Git email on the developer workstation (recent builds rely on Git email for membership matching).

Also note:

  • If a developer has no recent commits, they may not appear active until at least one commit is synced.

Step 1 — Verify repository remote URL matches the Portal

On the developer machine, run from inside the repo:

git remote -v
git remote get-url --push origin

In the Portal:

  • Confirm the repository is listed under the correct team/project
  • Compare the Portal repository URL with the developer origin URL

Watch for common mismatches:

  • Different host (e.g., github.com vs an enterprise Git host)
  • Organization/repo name casing differences
  • Redirected clone URLs

Optional: check for URL rewrite/alias rules

These can change the effective URL:

git config --global --get-regexp 'url\..*\.insteadof' || true

If the repo looks correct but still isn’t recognized

Collect the repository’s .git/config (or at least the [remote "origin"] section) and confirm:

  • The origin URL matches what’s configured in the Portal
  • The repo points to the expected host and repository path
  • No URL aliasing rules are rewriting the URL unexpectedly

Step 2 — Verify Git email is set and matches the Portal profile

On the developer machine:

git config user.email
git config --global user.email

If both are empty, the developer may appear as private and activity may not map to the correct user.

Set the email:

git config --global user.email "developer@company.com"

Confirm email matches in the Portal

In the Portal, open the developer profile and check:

  • Primary email / SSO email
  • Any alternate emails

The email returned by the Git commands must match at least one email on the profile.

If it does not:

  • Update the Git config email to match the Portal, or
  • Add the Git email as an alternate email in the Portal

Also check repo-level configuration (source of truth)

The email can be set in either location:

  • Global: ~/.gitconfig
  • Repo-specific: ${project}/.git/config

To see where user.email is coming from:

git config --list --show-origin | grep -i user.email || true

If no user.email exists in either config, the developer will always appear as private.


Environment notes

Snapshot environments (anonymized)

Anonymized snapshots may contain placeholder users and do not include valid user emails. In these cases, matching relies heavily on the developer machine Git configuration (user.email) and Portal profile emails.

WSL (Windows Subsystem for Linux)

If the developer uses WSL, ensure Git is configured inside WSL, not only in Windows:

# Run inside the WSL terminal
git config --global user.email

What to collect for support (minimum)

Ask for outputs from:

  • git remote -v
  • git remote get-url --push origin
  • git config user.email
  • git config --global user.email
  • git config --global --get-regexp 'url\..*\.insteadof' || true

If needed, include the relevant section of the repo’s .git/config showing [remote "origin"].