Hacker News Reader

> ... `goops file`, it adds the file, amends the last commits and force pushes the branch

Note that you should only ever do this if you are absolutely sure that you are the only person pushing to that branch.

You should consider using "--force-with-lease" instead of "--force". Otherwise you'll sooner or later overwrite a coworker's push without a trace. Maybe they'll notice know Git good enough to fix this, but it would still be very, very annoying.

EDIT: Changed "repository" to "branch", mention "--force-with-lease".

Definitely, don't force push unless you know what you are doing and the implications of force pushing. On the other hand don't blindly listen to people who tell you that force pushing is bad and should always be avoided

You can use --force-with-lease

push --force-with-lease can mitigate accidental overwrites though

Thanks for the hint. I wasn't aware of that option.

> Note that you should only ever do this if you are absolutely sure that you are the only person pushing to that repository.

I would revise this to say the only person pushing to that branch. But yeah.

you'll sooner or later overwrite a coworker's push without a trace

This is the kind of thing that makes it hard to see why git has become the One True DVCS - you can not just overwrite history but actually lose other people's work quite easily (presumably the commit also vanishes from their repo when they next pull?)

I think that's an unfair characterisation of git. Pretty much everything you can read online recommends against force pushing and it's definitely not part of any workflow recommended to beginners. Even with a force pushed branch when the person whose work has been overwritten tries to pull the pull will get reject and they'll retain the local copies of their commits. It's possible to resolve this problem as long as the person with overwritten commit doesn't delete their local copies.

Force pushing is super powerful when you learn to use git properly, but it's also like a gun with no safety so it's easy to shoot yourself in the foot if you don't know what you are doing.

No, the commit doesn't just vanish when they pull. They'll be asked to reconcile their local repo with the diverged upstream.

I agree, Mercurial is a lot better in this regard.

Note that you should only ever do this if you are absolutely sure that you are the only person pushing to that branch.

I've worked with multiple orgs where the convention for shared repos was to use branch names of the form <user>/<topic>, e.g. bowie/pipeline-v2. Such "user" branches should generally never be pushed to by anyone other than the dev they were named for. This has worked great to allow individuals to have visibility and/or backups of work-in-progress while avoiding lossage due to any branch cleanup prior to PR, etc.

Alternatively, if you like to stay close to the git commands themselves (which is very helpful when helping colleagues), use a git shell such as git sh¹.

After starting the git shell in the terminal (just git sh for the eponymous program) all command are simply the same as in git, only without git in front of them (so add, push, etc.). Aliases work as expected of course, so st for status, and d for diff are possible too.

These type of shells have the added benefit of a status prompt showing the basic git info, such as current branch and number of commits ahead or behind the tracked branch.

1: https://github.com/rtomayko/git-sh

I use scm_breeze[0] which adds these shortcuts + has numbered file shortcuts, which allow you to type 'ga 1 3' to add files 1 and 3 (numbers are shown by 'gs' - git status).

[0] https://github.com/ndbroadbent/scm_breeze

What does the `git add -A "$@"` do? I tried it just now, and it was equivalent to doing `git add .` (although I am using bash instead of ZSH). I have this alias for myself: `git commit -a --amend --no-edit && git push --force-with-lease`, which isn't perfect but close enough.

You can pass arguments so `goops app tests` only adds files in app and tests

Cool thanks! I just got that working for myself, with the extra logic of doing `git add -u` if there were no arguments.

I don't use aliases for the main git functions because they are easy enough to type anyway, a good idea to remember, and many of these operations are not things you want to do accidentally because of a split-second typo. The only exception is 'gs' for 'git status' because I use that more-or-less reflexively and it's completely safe.

What I do have is loads of aliases for getting different logs and graphs, because all the sensible formatting options are impossible to remember. I would be lost without these. Straight from my bash profile:

  # Quick summary git log variants (with and without hash, with condensed whitespace or tabs)
  alias 'gl=git --no-pager log --pretty=tformat:"%ad %an: %s" --date=short -n 15'
  alias 'gll=git --no-pager log --pretty=tformat:"%ad %h %an: %s" --date=short -n 15'
  alias 'glxl=git --no-pager log --pretty=tformat:"%ad %H %an: %s" -n 15'
  alias 'glt=git --no-pager log --pretty=tformat:"%ad%x09%an%x09%s" --date=short -n 15'
  alias 'gllt=git --no-pager log --pretty=tformat:"%ad%x09%H%x09%an%x09%s" --date=short -n 15'

  # Same, in reverse order, plus show slightly more entries (most recent won't scroll off top of screen)
  alias 'glr=git --no-pager log --reverse --pretty=tformat:"%ad %an: %s" --date=short -n 25'
  alias 'gllr=git --no-pager log --reverse --pretty=tformat:"%ad %h %an: %s" --date=short -n 25'
  alias 'gltr=git --no-pager log --reverse --pretty=tformat:"%ad%x09%an%x09%s" --date=short -n 25'
  alias 'glltr=git --no-pager log --reverse --pretty=tformat:"%ad%x09%H%x09%an%x09%s" --date=short -n 25'

  # Quick Git Graph viewing
  # Usage: gg <list of branches> | gg --all
  alias 'gg=git --no-pager log --decorate --oneline --graph -n 25'
  alias 'gga=gg --all'

There's a naming convention of 'gl' for 'git log' and 'gg' for 'git graph' where 'll' means "log, long" and "lxl" means "log, extra long". Adding 't' means tab-separated for piping & parsing, or copying into a spreadsheet and 'r' means reverse (which I would actually consider 'forwards' but I try to stick with git conventions even though it's the opposite of say, svn). I did not create every permutation, but all of these variants are useful quite often and if I try to run a variant that doesn't exist, I just add it quickly so it's there next time.

https://GitHub.com/GitAlias provides many git aliases like yours, plus ones for topic branches, packing, publishing, logging, and more.

I'm the maintainer so feel free to suggest ones.

You might be interested in this: https://gitlab.com/mikegerwitz/git-shortmaps

I'd rather use something like this: http://gggritso.com/human-git-aliases

Other useful ones I use everyday:

gdh -- git diff HEAD (what have I modified since last commit)

gl -- git log --graph --oneline --all --decorate (ASCII graph of all commits on all branches)

Or use magit! (And spacemacs)