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

Beej's Guide to Git

beej.us

Post reply on HN
Print view View original

91–100 of 318 posts

Re: Beej's Guide to Git

#91

Post by sampullman »

ujkiolp wrote: post #50
verandaguy wrote: post #34

Earlier quoted context omitted.

Eh, yes and no. Git porcelain stuff's plenty good for probably 95% of users. `rebase -i` comes with a guide on which commands do what, and you could write a couple of paragraphs about how to format `git log`'s output with your own preferences and tradeoffs -- and porcelain usually includes stuff as eclectic as `git gc`, `git fsck`, and `git rev-parse` by most accounts. Git plumbing's definitely a bit more obscure, an…

not my experience - almost always some edge case leads me to a git rabbit hole tldr: even if you never plan to use anything advanced, you’ll end up in some weird situation where you need to do something even if you’re in the “95% of the users” no shade, yes ofc you “could this, could that” to make things work and we have been stuck with this for so long that an alternative doesn’t even seem plausible

I can't remember the last time I ended up in a weird situation, I stick to basic options with init,clone,fetch,checkout,branch,commit,rebase,remote,log,stash,cherry-pick,blame,config.

It did take maybe a year or so to develop the mental model of the how commands map to the underlying structure of commits, and another few years to avoid footguns (like always "push --force-with-lease").

So I think it is probably too complicated and would be happy to switch to a better alternative if one comes up, but what seems really implausible to me is going back to the bad old days of SVN.

Re: Beej's Guide to Git

#92

Post by pkage »

nektro wrote: post #52
pkage wrote: post #2

I remember reading the excellent Beej's Guide to Network Programming[0] and Beej's Guide to Unix IPC[1] as a teenager, which were incredibly approachable while still having depth—fantastic reads both and very influential on the programmer I ended up being. [0] https://beej.us/guide/bgnet/ [1] https://beej.us/guide/bggit/

[1] https://beej.us/guide/bgipc/

mispasted, thanks!

Re: Beej's Guide to Git

#93

Post by sampullman »

rblatz wrote: post #59
chasil wrote: post #48

Earlier quoted context omitted.

The deal killer for me, the inescapable aspect of my users, is that they insist upon checking passwords into revision control. Because the C and PL/SQL people are on CVS, I can fix this with vi on the ,v archive. First on TFS repositories, and now with git grep I can easily find exposed passwords for many things. But it's just SQL Server! We will never be able to use git responsibly, so I will peruse this guide with…

The devs shouldn’t have access to prod credentials in the first place. That’s the real issue.

Commiting credentials is also a real issue, best to avoid doing both.

Re: Beej's Guide to Git

#95

Post by rtpg »

ajross wrote: post #43
scrapcode wrote: post #26

I can't help but feel that Git has completely missed the forest through the trees that you can make a 30+ part guide explaining how to use it.

My sense, bluntly, is that if people spent half the effort learning git that they do whining about it, no one would bother making a 30+ part guide just explaining stuff you could find in a man page. Commits are snapshots of a tree. They have a list of ancestors (usually, but not always, just one). Tags are named pointers to a commit that don't change. Branches are named pointers to a commit that do change. The index…

I think the trickiness with the simple abstraction is that you end up looking at a commit graph and thinking "I would like to make a couple new nodes in this in a very specific shape, but one that many people have likely done in the past. Is there a trick?"

Like so much of the porcelain is those kinds of tricks, and make otherwise tedious work much simpler.

Imagine if you didn't have interactive rebases! You could trudge through the work that is done in interactive rebases by hand, but there's stuff to help you with that specific workflow, because it is both complicated yet common.

I think jujutsu is a great layer over git precisely because you end up with much simpler answers to "how do I change up the commit graph", though.... the extra complication of splitting up changes from commits ends up making other stuff simpler IMO. But I still really appreciate git.

Re: Beej's Guide to Git

#96

Post by zymhan »

gitgood wrote: post #88
djeastm wrote: post #58

Earlier quoted context omitted.

>And on that note, I feel like the guide covers maybe 10% of Git guh I'm just going to be emailing myself versions of files with MyFile.Final.RealFinal2.txt from now on

[flagged]

Please learn how to understand humor and sarcasm.

Re: Beej's Guide to Git

#97

Post by zeroq »

I think the biggest problem with CVS is the lack of consensus on what and how to push to the repo.

On one hand you have the ideal world scenario when each and every change is granular and you can annotate and blame every single line of code with description. On the other hand you have a real world where teams are encouraged to squash changes so that every commit corresponds to a business requirement and you have to engage a whole cabal to smuggle a refactor.

A long time ago I've implemented a routine to use both SVN and GIT, so that I could use GIT on file save, and SVN on feature release. I think it was inspired by Eclipse workflow. Definitely not something I would recommend these days.

Re: Beej's Guide to Git

#98

Post by vanous »

> GitHub is a web-based front-end to Git.

¯\_(ツ)_/¯

208 mentions of GitHub.

4 mentions of Gitea.

3 mentions of GitLab.

Why is it so biased and why is it helping to continue to teach people to centralized git.

Re: Beej's Guide to Git

#99

Post by wodenokoto »

On the promise of going back in time, I’m finding myself getting more utility of VS Codes timed snapshots than my own commits.

I find it hard to judge when things are in a good enough state to commit and especially good enough to have a title.

I might start writing a new function, decide that I want it to be a class only to give up the class and wanting to return to my almost complete function. Snapshot works pretty well for that, but got isn’t really centered around snapshots and doing good snapshots is not straightforward, at least to me.

What do you guys do?

Re: Beej's Guide to Git

#100

Post by ujkiolp »

sampullman wrote: post #91
ujkiolp wrote: post #50

Earlier quoted context omitted.

not my experience - almost always some edge case leads me to a git rabbit hole tldr: even if you never plan to use anything advanced, you’ll end up in some weird situation where you need to do something even if you’re in the “95% of the users” no shade, yes ofc you “could this, could that” to make things work and we have been stuck with this for so long that an alternative doesn’t even seem plausible

I can't remember the last time I ended up in a weird situation, I stick to basic options with init,clone,fetch,checkout,branch,commit,rebase,remote,log,stash,cherry-pick,blame,config. It did take maybe a year or so to develop the mental model of the how commands map to the underlying structure of commits, and another few years to avoid footguns (like always "push --force-with-lease"). So I think it is probably too co…

>It did take maybe a year or so

we have normalized this for git - a tool to store versions of text. That’s the problem

Post reply on HN