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

Oh shit, git (2016)

ohshitgit.com

Post reply on HN
Print view View original

241–250 of 280 posts

Re: Oh shit, git (2016)

#241

Post by erik_seaberg »

dahart wrote: post #207
cesarb wrote: post #183

Earlier quoted context omitted.

> Aren’t git commits stored as patches? No, they aren't, git commits are stored as snapshots. Each git commit has one tree, which is a snapshot of the state after the commit; zero or more parent commits; a pair of authors with corresponding timestamps; a commit message; and nothing more. Any patch you see in git is an illusion, made by comparing the commit's tree with the parent commit's tree.

Thank you. Sheesh I feel like I should have known this about git. That would make diffing very far apart changes super fast. So what's the advantage to explicit storage in patches over snapshots? Are diffs between snapshots not able to capture the same information that explicit patches have?

The trouble with patches is that you can't get engineers to reliably declare whenever they copy or move code and where it came from. This is part of why svn merging was such a trainwreck, undeclared copies and moves (which look like delete+insert) almost always conflicted.

Re: Oh shit, git (2016)

#242

Post by thatoneuser »

tropdrop wrote: post #76
thatoneuser wrote: post #29

Earlier quoted context omitted.

Git isn't hard but it's usually taught like absolute shit. From the get go you're told to use 4 commands, 2 of which are usually not explained and when they are it's often hand wavey. From there on its usually people pontificating about high level philosophy while failing to give concrete working examples. At least that was my experience. I'm decent at got now for the work I do so I'm cool with it. It really is an aw…

It's just one of those tools that is very foreign to new users, but once you know how to use it, you can't remember not knowing how to use it because it's so easy... this is like a lot of programming, actually.

That's true. Probably why the teaching has such a knowledge gap.

Re: Oh shit, git (2016)

#243

Post by emilycook »

jchw wrote: post #35
_7fvc wrote: post #20

Reading this article, I realize that I'm old now. I still remember wrestling with cvs, svn. Merge, branch were slow and even more challenging. It was much easier to mess up and so difficult to rewind. When I first learned git, I thought it's pretty neat. It solves merge, branch, rewind problems. Git is one of the things in life that doesn't work like the way we think. But it turns out to be a better way.

I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. That’s not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit trac…

> I kind of wish GitLab would implement Mercurial support

Hi! GitLab employee here. Mercurial support has been a hot-ish topic internally. If you want to weigh in then please comment on this Issue, since Issue interaction plays a big part of how we prioritize https://gitlab.com/gitlab-org/gitlab-ce/issues/31600

(edit: I'm an idiot I should've read the full thread first since someone already linked it. gonna leave it up anyway)

Re: Oh shit, git (2016)

#244

Post by zoomablemind »

Git is nice tool, very versatile in able hands. Thanks to its promotion (plugins and github included), the pragmatic practice of source versioning gained wider adoption and lost that beg-your-IT-dept-to-set-it-up flair.

In the mean time, 'thanks' to Git, the source change history became a maintenance line-item. The expectations of a clean history were raised almost to the level of expectations for bug-free code.

I can see a utility of clean feature history, but asking developers to craft the history is shifting their focus away from the actual code. As long as the source state has been saved, the source control has done its main job.

So for the most of the listed 'shits', the developer should just be able to revert, cherry-pick, and re-commit, and keep going. Nothing esoteric and hard to remember, also fairly common commands across different VCS tools. Shit happens and will happen again, no biggie, no need to blame and shame, source annotation will show the right change/comment anyway.

Re: Oh shit, git (2016)

#245

Post by zapita »

jchw wrote: post #35
_7fvc wrote: post #20

Reading this article, I realize that I'm old now. I still remember wrestling with cvs, svn. Merge, branch were slow and even more challenging. It was much easier to mess up and so difficult to rewind. When I first learned git, I thought it's pretty neat. It solves merge, branch, rewind problems. Git is one of the things in life that doesn't work like the way we think. But it turns out to be a better way.

I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. That’s not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit trac…

I used Mercurial exclusively for a long time. I reluctantly switched to Git when it became obvious Github was the place to be if you wanted your open-source project to get any attention.

I think the way forward for Mercurial would be to become a Git frontend, or "porcelain" as they call it. That way we would get the best of both worlds: the ubiquitous git format and hosting infrastructure; and the superior UI and workflow of Mercurial. I'm sure it would be a difficult undertaking, and might require difficult trade offs between compatibility, performance and usability. But I think it would be worth it. For one, Mercurial would become relevant again, and probably get a lot of new users. A lot of users would probably come back. And Git users would also benefit from the renewed competition between competing frontends.

