251–260 of 550 posts
Earlier quoted context omitted.
This is only true until the first merge conflict or when you want to know when a bug was introduced to even find its location.
I resolve conflicts in GUI every week. I find the location of a bug by running tests and looking at the code.
Earlier quoted context omitted.
The irony with git is that the underlying data model is far simpler than the user interface implies. People assume git is complicated because the user interface is complicated, but it really is very simple under the hood. So much so that you can write your own basic version of git in a couple of hours: https://wyag.thb.lt/
The problem is that git leaks the underlying data model all over the place, even where it's unnecessary to actually controlling versions. It's a nice data model, but the user view shouldn't expose it. The data model is an implementation detail, but git treats it like a show & tell.
Earlier quoted context omitted.
> but I'm seriously falling behind due to jetbrains integration This IntelliJ integration is the source of quite a lot of git problems in teams I worked with. I'm quite flabbergasted by this - devs claim to know git on their CV, come in and know what "commit" is and how to use the IntelliJ UI, but don't even understand what its doing. And everyone is acting like it's OK and learning git is a "hard thing ill never nee…
This attitude mystifies me. The whole point of computers is to solve problems well enough that most people don't have to understand the machinery. It is literally impossible for us to understand how everything we use works. We expect a compiler to just compile things and work; nobody is ranting about how modern developers are lazy because they can't hand-verify the compiler is outputting the right opcodes. Nobody is…
How should git adapt? Can you get a simpler model than this? Is really a basic structure like a tree so complicated millions of developers are having a hard time with it?
Nobody is advocating for "dont use new stuff, old is betteer". Nobody is advocating for people to hand-check compiler outputs (unless your analogy pertains to people who work in a GUI tool that shows them pretty pictures for opcodes and they check if the pictures match).
You've missed the point.
The point is "try to understand the basics of the tool you are using".
If me wanting people to learn and understand more makes me an asshole, so be it.
I'd rather be an asshole and help people learn more and understand more than coddle them in the safety of the pretty buttons and say "it's ok, you don't have to understand".
If we don't understand our tools and the problems they solve, how will we make progress?
How will we make better tools?
How will we make better software?
How do you learn and grow if not by understanding what you don't?
Earlier quoted context omitted.
First of all, using "noob" like that is offensive. Everyone's a "noob" at some point. And if that's how you talk and treat people, I probably wouldn't want your help. And second, what exactly mystifies you about what e.g. SourceTree menu commands do? They map clearly and intuitively to CLI commands. If you have "no idea" what it's trying to do then you're not even trying to be helpful. You're just being condescending…
> First of all, using "noob" like that is offensive. Everyone's a "noob" at some point. And if that's how you talk and treat people, I probably wouldn't want your help. Unfortunately, a word needs to exist that stands in for this: "Person, who isn't so different than myself when I started, with little experience who is mistake prone due to the lack of experience, who's mistakes creates disruption and often great expe…
A lot of comments along the lines of ‘why do people use instead of learning the commands’. For me, I used to use the terminal git, and I still do occasionally. But I use Sourcetree now for most things because I make less mistakes seeing the tree visually all the time. My job isn’t to use git, it’s to write specialist software. If I get the software written and the customer is happy, it doesn’t matter whether I use or…
> My job isn’t to use git, it’s to write specialist software. If I get the software written and the customer is happy, it doesn’t matter whether I use or not. Imagine having 100 complex things bouncing around your head and having to make that 101 when you forget the order of arguments to merge. Imagine if you knew a cabinet builder who said: "My job isn't to use a table saw, it's to build beautiful cabinets. If I get…
Earlier quoted context omitted.
There were other solutions, much less complex to deal with than git, but hey, they lacked the luxury of being an hard requirement to deal with Linux kernel and related eco-system.
I've used, over the years, RCS, SCCS, CVS, SVN, Bitkeeper and Perforce. I would not trade any of them for git at this point in time, primarily due to the way that git allows for both net-connected and disconnected development without any change in the workflow.
Earlier quoted context omitted.
Version control isn't a tool I use. It's the filesystem I store my files in.
This is only true until the first merge conflict or when you want to know when a bug was introduced to even find its location.
Earlier quoted context omitted.
we use it because it's blazing fast, stable and extremely versatile
It’s not very fast when you account for all the time and productivity wasted on getting “unstuck” all the time.
Earlier quoted context omitted.
Sublime Merge’s three-way merge is so good. It’s totally spoiled me.
Is sublime doing the merge instead of git? Or are you referring to use sublime as the merge tool to resolve conflicts?
Earlier quoted context omitted.
If you have a CNC system, then I'd say you should absolutely be using that in preference to other things. But you should also come to as deep an understanding of the CNC system as possible, so as to be able to grasp what you can do with it, and how you could use it to carry out specific tasks that might arise in the course of your work. What you should not do, IMO, is to say "Oh, I have a CNC system, but I never inte…
> What you should not do, IMO, is to say "Oh, I have a CNC system, but I never interact with it directly, I let CNC-Foo on my computer control it whenever I need to do anything". I have experience with CNC machines, and I would still not recommend that anyone try to control their CNC machine by typing in G-Code directly. Understanding G-code can be helpful, but you really need to learn to use the higher-level tools p…
2) After I posted the comment you're replying to, I was absolutely certain that the question of which level of control was appropriate would come up (since that's really what we're discussing in the context of git). It doesn't seem obvious to try to carry the analogy too far, but for both systems there are obviously different levels that one can think about. I haven't used a CNC system, but I would imagine that there are very high level control systems that maybe start from some sort of design data and take it from there, some mid-level control systems that let you specify what you need and then program the machine to create it, and low-level control that would be rarely used unless the higher level tools just couldn't do what was needed.
If indeed this is an accurate description, then it seems to match the case with git quite well, and I'd still argue that even if you often/sometimes use the very high level control tool, you should understand and be aware of the possibilities of the lower level ones too.