9 ms·

> I’ve used it since GitHub was in beta This is the root of the author's issue. As another commented, git is born in a world where computers are mostly offline

• dijit 6y ago
  Weird question; have you looked at perforce? My previous and current company use perforce but many people (often those who recently join) are decrying that perforce is less elegant than git, but, realistically and based on your own criteria it would be "better" for the connected case. I'm personally a big fan of 'offline/local-first' being a thing, but I'm a sysadmin not a developer.
  • eloisius 6y ago
    I’ve had to use perforce before and was not a fan. Granted, I didn’t have to use it full time and can’t claim to be an expert, but I hated the notion of locking files, change lists, yuck. All of it felt so clunky compared to git.
    • dijit 6y ago
      I’m not sure locking files is as important as all that. You “check out” files, but nothing prevents anyone else “checking them out” (which is perforce parlance for: “make editable”) - conflicts can be resolved. There is locking but it’s seldom used- handy in the gaming industry for code which depends on data.
      • robaato 6y ago
        As cecilpl2 commented - it's the typically the binary art assets (occasionally other files) which are unmergeable which need the exclusive lock turned on. And of course you want to avoid branching those too in many cases.
    • simiones 6y ago
      Funny - I used P4 for about 7 years before switching to Git 2 years ago, and Change Lists are what I miss most from P4. For me it is extremely common to work on multiple changes in parallel, on the same branch or different branches, and organizing my changes in different change lists was the best way to handle it. I also find git's default of rewriting your worktree when you switch to a different branch extremely annoying compared to simply having each branch be a different directory in the FS. Fortunately, digging around I recently discovered git worktree and I'm much happier on this front at least. The file locking was always a relatively obscure workflow, so I'm surprised that you even had to see it if you didn't use P4 a lot. I've only seen it in 3 occasions: working with binary files, the error message when I didn't actually have write access, and when someone intentionally locked some files to make sure they don't have any merge conflicts while they finish up a huge commit.
    • cecilpl2 6y ago
      Locking files is critical when you are editing binary data which can't be merged - which in the games industry, is generally how the majority of the dev team works.
  • nikola1010 6y ago
    At my current job, I had to create a command-line tool just to be able to checkout things from perforce. It is ridiculous how difficult the UX is for this. And companies are still paying for it!
    • dijit 6y ago
      I really don’t want to be the guy defending perforce as I have gripes with it and prefer git for the reasons I mentioned.. but what was the issue with `p4 edit` that caused you to write a new CLI tool for checking out files?
  • lentil_soup 6y ago
    I use Perforce everyday since it aligns better to the needs of the games industry. I have my problems with it, but once you understand it I find the workflow quite simple. If you don't really need the decentralization I think it aligns quite well with how people expect version control to work. You make edits to your data, once you're done, you send them to the server to be shared with other people.
  • rakoo 6y ago
    Never used it but I had to use ClearCase at work even though I was already proficient in git. Ugh. The centralized model is better for companies, but ClearCase really makes its best to make your life miserable: - You have to think twice before modifying a file, because the steps to be able to modify a file can take from 30 seconds (if you already created the activity) to a few minutes (if you have to create it) - Activities are supposed to be like branches, summing up all the changes. But there is no way to see all changes in one go. It's click everywhere, waiting for the server to reply on each click. - Because there is no way to display the branch content in any way other than envisioned by IBM, there is no way to discuss a changeset. No pull requests, no exchange, nothing. - Horrible UI/UX all around. It's slow, it's unreadable, random bugs happen all the time where the only fix is to restart the service, .... and it's expensive. I'm not advocating for a system that only works when online (although the fully integrated system of Google does sound good), just that it be architectured around a point of centralization. This is the way I'd like to use git: - A branch created locally will be synhcronized and visible to everyone by default - A branch that I manually tag as private won't, but it will still be saved on the server - A branch that has a conflict between me and someone else will be marked locally in some way (maybe a second branch ?) - Bonus: my working repo and staging area are also synhcronized to the server
• thrwyoilarticle 6y ago
  +1. The very first question: >Oh, I just pushed a change. I really didn’t wanna push that, so how do I undo it? Is a Github problem, not a git problem. You might as well ask how to unsend an email. If you don't know what git push means, you shouldn't be using it and are playing with intellectual property fire. The conflation of Github with git is responsible for a lot of confusion. Having Github be your first interaction with git is a disaster. Regardless, there's no shortage of blog posts complaining about git being hard. But there is a shortage of effective, popular competitors. I think that, actually, many-chefs many-branch differential version control is just a hard problem and creating a simple model for it is much harder than complaining about git.
  • outsomnia 6y ago
    Right, it's also because github guides people into a history-only flow instead of rebase / force-push. Casual github users know they should follow the tree with pull and don't know what fetch is. With history if you make a vcs mistake, or realize iteratively after pushing that corrections are needed, your worthless threshing around trying to fix it becomes part of your project log forever, instead of just pushing the corrected tree with just the one corrected patch.
    • Macha 6y ago
      The objects are still there even with a rebase flow, it's not as if github does a gc every push?
      • outsomnia 6y ago
        It's not about the object database, it's about what you see with git log. History flow will show all the meandering around forever, but rebase will remove it and just put the most recent version of the commit on top of the tree. Ie, your log looks like you pushed just the perfect patches each time, every time, and the junk is gone.
    • thrwyoilarticle 6y ago
      I spoke to a person that didn't like rebasing who said that the threshing didn't matter because nobody reads the history. But for me it's one of the first tools I reach for when I find a bug or confusing code, trying to understand the intent. I see that as a fundamental difference in how the problem space is viewed and that they're stuck with a Github-first point-of-view. To me, even with merge commits, the history should be a statement of intent and treated as a first-class citizen, or even the primary output. Pushing a branch with threshing is like sending an email with visible backspaces.
