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

What comes after Git

matt-rickard.com

Post reply on HN
Print view View original

71–80 of 430 posts

Re: What comes after Git

#71

Post by bandie91 »

rswail wrote: post #59

I'd really like issues porcelain that is built over git so that when I clone I get all of the project's history, as well as it being merged with pull requests etc. I hate that the github/lab hosting solutions end up with a central database to keep track of issues, CI, etc. It breaks the whole "distributed" model.

i worried about the issues/tickets are centralized, too. so i put them in the repo itself as files and asked contibutors to submit tickets by PR into dedicated subfolder. i'd be worth to standardize it.

Re: What comes after Git

#72

Post by viraptor »

enasterosophes wrote: post #58
lloydatkinson wrote: post #46

Earlier quoted context omitted.

What’s wrong with the author?

Well, you can look at the author's past HN submissions to see what was meant. It's basically click-bait for hackers. "How to do X technology better" with a few paragraphs of ideas, and taking no responsibility for actually doing something about it, aside from hoping that their vision might inspire someone else to put in the hard work.

Some of us like to read ideas. The blog is more on the personal brand building side, sure. But I'm mainly coming to HN and comments to read what other people think about stuff.

Re: What comes after Git

#74

Post by vaughan »

kache_ wrote: post #7

Nothing. Keep it simple. There's a reason it has stuck around >inb4 it isn't simple it is

No one chooses to use git. They don’t say: let’s use it because it’s simple. It’s really the only choice because of network effects. It’s one of the biggest glaring monopolies in tech. Think about the barriers to entry of a new vcs. GitHub/gitlab support. Ide support.

Re: What comes after Git

#75

Post by kardos »

mikewarot wrote: post #39
nine_k wrote: post #12

Earlier quoted context omitted.

On the surface: - Git is slow on large repos, even on an SSD. - Git has trouble with large objects; git-annex and git-lfs sort of help, but are bolted on, not integral. - Git's submodules are unergonomic at best. - Git's CLI is a mess. Deeper: - Git has no idea of a conflict as a first-class object; hence merges and rebases with the user fixing the same conflicts multiple times (and `git rerere`). Compare this to Pij…

>Git is line-oriented and has no notion of semantic diffs and semantic merges. This makes it a raw tool when working with, ironically, source code. Git is a content addressable snapshot system, with bolted on code to make it retrospectively appear to be a line-oriented system. It's worse than you thought.

As I understand it, you can configure git's difftool to be something more clever than line based

Re: What comes after Git

#76

Post by alexchamberlain »

madmax108 wrote: post #37

I personally believe that making diffs more human friendly is the next step of evolution we need. I work with a team on a NodeJS+React project and nearly every other PR shows up as "Something changed in package.json, something changed in package-lock.json, some static assets added/modified, some JSON changed" etc and it makes reviewing code quite unwieldy (esp. since it forces folks to use Github UI interface to even…

I feel like you may be blaming the tool for a social problem there. We have a simple rule: no changes to package* in a feature PR. Adding a dependency? Cool, upgrade everything first, then add it fresh. (Be reasonable there- the idea is that the add should be clean, so if that can be done without doing a major upgrade, that is of course fine.)

Re: What comes after Git

#77

Post by formerly_proven »

nine_k wrote: post #12
stellalo wrote: post #4

> I saw the pain points of git What are these? Asking for real: it’s the second time I read a similar sentence on HN this week, without finding any specifics, so I’m curious

On the surface: - Git is slow on large repos, even on an SSD. - Git has trouble with large objects; git-annex and git-lfs sort of help, but are bolted on, not integral. - Git's submodules are unergonomic at best. - Git's CLI is a mess. Deeper: - Git has no idea of a conflict as a first-class object; hence merges and rebases with the user fixing the same conflicts multiple times (and `git rerere`). Compare this to Pij…

Diffs aren't actually a first-class object either, they're made up on the spot. Git just stores a complete snapshot for each commit; delta compression in the repo is incidental and unrelated to the diffs you see.

Re: What comes after Git

#78

Post by bloak »

Akronymus wrote: post #47
saxonww wrote: post #36

Earlier quoted context omitted.

In my experience they are correct all of the time for simple renames. It's when you move a file and make substantial edits that it gets confused. I think it's reasonable to argue that git shouldn't get confused in this scenario, but you could also do your renames in one commit and your changes in another.

Would it make sense to make one commit for the move and one for the changes?

Yes, in some cases, but it depends on your workflow. Some projects require each commit on the main branch to be fully working and pass all the tests.

Re: What comes after Git

#79

Post by vaughan »

torginus wrote: post #13

My main issue with Git, other than the terrible UX of the CLI, is just how common it is for one to want to rewrite the commit history - an operation for which there's no version control. You better get it right, or otherwise you get to nuke the whole repository.

Big issue is parent commit hash included in the commit hash. You have to rehash all commits following a history change.

Re: What comes after Git

#80

Post by relyks »

silisili wrote: post #66

Every time I use Git, I see how bad the UX is and marvel at how it ever became popular. Even a simple merge/rebase leaves one confused. Which should I use? What is incoming? Why does incoming change as you progress? I didn't change anything (on purpose) but Git won't let me change branches. What the hell does stashing do? How do I just unfuck what I did and go back to a branch? These are rather common use cases, and…

You and me both. Git's interface has been very hard for me to understand (especially coming from Mercurial). I ended up finding Gitless (https://gitless.com), a wrapper around Git with a better interface, and loving it. The original author hasn't updated it in a long time, but I've been using a maintained fork that's been pretty sweet: https://github.com/goldstar611/gitless
Post reply on HN