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

271–280 of 430 posts

Re: What comes after Git

#271

Post by sophacles »

indy wrote: post #69
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…

I wonder how many centuries of developer time have been wasted trying to "unfuck what I did and go back to a branch"?

Not as many as svn or cvs for sure. That's part of why it became popular. There was a job title "merge master" - literally there were people who's job was to handle merging in various feature branches. If you didn't have this person you risked days or even weeks of downtime because no one could use the central server without risk of making the situation worse. You would regularly open a file and find your work had been stomped on because one person added a small doc fix in their version of a file and merged it after your work went in, but the vcs didn't really merge, it just overwrote.

I'm not saying it can't be better - clearly it can.

Just pointing out that one person spending a little time unfucking a branch is massively superior to everyone not being able to work because that same person fucked up everyone's branches.

Re: What comes after Git

#272

Post by carapace »

hardware2win wrote: post #242
omnicognate wrote: post #188

Earlier quoted context omitted.

You don't need to learn its internals or read its code. You do need to learn what it does . This is not unreasonable, and is not the reason its interface is a mess.

Previous poster literally writes about implementation details. >You can, however, learn Git by reading about its architecture: blobs, trees, commits, pointers to commits (refs), and index (staging area where new commits are prepared). Impl details of e.g dbs, std libs, runtimes, compilers, etc are for advanced/expert cases, not for slighly above normal

Blobs, trees, commits, refs, and index are not "internals" or "implementation details", they are the domain.

It's like how for a word processor the domain is text, et. al., or for e.g. Inkscape the domain is SVG.

Git has two levels, called "plumbing" and "porcelain" (I think.)

The "plumbing" (blobs, trees, commits, refs, and index) is elegant and easy to understand and use.

The "porcelain" is where everybody gets bogged down. I'll omit my own opinion (low) and just say that most of the problems people have with git seem to be related to trying to do complicated things with the crummy UX porcelain.

And that seems to be because they learned the porcelain but not the plumbing.

So what you're hearing is people advising people to learn the plumbing (as a side effect the porcelain becomes less unbearable.) In fact, if you know the plumbing you can write your own porcelain, and it's not hard and the code is brief because git is actually elegant and easy to understand and use.

Re: What comes after Git

#274

Post by Aozora7 »

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…

I find git reasonably understandable as long as you are using a GUI. When you have a GUI, every action you take provides you visual feedback, so it's way easier to understand the purposes of merges, rebeases, stashes, and resets. My understanding of git workflow greatly improved thanks to it.

Re: What comes after Git

#275

Post by arein3 »

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…

Use sourcetree (older versions) or smartigit(similar ui to sourcetree) if you are on linux

Makes life a lot easier

Re: What comes after Git

#276

Post by vagab0nd »

japanuspus wrote: post #42
pgt wrote: post #15

Implicit branching in Pijul is a killer feature (IMO): https://pijul.org/

Yes, came here to plug Pijul as well: for distributed version control, the "first-class conflicts" of Pijul seems to be a step in the right direction. For anyone who hasn't looked at Pijul, the theory part of the documentation [0] is well worth a read. [0]: https://pijul.org/manual/theory.html

How production-ready is Pijul? I heard about it some time ago and was super impressed. But apparently at the time it had issues, and was going to be re-written in a different language.

Re: What comes after Git

#277

Post by kadoban »

shikoba wrote: post #99
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.

> It's when you move a file and make substantial edits that it gets confused. It's your POV that it's the same file. One could argue that it's a new file and the content of the old one embed in the file. That's the huge problem with git users, people cling desperately to the idea of changes, when git is just about snapshots.

Git has both concepts, snapshots and changes. You'd have to contort yourself more than a bit to describe common uses of "git rebase" without viewing it as changes, for instance.

You may be aluding to git's underlying storage being snapshot based, but it actually also has diffs in pack files.

Re: What comes after Git

#278

Post by dasil003 »

andyjohnson0 wrote: post #226
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…

I agree. I use git on a daily basis, and I think I'm converging on some intermediate level of understanding, but I constantly find it difficult to use. I go backwards and forwards between wondering whether (after three decades as a developer) my brain is just too used to the SVN approach of centralised repositories and branches-are-directories -- and at the other extreme thinking that there is something unbalanced(?)…

This take is surprising to me as I spent a decade using cvs/svn and at the end of that I didn’t really understand how it worked well enough to have any confidence branching and merging. Switching to git was a steep learning curve but made so much more conceptual sense that in a few months I was very confident in branching and merging and with a couple years had a deep and intuitive understanding of rebasing. Git allows me to edit my work before I push it, committing early and often to help my local development, then editing and packaging into atomic and well-documented commits that will make sense years down the line without wading through the irrelevant hiccups that were part of the short-term development cycle.

I won’t defend the git porcelain because it is incredibly baroque, but because it’s backed by a robust a simple data model underneath I see that as more of a rote memorization challenge than a fundamental flaw. This is far preferable to svn which conflates repos, directories, branches and tags, resulting in the possibility of nonsensical operations and unresolvable merge situations.

Re: What comes after Git

#279

Post by elsjaako »

hardware2win wrote: post #242
omnicognate wrote: post #188

Earlier quoted context omitted.

You don't need to learn its internals or read its code. You do need to learn what it does . This is not unreasonable, and is not the reason its interface is a mess.

Previous poster literally writes about implementation details. >You can, however, learn Git by reading about its architecture: blobs, trees, commits, pointers to commits (refs), and index (staging area where new commits are prepared). Impl details of e.g dbs, std libs, runtimes, compilers, etc are for advanced/expert cases, not for slighly above normal

These aren't implementation details, these are the things you are actually dealing with when you use git.

You have to have some mental model of what the program is doing. With SVN it's basically "the server has the latest version, you can download or update that". With git it's "You have commits (snapshots of the whole state of your directory) which are addressable by the hash of that commit and refer back to previous commits. Also, here's a bunch of tools to manipulate and share that". The gp list of terms you should know is pretty close to just covering that.

For me I like git because it doesn't guess what I want to do, it give me tools to do what I want and then does what I tell it.

Re: What comes after Git

#280

Post by pmeunier »

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…

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

Compare this with Pijul as well!

I've been working on legit.pijul.com (you can try it, but nothing is ready!), which leverages byte-level storage to get higher-level diffs (I know this sounds counter-intuitive, but finare storage granularity gives you more flexibility to compute diffs).

That said, Git isn't actually line-oriented, 3-way merge is. But then even a byte-oriented 3-way merge would give the same shitty merges as Git.

Post reply on HN