Lesser known Git commands • Hacker News Board

Re: Lesser known Git commands

#81

Post by kozak » Fri, Sep 30, 2016, 5:46 PM UTC

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…

My IDE stashes things behind the scenes quite often, allowing me to do many operations on "dirty" workspaces.

Re: Lesser known Git commands

#82

Post by CGamesPlay » Fri, Sep 30, 2016, 5:51 PM UTC

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

I always do this together, so I just use `git push-pull`

  $ git help push-pull
  `git push-pull' is aliased to `!git pull --rebase && git push'

Re: Lesser known Git commands

#83

Post by swang » Fri, Sep 30, 2016, 5:52 PM UTC

Author's "commend" function I just call "cane"

git (c)ommit --(a)mend --(n)o-(e)dit

Re: Lesser known Git commands

#84

Post by aisofteng » Fri, Sep 30, 2016, 6:01 PM UTC

sounds wrote: post #5

masklinn wrote: post #2

Warning: not actually git commands, rather TFAA's aliases for possibly useful combinations of switches and/or commands.

See, switches in git are there because git maintains backward compatibility. Sometimes a switch really would logically be better as a whole new command. But it's a common refrain to hear that git hides useful things in the switches. This article is a great way to find those hidden things.

Alternatively, read the documentation and know how to use your tools instead of reading blog posts that lists a few things one person has found useful.

Re: Lesser known Git commands

#85

Post by OJFord » Fri, Sep 30, 2016, 6:01 PM UTC

nilved wrote: post #10

masklinn wrote: post #2

Warning: not actually git commands, rather TFAA's aliases for possibly useful combinations of switches and/or commands.

Yes, the title is misleading. edit: downvote?

Agreed - these aren't lesser known git commands at all.

The switches given to git commands in the article might be lesser-known, but title could be clearer that this is:

    > Some suggestions for git aliases

Re: Lesser known Git commands

#86

Post by CGamesPlay » Fri, Sep 30, 2016, 6:02 PM UTC

A few that weren't mentioned below:

  git alias start 'checkout @{u} -B'

All my branches track origin/master (rather than local master), which makes it easy to git push / git pull without extra arguments. This will checkout a new branch from whatever the current branch is tracking. Usage: `git start my-new-feature`

  git alias track 'track = branch --set-upstream-to'

Sets up your current branch to track some other branch. Usage: `git track origin/master`.

  git alias gcbr 'gcbr = !git branch --no-track --no-color --merged | sed 's/[ *]*//' | grep -v master | xargs -n1 git branch -d &> /dev/null || exit 0'

"Garbage Collect BRanches" will delete any branches which are already merged into your current branch (excluding master). Basically, any branch which is "safe" to delete. (This one has been handed down through the ages; I initially found it on the skeleton dotfiles when I started working at Facebook. Thanks, whoever!)

Re: Lesser known Git commands

#87

Post by pattu777 » Fri, Sep 30, 2016, 6:03 PM UTC

    git diff origin/master -- test.file

It will show you a diff of a file between the master branch of remote origin and your local branch. I use it way more than I can think of.

Re: Lesser known Git commands

#88

Post by sqeaky » Fri, Sep 30, 2016, 6:04 PM UTC

pkamb wrote: post #64

michaelmior wrote: post #13

Earlier quoted context omitted.

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

"The enemy gate is down."

I love the implication that the upstream repo is the enemy, so you mentally put it down. Way to go Ender.

Re: Lesser known Git commands

#89

Post by sqeaky » Fri, Sep 30, 2016, 6:06 PM UTC

relics443 wrote: post #3

Some of the aliases are funny but could be renamed for brevity. Also grog is making me feel extremely groggy.

It make me think of pirates drinking their grog.

I would have named it "git rum"

Re: Lesser known Git commands

#90

Post by pkamb » Fri, Sep 30, 2016, 6:15 PM UTC

dahart wrote: post #79

pkamb wrote: 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…

I use stash in one of the two workflows below, neither of which have ever caused problems. Stash's advantage is in not needing to create branches, commit, or un-commit the code back into your working copy. Very quick, and I've never had problems.

- Paired operations `git stash` / `git stash pop` to quickly get rid of everything then reapply it a few minutes later.

- Stash as a "I probably don't want this code, but may as well keep a stashed copy" alternative to a hard reset. These stashes all then show up in my SourceTree sidebar to easily peruse or apply if needed (or copy/paste individual lines). Not a big deal if lost.

If I'm actually backing up code that I'll likely use, or need a remote backup of my current working copy to protect against laptop theft or HDD failure, I'll branch/commit/push the backup. Then use a mixed reset later to get rid of the commit itself and return everything to the working copy.