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

Git tips and tricks

blog.gitbutler.com

Post reply on HN
Print view View original

101–110 of 143 posts

Re: Git tips and tricks

#101

Post by wrs »

schacon wrote: post #2

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

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

Re: Git tips and tricks

#103

Post by kraftman »

BerislavLopac wrote: post #95

I never really understood why the majority of developers insist on using the git CLI, when modern UI clients like GitKraken [0] are perfectly usable and very helpful. :shrug: [0] https://www.gitkraken.com/

I do as little with git as possible unless im facinng some very specific issues, so for me at least it seems overkill to use a GUI for essentially just push, pull, and checkout.

Re: Git tips and tricks

#104

Post by schacon »

wrs wrote: post #101
schacon wrote: post #2

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

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

I dont think I knew this. Great tip, thanks!

Re: Git tips and tricks

#105

Post by schacon »

olvy0 wrote: post #93
schacon wrote: post #2

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

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

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

Re: Git tips and tricks

#106

Post by schacon »

devsda wrote: post #91

Learnt something new about core.fsmonitor. Thanks. On the subject of large monorepos, I wish "git clone" has a resume option. I had this issue back in 2000s when trying to clone the kernel repo on a low bandwidth connection. I was able to get the source only after asking for help on a list and someone was kind enough to host the entire repo as a compressed tar on their personal site. I still have this problem occassi…

I suppose you could do this by shallow cloning and then expanding it multiple times. But yes, the fetch/push protocols really expect smaller repos or really good inet connections and servers.

Re: Git tips and tricks

#107

Post by js2 »

bloopernova wrote: post #75
schacon wrote: post #2

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

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/ [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…

meta-tip: you can also put your aliases that start with '!' into stand-alone shell scripts named `git-fza` (e.g.) and then call it as `git fza` which will search your PATH for `git-fza` and invoke it as if it's built-in.

I do this for some of my more complicated aliases because I generally think it's poor form to embed shell scripts into configuration languages. (Looking at you, yaml.)

Re: Git tips and tricks

#108

Post by saiya-jin »

Shacklz wrote: post #34
ourmandave wrote: post #20

Earlier quoted context omitted.

Honestly, get outside of commit and pull and my brain feels dread like regular expressions. Hopefully the incantation is on the Cheat Sheet and I don't make it worse.

I had the same experience for a long time and then I took a bit of time to have a deeper look behind the curtain and I have to say, once you grasp the data-model of git itself (a branch is a pointer to a commit, a commit is a pointer with metadata to a tree, a tree is...), many of the commands start to make sense all of a sudden, or at the very least "stop looking dangerous". As it's one of those rare tools that's pr…

This generic statements can be said about basically any technology (MS MFC anybody? (L)DAP? IBM Websphere studio J2EE abominations?) if you are smart enough / have enough time to dig around. It doesn't help discussion at all (and plenty of folks complain about git all the time), since one can't avoid being branded as lazy/stupid if its not grokking this uber important yet trivial tool like me (TM).

But then there is Mercurial, used it decade and a half ago and it contained literally everything good about distributed model I could ever wish for, with maybe 50% of Git's complexity. Yet cargo-culting gonna cargo-cult, if Linus uses it so must we since we are not subpar and the rest be damned.

Yes sure its the tool to stay, and eventually can be learned well. But its design is far, very far from the most important software design principle (KISS).

Re: Git tips and tricks

#109

Post by js2 »

schacon wrote: post #104
wrs wrote: post #101

Earlier quoted context omitted.

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

I dont think I knew this. Great tip, thanks!

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

Re: Git tips and tricks

#110

Post by js2 »

Towaway69 wrote: post #38
schacon wrote: post #35

Earlier quoted context omitted.

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.

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! :)

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

Post reply on HN