291–300 of 309 posts
Earlier quoted context omitted.
> Add to that the necessity for less-technical people (artists, designers, VFX, audio, etc) to use it How is that solved with Git?
Maybe they just need to follow carefully written instructions created by more technical people?
Earlier quoted context omitted.
> Git has no such problem. There’s nothing it can’t do. It can't display me the branch I'm working on, starting from the commit that began the branch, until the last commit. (Or if it can, I have no idea how to do it.) This isn't a functionality issue, but rather a conceptual one. Git just fundamentally thinks of branches differently than I do. (And, maybe most humans?) To me, a branch begins ... when I branch it. To…
git log .. I often need the count of commits, usually for build IDs, git rev-list --count ^ I usually use gitk for visualizing branch commits. CLI equivalent is git log --graph --oneline --all
Earlier quoted context omitted.
>I understand that people might want to make it easier, since the UI is complex, but that’s never going to work. If you abstract away the complexity of the UI, you will necessarily abstract away the power. I disagree, really. There is not fundamental reason why you cannot have user-friendly UI for 98% of the cases and some "advanced" for those 2%. Just like GUIs have "advanced" settings, the CLI can have well designe…
The problem is that for 99.99% of the people engaged in the debate over if git is good or not and should be replaced the correct answer for them is "stop fighting it and just learn git" because there's nothing better. They need to stop thinking about how git sucks because that is literally getting in the way of their career goals and is self-sabotage. And if anyone seriously wants to try to replace git they need to u…
2. Literally no relevant career goal is significantly obstructed by less git proficiency.
Earlier quoted context omitted.
Maybe they just need to follow carefully written instructions created by more technical people?
When has that ever worked? And why does this count as a solution rather than a poor workaround for you?
Disclamer: I'm working on it. But yes, I think we can. Almost everything can be better: * Merges/rebase/branch management. * Project management. * Diff. * Large files. * User management. * Partial checkouts. * ACID semantics. * Binary file management. * User experience, including making it accessible to non-technical folks. * A bunch of others.
Semantic diffs would be a very long overdue, and a very welcome, change.
The hard part about it is that it's different for every language, so to support it for a language, you have to implement diff for that language.
I'm hoping to make money off of companies wanting those languages.
But you could also do better than Linux or OSX as an OS, but the mindshare and industry investment there is so strong, moving to a new thing is a monumental undertaking
Earlier quoted context omitted.
This sounds like a case of using excel as a db. Holding a hammer by it's head a declaring it unfit for normal people to paint with.
I also work in games and everyone I know uses Perforce for the reasons mentioned above Have you considered that maybe they just have a different use case than you?
Yes of course they have a different use case. That is just another way to say the same thing.
A lot of people these days have just been thrown into the fire with Git as the first and only VCS they’ve ever seen. I’m not that old, but I’m old enough to have used RCS, CVS, SVN, then finally Git. I started using Git super early, before GitHub existed. You may not believe me, but Git was the answer to all my prayers. All those previous systems had fundamental architectural flaws that made them a complete nightmare…
>I understand that people might want to make it easier, since the UI is complex, but that’s never going to work. If you abstract away the complexity of the UI, you will necessarily abstract away the power. I disagree, really. There is not fundamental reason why you cannot have user-friendly UI for 98% of the cases and some "advanced" for those 2%. Just like GUIs have "advanced" settings, the CLI can have well designe…
Earlier quoted context omitted.
The problem is that for 99.99% of the people engaged in the debate over if git is good or not and should be replaced the correct answer for them is "stop fighting it and just learn git" because there's nothing better. They need to stop thinking about how git sucks because that is literally getting in the way of their career goals and is self-sabotage. And if anyone seriously wants to try to replace git they need to u…
1. That‘s called stockholm syndrome. 2. Literally no relevant career goal is significantly obstructed by less git proficiency.
A lot of people these days have just been thrown into the fire with Git as the first and only VCS they’ve ever seen. I’m not that old, but I’m old enough to have used RCS, CVS, SVN, then finally Git. I started using Git super early, before GitHub existed. You may not believe me, but Git was the answer to all my prayers. All those previous systems had fundamental architectural flaws that made them a complete nightmare…
The git model has fundamental limitations because it saves snapshots rather than changes, and doesn't capture some metadata changes like renames. A tool like Darcs or one of its spiritual descendants will have fewer merge conflicts than git. Totally agree on your main point though. The benefits of switching are far lower than the costs.