5 ms·

Heya, author here. I have to admit that I learned a lot of these things fairly recently. The large repository stuff has been added into core piece by piece by

Heya, author here. I have to admit that I learned a lot of these things fairly recently. The large repository stuff has been added into core piece by piece by Microsoft and GitHub over the last few years, it's hard to actually find one place that describes everything they've done. Hope it's helpful. I've also had some fun conversations with the Mercurial guys about this. They've recently started writing some Hg internals in Rust and are getting some amazing speed improvements. I'm also thinking of doing a third edition of Pro Git, so if there are other things like this that you have learned about Git the hard way, or just want to know, let me know so I can try to include it.

SushiHippie 3y ago
Hey little feedback on the terminal images in your posts. I'm viewing this on a phone, and it would be better if the terminal images were just the terminal (some are) and not surrounded by a large blank space which is your wallpaper. This would make it a bit easier to read on small screens, without the need to zoom in!
- schacon 3y ago
  But then would it be as pretty?
juliusdavies 3y ago
I wrote this and wish more people followed this specific git advice: https://mergebase.com/blog/doing-git-pull-wrong/ https://mergebase.com/blog/doing-git-pull-wrong/ TLDR: don’t be afraid of rewriting history but ALWAYS do “git pull -r —autosquash “
ulope 3y ago
I just wanted to say thanks for the entertaining talk you gave at FOSDEM and also that I appreciated the Sneakers reference :)
- schacon 3y ago
  Ha! Yeah, I was wondering if anyone would catch that. I thought I heard a snicker or two in the audience, but I couldn't be sure.
nemoniac 3y ago
How about an RSS feed on your blog? If there's one there, it's not obvious.
- tsukurimashou 3y ago
  https://blog.gitbutler.com/rss/ https://blog.gitbutler.com/rss/ most of the time trying the main URL + /rss works also the tag is there <link rel="alternate" type="application/rss+xml" title="GitButler" href="https://blog.gitbutler.com/rss/ https://blog.gitbutler.com/rss/">
bemusedthrow75 3y ago
Thank you for your writing on Git over the years, particularly Pro Git, which is helpful.
- schacon 3y ago
  Thank you for reading. :)
diarrhea 3y ago
I remember watching your FOSDEM talk on YouTube, where you asked whether people have rerere turned on _and_ know what it is, in one question. I have it on, but only the faintest of clues what it is! Just git things, I suppose. https://youtu.be/aolI_Rz0ZqY?t=910 https://youtu.be/aolI_Rz0ZqY?t=910
Towaway69 3y ago
Great tips and great article :+1: One question that I have is what is happening to large file support within Git? Has that been merged into the core since Microsoft changes have also made it into core. Obviously there is a difference in supporting very many small files or a few very large files but won't it make sense to roll LFS into core as well?
- schacon 3y ago
  What a great question. If I recall correctly, the LFS project is a Go project, which makes it difficult to integrate with Git core. However, I believe that the Git for Windows binary _does_ include LFS out of the box. There was a discussion very recently about incorporating Rust into the Git core project that I think had a point about LFS then being viable due for some reason, but I'd have to find the thread.
  - Towaway69 3y ago
    Thanks for the insight. I'm surprised to hear that LFS is Go based, I would have thought LFS outdated Go - but learn something new everyday! :)
    - js2 3y ago
      Looks like it was started in 2015, so Go had about a 6 year head start on it: https://github.com/git-lfs/git-lfs/blob/main/CHANGELOG.md https://github.com/git-lfs/git-lfs/blob/main/CHANGELOG.md
