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

111–120 of 143 posts

Re: Git tips and tricks

#111

Post by rendaw »

chx wrote: post #49

Thanks, I knew about -committerdate but not that you can set it as default sort, super useful. A few notes... 1. git columns gets real confusing if you have more data than fits the screen and you need to scroll. Numbers would help... 2. git maintenance sounds great but since I do a lot of rebases and stuff, I am worried: does this lose loose objects faster than gc would? I see gc is disabled but it's not clear. 3. Re…

Is there a way to do the reverse sort? A simple solution to branches going off screen seems to be have the latest branch last. That's what I do (although with a custom script).

Re: Git tips and tricks

#112

Post by wrs »

js2 wrote: post #109
schacon wrote: post #104

Earlier quoted context omitted.

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

Yes! I recommend making a script that does that little dance automatically.

Re: Git tips and tricks

#113

Post by bloopernova »

js2 wrote: post #107
bloopernova wrote: post #75

Earlier quoted context omitted.

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

Oh nice, I didn't know that!

For git fza I override an oh-my-zsh alias "ga" to run it.

Re: Git tips and tricks

#114

Post by phillco »

goku12 wrote: post #39
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…

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

Julia Evans wrote a nice blog post about this recently, in that sometimes it's helpful to think commits as snapshots and sometimes as diffs.

https://jvns.ca/blog/2024/01/05/do-we-think-of-git-commits-a...

I guess while it's true the storage layer is snapshot based, as you say, that only gets you so far conceptually, and it's probably best to focus on the _operation_ you're doing, as rebase, cherry-pick, apply-patch, etc are easier to think in terms of diffs.

When I used to use Phabricator, the fact that I could always fall back to handing it a raw patch file to submit changes also made it easier to reason about (regardless of what the server and client were actually doing).

Re: Git tips and tricks

#115

Post by keybored »

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…

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

Re: Git tips and tricks

#116

Post by sunshowers »

goku12 wrote: post #21
iraqmtpizza wrote: post #17

Earlier quoted context omitted.

>originally meant to just the plumbing this describes all of unix. as soon as scripts were allowed to use commands, those commands could never be changed. lest we have a nerd riot on our hands

Creating an alternative UI is rather uncontroversial. The plumbing doesn't need replacement. Jujutsu for example, seems to be popular.

Note that Jujutsu is not exactly a frontend for Git (it is only loosely coupled to Git) -- Git is one of at least two backends for Jujutsu.

Re: Git tips and tricks

#117

Post by svieira »

js2 wrote: post #107
bloopernova wrote: post #75

Earlier quoted context omitted.

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

I have several scripts like that in my PATH, but Git on Mac can never find them. What am I doing wrong?

Re: Git tips and tricks

#118

Post by pdimitar »

keysersoze33 wrote: post #97
bloopernova wrote: post #75

Earlier quoted context omitted.

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…

Thanks for the difftastic & zoxide tips! However, I've been using this git pager/difftool: https://github.com/dandavison/delta While it's not structural like difft, it does produce more readable output for me (at least when scrolling fast through git log -p /scanning quickly)

Yep, I tried at least 3 other differs (difft included) but delta was perfect and still is. Using it all the time.

Re: Git tips and tricks

#119

Post by mook »

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…

That sounds like you want git bundles†; however, that still requires somebody to create the bundle in the first place…

† https://git-scm.com/docs/git-bundle

Re: Git tips and tricks

#120

Post by samatman »

patatino wrote: post #3

I do not want to learn git tricks. I just wanna use it as simple as possible. Just let me push my code and be done with git and keep on working. Kudos to all who love git, for me, it's just a tool I have to use.

It's unfortunate that the weight of ecosystem and tooling (and the 800 point Microsoft-owned GitHub gorilla) has effectively locked the profession into using git. I don't hate it, I'm just keenly aware that a better approach is possible.

I wish someone with deep pockets would hook the pijul team up with the money and talent they need to make pijul a full-featured alternative with first-class hosting tools. The way it models change is principled and based on solid theory, and I'm convinced that a markedly better tool than git could be built on that foundation.

Post reply on HN