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

71–80 of 148 posts

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

#71

Post by maicro »

stackbutterflow wrote: post #65
NKCSS wrote: post #54

Earlier quoted context omitted.

GIT is just the new Regex. Everybody uses it, most have no clue how it works and just copy/pasts stuff from other places/repeats the same little trick

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.

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

#72

Post by foobarian »

scrollaway wrote: post #57
NKCSS wrote: post #54

Earlier quoted context omitted.

GIT is just the new Regex. Everybody uses it, most have no clue how it works and just copy/pasts stuff from other places/repeats the same little trick

No, that’s terrifyingly untrue. Git is more like… the new car. It’s complicated and most people have no idea how it works, but they know how to steer very simply and can drive it with a bit of training. Experienced people however, who know how cars work, can do really cool things with them and have no problem repairing them on their own. Still, cars are useful. A bike would be better of course.

I like it! I'll do you one further. Git is more like... someone ripped out all the controls from your car and installed a Boeing 787 dashboard. You'd probably figure out how to start it and make it go forward, left and right, but you'd miss out on a lot of functionality and likely destroy something while playing with unknown buttons.

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

#73

Post by pc86 »

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…

> once you have to do anything more complicated than just commiting/merging

If you really have to do more complicated things with git.. why? I mean that seriously, if your workflow necessitates anything more complicated that committing or merging with any level of regularity, it sounds like you have a bad workflow. Committing and merging should be 99.9% of your activity within git, shouldn't it?

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

#74

Post by pc86 »

afarviral wrote: post #70
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'd love to know how to do this in VSCode. Its infuriating that it yells at you for exeeding a 50 character limit.

The terminal in VSCode. Over the past 6 months or so I've been forcing myself to move as much of my workflow into the terminal as possible and I've found things have been continually getting easier and easier. A lot of arbitrary restrictions based around half-baked UIs get removed when there's no more half-baked UI.

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

#75

Post by shikoba »

joe8756438 wrote: post #63

Learning git is not easy. There is one thing that will almost guarantee no work is ever lost: commit. if something is commit, even if it’s not pushed it can be retrieved. One other thing that has nothing to do with how it works, but makes all the difference in usability: write commit messages describing _why_. To learn git is to use git, reading about it has not helped me.

> write commit messages describing _why_.

Could you provide a concrete example? I don't understand your point.

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

#76

Post by praptak »

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.

2. is true or untrue depending on how deeply you interpret it.

A branch is named, points to a commit and under normal circumstances will track the sequence of commits made via itself (i.e. when you commit and HEAD points to branch b, b starts pointing to the child commit). So you could say it's a named sequence of commits.

On the other hand you can reset the branch to any commit in the tree, even ones which aren't even on the current sequence of parents. It is still technically a named sequence of commits, just a totally different one.

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

#77

Post by pie_flavor »

afarviral wrote: post #70
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'd love to know how to do this in VSCode. Its infuriating that it yells at you for exeeding a 50 character limit.

Hit enter. Line #2 starts the body.

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

#78

Post by themulticaster »

pc86 wrote: post #73
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…

> once you have to do anything more complicated than just commiting/merging If you really have to do more complicated things with git.. why? I mean that seriously, if your workflow necessitates anything more complicated that committing or merging with any level of regularity, it sounds like you have a bad workflow. Committing and merging should be 99.9% of your activity within git, shouldn't it?

It depends a little on how you use git. Apart from stashing (git-stash), I use interactive rebases a lot. Combined with autosquashing it's a very powerful tool to ensure a somewhat nice history.

Of course, this only matters if you care about your history. It feels like there are two camps of git users: One camp squashes every MR/PR together even if it's huge, hasn't heard of git-bisect, creates plenty of merge commits in both directions, and piles unrelated changes into a single commit. The other camp cleanly groups changes into self-contained commits, rebases often resulting in a clean patch-series-style MR/PR, and likes to use git-bisect.

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

#79

Post by witcher01 »

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

merge and pull update the reflog just like rebase does, so both can be undone!

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

#80

Post by cassianoleal »

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…

What's `git gui`?

    $ git gui
    git: 'gui' is not a git command. See 'git --help'.

    The most similar commands are
      ci
      gc
      grep
      init
      lg80
      pull
      push
Post reply on HN