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

Git for Computer Scientists (2010)

eagain.net

Post reply on HN
Print view View original

91–100 of 110 posts

Re: Git for Computer Scientists (2010)

#91

Post by ojbyrne »

sigjuice wrote: post #88
avalys wrote: post #25

Earlier quoted context omitted.

Things have gotten a little better. But, try to do something off the beaten path in Git, and you may ultimately get the joke. For example: “two weeks ago an intern accidentally committed a file containing IP we’re not allowed to use, we need to erase it from the repository and all developer machines.” Have fun with that one! EDIT: I mean, try to figure this out from the official Git documentation ( https://git-scm.co…

Curious why the IP address has to be obliterated from history instead of just correcting it in a new commit? An IP does not seem sensitive like a secret or private key. EDIT: Sorry, my bad. I misread.

I believe in this case, IP == Intellectual Property.

Re: Git for Computer Scientists (2010)

#92

Post by usr1106 »

Izkata wrote: post #72
umvi wrote: post #20

I just think of git as a graph and branches/tags as text pointers to nodes in the graph. Doesn't seem that complex to me... Maybe I "got gud" though and can no longer empathize with git beginners

Yeah, something along these lines is how I've explained it to co-workers as well. Tossing in "git log --all --oneline --decorate --graph" so they can actually see the graph also helps a lot.

    gitk --all
is even better. Most people don't work in front of VT100s today.

Actually I work most of the day remotely in `screen` on my office machine. But in case of complicated/confusing/buggy history/branching I fetch for the repo so I can run gitk locally.

Re: Git for Computer Scientists (2010)

#93

Post by Igelau »

crispyambulance wrote: post #81
Igelau wrote: post #28

Earlier quoted context omitted.

It could be hard if you never took Discrete or another course that introduces graph theory. Or if you cheated your way through or barely scraped by. I can see how a CS freshman or someone from another field might struggle, but even then it's more comprehensible than any of the alternatives.

The hard part of git has never been the understanding its graph model. The hard part HAS ALWAYS BEEN is memorizing all those badly named and counterintuitive commands.

Even that is only true if you're coming from a system where branch, tag, and checkout mean something else.

Re: Git for Computer Scientists (2010)

#94

Post by usr1106 »

lanstin wrote: post #39
hyperman1 wrote: post #36

Earlier quoted context omitted.

My experience with git is it's organically grown, and regularly a mess. It works reasonably well and in fact is better than a lot of alternatives, but can become a monster quickly and unexpectedly. My experience with mercurial was better than with git. But none of this matters, as git/github/gitlab is today the industry standard, or even the category killer for version control. You will have to deal with it in one ca…

The main thing to know for newbies is as long as you don’t force push to a remote branch, it is safe. You are creating new state only, not destroying. All errors are Recoverable.

Even force pushing is not really a problem. If you don't want to keep every typo and braindead approach in history, force push is a required tool.

Naturally things go wrong occasionally, but garbage collection is not run often. You only need to know the SHA-1 and you can fetch "lost" commits again.

Old SHA-1s can be found in reflog. We also have all pushes automatically announced all in chat, so you can look up previously pushed SHA-1s in chat history (we use gitlab and zulip and those support it out of the box).

Of course you still need a mental model how git history (including history rewriting) works, othwerwise you cannot understand what exactly went wrong. And without knowing what went wrong fixing it gets awkward trial and error, which unfortunately many less experienced git users seem to do.

Re: Git for Computer Scientists (2010)

#95

Post by LAC-Tech »

u801e wrote: post #89
LAC-Tech wrote: post #75

Earlier quoted context omitted.

> git log -p origin/master..HEAD See THIS is the problem. Ugly, inconsistent, clumsy use of the english language, and confusing. This will go on my git sheet, with a comment as to what it actually does because I don't have the time to actually unpack that from first principles. I've got better things to do than become an expert on needlessly complicated software.

> See THIS is the problem. Ugly, inconsistent, clumsy use of the english language, and confusing. It's a command line interface, not plain English. What's ugly and inconsistent about the git log command as was quoted in your reply? > I've got better things to do than become an expert on needlessly complicated software. As a software developer, I have to read through a lot of documentation to be able to use programmin…

I use plenty of command line interfaces everyday. Most of them are pleasant, predictable, and easy to remember. None of them consistently confuse me like git does. (How many different things does 'checkout' do?)

SQL is not only much more intuitive than git, it gives me amazing leverage to deliver value to clients. By comparison, git wastes my time. There's zero or minimal competitive advantage to using it over any other VCS.

Re: Git for Computer Scientists (2010)

#96

Post by actually_a_dog »

umvi wrote: post #20

I just think of git as a graph and branches/tags as text pointers to nodes in the graph. Doesn't seem that complex to me... Maybe I "got gud" though and can no longer empathize with git beginners

I think that's a fine perspective for a computer scientist or graph theorist, myself. Fortunately, since the article title is "Git for Computer Scientists," that's essentially the approach the article takes. :-)

Re: Git for Computer Scientists (2010)

#97

Post by rubyist5eva »

Spivak wrote: post #52
rubyist5eva wrote: post #22

Earlier quoted context omitted.

Because that's exactly what it is, and it's not. When I explain git to newbies in this way, it's like something clicks in their brain and they just start to "get it" as well.

But then once you get the mental model you spend the other 90% of the time figuring out what magic incantations are needed to transform the graph in the way you want.

90% of the time you can achieve what you want with `git rebase -i`

Re: Git for Computer Scientists (2010)

#98

Post by andi999 »

booleandilemma wrote: post #63
andi999 wrote: post #55

Earlier quoted context omitted.

Thanks. They really seem to have a bias against deleting (and not so good rationalizations): https://fossil-scm.org/home/doc/trunk/www/shunning.wiki Apart from that, did you try it, and was it smooth?

I tried it just for an afternoon, but I did find it easy to work with. I find git easy to work with too though, as long as everyone sticks to a well-defined workflow and doesn’t do anything weird.

Maybe that is the problem here, we do not have a defined workflow. Do you know of any good workflow sheet for git we can lift ideas from?

Re: Git for Computer Scientists (2010)

#99

Post by uhhhhhhhhhhhhhh »

RobRivera wrote: post #85
umvi wrote: post #20

I just think of git as a graph and branches/tags as text pointers to nodes in the graph. Doesn't seem that complex to me... Maybe I "got gud" though and can no longer empathize with git beginners

i honestly feel people are allergic to rtfm

There needs a canonical git repo on which TFM allows a notebook-esque running of the many forms of each command

Re: Git for Computer Scientists (2010)

#100

Post by sleepychu »

nerdponx wrote: post #78
sleepychu wrote: post #48

Earlier quoted context omitted.

`git checkout` great for switching to a different commit and for throwing away local unstaged changes!

Using `git checkout` with a filename really really really should have a yes/no prompt by default, or at least an `-i` option like `rm`.

I think `git switch` is an attempt to resolve this
Post reply on HN