Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lesser known Git commands

hackernoon.com

Post reply on HN
Print view View original

61–70 of 142 posts

Re: Lesser known Git commands

#61

Post by pkamb »

dahart wrote: 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 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 sure to get rid of that commit via something like a mixed reset when you start working on it again.

If that temporary backup commit somehow stays around in the final feature branch, a stash would be much preferred.

Re: Lesser known Git commands

#62

Post by cm3 »

SonOfLilit wrote: post #58

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 just `git`. For example, to define `ca`, run this

    git config --global alias.ca 'commit -am'

Re: Lesser known Git commands

#63

Post by iamthad »

SonOfLilit wrote: post #58

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.

While it will end up being a little longer, these can all be defined as aliases within git (see https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases). Some users might prefer the aliases there rather than in their shell configuration.

Re: Lesser known Git commands

#64

Post by pkamb »

michaelmior wrote: post #13
SEJeff wrote: 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

While these aliases are useful, I'm confused why "down" means "push".

"The enemy gate is down."

Re: Lesser known Git commands

#65

Post by leephillips »

dahart wrote: post #26
ryanSrich wrote: post #17

Earlier quoted context omitted.

I use stash when I forget to branch. So I might be working and then realize I never branched. So I stash my changes, create a new branch, and then pop my changes on the new branch.

Makes sense, but fwiw, there's a safer alternative: branch immediately, then go back to the source branch and reset. There's nothing wrong with your workflow, btw, stash works in that case, as long as you immediately pop & don't get interrupted by lunch or a phone call. Stashing is obviously providing some value that people like, it's very popular. But considering that it has extra danger, and that it's really easy t…

I'm not a git expert (yet), but I agree. I've read the stash man page a few times and tried to imagine when I'd want to use it over the alternatives, but I never do.

Re: Lesser known Git commands

#66

Post by spike021 »

ashark wrote: post #31
ryanSrich wrote: post #17

Earlier quoted context omitted.

I use stash when I forget to branch. So I might be working and then realize I never branched. So I stash my changes, create a new branch, and then pop my changes on the new branch.

My #1 use of stash is as the quickest way to express "get rid of all this crap". I rarely intend to ever retrieve it.

For one of my projects, the 'build process' requires that I use the git archive command (basically archive to .tar.gz without any git-related files/directories). git archive on its own is fine for final builds because it's based off of HEAD for the current branch, but if I want to test a build with working changes, I would either need to commit all the changes _or_ use git stash and then archive based on the state I just stashed.

So in this case git stash works a lot better for a 'temporary' commit, kind of deal.

It might not be optimal but I've found the process to work pretty well for this particular project's situation.

Re: Lesser known Git commands

#67

Post by chocolatebunny »

dahart wrote: 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 mostly only stash when I want to rebase -i because rebase -i seems to complain when I have uncommitted changes.

Re: Lesser known Git commands

#68

Post by eatbitseveryday »

dahart wrote: 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`.

Re: Lesser known Git commands

#70

Post by smazga »

spinningarrow wrote: post #38
smazga wrote: post #30

Earlier quoted context omitted.

I like where your head's at and added a little something to help me here at work: void:~% git config alias.funky ! git up && git submodule update And speaking of lesser known commands, I've been using 'git worktree' recently at work and I'm a big fan. Admittedly, it's probably mostly unknown because it's a new feature. It's a little rough around the edges, but it has made things like customer support context switchin…

Could you share your workflow with worktree a little? What kind of development do you do and where does it fit in with your workflow? I tried using it in a JS project for those times when I'm in the middle of work but someone asks "hey is master working fine on your system?" - eventually though, having to install all the node and bower modules and rebuild everything on the worktree didn't seem much smoother than just…

Well, admittedly my current situation lends itself well to 'worktree' where normally a stash is probably just fine.

At the moment I'm doing a big rework (porting our software from a 10 year-old OS to CentOS 7), so I have many, many modified files (all tiny mods to fix new compiler warnings from new toolchains) and untracked and obsoleted files.

Basically, it's too much for me to keep track of if I change anything, so it's a case of "whatever you do, don't touch" that pushes me toward the worktree solution.

I've been pulled in to work on customer escalations on released code (one instance from 2 releases ago), so it's just easier for me to create a whole new worktree.

I imagine that once I'm back into a normal dev cycle that I'll be back to stashing.

Post reply on HN