Live data from Hacker News

Lore – Open source version control system designed for scalability

lore.org

371–380 of 717 posts

Re: Lore – Open source version control system designed for scalability

#371

Earlier quoted context omitted.

Isn't this just the same thing as `git mv`?

I don't think so, but I'm not sure. It seems to imply that renaming a file without using `lore stage` subcommands will record a delete and an add, meaning that changes made in a branch prior to the rename won't automatically propagate. Git will detect this without using it's own mv command.

No they're saying that it will explicitly record the move, unlike Git which has to guess (it often fails).

Re: Lore – Open source version control system designed for scalability

#372

As long as Epic Games is anti Linux I will never use any Epic Games product. Count on it.

I'm not a gamer so I'm entirely ignorant of the situation. What's the root of your objection? The games are proprietary, right? So I figure it's not a Stallmanesque position. Is it a big problem to run games on Windows?

Re: Lore – Open source version control system designed for scalability

#373

Earlier quoted context omitted.

They're actually saying it's better than `git mv`, because it actually records the move, unlike Git.

I think they're saying the opposite. It won't detect a filesystem-level move. It will simply record a delete and create without the relationship. Git does record the rename, though: ~/work/tmp/repo git init . --quiet ~/work/tmp/repo master echo 'foo' > foo.txt ~/work/tmp/repo master? git add . ~/work/tmp/repo master+ git commit -m "create" --quiet ~/work/tmp/repo master mv foo.txt bar.txt # no `git mv` ~/work/tmp/rep…

> Git knows that the file was renamed even without using git to do the rename.

No it doesn't. Git knows that file A was deleted and file B was created, and if they have the same content then it will guess that it was a rename. But it's a heuristic that doesn't always work. E.g. I think it doesn't try to guess for large diffs, and it doesn't work if you modify the file in the same commit.

Re: Lore – Open source version control system designed for scalability

#374

Earlier quoted context omitted.

That sucks, git is so absolutely horrible. It's crazy to me that nobody has made anything better yet. Although I could start that myself and yet have not.

There are some projects: * https://github.com/jj-vcs/jj * https://nest.pijul.com/pijul/pijul

Also some older but still kicking alternatives:

* https://darcs.net/

* https://mercurial-scm.org/

Re: Lore – Open source version control system designed for scalability

#375

Earlier quoted context omitted.

I don't think so, but I'm not sure. It seems to imply that renaming a file without using `lore stage` subcommands will record a delete and an add, meaning that changes made in a branch prior to the rename won't automatically propagate. Git will detect this without using it's own mv command.

No they're saying that it will explicitly record the move, unlike Git which has to guess (it often fails).

Git does record the move, and you don't have to use the git ui to do it. Lore says it requires `lore stage move` to record it. More details in the reply to your other comment.

Re: Lore – Open source version control system designed for scalability

#376

Just today as I pushed some changes to Github, I was thinking how user-unfriendly Git's UI is: Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 10 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 290 bytes | 290.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (2/2), completed with 2 local obje…

This has bothered me ever since I was using git for the first time: what do you mean I have to 'add' and 'commit' and then 'push'? I just want to save my stuff, this is SO many steps.

Re: Lore – Open source version control system designed for scalability

#377
post #136

Just today as I pushed some changes to Github, I was thinking how user-unfriendly Git's UI is: Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 10 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 290 bytes | 290.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (2/2), completed with 2 local obje…

Objects are your files. Underlying git is a content-addressable filesystem. The objects are referenced by trees. A tree is just a directory. The trees are then referenced by commits and/or tags into a DAG with named pointers into various parts of it (which are your branch and tag references): https://git-scm.com/book/en/v2/Git-Internals-Git-Objects Because it would be terribly in-efficient to have a bunch of loose ob…

The point is that if it's useless information for 99.9% of users, what's it doing in the UI?

Re: Lore – Open source version control system designed for scalability

#378

Earlier quoted context omitted.

Probably unacceptable as many would have built tooling around the specific default behaviors.

If tooling is relying on the output format of porcelain commands, it's wrong. The output of various subcommands have already changed more than once.

Relying on porcelain commands' output is the official way of interacting with git, they famously always refused to break it into a library. Nobody is going to use the low level git commands because: 1. Their output isn't any more reliable than the porcelain, and 2. How the porcelain uses them is also subject to change, so your UI might end up doing something different from the git high level command which is undesirable.

At least they gave us the `--porcelain` flag, meant exactly for this use case, to make the output format of porcelain commands never change. Dumb flag name, though.

Re: Lore – Open source version control system designed for scalability

#379

Earlier quoted context omitted.

Something else that git isn't good at: permissions. In gamedev, you might have proprietary work that you want to restrict to certain users. In P4, you can add restrictions to certain directories for only those who have signed the required NDAs. That's not something that you can do in git: it's all or nothing. Maybe you can set something up with submodules, but that's going to upend your repository if you hadn't plann…

That always seemed crazy to me about git. Permissions are a pretty basic enterprise offering. Does Gitlab do better with this?

How is it crazy? It's perhaps not granular (the repository is the boundary, and that's that), but you can definitely restrict who can pull or push as easy as you can make rules for SSH.

Plenty of not-very-granular "enterprise" systems out there, it's not exactly unique to not always have full ACLs on the smallest of objects.

Re: Lore – Open source version control system designed for scalability

#380

Earlier quoted context omitted.

I’ll chip in here and say theres ime a world of difference between the amount of condescension and acerbic noise produced by Blow versus Casey. Casey comes of as grumpy but fundamentally pretty respectful in the stuff I’ve seen him in.

I have only seen Casey's writing in the whole "why is the terminal so slow" debacle, but he was a massive jerk in that. He was right! But still a jerk.

I often feel that while Casey can end up saying you're an idiot, he does not believe you are, only the things you do are. And given the chance, he will happily and warmly engage with "why smart people do idiotic things".

Whereas JB actively thinks you're an idiot, and the things you do are idiotic because of your stupidity, period.

Post reply on HN