We don't understand TFS and we don't want to.
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
Clearly you miss things. There is no management for me to push back against. I have been an independent for quite some time (most likely more years than the median age of members here).
Now you are clearly just fucking with me. You speak about something as if you were working in a company and then say "well I don't". Whatever mate.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
@bulb said in We don't understand TFS and we don't want to.:
Because branch names in git (and other DVCS) ARE NOT PERMANAENT.
The branch names aren't, but the commit name you have to provide before the code goes into the branch is.
Now I don't know what you are talking about. Commit objects don't have any property called name. They have just comment, author, committer, the two respective dates, parents, and tree, which is the actual content.
So either you are using sloppy terminology, or you are blaming behaviour of some other tool on git, but it's not actually git's fault—I believe we already established that you do use some tools on top of git that are opinionated about the workflow and may interfere with many useful ways of using git.
@blakeyrat said in We don't understand TFS and we don't want to.:
If I could push a stash to a server without having to make a commit
You can:
git push origin stash@{0}:u/blakeyrat/stash/test # ^^^^^^^^^^^^^^^^^^^^^ this essentially corresponds to the shelveset name you'd give to TFSIf you can't do this, there is something wrong with the server that is not git's fault, because with normal git server you can.
@blakeyrat said in We don't understand TFS and we don't want to.:
stash […] without having to make a commit
A stash IS a commit. Stored in the reflog of a special branch called
stash.@blakeyrat said in We don't understand TFS and we don't want to.:
So it's great that Git is so usable and discoverable.
I mostly do agree with you on this. Git is insanely powerful, but it comes at two huge costs:
- It is complicated like an onion threshing machine.
- It is like a huge box of tools that you have to chose from what suits you and insert the bits you need into the handles.
@blakeyrat said in We don't understand TFS and we don't want to.:
There's only 4 ways of doing this task, three of them have nonsense gibberish names. Good jorb [sic] Git developers.
There are often quintillion ways of doing some task. But in this case it is not actually 4 different ways and the names (fast-forward, amend, soft reset, cherry-pick) refer to various parts of the process.
We all know naming things is one of two hard things in computing (along with cache invalidation and off-by-one errors). However in this case the concepts are new, so is the naming. Using the terms you are familiar with would be more confusing, because the concepts are different.
It just proves
@lucas1 said in We don't understand TFS and we don't want to.:
Again you don't understand Git
And I would dare to say you don't actually understand TFS either. However, TFS is much simpler, so sitting down to the UI lets you use most of it, while sitting down to Git UI just leaves you totally baffled. Because you won't get anywhere without reading up about the concepts in Git.
Nevertheless none of the attempts to create a simple UI for Git that you could just sit down and use never succeeded—and there have been several attempts—probably because while most users only use 1% of the Git power, each uses different 1%, so the UI still needs to support much more of it—and ends up no longer being easy.
-
@bulb said in We don't understand TFS and we don't want to.:
Because you won't get anywhere without reading up about the concepts in Git
Which is why Git is bad
-
@lucas1 said in We don't understand TFS and we don't want to.:
@pleegwat In the UK it is called a mobile elevating platform.
Might be slightly regional, I've hired quite a few in south england and it's always been a cherry picker.
In South Africa it's a Manitou, a lot of the heavy equipment was just 'a Manitou' so you'd likely end up with a telehandler if you weren't specific.
-
@jaloopa said in We don't understand TFS and we don't want to.:
@bulb said in We don't understand TFS and we don't want to.:
Because you won't get anywhere without reading up about the concepts in Git
Which is why Git is bad
No. The need to read documentation does not make a tool bad. Especially a tool that may be necessarily complex.
Git is bad for entirely different reasons than you needing to read the documentation. You really don't, as long as you do not stray from the commonly used bits of it, such as commit, pull and push. When you start doing something harder than that, you get into areas where you need to know what you are doing or it will be painful.
-
@carnage said in We don't understand TFS and we don't want to.:
The need to read documentation does not make a tool bad.
Maybe not, although a good tool should strive to make as much of its functionality as possible obvious without reading documentation.
But @bulb didn't say you have to read the documentation, he said you have to read up on the core concepts. That's a whole other level and is why people trying to convince you to use Git always say "directed acyclic graph" (or just DAG if they're real dicks) within about 5 minutes. Tracking changes to source control shouldn't require a grounding in graph theory or any of the other core concepts. A good tool would abstract that away rather than promoting it to required knowledge.
Car analogy time. You can become a pretty good driver without ever opening the bonnet or understanding what an internal combustion engine does. In fact, cars abstract the engine away so much that the engine can be entirely swapped out for an electric motor and the majority of your interaction with it doesn't change. Knowing the internals may mean you can maintain the vehicle better or get some more power out of it but it's not required for day to day use. A Git car would make you have to measure out some fuel and directly inject it into the cylinders because the guy who built it knows how to do that and so didn't see the point in an accelerator pedal
-
@jaloopa said in We don't understand TFS and we don't want to.:
Car analogy time. You can become a pretty good driver without ever opening the bonnet or understanding what an internal combustion engine does. In fact, cars abstract the engine away so much that the engine can be entirely swapped out for an electric motor and the majority of your interaction with it doesn't change. Knowing the internals may mean you can maintain the vehicle better or get some more power out of it but it's not required for day to day use. A Git car would make you have to measure out some fuel and directly inject it into the cylinders because the guy who built it knows how to do that and so didn't see the point in an accelerator pedal
I'd say that you really need to know the difference between the engine types to successfully make use of the car. Pouring gasoline into the charging port will not be good. Nor will connecting the charging outlet to the gasoline tank.
So, your car analogy just proved that you do, in fact, need to know some basics.
As far as the driving goes, as a track day addict, my definition of "pretty good driver" requires you to know the inner workings of the car (not limited to engine, but suspension, tires and a few other bits and bobs), so I will not comment on that bit.
-
@jaloopa said in We don't understand TFS and we don't want to.:
Maybe not, although a good tool should strive to make as much of its functionality as possible obvious without reading documentation.
Of course, but you won't understand git at any level of complexity at all without understanding the concepts of history graphs, and they're simply stuff that you need to actually learn complex things to appreciate. Given that we're talking about fundamental irreducible complexity here — the base model is necessarily complicated — then the only way to get a very large proportion of the functionality understandable without specific learning is to greatly reduce what is possible. Training wheels are all very well, but that's an approach that git itself specifically rejects; it's an advanced tool with advanced capabilities and you need to understand what you're really doing to comprehend what's going on.
The various GUI front ends to Git do dumb it down a lot. The command line client suite is more oriented towards exposing the full capabilities.
-
@magus said in We don't understand TFS and we don't want to.:
@boomzilla And yet if I were to merge from that version, in TFS, it wouldn't have rolled back my work. So functionally, it is more like cherry picking.
No. It is not really like cherry picking, except that you select a particular point in the history. Which you can then manually merge.
-
@magus said in We don't understand TFS and we don't want to.:
@greybeard "It's source control jargon" is not a valid response to "this jargon is pointless and we shouldn't have it"
I don't care how long ago someone came up with a bad idea if it's a bad idea.
But it's not a bad idea and your "check out" / "check in" is no less jargony for this purpose, even if your familiarity with the terms prevents you from recognizing that.
-
@jaloopa said in We don't understand TFS and we don't want to.:
@boomzilla said in We don't understand TFS and we don't want to.:
That's what get specific does with TFS?
Hard to tell since you quoted some Git documentation and apparently expected people to understand it
Ah, well
'd. Still I couldn't even find the TFS documentation.
-
@bulb said in We don't understand TFS and we don't want to.:
I mostly do agree with you on this. Git is insanely powerful, but it comes at two huge costs:
"powerful" and "easy to use" aren't mutually-exclusive.
For some reason I'll never understand, open source developers seem to think they are. Conveniently, that gives them an "excuse" to never improve the usability of any of their products, and a nice-sounding response to barf out every time someone says an open source product sucks ass.
@bulb said in We don't understand TFS and we don't want to.:
It is complicated like an onion threshing machine.
a.k.a. it's a shitty product.
@bulb said in We don't understand TFS and we don't want to.:
It is like a huge box of tools that you have to chose from what suits you and insert the bits you need into the handles.
a.k.a. it's a shitty product.
@bulb said in We don't understand TFS and we don't want to.:
We all know naming things is one of two hard things in computing (along with cache invalidation and off-by-one errors). However in this case the concepts are new, so is the naming. Using the terms you are familiar with would be more confusing, because the concepts are different.
What are you, Mr. Git now? Do you work on the Git project? Because goddamned do I have some feedback for you.
@bulb said in We don't understand TFS and we don't want to.:
And I would dare to say you don't actually understand TFS either. However, TFS is much simpler, so sitting down to the UI lets you use most of it, while sitting down to Git UI just leaves you totally baffled. Because you won't get anywhere without reading up about the concepts in Git.
If Git wasn't such a shitty product, I'd learn it as I used it.
@bulb said in We don't understand TFS and we don't want to.:
Nevertheless none of the attempts to create a simple UI for Git that you could just sit down and use never succeeded
Right; because Git is a shitty product designed by incompetents who don't even understand basing engineering principles like "separate the machine interface from the user interface". Do you think Visual Studio's Git interface is as bad as it is because they wanted it to be bad? No, it's because the incompetent developers in charge of Git didn't do the most basic of design work before releasing their garbage shitty product to the world.
People who come here and "defend" Git basically are just typing "Git is a shitty product" over and over again in various guises. Yes I know it's shitty. Thanks I guess.
@carnage said in We don't understand TFS and we don't want to.:
No. The need to read documentation does not make a tool bad.
Yes it does.
Well... no, not if you live in 1983. But Apple and many others showed in the mid-80s... yes it does.
But having that knowledge would require Git developers to be competent, and as we've discussed they are not. I'm sure they haven't even used any technologies newer than 1982, based on their UI "design".
@carnage said in We don't understand TFS and we don't want to.:
Especially a tool that may be necessarily complex.
Git isn't necessarily complex, it's unnecessarily complex.
@carnage said in We don't understand TFS and we don't want to.:
Git is bad for entirely different reasons than you needing to read the documentation. You really don't, as long as you do not stray from the commonly used bits of it, such as commit, pull and push.
Only because people outside of the Git team have moved heaven and hell to try to make some sense of it's gibberish bullshit interface. (Notably Microsoft, the company that open source-y people hate because it's so evillz! They're so evil, open source community, that they're vastly improving your products for free! How evil!) Not due to anything Git itself has done.
@carnage said in We don't understand TFS and we don't want to.:
When you start doing something harder than that, you get into areas where you need to know what you are doing or it will be painful.
Now Git has "areas" that you can "get in to"? What is it, a Metroid game?
BTW, it's painful anyway. I wish there was some telepathic technology so the developers of Git could actually feel the pain their shitty product has caused. Maybe they'd make it less shitty. But probably still not, since they're incompetent.
-
@dkf said in We don't understand TFS and we don't want to.:
Of course, but you won't understand git at any level of complexity at all without understanding the concepts of history graphs, and they're simply stuff that you need to actually learn complex things to appreciate.
I don't want to understand Git at any level of complexity. I hate complexity. I just want to use the software.
Yeah yeah we all know the incompetent Git developers made it difficult to use because they love pointing at people and saying "ha ha you're stupid because you can't use Git and I'm smart because I can I am so much smarter than you". That's not exactly selling me on the quality of the software here.
I don't want to appreciate Git, I just want to use it. I don't have to appreciate my dishwasher before using it. I don't have to appreciate my toaster before using it. Just make it easy to use.
(Which, BTW, would make me appreciate it a hell of a lot more. Since just yelling "DAG!!!!" at people is easy, and making product easy to use is actually an accomplishment.)
@dkf said in We don't understand TFS and we don't want to.:
Training wheels are all very well, but that's an approach that git itself specifically rejects;
Right; because its developers are incompetent.
Also the term "training wheels" show you have the wrong conception of usability. It doesn't work that way. Microsoft Word is an extremely complex product, with far more features than Git has. It has no "training wheels". All the features are there for everybody to use right from the start. It's still infinitely easier to use than Git.
@dkf said in We don't understand TFS and we don't want to.:
The various GUI front ends to Git do dumb it down a lot.
Again: this is a weird falsehood that open source-y developers have. You don't have to "dumb something down" (what does that even mean?) to make it easy to use. Word isn't "dumbed down". All the features are right there for every user of it from the start. It's still far easier to use than Git.
@dkf said in We don't understand TFS and we don't want to.:
The command line client suite is more oriented towards exposing the full capabilities.
Except there's a wide swath of the population who can't use command lines (myself included), which the developers of Git might have compensated for, had they not been incredibly incompetent.
It's one thing to say "this product is difficult to learn", but it a whole 'nother level to say "this product isn't accessible to you because fuck your disability". For one thing, the second is literally illegal in virtually every other context in the western world.
-
@dkf said in We don't understand TFS and we don't want to.:
Of course, but you won't understand git at any level of complexity at all without understanding the concepts of history graphs, and they're simply stuff that you need to actually learn complex things to appreciate
That may be true, or it may be a massive cop out. I admit I don't know Git well enough to say definitively.
I don't see how it's necessarily impossible to understand how a set of changes, branches and merges have interacted without knowing what a DAG is. A well thought out visualisation could show the data in such a way as to present the most salient information and abstract away the rest but allow it to be drilled into.
Ultimately, I'm not convinced at all that source control is as complicated as Git seems to make it. There are plenty of other VCSes that don't make it as difficult, so the claim that it's irreducibly complex seems wrong.
-
@jaloopa said in We don't understand TFS and we don't want to.:
A well thought out visualisation could show the data in such a way as to present the most salient information and abstract away the rest but allow it to be drilled into.
Ah, but visualizing things would require... (gasp!)... GRAPHICS!
And those don't exist for us Git developers here in 1982.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
Again: this is a weird falsehood that open source-y developers have. You don't have to "dumb something down" (what does that even mean?) to make it easy to use.
I think it's probably possible to make a usable GUI for something like Git that isn't dumbed down, but all of the front ends I've seen do dumb it down.
This reminds me of something that occurred to me after another argument recently on CLI vs GUI. It's a common claim that CLI programs are "more powerful", as if that's just a Gospel fact you shouldn't bother trying to deny. I think that's almost certainly due to the CLI first mindset those developers have. Of course if you make a CLI app, then make a GUI on top of that the GUI will, at best, have the same power as the CLI. If you instead make a library and then implement graphical and command line interfaces on that, there's no reason for the GUI to be any less powerful. If you want the GUI to be the main interface then it's entirely possible the CLI version would be the cut down, less powerful version.
So in summary, if anyone tells you that CLIs are always more powerful than GUIs, what they're actually saying is "I can't think of any other way to write software other than using a UI as an API"
-
@boomzilla "Hey, can you commit your work?" does not communicate as well to someone who doesn't know what subject you're talking about as well as "Hey, can you check in your work?"
-
@jaloopa said in We don't understand TFS and we don't want to.:
A well thought out visualisation could show the data in such a way as to present the most salient information and abstract away the rest but allow it to be drilled into.
You can do a lot of it, but that really isn't the whole story. For example, see the Github network graph UI, though that's not a great visualisation at all when dealing with single repositories, and gets really weird once you start to really get interwoven branches as the view from the forks can be really different from the parent even if they all agree on what commits exist. (The complexity comes in part because each repository need only talk about a different subset of labelings of the branches from all the others, and none of the labels need to be consistent with anyone else's either. And of course nobody has an actual global view of what is going on either…)
That's without considering the things that you can do with timeline rewriting.
-
@jaloopa I cannot upvote your post enough.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
I don't want to understand Git at any level of complexity. I hate complexity. I just want to use the software.
The problem is that people talk about the underlying concepts and you think they're talking about the software when they're actually talking about the problems that the software is a tool for solving.
-
@pie_flavor said in We don't understand TFS and we don't want to.:
Yes, and said point has been consistently countered. Not sure where restating it will get you.
"Hurr durr, I learned it, just learn it!" does not count as countering someone's point.
-
@magus said in We don't understand TFS and we don't want to.:
@boomzilla "Hey, can you commit your work?" does not communicate as well to someone who doesn't know what subject you're talking about as well as "Hey, can you check in your work?"
What do you want me to check for?
Sorry, but nope.
-
@boomzilla "Why do you not think I'm committed to the project?"
Sorry dude, but nope.
-
@magus said in We don't understand TFS and we don't want to.:
@boomzilla "Why do you not think I'm committed to the project?"
Sorry dude, but nope.
Exactly! It is you who is saying that there is a "non-jargon" and obvious set of words to use. I've been saying (and demonstrating) that you're wrong.
-
@boomzilla Except one of those is closer to something someone might do. A bit of thought will lead somewhere with 'check in' - but 'commit'? No one uses the word commit the way you've said they do. Sure, 'committing it to paper' is a thing people have said, but all of them are now telling kids to get off their lawn at best. No one thinks of that meaning of the word anymore. And why would committing something to paper have anything in common with what you're doing when you check in code? You aren't just writing it down.
Unless you're talking about adding it to the history of work done. And that above else, is a concept no one cares about if all they want to do is check in their work.
-
@magus Meh. It's all learned stuff. It's all non-obvious. Different people chose different terms originally in old software systems (all now obsolete) and that's just been carried forward. You're used to one set of terms so you think that that's obvious, but that's just from your perspective. People with a different history of what they've learned think that you're uttering Crazy Talk.
-
@jaloopa said in We don't understand TFS and we don't want to.:
I think it's probably possible to make a usable GUI for something like Git that isn't dumbed down, but all of the front ends I've seen do dumb it down.
You're more generous than I am.
I don't think it is possible. Especially since Git can run arbitrary CLI commands on creating commits ("hooks") and naturally didn't bother creating any kind of standard for how those should output so they're impossible for a GUI to parse. Not that a GUI in 2018 should ever have to parse text at all... but I digress.
I think it could be made possible if development of Git was taken away from the incompetent idiots in charge of it now and a serious effort was made to actually turn it into a well-designed piece of modern software.
And please stop using the term "dumb down" or at least not without actually defining it. What does it even mean?
@jaloopa said in We don't understand TFS and we don't want to.:
This reminds me of something that occurred to me after another argument recently on CLI vs GUI. It's a common claim that CLI programs are "more powerful", as if that's just a Gospel fact you shouldn't bother trying to deny.
Right; made by people who have never used AppleScript.
@jaloopa said in We don't understand TFS and we don't want to.:
I think that's almost certainly due to the CLI first mindset those developers have.
The problem isn't being "CLI first", the problem is being "CLI only". Git doesn't have an interface for other apps. It only has a CLI interface, which has to pull double-duty as a human interface and a machine interface.
That's because, one more time y'all: Git's developers are incompetent.
@jaloopa said in We don't understand TFS and we don't want to.:
If you instead make a library and then implement graphical and command line interfaces on that, there's no reason for the GUI to be any less powerful.
a.k.a. the way all non-incompetent developers have been making all software for the last 20 years. Yes.
@jaloopa said in We don't understand TFS and we don't want to.:
If you want the GUI to be the main interface then it's entirely possible the CLI version would be the cut down, less powerful version.
Or you could just not have a "main" interface at all. The Git developers obviously love computar machines and hate human beings; why didn't they refrain from making a human being interface at all? Then someone more competent could have before they'd established the current shitty baseline.
@jaloopa said in We don't understand TFS and we don't want to.:
So in summary, if anyone tells you that CLIs are always more powerful than GUIs, what they're actually saying is "I can't think of any other way to write software other than using a UI as an API"
Yup. Sadly this message never filters through to the kind of morons who think Git is a good tool.
@dkf said in We don't understand TFS and we don't want to.:
You can do a lot of it, but that really isn't the whole story. For example, see the Github network graph UI, though that's not a great visualisation at all when dealing with single repositories, and gets really weird once you start to really get interwoven branches as the view from the forks can be really different from the parent even if they all agree on what commits exist. (The complexity comes in part because each repository need only talk about a different subset of labelings of the branches from all the others, and none of the labels need to be consistent with anyone else's either. And of course nobody has an actual global view of what is going on either…)
(whine) it's slightly hard therefore nobody should try to solve the problem ever!!! (cries like an infant)
Yeah, sorry, designing software is difficult. But using "it's difficult" as an excuse to never improve anything is disgusting to me.
@boomzilla said in We don't understand TFS and we don't want to.:
The problem is that people talk about the underlying concepts and you think they're talking about the software when they're actually talking about the problems that the software is a tool for solving.
It's a tool for solving them, but it creates an equal amount of new problems, so the net gain ain't so impressive.
@dkf said in We don't understand TFS and we don't want to.:
Meh. It's all learned stuff. It's all non-obvious. Different people chose different terms originally in old software systems (all now obsolete) and that's just been carried forward. You're used to one set of terms so you think that that's obvious, but that's just from your perspective. People with a different history of what they've learned think that you're uttering Crazy Talk.
But Git's (incompetent) developers didn't carry any terms forward. They invented their own terms anyway.
-
@dkf I'm saying all of this from experience. I had never heard of TFS before my first programming job, and hadn't heard of git either. When someone asked me to check my work in, I found where to do that, and understood what it meant. 'Commit' has far too much to do with implementation details, like everything in git. They don't want you using it unless you appreciate the artistry of their design.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
And please stop using the term "dumb down" or at least not without actually defining it. What does it even mean?
In terms of interfaces, I'd say focusing on making certain actions simple at the expense of making others overly complicated or even impossible. A dumbed down word processor might have a simple way to choose between 10 predefined font choices, which cover what a lot of people use but then have no way to set, say, 18 point Helvetica in strikethrough bold purple.
@blakeyrat said in We don't understand TFS and we don't want to.:
The problem isn't being "CLI first", the problem is being "CLI only"
I was talking more generally about CLIs being seen as a more powerful option, not specifically about Git (which is a leading example of the phenomenon)
-
@magus said in We don't understand TFS and we don't want to.:
Except one of those is closer to something someone might do. A bit of thought will lead somewhere with 'check in' - but 'commit'? No one uses the word commit the way you've said they do. Sure, 'committing it to paper' is a thing people have said, but all of them are now telling kids to get off their lawn at best. No one thinks of that meaning of the word anymore. And why would committing something to paper have anything in common with what you're doing when you check in code? You aren't just writing it down.
Sure, keep pushing on this rope. You're not doing anything but confirming that you can't see past your own bias here.@magus said in We don't understand TFS and we don't want to.:
Unless you're talking about adding it to the history of work done. And that above else, is a concept no one cares about if all they want to do is check in their work.
Check in it for what?
-
@magus said in We don't understand TFS and we don't want to.:
@dkf I'm saying all of this from experience. I had never heard of TFS before my first programming job, and hadn't heard of git either. When someone asked me to check my work in, I found where to do that, and understood what it meant. 'Commit' has far too much to do with implementation details, like everything in git. They don't want you using it unless you appreciate the artistry of their design.
I think you're just proving @dkf's point here.
-
@boomzilla My bias is exactly what I'm arguing here. Because in my experience, one was easy, and made sense immediately. The other makes no sense even though I understand it.
-
@magus said in We don't understand TFS and we don't want to.:
@boomzilla My bias is exactly what I'm arguing here. Because in my experience, one was easy, and made sense immediately.
Yes but you're also trying to claim that your experience and bias is universal and that's the part where you're wrong.
-
@jaloopa said in We don't understand TFS and we don't want to.:
In terms of interfaces, I'd say focusing on making certain actions simple at the expense of making others overly complicated or even impossible. A dumbed down word processor might have a simple way to choose between 10 predefined font choices, which cover what a lot of people use but then have no way to set, say, 18 point Helvetica in strikethrough bold purple.
Ok; but then we get back to the first issue:
Word is relatively easy to use, and yet is not at all dumbed down. So why to open source-y people always think the two things are mutually-exclusive? Most of the most popular software on Earth is the same way Word is. Photoshop. Vegas. Web browsers. Steam. Web browsers. Etc.
For the record, the reason "dumbed down" is such a pet peeve of mine is that people generally use it to mean "I don't like it but I can't articulate why" and when you ask them to define what dumbed down actually means they go "durrrrrrrrrrrr". I'm glad you have some kind of definition you're working off of.
@jaloopa said in We don't understand TFS and we don't want to.:
I was talking more generally about CLIs being seen as a more powerful option, not specifically about Git (which is a leading example of the phenomenon)
Right; but if they were only "CLI first" they'd still be far better-designed than Git. I guess is what I was trying to say.
-
@boomzilla said in We don't understand TFS and we don't want to.:
Yes but you're also trying to claim that your experience and bias is universal and that's the part where you're wrong.
If you want to do that, you'll have to introduce me to someone who was told to commit something in git and went and did it successfully. Without having to find a guide. And a guide to that guide. And read up on Directed Acyclic Graphs. And didn't break anything. And understood what they were doing.
Because what my point is and has always been is that git is hard and TFS is easy. Git uses terminology that makes sense if you understand how git is implemented, and TFS uses terminology based around the goal the user is trying to accomplish.
-
@magus said in We don't understand TFS and we don't want to.:
Git uses terminology that makes sense if you understand how git is implemented,
I know this is unrelated to your argument but I very much doubt that's true. Like if I read up enough about directed acyclic whatevers, I'd suddenly understand why a cherry picker is useful for source code? What kind of metaphor even is that. "Your source code is a field of trees." Are the data structures in Git named like "code orchards" or something?
-
@blakeyrat I was more referring to things like 'push', 'pull', and 'commit', which apply (rightly) to a historical record. But when you're using source control, what you care about is that the version on your machine matches the one on other people's machines sometimes. The history being important is not something that should come up every day.
-
@magus Well ok but Git uses way more terminology than that.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
Ok; but then we get back to the first issue:
Word is relatively easy to use, and yet is not at all dumbed down. So why to open source-y people always think the two things are mutually-exclusive? Most of the most popular software on Earth is the same way Word is. Photoshop. Vegas. Web browsers. Steam. Web browsers. Etc.Yeah, I was agreeing with you on that point. Just because all of the popular Git front ends are dumbed down doesn't mean they have to be. Although I wasn't aware that arbitrary CLI commands were a part of what a fully featured GUI would have to deal with; maybe the architectural problems really are so bad that the choice is between having all the features and having an interface that's usable. Even if that is the case, doesn't mean it's a necessary consequence of Git's complexity
-
@blakeyrat Yes, and most of it seems to have more to do with how git is implemented than what a user is trying to accomplish. Because if you're using git, the important thing is that you're using git, not your goals.
-
@jaloopa said in We don't understand TFS and we don't want to.:
Yeah, I was agreeing with you on that point. Just because all of the popular Git front ends are dumbed down doesn't mean they have to be.
I wouldn't even call them dumbed down. By your definition. I'd say they've implemented everything they can implement in a relatively bug-free manner given Git's horrible design.
Again: it's not like Microsoft could have done better and just decided not to. They stopped where they stopped for really good reasons. The fact that it's the same place where, for example, the GitHub GUI stopped and that Eclipse stopped and that VS Code stopped indicates to me that that's literally the best you can do.
@jaloopa said in We don't understand TFS and we don't want to.:
Although I wasn't aware that arbitrary CLI commands were a part of what a fully featured GUI would have to deal with;
Ah; the bliss of ignorance. No, trust me: Git is even worse than you imagined.
@jaloopa said in We don't understand TFS and we don't want to.:
maybe the architectural problems really are so bad that the choice is between having all the features and having an interface that's usable.
The solution is to boot Git's current development team and replace it with people who know how to write software and actually give a shit, instead of people whose primary attitude appears to be "never do anything even slightly difficult" and "got mine, fuck everybody else".
And BTW, while I'm ranting, Git was originally designed by Linus Torvalds. Guy's got like $500 million in the fucking bank. You telling me he couldn't afford to hire a UX person? What an absolute asshole.
-
@jaloopa said in We don't understand TFS and we don't want to.:
Although I wasn't aware that arbitrary CLI commands were a part of what a fully featured GUI would have to deal with;
If there is anything you can do with the CLI but can not do with the GUI - then by definition it is not "fully featured".
-
@tsaukpaetra said in We don't understand TFS and we don't want to.:
I wish we could have that many builds per hour.
Really. On our build server (under powered VM), it takes just over 2 hours. Much of that time is the signing / installer build.
-
@carnage said in We don't understand TFS and we don't want to.:
They got the sizing of the nozzles the wrong way around imho.
Looks at it this way - diesel owners are smarter.
-
@thecpuwizard said in We don't understand TFS and we don't want to.:
If there is anything you can do with the CLI but can not do with the GUI - then by definition it is not "fully featured".
Right; I wouldn't be surprised if Git added that feature on purpose just to make GUIs impossible, because the developers running Git are horrible, horrible people who love causing pain.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
Like if I read up enough about directed acyclic whatevers, I'd suddenly understand why a cherry picker is useful for source code? What kind of metaphor even is that
I think this is one argument you should step away from. Cherry pickers and cherry picking both come from the actual act of picking cherries
The term is based on the perceived process of harvesting fruit, such as cherries. The picker would be expected to only select the ripest and healthiest fruits. An observer who only sees the selected fruit may thus wrongly conclude that most, or even all, of the tree's fruit is in a likewise good condition
The articulated boom lift, or commonly known as the cherry picker, was envisioned due to frustration, like most inventions. Reportedly, in 1944 a young boy called Jay Eitel was picking cherries during his school holidays, and became intensely frustrated with having to climb up and down the ladder every time he had to move to a new picking spot.
-
@magus said in We don't understand TFS and we don't want to.:
@boomzilla said in We don't understand TFS and we don't want to.:
Yes but you're also trying to claim that your experience and bias is universal and that's the part where you're wrong.
If you want to do that, you'll have to introduce me to someone who was told to commit something in git and went and did it successfully. Without having to find a guide. And a guide to that guide. And read up on Directed Acyclic Graphs. And didn't break anything. And understood what they were doing.
I don't know. I've never heard anyone express confusion about "commit" in svn or hg, which are the tools I've used the most.
Because what my point is and has always been is that git is hard and TFS is easy. Git uses terminology that makes sense if you understand how git is implemented, and TFS uses terminology based around the goal the user is trying to accomplish.
I don't disagree that git makes a lot of things difficult but you chose a terrible example and made an obviously false claim when you said that TFS didn't use jargon.
-
@blakeyrat said in We don't understand TFS and we don't want to.:
Like if I read up enough about directed acyclic whatevers, I'd suddenly understand why a cherry picker is useful for source code?
No, this is just your retarded language ability where you confuse a verb with a noun and then refuse to admit that your confusion isn't the most reasonable interpretation ever.
-
@magus said in We don't understand TFS and we don't want to.:
I had never heard of TFS before my first programming job, and hadn't heard of git either
I hadn't either. Oh, wait. They hadn't been created yet.
-
@jaloopa said in We don't understand TFS and we don't want to.:
I think this is one argument you should step away from. Cherry pickers and cherry picking both come from the actual act of picking cherries
And yet I am not picking cherries. I'm working on source code. So what's the metaphor exactly? When I "stash" the source code, it feels like I'm "stashing" a document in a hidey-hole, ok. But when I "cherry pick" suddenly my document becomes a cherry? How does that make sense?
Let me ask you a different question: do you honestly believe there was any debate among the Git developers about which term would best communicate that concept? Any debate at all?
Because I don't believe so. I think one of them came up with this "cute" name, and just arbitrarily decided to make it official without consulting even one other person.
Come to think of it, do you think the Git developers have ever talked to anybody who's been subjected to their shitty product as a condition of employment? Ever? Even once? It's hard to imagine how Git could be in its current state if any had.
Cherry picking - Wikipedia
Do you know why a cherry picker is called a cherry picker?