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

101–110 of 148 posts

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

#101

Post by MontyCarloHall »

pif wrote: post #67
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 find regex easier to write than to read. There is nothing new under the sun. Joel, 22 years ago: There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. [...] The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming: It’s harder to read code than to write it. https://www.joel…

Joel is 100% spot on. This is exactly why I don’t think things like Copilot will catch on. Making programming involve less writing code and more reading code actually makes the job more difficult.

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

#102

Post by LgWoodenBadger »

awaisraad wrote: post #38

a colleague accidentally force pushed a stale branch to master and a weeks worth of work was potentially lost. That day git reflog helped and saved our jobs as we were contractors for a big Germany based client.

I hope you(they) are backing up their source code as well, which would have helped you if reflog did not.

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

#103

Post by sophacles »

kleinsch wrote: post #62
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.

If you're in a detached head state and create a new commit, you have a commit that isn't on a branch. The commit still has a parent, so it's not the branch that's tracking the sequence, it's the commit. Branches are just pointers that get updated as you add commits.

This feels like declaring squares aren't rectangles because you can make rectangles that aren't a square.

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

#104

Post by [deleted] »

stu2b50 wrote: post #98
layer8 wrote: post #96

Earlier quoted context omitted.

Items 1 and 2 are somewhat misleading. Commits are only immutable in the sense that the same commit hash will (with huge likelihood) always refer to the same commit history. But they are not immutable in the sense that you couldn’t change the history of e.g. a branch. Other VCSs actually offer more immutability than Git here. Branches are sequences of commits only up to the last merge, because they are really just la…

> But they are not immutable in the sense that you couldn’t change the history of e.g. a branch. That sentence doesn't make sense, though. Assuming from context that `they` = commits, "[commits] are not immutable in the sense you couldn't change the history of a branch" Branches and tags are mutable - they're just pointers to commits - but that doesn't change whether or not commits are immutable. When you "change" th…

[deleted]

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

#105

Post by layer8 »

stu2b50 wrote: post #98
layer8 wrote: post #96

Earlier quoted context omitted.

Items 1 and 2 are somewhat misleading. Commits are only immutable in the sense that the same commit hash will (with huge likelihood) always refer to the same commit history. But they are not immutable in the sense that you couldn’t change the history of e.g. a branch. Other VCSs actually offer more immutability than Git here. Branches are sequences of commits only up to the last merge, because they are really just la…

> But they are not immutable in the sense that you couldn’t change the history of e.g. a branch. That sentence doesn't make sense, though. Assuming from context that `they` = commits, "[commits] are not immutable in the sense you couldn't change the history of a branch" Branches and tags are mutable - they're just pointers to commits - but that doesn't change whether or not commits are immutable. When you "change" th…

You are defining commits to be different by the mere fact that their contents (and history) is different. With that definition, how could a commit ever be mutable? Only by an indirection were the VCS allows the referencee to change. And that is exactly what Git allows with branches.

When rewriting history, the fact that the “new” commits are new is a tautology if you define commits to be different when their contents is different. This only matters when you use the commit hash as your reference point, which is what I was pointing out in the parent comment.

The expectation of immutable commits would be that history never gets lost and cannot be changed (without rewriting history into a different repository), but it certainly can in Git.

The real point about Git’s content-derived addressing is that it enables the distributed aspect, because it makes the path a commit has taken between repositories not matter. But that is already better expressed in point 3.

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

#106

Post by yogeshg »

["Git from the Bottom Up"](https://jwiegley.github.io/git-from-the-bottom-up/) changed my life. Someone recommended this to me, and I recommend this to anyone seeking more information about git. People often just want to know "which commands to run", which is a fair expectation, until they reach a threshold of what they can do without knowing the internals.

[When should someone read "Git from the Bottom Up"? What are your git recommendations?](https://forms.gle/aqFy52uvTp8CUvkF9)

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

#107

Post by Rediscover »

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.

Thanks for pointing out regexr.com.

I really appreciate the availability of tools like that.

See also the Emacs built-in M-x re-builder (for elisp-style regexp).

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

#108

Post by lelandfe »

stu2b50 wrote: post #92
lelandfe wrote: post #31

Earlier quoted context omitted.

As a corollary: cheap branches are wonderful. The workflow I teach the newbies at my job is to just do a quick `git checkout -b tempbranch` when trying out: complicated rebasing, cherry-picking commits, whatever. Do your thing on that temporary branch. Did the thing work? Hell yeah. `git checkout - && git reset --hard tempbranch`. Presto magic, your old branch is now a perfect replica of tempbranch . It's as if you d…

Those are pretty much the same thing. Branches work for that purpose because commits are immutable - the branch just saves you from having to remember the hash. A tag would also work in this case.

> just saves you from having to remember the hash

You're underselling it :) That is the entire point. Don't tell me you enjoy using reflog. This "just saves you" in the same way that a rebase "just saves you" from having to write out enormous cherry-pick statements.

While "the plumbing is the same" is a nice bit of trivia, the porcelain is all that we should care about when we're recommending behaviors.

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

#109

Post by bityard »

chrismorgan wrote: post #81
rjmunro wrote: post #42

Earlier quoted context omitted.

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…

Thanks for this tip. One of the things I always did in larger commits was compose the commit message in a separate text editor while reviewing the diff in my terminal. This puts the diff right where I can see it, although time will tell if I enjoy scrolling up and down to switch between reading the diff and editing the commit message.

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

#110

Post by dotancohen »

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…

  > even after a decade of using git as a mandatory part of my professional life, I'm still learning new things.
I still learn new things in Python every month. I still learn new things in Magento every _day_. I'll learn something new in VIM or PyCharm or PhpStorm at least once every few weeks. I'll learn something new in my native language every few weeks, and I'll learn something new in my other languages almost every day. I'll learn something new about Bash or Linux or CORS or Selenium or some useful Chrome or Firefox setting or extension at least every week.

Learning new things is not unusual in the software development industry.

Post reply on HN