Programming

17389 readers

144 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 1 year ago

MODERATORS

[email protected]

Advanced git commands every senior software developer needs to know (optimizedbyotto.com)

submitted 8 months ago by [email protected] to c/[email protected]

42 comments fedilink hide all child comments

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'

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 3 points 8 months ago* (last edited 8 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.