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

381–390 of 430 posts

Re: What comes after Git

#381

Post by WorldMaker »

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.

On the PR side, I'm pretty strict about PRs requiring merge commits (no fast-forwards/squashes/rebases), because that's a useful in source control history of the PR no matter if you switch hosts.

If everything is PRed and all PRs make merge commits `git log --first-parent` in your main branch is your PR history. If PRs are also your unit of CI `git bisect --first-parent` is a bisect on your (PR) integration log.

The only thing missing from your "central database" at that point is comments inside the PRs that aren't accounted for in your final merge message in the merge commit.

Re: What comes after Git

#382

Post by WorldMaker »

EdSchouten wrote: post #2

- A client side virtual file system (FUSE), so that you can work with large repos that exceed the size of your own system. Version control systems like Piper (Google internal) and Eden (Facebook), GitVFS (Microsoft) already do this, but adoption is marginal.

It's also interesting to note that at this point Microsoft seems to be pivoting away from GitVFS. They've put a lot of collective engineering work in git sparse clones and git partial clones and the intersection of the two ("sparse cones") and optimizations like git commit graph pushing git itself to better at virtualizing its object store, not touching objects it doesn't need, and better handling just-in-time scenarios for object retrieval when it really does need them.

Re: What comes after Git

#383

Post by WorldMaker »

geenat wrote: post #14

Native large file support. Git annex functionality built in = gg every other source control system.

Git annex "competitor" Git LFS is bundled in many distros of git today and supported by most of the major hosting providers at this point (if you are willing to pay for LFS space).

Re: What comes after Git

#384

Post by WorldMaker »

ziml77 wrote: post #237

The semantic diffing bullet point has me wondering what attempts there are at making open source semantic diff tools. I love the closed source tool SemanticMerge, but the company behind it decided to be shitwads and pull the product so they could add a selling point to their proprietary version control system.

Several threads here point to difftastic: https://github.com/Wilfred/difftastic

I know a lot of people who have a lot of hope for diffsitter (or something like it): https://github.com/afnanenayet/diffsitter

Personally, I think the reason most "good" semantic diff tools are proprietary is that they are huge amounts of effort that are mostly "hacks" and "heuristics" bandaged together in ways that people don't want to let out how the sausage was made.

But I also think "general, language agnostic AST-based semantic diff" is a mountain peak we cannot reach (probably ever), and I believe my experiments found an interesting local maxima that people are maybe passing by on the way to that ideal mountain (lexer-based diffs rather than parser-based diffs): https://github.com/WorldMaker/tokdiff

Re: What comes after Git

#385

Post by ghoward »

lucideer wrote: post #204

A lot of people responding (in good faith) to the premise of the title but not really engaging with the absolute nonsense points made within it. Aside from it all being very vague, it struck me these are high level concepts and keywords the author seemed to have gleaned from experience working with knowledgeable peers but never quite grokked themselves. So it surprised me to read their open-source maintainer experien…

> Git repos are as atomic as you make them.

Not with submodules, apparently. [1]

> Package managers already use checksums. This entire point is just wrong and ignorant. Reproducible builds would be nice here, sure, but outside of a few weird exceptions in dynamic builds we already have what the author wants here.

I agree with this point, but maybe using the cryptographic hashes from a VCS is better than a checksum? Other than that, I don't think there's any reason to tie the two together.

> This would be great but... the author is an engineer right. How much have they thought about this? This would be a gargantuan undertaking. An awesome feature no doubt, but the maintenance effort...

Actually, not really a gargantuan undertaking. Large, yes, but that's only to tell the VCS about the semantics of each language. The actual algorithms to do so are pretty small, and the semantics needed for each language consists of a lexer and some dumb knowledge about the structure, i.e., what a function looks like, what a type definition looks like, etc. Source: I am designing those algorithms right now.

Other than that, I agree with your points, except that I'm now making a competitor to fossil. :)

[1]: https://news.ycombinator.com/item?id=31792303

Re: What comes after Git

#386

Post by ralgozino »

morelisp wrote: post #379
sophacles wrote: post #372

Earlier quoted context omitted.

Sure there was, it was called stash (and then that was bought by atlassian becoming bitbucket). You could host mercurial repos there until just a few years ago. And at that point, even the use of dvcs was in question, so you could use svn on google's forge, or sourceforge. Launchpad had bzr support too. It wasn't clear github was going to win until it was clear that git was going to win.

Google Code also had hg support before it had git support, if I remember right. Certainly the SVN -> hg migration was easier than SVN -> git if you were using it.

And canonical's launchpad.net

Re: What comes after Git

#387

Post by tommyage »

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…

Maybe you should try a proven front-end in order. Maybe you are kind of a visual learner.

Re: What comes after Git

#388

Post by morelisp »

ralgozino wrote: post #386
morelisp wrote: post #379

Earlier quoted context omitted.

Google Code also had hg support before it had git support, if I remember right. Certainly the SVN -> hg migration was easier than SVN -> git if you were using it.

And canonical's launchpad.net

At the time I’m talking about that was a proprietary forge for bzr, Canonical’s unnecessary version of baz, which was the community fork of tla, which was the GNU experiment in DVCS with an even worse interface than git.

Re: What comes after Git

#389

Post by minitech »

koonsolo wrote: post #366
bvrmn wrote: post #282

Earlier quoted context omitted.

Do/did you use other VCSes? I did. ClearCase, CVS, SVN, Mercurial. It's a real horror (excluding later) to deal with. Sometimes basic operations like merge need separate role (human) to perform. Mercurial is nice if you are a max middle-level and do not use anything besides checkout/commit/push. Any non-trivial stuff requires manual reading (the same as for git) I know you have no time to know your tool. But I don't…

> Do/did you use other VCSes? I did. ClearCase, CVS, SVN, Mercurial. It's a real horror (excluding later) to deal with. I did, plus MS SourceSafe, Team Foundation Source Control and Bazaar. I don't see the problem with SVN and Mercurial. If you have merge conflicts, no tool is going to solve that. If you love git so much, try to do a squash merge to the main, then do some other changes in your branch, and try to merg…

> do a squash merge to the main

If you want Git to continue keeping track of your commits, don’t squash-merge them.

Squash merging loses valuable history in general and use of it is a sign that commits on source branches are being made carelessly.

(That said, if I had to do this, I’d rebase off of the squash before merging again and have no problems.)

Re: What comes after Git

#390

Post by IshKebab »

pdmccormick wrote: post #100

Am I the only one who thinks that Git's UX is fine, and maybe even rather enjoyable? It has taken time to learn, and I am by no means a power user, but its model is now in my brain so, for better or worse, it's how I think and work now too (interactive rebasing for the win, all the time, and lots of shell aliases to shorten things). I do wish I had an easier way to split up a commit that accidentally included several…

Yep I think you might be the only one!

Actually I think you might be misunderstanding what people think is bad. Nobody dislikes the model of Git. It's great. That's partly why it's so popular.

It's the CLI and terminology that are the issue. Some things are very badly named (e.g. the "index"; anyone sane would call that the "draft") and the CLI is a complete mess. Remind me how you list submodules? Or delete a remote branch?

Post reply on HN