• deleted 6y ago
  [deleted]
• rusk 6y ago
  > a system that knows it's connected to other people, where changes are instantly propagated and easily visible We have this already. It's called collaborative desktops over VNC ... > the differentiator between "branches" is not "what computer does it reside on" but "who did it" So you're into collaboration, but not on branches? I would have said branches related to specific units of functionality, streams of development or specific issues. Definition of branches aside, this is the way old-style centralised VCS like CVS, Subversion actually work - and you can still use SVN if you want to ... or you can use git in that manner and never have to worry about it's more complex details. The whole point of Git is that it addresses the specific problem that once you are disconnected you de facto have a branch. Once you push to remote its more like that ideal you're reaching for. > at this point it's not git anymore, so we might as well start from scratch. I'm sorry this is really quite hilarious. Go! Stop whinging and go do it!
  • rakoo 6y ago
    I don't understand the negativity. I'm not saying that git is bad, or that git sucks. It is what it is, and not wat most of the people really want. > We have this already. It's called collaborative desktops over VNC ... We still want a revision control system, things like commits and all. > So you're into collaboration, but not on branches? I would have said branches related to specific units of functionality, streams of development or specific issues. Depends on the workflow. Many people have long-lived branches, introducing big features/refactorings. Many other prefer short-lived branches, where one branch typically is used by a single person. I still think branches should be focused on topics, but the topic (and thus the branch) must be the same on all computers, instead of having one version locally, another one that is mapped to it but potentially has different content on the server, and 1 different branch per other user. How many times have we had to "oh you pushed on your branch, I have to get it first" > Definition of branches aside, this is the way old-style centralised VCS like CVS, Subversion actually work - and you can still use SVN if you want to ... or you can use git in that manner and never have to worry about it's more complex details. Yep, that's the model: one place where people synchronize. The issue with those was not the centralization (look at GitHub), it was the lock mechanism. I can use git to replicate it, or I can use the folder.bak and folder.v1.final on a NAS method. It's not because it's possible that it's desirable > I'm sorry this is really quite hilarious. Go! Stop whinging and go do it! Ah, so it's not possible to criticize work until we have developed a complete alternative ?
• marcus_holmes 6y ago
  I found the author's apparent belief that Git and Github are the same thing extremely annoying. Github is a parasite.
  • zeroimpl 6y ago
    Not just that, they seem to suggest Github created Git... > the quality of the tech that is Git is a testament to GitHub being able to make it this far in the tech space But in reality, Github makes Git more complex, because now you have to understand the concept of forks. Not only is there your local copy and an origin, there is a 3rd repository in play.
    • hinkley 6y ago
      What other structures would work for having a public forum for PRs? I'm having trouble coming up with many that would be compelling enough to make that change, especially once you consider bad-faith actors in there (eg, I can't flood your git repo with my nonsense, because my code doesn't exist in your repository until the PR is merged) I spend too much time doing archaeology to support squashed PRs, which eliminates a few alternatives I might otherwise suggest.
      • zeroimpl 6y ago
        They could have added namespaces to branch names. Right now branch names are just a free-for-all. Instead, if they insisted that branch names are always prefixed with "username/", then you wouldn't need forks and anybody could freely submit code to any project. PRs would become MRs. I believe this is how most Git repos are managed within organizations. I'm not sure why public repos need to require users to fork things to propose changes. And isn't this basically how Github works internally anyways? (eg https://news.ycombinator.com/item?id=24882921 https://news.ycombinator.com/item?id=24882921)
• hinkley 6y ago
  I think we're all still dancing around a blind spot, where we want eventual, Pareto Principle consistency (where a consensus is formed around 10% of edit histories, many others require only a consensus of 2, and the rest are backups that require a consensus of 1) We're trying to assemble this from different pieces, without a clear idea if we can even get there from here, given all of the roadblocks Information and other Theories throw in the way. I hope someday we meet in the middle with systems that can handle code and incidentally a bunch of other problem domains we also care about.
• koonsolo 6y ago
  So basically Subversion?