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

Things I wish everyone knew about Git (Part II)

blog.plover.com

Post reply on HN
Print view View original

41–50 of 148 posts

Re: Things I wish everyone knew about Git (Part II)

#41

Post by TacticalCoder »

lelandfe wrote: post #32

> A few things can be lost forever! > The dangerous commands are git-reset and git-checkout Don't forget about `git clean`, which will happily gobble up all your important ignored files (API keys, IDE configurations, etc)

But git clean requires confirmation, unless you configured Git to not ask your permission to trash the .gitignored files.

It even shows you which files are going to be deleted.

Now, on that topic of "important but (.git)ignored files", I don't know what the best practices are but I like to symlink my IDE config files / test API keys etc. that aren't to be committed to Git. So in case I'm not cautious I'm only deleting the symlink but not the file itself.

To me it's the best of every world: I don't need to take any special care of "not backuping" these infos were they shouldn't be backed because I don't backup my Git repo with anything but Git (and they're .gitignore'd so I'm good), I don't risk losing them even if in engage in reckless behavior (like a git clean or some "rm -rf ..." the whole repo and re- git clone, you guys know what I mean) and I can centralize my secret / personal config files into a specifir dir which I know is important and which I can securely backup (say doing encrypted backups).

If I delete the symlink (and git clean only deletes the symlink, as expected), I can just re-create it.

Re: Things I wish everyone knew about Git (Part II)

#42

Post by rjmunro »

brenainn wrote: post #7

A simple one is being able to write multiple messages (subject and body), e.g. git commit -m "subject" -m "a longer body" or just running 'git commit' and using your text editor (subject first line, body after). I've worked on too many repos with messages like "fixed the thing" where a few more sentences of context would've prevented headaches when trying to debug or change something.

I always tell people the `-m` flag of `git commit` is only ever to be used in scripts. Let git open an editor and write your multi-line message there. Look at the comments telling you which files have been changed.

Even better than using `git add` and `git commit` is to use `git gui` to add and commit files. The (standard) GUI is not to help beginners, it is to make you a more effective user of git. Note there are other apps you can use with more features, for example I like gitx on MacOS, but there are also terrible apps out there that do try to be easy for beginners, and they should be avoided. The most obvious is github desktop (I haven't tried it for a while - it might have slightly improved, but I still won't go near it)

Re: Things I wish everyone knew about Git (Part II)

#43

Post by rjmunro »

tsimionescu wrote: post #14
perlgeek wrote: post #9

Earlier quoted context omitted.

... or with `git checkout` or with `rm` or `git clean` (for files not yet under version control).

... or git merge / git pull (but not git rebase) ...

How do you loose files with git merge / git pull?

Re: Things I wish everyone knew about Git (Part II)

#44

Post by mabbo »

I said this in another comment recently about git, but I find it odd that even after a decade of using git as a mandatory part of my professional life, I'm still learning new things.

That's maybe not a good sign about the usability of git.

That `@{'3 days ago'}` thing? That's incredible. Why didn't I know about that 8 years ago? Why wasn't it obvious, intuitive to me that this was possible?

git is brilliant and I love it. But there are very few affordances that make it obvious what to do next, what is possible. There's few patterns in it where I can apply what I already know.

The thing that replaces git will have most of the power of git, but an intuitive interface that makes learning everything about it easy.

Re: Things I wish everyone knew about Git (Part II)

#45

Post by rjmunro »

emacs28 wrote: post #35

I made a simple script below I find useful that commits current changes then automatically rebases and squashes it with the previous commit, preserving the previous commit message. I find it useful for a way to quickly save current changes before switching branches, or for easily backing up work before its worth making a new separate commit: git add --all git commit --fixup=HEAD~1 GIT_SEQUENCE_EDITOR="sed -i -re 's/^…

Isn't this the same as something like:

  git commit --all --amend
With maybe a --no-edit thrown in?

Re: Things I wish everyone knew about Git (Part II)

#46

Post by IshKebab »

shikoba wrote: post #28
formerly_proven wrote: post #23

Earlier quoted context omitted.

Maybe it would have been good if the git defaults were changed from the defaults used for the kernel development workflow to the git workflow ~everyone else is using, even though git was created for the kernel people by the kernel people - most users are not kernel people. "git pull" in the kernel workflow is for integrating downstream changes into your own upstream repository. Meanwhile, "git pull" in the everyman w…

The idea of "merging into" has no meaning with git. You're merging two things into one. But saying that there are a master thing and a slave thing has no meanings.

Not true because commit parents are ordered. One of them is first - the main parent.

Re: Things I wish everyone knew about Git (Part II)

#47

Post by pfarrell »

rjmunro wrote: post #42
brenainn wrote: post #7

A simple one is being able to write multiple messages (subject and body), e.g. git commit -m "subject" -m "a longer body" or just running 'git commit' and using your text editor (subject first line, body after). I've worked on too many repos with messages like "fixed the thing" where a few more sentences of context would've prevented headaches when trying to debug or change something.

I always tell people the `-m` flag of `git commit` is only ever to be used in scripts. Let git open an editor and write your multi-line message there. Look at the comments telling you which files have been changed. Even better than using `git add` and `git commit` is to use `git gui` to add and commit files. The (standard) GUI is not to help beginners, it is to make you a more effective user of git. Note there are ot…

Good points. I occasionally use gitk to browse recent commits. A gui definitely has its place.

I like using the terminal, so my workflow is to use `git add -p`. That makes me look at each change, in small chunks,as I stage them. As a bonus, it helps me keep commits small, or decide if there’s some logical separation in my changes that would be better expressed in two or more commits.

Re: Things I wish everyone knew about Git (Part II)

#49

Post by papito »

rob74 wrote: post #11

My thoughts on this: - even after years of working with git, I'm still not familiar with all the dark corners I can get myself into by running the wrong command at the wrong time. Yes, most of the time my changes are still there, but the way back to the state I actually want for my repository may be long, complicated and require lots of googling/asking around. - as the article mentions, git cares a lot about stuff th…

I can't tell you how many times IDEA's "local history" saved my ass. I use it extensively. Instead of stashing local changes and going around messing with my working tree, what I did 30 minutes ago is just a right-click away.

(Also, if you right-click on the top project folder itself, you can restore the entire project to a previous snapshot, if something was working before and you heroically went down the wrong path).

Re: Things I wish everyone knew about Git (Part II)

#50

Post by sophacles »

eulenteufel wrote: post #25
praptak wrote: post #16

I love this quote from Part I: "Git has an elegant and powerful underlying model based on a few simple concepts: 1. Commits are immutable snapshots of the repository 2. Branches are named sequences of commits 3. Every object has a unique ID, derived from its content Built atop this elegant system is a flaming trash pile. "

The quote is kinda wrong in that point 1 and 2 are mixed up. Branches are just pointers to commits. Commits contain a reference to their history. It's only kind of incorrect because in praxis branches are used to refer to a history (a sequence of commits). But it's also misleading once you have to do anything more complicated than just commiting/merging. When I started out using git I was working with the same assump…

Do you have an actual example of this? I've never encountered a situation where those three points are incorrect.
Post reply on HN