goku12 3y ago
One thing about git I learned the hard way is the use of diffs and patches (more accurately, 3-way merges) for operations like merging, cherry picking and rebasing. Pro-git (correctly) emphasizes the snapshot storage model of git - it helps a lot in understanding many of its operations and quirks. But the snapshot model can cause confusion in the case of the aforementioned operations - especially rebasing. For example, I couldn't understand why the deletion/dropping of a commit during a rebase caused changes to all subsequent commits. After all, I only asked for a snapshot to be dropped. I didn't ask for the subsequent snapshots to be modified. Eventually, I figured out that it was operating on diffs, not snapshots (though storage was still exclusively based on snapshots). The correction on that mental model allowed me to finally understand rebasing. (I did learn later that they were 3-way merges, but that didn't affect the conclusions). That assumption was eventually corroborated somewhere in Pro-Git or the man pages. But I couldn't find those lines again when I searched it a second time. I feel that these operations can be better understood if the diff/patch nature of those operations are emphasized a bit more. My experience on training people in rebasing also supports this. PS: Thanks for the book! It's a fantastic example of what software documentation should look like.
- smallpipe 3y ago
  > Eventually, I figured out that it was operating on diffs, not snapshots The snapshot include all the history that led to the current snapshot. So even if you did a squash instead of dropping, you're changing everything that depends on that
  - goku12 3y ago
    > The snapshot include all the history that led to the current snapshot Git snapshots don't contain any history, other than the commit chain (reference to the parent commit/s) in the commit object. While the storage format is a bit complex, they behave fundamentally like a copy of the working tree at the point of commit. > So even if you did a squash instead of dropping, you're changing everything that depends on that Squashes don't change the subsequent commits/snapshots either, other than the commit ID and chain. The tree itself remains untouched. You can verify this.
vinc 3y ago
I watched the FOSDEM talk yesterday, and I laughed hard when I heard "Who use git blame -L? Does anybody know what that does?" because it suddenly looked like the beginning of a git wat session. But it was really informative, I learned a lot of new things! Thanks
foobarian 3y ago
I chuckled at the title - "So You Think You Know Git" - no, one does not think one knows git :-)
- rafacm 3y ago
  Except Chuck Norris that is!
  - TravelPiglet 3y ago
    Chunk Norris
- pantulis 3y ago
  Git thinks it knows you.
- unclebucknasty 3y ago
  Never not a good time for this: https://xkcd.com/1597/ https://xkcd.com/1597/
surge 3y ago
Hey Scot, I met you and we chatted for a bit at a bar after hours at a tech conference years ago, before you dropped you were a GitHub co-founder towards the end. You actually gave me some advice that has worked out well for me. Just wanted to say thanks!
- schacon 3y ago
  In vino veritas. Thanks for the thanks. :)
bloopernova 3y ago
You probably already know these bits & bobs, but I wanted to share: [diff] external = difft Use the fantastic difftastic instead of git's diff. https://difftastic.wilfred.me.uk/ https://difftastic.wilfred.me.uk/ [alias] fza = "!git ls-files -m -o --exclude-standard | fzf -m --print0 | xargs -0 git add" gone = "!f() { git fetch --all --prune; git branch -vv | awk '/: gone]/{print $1}' | xargs git branch -D; }; f" root = rev-parse --show-toplevel Those are the most used aliases in my gitconfig. "git fza" shows a list of modified/new files in an fzf window, and you can select each file with tab plus arrow keys. When you hit enter, those files are fed into "git add". Needs fzf: https://github.com/junegunn/fzf https://github.com/junegunn/fzf "git gone" removes local branches that don't exist on the remote. "git root" prints out the root of the repo. You can alias it to "cd $(git root)", and zip back to the repo root from a deep directory structure. This one is less useful now for me since I started using zoxide to jump around. https://github.com/ajeetdsouza/zoxide https://github.com/ajeetdsouza/zoxide
- bloopernova 3y ago
  This one I'm less sure about. I haven't yet gotten it to the point where I really like using it, but I'm sharing since someone might find it useful as a starting point: [alias] brancherry = "!f() { git checkout -b $(git rev-parse --abbrev-ref HEAD)-$(git rev-parse --short \"$1\") $1; }; f" It's intended to be used for creating a cherry-picking branch. You give it an branch name, let's say "node", and it creates a branch with that as its parent, and the short commit hash as a suffix. So running "git brancherry node" creates the branch "node-abc1234" and switches to it. The intended workflow being you cherry pick into that branch, create a PR, which then gets merged into the parent.
