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

91–100 of 143 posts

Re: Git tips and tricks

#91

Post by devsda »

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 occassionally while trying to clone a large repo on corporate vpn that can disconnect momentarily for any reason(mainly ISP level). Imagine trying to clone the windows repo(300GB) and then losing the wifi connection for a short time after downloading 95%.

It is wild that both git and docker, the two major bandwidth intensive software of modern development stack don't have proper support (afaik) to resume their downloads.

Re: Git tips and tricks

#92

Post by yjftsjthsd-h »

iraqmtpizza wrote: post #17
goku12 wrote: post #9

Earlier quoted context omitted.

A part of Git's complexity is due to the fact that it was originally meant to be just the plumbing. It was expected that more user-friendly porcelain would be written on top of the git data model. Perhaps that is still the best bet at having a simple and consistent UI. Jujutsu and Got (game of trees) are possible examples.

>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

> as soon as scripts were allowed to use commands, those commands could never be changed

That's not a script thing, that's an API surface thing, and even then only applies to backwards-incompatible changes. You can change the arguments to git or chmod just as easily as printf() or fork()

Re: Git tips and tricks

#93

Post by olvy0 »

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

Re: Git tips and tricks

#94

Post by pwb25 »

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.

I agree, what more is needed than push and diff and branching, sometimes reset and rebase

Re: Git tips and tricks

#96

Post by goku12 »

smallpipe wrote: post #63
goku12 wrote: post #39

Earlier quoted context omitted.

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…

> 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

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

Re: Git tips and tricks

#97

Post by keysersoze33 »

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…

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)

Re: Git tips and tricks

#98

Post by mgbmtl »

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/

Looks neat, but I tend to get way too distracted by graphical interfaces. I assume it's really a question of personal preference. CLIs are faster to use, but have a bigger learning curve. (we will probably not solve that debate here, but I do wonder sometimes, whether to recommend the CLI or not)

Most of my git usage on the CLI is nothing fancy, just a few commands, but I keep a text file for some tips/tricks I don't use regularly.

Re: Git tips and tricks

#99

Post by sodapopcan »

dayjaby wrote: post #15
goku12 wrote: post #9

Earlier quoted context omitted.

A part of Git's complexity is due to the fact that it was originally meant to be just the plumbing. It was expected that more user-friendly porcelain would be written on top of the git data model. Perhaps that is still the best bet at having a simple and consistent UI. Jujutsu and Got (game of trees) are possible examples.

That's a bold statement. Any proof or article where Linus states that?

I wouldn't say it's very bold at all. I don't have any links but if you've been using git for the past decade, you would have heard something along these lines. "A toolkit for building VCS's" is one thing I remember reading. There was little in the way of polish when it came to porcelain commands when people started using it. I think there are still many people who don't use it who still think it's still this way.

Re: Git tips and tricks

#100

Post by sodapopcan »

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/

Shrug back at ya. I find the cli perfectly usable. I use an editor plugin as well but if I'm already on the command line I use it there. Having to switch to a different program just to make a commit kills the desire to commit often.
Post reply on HN