Live data from Hacker News

Lesser known Git commands

hackernoon.com

51–60 of 142 posts

Re: Lesser known Git commands

#51
A couple of aliases I use all the time:

    [alias]
        graph = log --oneline --decorate --graph --all
        copy-logs-since = !git log --reverse --format=%B "$1".. | pbcopy
`graph` is similar to `grog` in the article. `git copy-logs-since ` copies log messages since the tag, which I use for release notes. Very handy.

Re: Lesser known Git commands

#52
post #37

> git it and empty root commit Why doesn't git init does this by default? It would be nice if every repo had an empty root commit (with no author, date,... so it has the same commit hash), then every two repos would have a common commit. Semantically it would mean that repos would be just specific branches of a hypotetical large repo.

You can already merge two divergent histories with the --allow-unrelated-histories option. (At the data level, merge commits don't care that their parents have a common ancestor, but the git merge command does this as a safety check.)

In other words, all repos already are subsets of the ur-repo. The semantically-interesting data in git is not the commits themselves, but the branch names given to specific commits in specific (groups of) repos. :)

Re: Lesser known Git commands

#53
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 would name them the other way around since I'm pulling "down" and pushing "up" ....

Re: Lesser known Git commands

#54
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…

personally I rarely stash and often it's just to get rid of a bunch of crap. rather than googling reset --hardhatheadhenry, I stash and drop.

Total hack I know, but whatever.

Re: Lesser known Git commands

#55
post #12

My most useful bash alias (when you go back to master and want to start at the most up to date everything before creating a new branch): alias grm="git fetch origin && git reset --hard origin/master"

same here but I switch to master first: resync = !git reset --hard HEAD && git checkout master && git reset --hard origin/master && git pull or with a parameter to do the same with any branch: resync = "!f() { git reset --hard HEAD && git checkout $1 && git reset --hard @{u} && git pull ; }; f"

I use a very similar version of this, and people are often surprised that I'm working directly on master. Well, when it's ready to go, `git checkout -b feature/name; git push origin HEAD; git resync`.

Re: Lesser known Git commands

#56
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 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.

I use `legit` aliases for this. It allows me to do `git sprout `, where it stashes my untracked changes, create a new branch, pop the stash and applies it. Pretty handy!

legit: https://github.com/kennethreitz/legit [1]

[Ignore the pretentious "for humans" tagline though...]

Re: Lesser known Git commands

#57
post #42

Earlier quoted context omitted.

While it's true that they can't be recovered through the "normal" safety mechanisms, they can certainly be recovered - that too up to 30 days in most cases. `git fsck` can help here [0]. Also when a stash is dropped, it's SHA is printed to the console. If the console buffer hasn't been cleared and you realise it soon enough, recovery can be quite straightforward. [0]: http://stackoverflow.com/questions/89332/how-to-r…

Yep true, and to be fair to the man page, that's the next sentence after the one I quoted. But, fsck is a big hammer, and most people I've had to help recover their stashes completely glaze over when they see commands named fsck and reflog. Some people when faced with fsck opt to give up and recreate the lost changes, it's that intimidating. And why not just avoid accidents? git's role in life is to be a safety net.…

You're right of course, but whereas for a lot of purposes I understand the impulse of "I don't have time to learn this". For so many things that's the right call, but for a developer using git I would like to insert the brain worm that maybe it isn't.

I consider git to be on the short list of career-long tools. The rest of the list is linux, bash and vim. Knowledge of these things has a long half life and will serve me across jobs. Even a language I've used for 10+ years in my daily work like Ruby is more likely to become obsolete within my career than git. And the thought of using git without understanding reflog is anxiety producing. The beauty of git is not in memorizing its arcane syntax, it's in understanding the elegant data model.

That's my case for why every developer should at least know git-reflog. git-fsck I have to admit never having used :)

Re: Lesser known Git commands

#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.

Re: Lesser known Git commands

#60
I like "git ready":

    ready = !git checkout master && git fetch -p && git merge --ff-only
The use case is for when you're done with a particular feature branch and ready to start something new. It puts you back on master and updates it in a safe way.
Post reply on HN