- ulope 3y ago
  difftastic - amazing! I've been wanting something like this for years...
  - bloopernova 3y ago
    Be prepared to hand out the difftastic URL and install instructions a lot :) I get asked "what git setting is that?" when I do diffs while sharing my screen.
olvy0 3y ago
Hi Scott! First off, I loved your presentation. And your book. As someone who actually bothers to read most of github's "Highlights from Git" blogs, that the, I was somewhat familiar with some of them, but it was still very informative. Also liked your side-swipe at people who prefer rebase over merge, I'm a merge-only guy myself... I also took a look at GitButler and it looks like it could potentially solve one of my pain points. If you're looking for things which are confusing to beginners, for a future version of your book, there are many useful / interesting / sometimes entertaining git discussions/rants here on HN. One of the recent ones is: https://news.ycombinator.com/item?id=38112951 https://news.ycombinator.com/item?id=38112951
- schacon 3y ago
  I love the GitHub Git blog posts. They should have a bigger audience. Taylor is a machine.
wrs 3y ago
In the part about whitespace diffs, you might want to mention ignore-revs-file [0]. We check an ignore-revs file into the repo, and anyone who does a significant reformat adds that SHA to the file to avoid breaking git-blame. [0] https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revltrevgt https://git-scm.com/docs/git-blame#Documentation/git-blame.t...
- schacon 3y ago
  I dont think I knew this. Great tip, thanks!
  - js2 3y ago
    Note that git itself doesn't care what the ignore-revs file is called, but GitHub does. It has to be named `.git-blame-ignore-revs`: https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/ https://github.blog/changelog/2022-03-24-ignore-commits-in-t... One other thing you might want to be mention, which is obvious after thinking about it, is that updating the ignore-revs file has to occur in a commit after the one that you want to ignore, since you don't know what that first commit's ID is till after you make it. :-)
    - wrs 3y ago
      Yes! I recommend making a script that does that little dance automatically.
keybored 3y ago
Hey, thanks for a great little series. The part about `--force-with-leash` could include `--force-if-includes` as well. `--force-with-leash` doesn’t do much if you fetch often. https://stackoverflow.com/questions/65837109/when-should-i-use-git-push-force-if-includes/65839129#65839129 https://stackoverflow.com/questions/65837109/when-should-i-u...
- CRConrad 3y ago
  "--force-with-leash" sounds like git for the BDSM community...
lasereyes136 3y ago
The YouTube video of your presentation is great and I recommend to anyone that wants to learn more about Git or uses Git on a regular basis. Thanks for the info.

SushiHippie 3y ago

Hey little feedback on the terminal images in your posts. I'm viewing this on a phone, and it would be better if the terminal images were just the terminal (some are) and not surrounded by a large blank space which is your wallpaper. This would make it a bit easier to read on small screens, without the need to zoom in!

schacon 3y ago
But then would it be as pretty?

juliusdavies 3y ago

I wrote this and wish more people followed this specific git advice: https://mergebase.com/blog/doing-git-pull-wrong/ https://mergebase.com/blog/doing-git-pull-wrong/ TLDR: don’t be afraid of rewriting history but ALWAYS do “git pull -r —autosquash “

ulope 3y ago

I just wanted to say thanks for the entertaining talk you gave at FOSDEM and also that I appreciated the Sneakers reference :)

schacon 3y ago
Ha! Yeah, I was wondering if anyone would catch that. I thought I heard a snicker or two in the audience, but I couldn't be sure.

nemoniac 3y ago

How about an RSS feed on your blog? If there's one there, it's not obvious.

tsukurimashou 3y ago
https://blog.gitbutler.com/rss/ https://blog.gitbutler.com/rss/ most of the time trying the main URL + /rss works also the tag is there <link rel="alternate" type="application/rss+xml" title="GitButler" href="https://blog.gitbutler.com/rss/ https://blog.gitbutler.com/rss/">

bemusedthrow75 3y ago

Thank you for your writing on Git over the years, particularly Pro Git, which is helpful.

schacon 3y ago
Thank you for reading. :)

diarrhea 3y ago

