651–660 of 717 posts
never trust epic
Why not?
Earlier quoted context omitted.
A significant part of my job, unfortunately, is helping people fix their workspaces when Perforce (p4) goes bad, or creating guardrails and wrappers to stop Perforce doing bad things. In fairness, p4 predates most of the VCSes we consider "modern", so I empathize with a lot of the underlying architecture decisions. However, it has and continues to utterly fail at improving at a reasonable pace. For example: - p4 trac…
> Scripting p4 is a nightmare This is why I wish more command line tools were split into a library that does most of the work and a cli module for purely user interaction. Parsing stdout seems so unnecessary and could be avoided if a program could simply import a library.
Earlier quoted context omitted.
You can use Mozilla SOPS instead with IAM roles and KMS instead of gpg. They also shifted to AGE over gpg.
It’s the same problem. You don’t have an audit trail. That’s needed in a lot of situations for compliance reasons
Why is this ranking #1 on HN? Seems quite niche to me.
There was and still is a very nice competitor in this space called PlasticSCM. They were bought by Unity a few years ago. Unity has not been a good steward. They should have done what Epic is doing and open sourced it. But instead they chose to give it P&L responsibility. Curious what it's contributing to their financials.
Earlier quoted context omitted.
I hate the word mansplaining but this comment could go into the dictionary as an example. The point was that this bothered me when I used git for the very first time (what is it like 15 years ago at this point) and indeed did not understand it yet. Hope your comment made you feel better about yourself at least.
> The point was that this bothered me when I used git for the very first time and that is fine. From your original comment, you "just" wanted to save things and got confused why you had to `add`, `commit` and `push`. Its just that you didn't know that git isn't a word processor that gives you a way to save your work - you've done that already when you saved the file with your editor. When I came to git, I was also co…
I think most people think about file access in the word processor terms, like you mentioned. You "edit," "save," "upload," and "download." Actions like that.
Then they have to use git for the first time and the terms/actions are really foreign. It's likely made worse if they have experience with auto-syncing file software, since that software does the whole remote management process for them.
Earlier quoted context omitted.
What does that have to with your VCS being integrated with your IDE? Isn't resolving merge conflicts in binary files going to entirely a function of the IDE and not the VCS ? What am I missing?
Merge conflicts on binary files are typically unresolvable in practice because the editing tools don't normally have the ability to compare files. This leads to one of the two divergent sets of changes getting lost. That's why great VCSes allow file locking: locks are a communication tool between team members to avoid losing work.
Earlier quoted context omitted.
Merge conflicts on binary files are typically unresolvable in practice because the editing tools don't normally have the ability to compare files. This leads to one of the two divergent sets of changes getting lost. That's why great VCSes allow file locking: locks are a communication tool between team members to avoid losing work.
a great VCS wouldn't require locking or pre-communication; it would simply refuse to even try to merge assets it couldn't deal with, and leave the result of a merge in a state where the user can reasonably address it (in this case, presumably just "yes, use mine" or "no, use the one already in the repo" and perhaps "use mine but rename it").
(It's usually possible to bypass the locking mechanism, but this is not a habit people get into, because the end result is the situation you describe, and nobody wants to end up there.)
We seem to be in some kind of local minimum here, but perhaps LLMs might help us escape it by facilitating the creation of more merge tools.
Earlier quoted context omitted.
Does `--no-verify` override the restriction via hooks, or are there some kind of server-side hooks that can be used?
no-verify cancels local hooks, remote hooks are unaffected. Gitolite supports per-diectory/file write access natively, for gitlab you'd probably need to write your own.
Earlier quoted context omitted.
As others have said, it's Apple and they do not take kindly to other people leaking their technology/announcements ahead of time. See also: the time that ATI's CEO told his employees that their chips would be powering Apple's to-be-announced hardware a few days before the announcement. Steve Jobs responded by pulling all of ATI's hardware from its demo units at the announcement, not mentioning ATI at all, cancelling…
It’s funny how exciting Apple Pay was when introduced, only Apple pulled the lock-everyone-in card and now we’re all using QRcodes.