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

31–40 of 143 posts

Re: Git tips and tricks

#31

Post by schacon »

goku12 wrote: post #25
schacon wrote: post #19

Earlier quoted context omitted.

Boy, I can't find this either (but also, the kernel mailing list is _really_ difficult to search). I really remember Linus saying something like "it's not a real SCM, but maybe someone could build one on top of it someday" or something like that, but I cannot figure out how to find that. You _can_ see, though, that in his first README, he refers to what he's building as not a "real SCM": https://github.com/git/git/co…

Here is what I found based on your lead ("real SCM", from 17 Apr 2005): > That was really what I always personally saw "git" as, just the plumbing beneath the surface. For example, something like arch, which is based on "patches and tar-balls" (I think darcs is similar in that respect), could use git as a _hell_ of a better "history of tar-balls". [1]: https://lore.kernel.org/git/Pine.LNX.4.58.0504170916080.7211...

Nice, yes, I think this is what I was remembering. Good find!

Re: Git tips and tricks

#32

Post by Towaway69 »

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…

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?

Re: Git tips and tricks

#33

Post by Shacklz »

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 understand your sentiment but git is really not all that hard. And knowing a few things that go beyond bog-standard checkout/commit/push, especially history-rewriting activities, will greatly improve quality of commit-history - which might not be of much use for you but might help other engineers working on your project to make easier sense of what's going on.

And on another note, git is probably one of the longer-lasting constants in our industry. Technologies develop and change all the time, but for git, it looks like it's here to stay for a while, and it's probably one of the tools we interact with most in day-to-day dev-work. Might be worth having a bit of a look at :)

Re: Git tips and tricks

#34

Post by Shacklz »

ourmandave wrote: post #20
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.

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 probably meant to stay for quite some time and we interact with quite frequently, it was time well spent for me, and it turns out it's really not as hard as the scary-looking commands imply.

Re: Git tips and tricks

#35

Post by schacon »

Towaway69 wrote: post #32
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…

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?

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.

Re: Git tips and tricks

#36

Post by javier_e06 »

Tips and Tricks are sometimes the way for developers to throw jabs at each other on the 'workflow' battles that every dev team faces. The bells and whistles are all there to run everything from a lemonade stand to a Walmart Super-Center. Hence the overwhelming complexity. Just lately I started running 'git init' in all the new folders I create in my development box. Heck, is good to see whats going on everywhere you work, not only in the designated git repos. But going back to the well known complexity of the git API's I recall the the song that goes: "It takes a man to suffer ignorance and smile"

Re: Git tips and tricks

#37

Post by withinboredom »

iraqmtpizza wrote: post #30
goku12 wrote: post #21

Earlier quoted context omitted.

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

Ha, replacement? You can't even get them to fix bugs. If you fix a bug in a unix command you'll break every script in existence and bring the world down. It's idiotic. The user's a file! The internet's a file! Keyboard is a file! What are checkboxes? This is a volunteer project! You can't expect us to include UI in the OS! We'll just bikeshed forever so sorry, write your own, lol.

Getting a bug fixed in rsync, pulled down to LTS Ubuntu took a single email. I’m not sure what you are going on about.

Re: Git tips and tricks

#38

Post by Towaway69 »

schacon wrote: post #35
Towaway69 wrote: post #32

Earlier quoted context omitted.

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?

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

Re: Git tips and tricks

#39

Post by goku12 »

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

Re: Git tips and tricks

#40

Post by mikro2nd »

Shacklz wrote: post #33
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 understand your sentiment but git is really not all that hard. And knowing a few things that go beyond bog-standard checkout/commit/push, especially history-rewriting activities, will greatly improve quality of commit-history - which might not be of much use for you but might help other engineers working on your project to make easier sense of what's going on. And on another note, git is probably one of the longer-…

I'd argue that CVS outlasted git by at least a couple of decades...
Post reply on HN