I remember watching your FOSDEM talk on YouTube, where you asked whether people have rerere turned on _and_ know what it is, in one question. I have it on, but only the faintest of clues what it is! Just git things, I suppose. https://youtu.be/aolI_Rz0ZqY?t=910 https://youtu.be/aolI_Rz0ZqY?t=910

Towaway69 3y ago

Great tips and great article :+1: One question that I have is what is happening to large file support within Git? Has that been merged into the core since Microsoft changes have also made it into core. Obviously there is a difference in supporting very many small files or a few very large files but won't it make sense to roll LFS into core as well?

schacon 3y ago
What a great question. If I recall correctly, the LFS project is a Go project, which makes it difficult to integrate with Git core. However, I believe that the Git for Windows binary _does_ include LFS out of the box. There was a discussion very recently about incorporating Rust into the Git core project that I think had a point about LFS then being viable due for some reason, but I'd have to find the thread.
- Towaway69 3y ago
  Thanks for the insight. I'm surprised to hear that LFS is Go based, I would have thought LFS outdated Go - but learn something new everyday! :)
  - js2 3y ago
    Looks like it was started in 2015, so Go had about a 6 year head start on it: https://github.com/git-lfs/git-lfs/blob/main/CHANGELOG.md https://github.com/git-lfs/git-lfs/blob/main/CHANGELOG.md

goku12 3y ago

One thing about git I learned the hard way is the use of diffs and patches (more accurately, 3-way merges) for operations like merging, cherry picking and rebasing. Pro-git (correctly) emphasizes the snapshot storage model of git - it helps a lot in understanding many of its operations and quirks. But the snapshot model can cause confusion in the case of the aforementioned operations - especially rebasing. For example, I couldn't understand why the deletion/dropping of a commit during a rebase caused changes to all subsequent commits. After all, I only asked for a snapshot to be dropped. I didn't ask for the subsequent snapshots to be modified. Eventually, I figured out that it was operating on diffs, not snapshots (though storage was still exclusively based on snapshots). The correction on that mental model allowed me to finally understand rebasing. (I did learn later that they were 3-way merges, but that didn't affect the conclusions). That assumption was eventually corroborated somewhere in Pro-Git or the man pages. But I couldn't find those lines again when I searched it a second time. I feel that these operations can be better understood if the diff/patch nature of those operations are emphasized a bit more. My experience on training people in rebasing also supports this. PS: Thanks for the book! It's a fantastic example of what software documentation should look like.

smallpipe 3y ago
> Eventually, I figured out that it was operating on diffs, not snapshots The snapshot include all the history that led to the current snapshot. So even if you did a squash instead of dropping, you're changing everything that depends on that
- goku12 3y ago
  > The snapshot include all the history that led to the current snapshot Git snapshots don't contain any history, other than the commit chain (reference to the parent commit/s) in the commit object. While the storage format is a bit complex, they behave fundamentally like a copy of the working tree at the point of commit. > So even if you did a squash instead of dropping, you're changing everything that depends on that Squashes don't change the subsequent commits/snapshots either, other than the commit ID and chain. The tree itself remains untouched. You can verify this.

vinc 3y ago

I watched the FOSDEM talk yesterday, and I laughed hard when I heard "Who use git blame -L? Does anybody know what that does?" because it suddenly looked like the beginning of a git wat session. But it was really informative, I learned a lot of new things! Thanks

foobarian 3y ago

I chuckled at the title - "So You Think You Know Git" - no, one does not think one knows git :-)

rafacm 3y ago
Except Chuck Norris that is!
- TravelPiglet 3y ago
  Chunk Norris
pantulis 3y ago
Git thinks it knows you.
unclebucknasty 3y ago
Never not a good time for this: https://xkcd.com/1597/ https://xkcd.com/1597/

surge 3y ago

Hey Scot, I met you and we chatted for a bit at a bar after hours at a tech conference years ago, before you dropped you were a GitHub co-founder towards the end. You actually gave me some advice that has worked out well for me. Just wanted to say thanks!

schacon 3y ago
In vino veritas. Thanks for the thanks. :)

bloopernova 3y ago

