As aliases

alias g-log="git log --graph --format='format:%C(yellow)%h%C(reset) %s %C(magenta)%cr%C(reset)%C(auto)%d%C(reset)'"
alias g-history='gitk --all &'
alias g-checkout='git checkout $(git branch --sort=-committerdate --no-merged | fzf)'
alias g-commit='git citool &'
alias g-amend='git citool --amend &'
alias g-rebase='git rebase --interactive --autosquash'
alias g-pull='git pull --verbose --rebase'
alias g-pushf='git push --verbose --force-with-lease'
alias g-status='git status --ignored'
alias g-clean='git clean -fdx && git reset --hard && git submodule foreach --recursive git clean -fdx && git submodule foreach --recursive git reset --hard'
  • porous_grey_matter
    link
    fedilink
    arrow-up
    3
    ·
    edit-2
    9 months ago

    So you never stumbled upon bugs while doing work

    That’s not what I said… Either the bug is related to the task, or it isn’t. If it’s not related to the task, there’s no reason to fix it on the same local branch either.

    Also, some teams do care about building their work on atomic commits, because they understand the problems caused by mixing up unrelated work on the same PR, specially when auditing changes to track where a regression was introduced. You might feel it’s ok to post a PR that does multiple things like bumping up a package version, linting unrelated code, fixing an issue, and post comments on an unrelated package, but others know those are four separate PRs and should be pushed as four separate PRs.

    Well, these things don’t meet the standards of your earlier example at all. Linting unrelated code and posting comments on an unrelated package clearly aren’t needed for someone to work on the main issue fix they’re doing. If it’s unrelated code you again lose nothing by switching branches to do the work.