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

81–90 of 148 posts

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

#81

Post by chrismorgan »

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…

> Look at the comments telling you which files have been changed.

And you can make this even better by adding the diff that’s being committed with verbose mode (see `git commit --help`), so that you can scroll down and easily see exactly what’s going into the commit:

  git commit --verbose
You can make it permanent so:

  git config --global commit.verbose 1
I also recommend setting commit.cleanup = scissors as a related thing.

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

#82

Post by Slade_ »

mg wrote: post #2

"It is really hard to lose stuff" Indeed. This also means that garbage keeps piling up in git repos. This is how I make sure, I do lose stuff eventually: https://github.com/no-gravity/git-gc-all-repos.sh A script that goes through all my repos and performs garbage collection.

You might be interested in the `git maintenance` subcommand that was introduced in Git 2.31. It can do per-repository automatic background garbage collection on a configurable schedule, among other things.

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

#83

Post by beeforpork »

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)

That!

Also, 'git reset' is only dangerous in some modes, e.g., --hard. It's a user experience nightmare to have the same command be nice in one case and dangerous in another, depending on an option parameter. It is a very useful command, so it's likely that you accidentally lose your local changes the one day when you're a bit tired, maybe.

Also, 'git checkout' is used for many good things like, well, checkout. To abuse it also for reverting local changes is a user experience nightmare, too. It should have a different command for that functionality.

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

#84

Post by lazide »

maicro wrote: post #71
stackbutterflow wrote: post #65

Earlier quoted context omitted.

I find regex easier to write than to read. I never copy them from stackoverflow because I'm worried it does some weird magic that I don't want. Instead I build them against one or more examples.

I can highly recommend regexr.com for testing and developing regex patterns; paste a representative sample in the "Text" area and it'll show you how things match (and usually, crucially, don't match) as you change the regex pattern. I'm not associated with them, and I understand you don't seem to have any real issues with regex, but thought this would be a good place to mention a useful tool.

Nice! I’ve been writing (and reading) regexes for over 20 years now. I can usually ‘read’ them on sight, but I’ve been wanting this tool for when it all goes wrong.

Which of course always happens at least once or twice in any new dataset/usage.

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

#85

Post by valenterry »

mabbo wrote: post #44

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 lov…

git could also have just followed some standards. For instance, how am I supposed to know the syntax of "3 days ago" in general?

They could have used time spans from ISO 8601 standard, so for instance simply "P3D". Or "P3Y6M4DT12H30M17S".

git is powerful but it involves a higher amount of time investment than it could if it were not reinventing the wheel and taking shortcuts as much. It's easy to see that it is and was built for powerusers mainly.

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

#86

Post by mgkimsal »

maicro wrote: post #71
stackbutterflow wrote: post #65

Earlier quoted context omitted.

I find regex easier to write than to read. I never copy them from stackoverflow because I'm worried it does some weird magic that I don't want. Instead I build them against one or more examples.

I can highly recommend regexr.com for testing and developing regex patterns; paste a representative sample in the "Text" area and it'll show you how things match (and usually, crucially, don't match) as you change the regex pattern. I'm not associated with them, and I understand you don't seem to have any real issues with regex, but thought this would be a good place to mention a useful tool.

I've used that and regexbuddy and others over the years. Almost anything the gives you some visual rendering of what's going on is helpful. Personally, I've taken to using the regex stuff in the Jetbrains IDEs, mostly because I'm there already most of the time, and it's 'good enough'. But I'm not always at my own setup, and regexr and similar are always a good tool to have (and to share with others to show them how a regex is working).

If I did this all the time, I might not need tools like this. But complex regex are something I only dive in to a handful of times per year, and it's never the same problem twice.

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

#87

Post by stonemetal12 »

sophacles wrote: post #50
eulenteufel wrote: post #25

Earlier quoted context omitted.

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.

Git supports history rewriting so 1 isn't true. Git uses hashes for "unique ids" hashes aren't unique just low probability of collision, so 3 is also not true.

Having run into issues that appear to be caused by 3 not being true, I don't see that as a theoretical issue.

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

#88

Post by stu2b50 »

stonemetal12 wrote: post #87
sophacles wrote: post #50

Earlier quoted context omitted.

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

Git supports history rewriting so 1 isn't true. Git uses hashes for "unique ids" hashes aren't unique just low probability of collision, so 3 is also not true. Having run into issues that appear to be caused by 3 not being true, I don't see that as a theoretical issue.

1 is true. When git is “rewriting” history it’s actually creating a new commits and moving the branch pointer over.

Until the gc reaps them, you can absolutely git checkout the hash of any of the rewritten history and it’s still there, same as you left it. You can even move the branch pointer back, undoing the history rewrite.

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

#89

Post by valenterry »

papito wrote: post #49
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…

Yeah I agree. This is a huge productivity boost.

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

#90

Post by stu2b50 »

TheChaplain wrote: post #13
MBlume wrote: post #6

"It is really hard to lose stuff" It is really hard to lose stuff that you have ever committed. It is really hard to lose stuff as long as you commit early and often. Uncommitted work is pretty easy to lose with 'git reset'.

Depends. I use an IDE from Jetbrains, their "Local History" feature makes it fairly difficult to lose anything, even between changes on uncommitted files.

I don’t think that counts as a “depends” if it involves the use of another tool.
Post reply on HN