You probably already know these bits & bobs, but I wanted to share: [diff] external = difft Use the fantastic difftastic instead of git's diff. https://difftastic.wilfred.me.uk/ https://difftastic.wilfred.me.uk/ [alias] fza = "!git ls-files -m -o --exclude-standard | fzf -m --print0 | xargs -0 git add" gone = "!f() { git fetch --all --prune; git branch -vv | awk '/: gone]/{print $1}' | xargs git branch -D; }; f" root = rev-parse --show-toplevel Those are the most used aliases in my gitconfig. "git fza" shows a list of modified/new files in an fzf window, and you can select each file with tab plus arrow keys. When you hit enter, those files are fed into "git add". Needs fzf: https://github.com/junegunn/fzf https://github.com/junegunn/fzf "git gone" removes local branches that don't exist on the remote. "git root" prints out the root of the repo. You can alias it to "cd $(git root)", and zip back to the repo root from a deep directory structure. This one is less useful now for me since I started using zoxide to jump around. https://github.com/ajeetdsouza/zoxide https://github.com/ajeetdsouza/zoxide

bloopernova 3y ago
This one I'm less sure about. I haven't yet gotten it to the point where I really like using it, but I'm sharing since someone might find it useful as a starting point: [alias] brancherry = "!f() { git checkout -b $(git rev-parse --abbrev-ref HEAD)-$(git rev-parse --short \"$1\") $1; }; f" It's intended to be used for creating a cherry-picking branch. You give it an branch name, let's say "node", and it creates a branch with that as its parent, and the short commit hash as a suffix. So running "git brancherry node" creates the branch "node-abc1234" and switches to it. The intended workflow being you cherry pick into that branch, create a PR, which then gets merged into the parent.
ulope 3y ago
difftastic - amazing! I've been wanting something like this for years...
- bloopernova 3y ago
  Be prepared to hand out the difftastic URL and install instructions a lot :) I get asked "what git setting is that?" when I do diffs while sharing my screen.

olvy0 3y ago

Hi Scott! First off, I loved your presentation. And your book. As someone who actually bothers to read most of github's "Highlights from Git" blogs, that the, I was somewhat familiar with some of them, but it was still very informative. Also liked your side-swipe at people who prefer rebase over merge, I'm a merge-only guy myself... I also took a look at GitButler and it looks like it could potentially solve one of my pain points. If you're looking for things which are confusing to beginners, for a future version of your book, there are many useful / interesting / sometimes entertaining git discussions/rants here on HN. One of the recent ones is: https://news.ycombinator.com/item?id=38112951 https://news.ycombinator.com/item?id=38112951

schacon 3y ago
I love the GitHub Git blog posts. They should have a bigger audience. Taylor is a machine.

wrs 3y ago

In the part about whitespace diffs, you might want to mention ignore-revs-file [0]. We check an ignore-revs file into the repo, and anyone who does a significant reformat adds that SHA to the file to avoid breaking git-blame. [0] https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revltrevgt https://git-scm.com/docs/git-blame#Documentation/git-blame.t...

schacon 3y ago
I dont think I knew this. Great tip, thanks!
- js2 3y ago
  Note that git itself doesn't care what the ignore-revs file is called, but GitHub does. It has to be named `.git-blame-ignore-revs`: https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/ https://github.blog/changelog/2022-03-24-ignore-commits-in-t... One other thing you might want to be mention, which is obvious after thinking about it, is that updating the ignore-revs file has to occur in a commit after the one that you want to ignore, since you don't know what that first commit's ID is till after you make it. :-)
  - wrs 3y ago
    Yes! I recommend making a script that does that little dance automatically.

keybored 3y ago

Hey, thanks for a great little series. The part about `--force-with-leash` could include `--force-if-includes` as well. `--force-with-leash` doesn’t do much if you fetch often. https://stackoverflow.com/questions/65837109/when-should-i-use-git-push-force-if-includes/65839129#65839129 https://stackoverflow.com/questions/65837109/when-should-i-u...

CRConrad 3y ago
"--force-with-leash" sounds like git for the BDSM community...

lasereyes136 3y ago

The YouTube video of your presentation is great and I recommend to anyone that wants to learn more about Git or uses Git on a regular basis. Thanks for the info.