Live data from Hacker News

Lesser known Git commands

hackernoon.com

91–100 of 142 posts

Re: Lesser known Git commands

#91

One of my personal favorite: stp = !git stash && git pull && git stash pop

If you `git pull --rebase` by default, just set the rebase.autoStash config to true and git will automatically do this for you.

Can't believe I just learned about rebase.autoStash! That is super handy.

Re: Lesser known Git commands

#92
post #62

Nothing esoteric, but I advise every person I teach git about to put this in their .bashrc: alias s='git status' alias l='git log --graph --oneline --decorate --all --show-signature' alias d='git diff' alias dc='git diff --cached' alias c='git commit -m' alias ca='git commit -am' alias a='git add -p' alias u='git checkout -p' These probably saved me hours of typing by now. Especially `l` I think should be canon.

I don't know if you're aware, so this is just a friendly suggestion: if you define these as git aliases instead, you won't use your shell's namespace and have it available for other aliases. As git aliases you would run it like `git s` or `git ca`. If you also alias git to g it will be `g ca`. If you do that, don't forget to call `__git_complete g __git_main` in .bashrc for it to auto-complete aliases for `g` and not…

I am of course aware of git aliases (e.g. because OP uses them a lot) but it never occured to me specifically to shorten git to g and find a way to keep autocomplete working.

However, since these are by far my most typed commands (specifically, probably 40% of my executed commands are `s`), I strongly care about the difference even between 1 and 3 keystrokes.

Thanks for your feedback. I wonder if the downvote was because of using bash aliases or for something more substantial...

Re: Lesser known Git commands

#94

> so it’s good practice to create an empty commit as your repository root While I'm aware of issues with rebasing the root commit, I've never heard this advice before and it seems unnecessary.

It also helps if you want to do an octopus merge of branches that otherwise have no common ancestor. If it comes to it, you can use git replace to provide a false parent for the root commit.

Re: Lesser known Git commands

#95
post #79
post #61

Earlier quoted context omitted.

> do people actually find stashing easier than branching? Branching wouldn't be enough, you'd need to commit your entire working copy to approximate a stash. I'd say it's generally a bug-prone mistake any time you commit your entire working copy (rather than staging lines/hunks on a one-commit-per-feature/bug basis). So branching and committing and pushing into a `backupForTomorrow` branch is fine, but you have to be…

> Branching wouldn't be enough, you'd need to commit ... Yes, you're right. I mentioned both committing I branching. I imagine commits only as the alternative to a single stash/pop, and commits & branching as the alternative to using multiple stashes. > I'd say it's generally a bug-prone mistake any time you commit your entire working copy The workflow I'd use instead of stash is to commit, do things, then reset --so…

there's no sense arguing. to many git users I have met, the software isn't the product, the git repository is. I have met someone who will happily spend an entire day refactoring all the commit boundaries by teasing apart and combining diffs so that they match some retroactive narrative that looks prettier.

you must be one of those squash haters

Re: Lesser known Git commands

#96
post #43

Earlier quoted context omitted.

Typically once I've noticed I haven't branched is after I've already added and committed.

Then just create the branch where you are, and afterwards go back and reset the original branch

and make sure to patch up the upstream reference

Re: Lesser known Git commands

#97
post #16

I've seen more stash accidents than any other kind with git. Stashing is more dangerous than committing or branching, and to me it doesn't seem to provide any advantages... do people actually find stashing easier than branching? Is it just because when you branch you have to name it, and that causes friction? I stay away from stash. Right from the man page: "If you mistakenly drop or clear stashes, they cannot be rec…

In regards to stash, yes, loss is problematic, but one can simulate it by saving the diff to a file: git diff > my-stash.diff Then you can even commit these if you like, or copy them to a safer directory. Applying them is just an invocation of `patch`.

Or even better than patch, git apply.

Re: Lesser known Git commands

#98
post #16

I've seen more stash accidents than any other kind with git. Stashing is more dangerous than committing or branching, and to me it doesn't seem to provide any advantages... do people actually find stashing easier than branching? Is it just because when you branch you have to name it, and that causes friction? I stay away from stash. Right from the man page: "If you mistakenly drop or clear stashes, they cannot be rec…

Do people really use stash for things they value longer than a few minutes?

I've only ever used stash as a way to store changes that I made on the wrong branch.

  git checkout my_old_branch (wrong branch not realized yet)
   - work work work...
  git status
   - "oh, I'm on the wrong branch"
  git stash
  git checkout the_correct_branch
  git pull
  git stash apply (or git pop - but you lose what was on the top of the stash)

Re: Lesser known Git commands

#99
post #6

My personal favorite two: jschroeder@omniscience:~$ git config alias.up pull --rebase jschroeder@omniscience:~$ git config alias.down push They can be used thusly: git up && git down

I have up aliased to

  pull --rebase --stat
That gives me an idea of what has changed, Though I often follow with:

  git log @\{1\}..

Re: Lesser known Git commands

#100
post #16

I've seen more stash accidents than any other kind with git. Stashing is more dangerous than committing or branching, and to me it doesn't seem to provide any advantages... do people actually find stashing easier than branching? Is it just because when you branch you have to name it, and that causes friction? I stay away from stash. Right from the man page: "If you mistakenly drop or clear stashes, they cannot be rec…

I tend to stash debug code, so for example I'm working on a feature, and while developing I've added a bunch of console.log()s (or pprint.pprint()s, print_r()s, whatever). Then I can do:

    git add --patch  # include only the code I want comitted
    git stash --keep-index
    # now I can do some tests without my debug cruft
    git commit
And then ship the feature to staging/production, if there are any remaining issues with it I still have my debug cruft in the stash. It's rarely needed, so I don't want the overhead of a branch for it. If I lose it it's also easy enough to just add the debug code I need at that moment in case the stash was cleared.
Post reply on HN