Posts tagged with “github”

Tired of Git Branch Case Sensitivity? Here's a Fix for Git Bash Users

Hey fellow devs! Here’s a small but super useful Git trick for dealing with that annoying branch case sensitivity issue. You know the drill—someone creates feature/UserAuth, but you type feature/userauth. On a case-sensitive OS, Git tells you the branch doesn’t exist. On a case-insensitive OS like Windows or macOS, it’s worse—you switch to the wrong branch without realizing it. Later, you discover both feature/userauth and feature/UserAuth exist on GitHub. Ouch.

This is particularly painful when working with Windows or macOS, where the filesystem is case-insensitive, but Git isn't. Add in a mix of developers with different habits (some love their CamelCase, others are all-lowercase fans), and you've got yourself a daily annoyance.

The Fix

I wrote a little Git alias that makes checkout case-insensitive. It's basically a smarter version of git checkout that you use as git co. Here's what it does:

$ git co feature/userauth
⚠️ Warning: "feature/userauth" is incorrect. Switching to: "feature/UserAuth"
Switched to branch 'feature/UserAuth'

Nice, right? No more "branch not found" errors just because you got the case wrong!

Important Note ⚠️

This works in:

  • Windows Git Bash (tested and used daily)
  • Should work in macOS/Linux (though I haven't tested it - let me know if you try!)

But it won't work in:

  • Windows CMD
  • Windows PowerShell
  • Any other Windows terminals

Why? Because it uses Bash commands and parameters. But hey, you're using Git Bash anyway, right? 😉

How to Install

Just run this in Git Bash:

git config --global alias.co '!f() {
  # If no args or help flag, show git checkout help
  if [ $# -eq 0 ] || [ "$1" = "-h" ] || [ "$1" = "--help" ]; then
    git checkout --help;
    return;
  fi;
  # If any flags are present (except -q or --quiet), pass through to regular checkout
  if [ $# -gt 1 ] || [[ "$1" == -* && "$1" != "-q" && "$1" != "--quiet" ]]; then
    git checkout "$@";
    return;
  fi;
  # Pass through if argument is a commit reference (HEAD, SHA, tag, etc)
  if [[ "$1" =~ ^HEAD([~^]|@{)[0-9]*$ ]] || # HEAD~1, HEAD^1, HEAD@{1}
     [[ "$1" =~ ^(FETCH_HEAD|ORIG_HEAD|MERGE_HEAD)$ ]] || # Special refs
     [[ -f ".git/refs/tags/$1" ]]; then # Tags
    git checkout "$@";
    return;
  fi;
  # Fetch and prune to ensure we have latest refs
  git fetch --prune --quiet;
  # Check both remote and local branches
  correct_branch=$(git branch -r | sed "s/^  origin\///" | grep -i "^$1$");
  if [ -z "$correct_branch" ]; then
    correct_branch=$(git branch | sed "s/^[* ] //" | grep -i "^$1$");
  fi;
  # If branch found with different case, warn and use correct case
  if [ -n "$correct_branch" ] && [ "$1" != "$correct_branch" ]; then
    echo "⚠️ Warning: \"$1\" is incorrect. Switching to: \"$correct_branch\"";
    git checkout "$correct_branch";
    return;
  fi;
  # Otherwise just pass through to regular checkout
  git checkout "$1";
}; f'

What's Cool About It?

  • Finds your branch regardless of how you type the case
  • Still works normally for everything else (files, creating branches, etc.)
  • Shows you the correct branch name when you get the case wrong
  • Auto-fetches to make sure it sees all remote branches

The best part? If it doesn't recognize what you're trying to do, it just passes everything to regular git checkout. So it won't break any of your normal Git workflows.

Real World Usage

I use this daily in a Windows-heavy dev team where we have branches like:

  • feature/UpdateUser
  • hotfix/FixLoginBug
  • release/v2.0.0

And now I can type them however I want. Life's too short to remember exact branch capitalization!

Give It a Try!

If you're using Git Bash on Windows and tired of case sensitivity issues, give this a shot. It's one of those small tools that just makes your day a tiny bit better.

And hey, if you try this on macOS or Linux, let me know how it goes! Always curious to hear if these tricks work in other environments.

GitHub: Persist "Hide whitespace" preference across PRs

Default 'Hide whitespace' can significantly save your time on reviewing. Many many developers have asked for this feature for a long time, but GitHub still doesn't officially support it. You don't have to wait. This small browser extension GitHub Whitespace comes to rescure!

gh pr view can't find PR just created

TLDR;

The solution is git push -u

David.Wei @ /d/git/xemt-core/dfx - [feature/mt-38546-axo] $ git push -u
branch 'feature/mt-38546-axo' set up to track 'origin/feature/mt-38546-axo'.
Everything up-to-date
David.Wei @ /d/git/xemt-core/dfx - [feature/mt-38546-axo] $ gh pr view
MT-38546 Fintrac API| DFX DB changes #1355
Open • David-Wei_euronet wants to merge 6 commits into integration from feature/mt-38546-axo • about 3 days ago
...

vilmibm wrote the following on this issue and it reminds me why I couldn't find the PR:

gh pr view relies on mapping the current locally checked out branch to a remote tracking branch so that the github host can be queried appropriately for PR data; in your example it seems like you're creating PRs without any configured tracking information, making it impossible for gh to open the PR.

To avoid this issue happening in the future, you can run the following command to enable the auto tracking feature.

git config --global push.autoSetupRemote true

If your git version is lower and couldn't upgrade easily, another measure is to create an alias like the following

git config --global alias.p 'push -u origin HEAD'

Then always use git p instead of git push will do the trick.

A memo: Using GitHub actions to deploy a project to your VPS

Today, I created another workflow file to deploy my side project to the production environment. Here's a simple memo for what I have done.

  1. Setup a new domain name on <cloudflare.com>

  2. Setup a GitHub runner on the target VPS (this step is not really necessary, I can use an existing runner, but then I'll need to cope with coping built result to the target VPS )

    1. Setup the runner as a service, in the runner folder, run

      1. sudo ./svc.sh install
      2. sudo ./svc.sh start
  3. Create a work-flow file in the .github/workflow folder, and set

      on:
        workflow_dispatch
    
  4. Manually run the work flow and deploy the project to the target place

  5. Setup that project as a systemd service so we can easily restart it in the workflow file

For your reference, here the whole workflow file, and as I mentioned before, this article helped me a lot.

name: Deploy to the production env

# Controls when the workflow will run
on:
  workflow_dispatch:

jobs:
  deploy:
    # Our previously created self-hosted runner
    runs-on: [self-hosted, linux, racknerd]

    strategy:
      matrix:
        dotnet: ["8.0.x"]

    # A sequence of tasks that will execute as part of the job
    steps:
      # Checks out repository so our job can access it
      - uses: actions/checkout@v4
      - name: Setup .NET Core SDK ${{ matrix.dotnet-version }}
        uses: actions/setup-dotnet@v4
        with:
          ref: ${{ github.event.inputs.tag }}
          dotnet-version: ${{ matrix.dotnet-version }}

      - name: Install dependencies
        run: dotnet restore

      - name: Build
        run: dotnet build --configuration Release --no-restore

      - name: Publish
        run: dotnet publish -c Release --property:PublishDir=/a-target-folder/HappyNotes.Api

      - name: Replace credentials
        run: |
          pwd
          sed -i "s/password-placeholder/${{ secrets.PRODUCTION_MYSQL_PASSWORD }}/g" /a-target-folder/HappyNotes.Api/appsettings.json
          sed -i "s/symmetric-security-key-placeholder/${{ secrets.PRODUCTION_SYMMETRIC_SECURITY_KEY }}/g" /a-target-folder/HappyNotes.Api/appsettings.json
          sed -i "s/staging-happynotes-api.dev/happynotes-api/g" /a-target-folder/HappyNotes.Api/appsettings.json

      - name: Restart the app
        run: |
          echo $XDG_RUNTIME_DIR
          export XDG_RUNTIME_DIR=/run/user/$(id -u)
          systemctl --user restart HappyNotes.Api.service

Change Github TABSIZE to 4 and make code review easier

Have you ever seen weird indentations when doing code review? Mostly, the cause is that GitHub's default TABSIZE setting is 8 instead of 4 while some old code uses TAB for indentation. Fortunately, we can easily fix it by change this setting. 8 is not an ideal default TABSIZE nowadays, right? so it is all GitHub's fault!

Reference