Re: Oh shit, git (2016)

#246

Post by mixmastamyk »

sirsuki wrote: post #187
crispyambulance wrote: post #130

Earlier quoted context omitted.

Git is neither beautiful nor elegant. It survives because it does the job and a critical mass of people has miraculously brought it to prominence. What I will NEVER be able to understand is WHY the commands are so fucked-up, inconsistent and counter-intuitive. It doesn't have to be that way. If git feels comfortable, it's only because you've crashed and burned it so many times or suffered though countless google sear…

The reason "the commands are so [messed]-up, inconsistent and counter-intuitive" is most likely that you expect the commands to represent your mental model of the system when in fact they represent the mental model of the system designers. I once felt it was weird till I dove in and looked at the underlying data model. Then It struck me and all the awkwardness evaporated and the commands actually make sense to me now…

> till I dove in and looked at the underlying data model.

Everyone says that and I've done the same. Quickly forgotten and left with the same inscrutable commands and looking up explanations on stack overflow.

Re: Oh shit, git (2016)

#247

Post by jchw »

dllthomas wrote: post #206
fouronnes3 wrote: post #181

Earlier quoted context omitted.

Even if you understand the data model perfectly, git still has terrible UX. reset can do 3 different things, a "remote" can mean 3 different things depending on context... I could go on all day. Just the fact that there are parodies of git man pages should drive the point home. (Disclaimer: I love git). Oh and what the hell is 'git rerere' anyway?

You love git because your experience, overall, is far from terrible. It's true that there are a lot of inconsistencies to memorize, and that's a worse UX than the equivalent without those inconsistencies, but that only matters so much. We both speak English - we can cope with inconsistencies in a language.

I don't love Git because it’s got a great UX. I love Git because of what can be done once you get past the awful UX.

The first year or two of Git usage ended in many, many incidents of lost work. That is not good UX for source control, its the most catastrophic UX imaginable for something designed to track source changes...

That’s why the site this post is about exists. If you don’t know about reflog, you are severely disadvantaged... and many of my coworkers at my previous employer certainly did not.

Re: Oh shit, git (2016)

#248

Post by dllthomas »

jchw wrote: post #247
dllthomas wrote: post #206

Earlier quoted context omitted.

You love git because your experience, overall, is far from terrible. It's true that there are a lot of inconsistencies to memorize, and that's a worse UX than the equivalent without those inconsistencies, but that only matters so much. We both speak English - we can cope with inconsistencies in a language.

I don't love Git because it’s got a great UX. I love Git because of what can be done once you get past the awful UX. The first year or two of Git usage ended in many, many incidents of lost work. That is not good UX for source control, its the most catastrophic UX imaginable for something designed to track source changes... That’s why the site this post is about exists. If you don’t know about reflog, you are severel…

I guess I'm arguing that UX extends beyond command names and learning curves (while definitely incorporating those things). I'm on-board with the notion that there are aspects of git's UX that are terrible. But as a user, if your experience was awful, you would not love the software.

Re: Oh shit, git (2016)

#249

Post by aeorgnoieang »

dwaltrip wrote: post #41

Git is pretty nice, but I'm sure there is something much better waiting to he invented. The CLI in particular could use a ton of improvements. And I feel it in my bones that there is a revolutionary GUI waiting to be invented. Why can't I drag a commit or set of commits from one branch to another? With safe, easy undo (reflog doesn't count) and super smooth conflict resolution? Etc etc. And of course there is the int…

I used this semantic diff tool before (with Git) and it worked pretty well:

- [SemanticMerge](https://www.semanticmerge.com/)

Re: Oh shit, git (2016)

#250

Post by paulddraper »

jchw wrote: post #35
_7fvc wrote: post #20

Reading this article, I realize that I'm old now. I still remember wrestling with cvs, svn. Merge, branch were slow and even more challenging. It was much easier to mess up and so difficult to rewind. When I first learned git, I thought it's pretty neat. It solves merge, branch, rewind problems. Git is one of the things in life that doesn't work like the way we think. But it turns out to be a better way.

I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. That’s not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit trac…

> So why does it never seem to get consideration? I guess it’s because of the insane proliferation of Github and Linux

Part of it is not wanted to learn multiple VCS's. Part of it is Github. Part of it is performance.

I honestly believe that if Github supported Mercurial, or if Bitbucket had "won" over Github, then Git:Mercurial would be something like 4:1.

Post reply on HN