Git help - branches with no commits?
-
If I have a device that feeds me chocolate and beer while giving me a massage, but the interface requires me to break all my fingers, then it is a bad product.
But if I had a device that gives me million dollars, but every time I used it, I felt pain like my fingers were all being broken, but they don't actually get broken, I'd still be happy.
-
others (including me) think it's important, but not as important as core architecture
<insert four hours of uncontrollable laughter>
So, in your world, if you have the greatest program in the universe, a shining gem of quality far beyond anything else with absolutely no entrypoint, it is good software because it has the most important thing done right?
-
That's great, but it requires going through one-by-one and that ain't gonna happen.
You're getting paid, aren't you?
-
So, in your world, if you have the greatest program in the universe, a shining gem of quality far beyond anything else with absolutely no entrypoint, it is good software because it has the most important thing done right?
No, because it's not functional.
-
-
Well, you
ed first by going from terrible, terrible UI to no UI at all.
-
If you have UI no one wants to use, that isn't much different from not having UI. No matter how beautiful your architecture, no one will use it.
-
Which can only lead to the conclusion that since there is so many git users, it's proof that its UI is not that bad.
-
A lot of people at the circus pay to watch the dancing bear, even though his dancing is awful.
-
If you have UI no one wants to use, that isn't much different from not having UI.
Yes there is. For example, it works.
-
What? Do you not understand simple logic at all? Oh right, you use git.
-
Yes there is. For example, it works.
If even 30% of your potential customers look at your product and say 'Wow, I never want to touch that with a 10 foot pole' and you have competitors, you are doing something wrong.
You don't seem to believe this for some reason, which implies that you do not have the ability to reason.
-
If you have UI no one wants to use, that isn't much different from not having UI. No matter how beautiful your architecture, no one will use it.
My answer :
@TimeBandit said:Which can only lead to the conclusion that since there is so many git users, it's proof that its UI is not that bad.
You don't seem to understand simple logic.
-
No, it doesn't. Look up logical implication. You are just making yourself look stupid.
-
This post is deleted!
-
If even 30% of your potential customers look at your product and say 'Wow, I never want to touch that with a 10 foot pole' and you have competitors, you are doing something wrong.
Yes, I do. I do UI wrong. It says nothing about the quality of the rest of software. And how much it affects overall quality depends on how I measure overall quality. Clearly, we have different methodology.
-
It says nothing about the quality of the rest of software.
What does any kind of quality matter that doesn't affect your customers? Writing clean code is important to exactly the extent that it makes it easier to improve the product for customers. Unless you are the only person who will ever use your software, you cannot possibly make an argument in favor of internal quality over external quality without being 100% pure unrefined front page material.
-
No, it doesn't. Look up logical implication.
Your statement:- X has shitty UI ⇒ (¬ X has users)
By definition of implication: - (¬ X has shitty UI) ∨ (¬ X has users)
Variable substitution: - (¬ Git has shitty UI) ∨ (¬ Git has users)
Fact: - Git has users
Taking 3 and 4 together: - ((¬ Git has shitty UI) ∨ (¬ Git has users)) ∧ Git has users
Applying disjunctive syllogism on 5: - ¬ Git has shitty UI
QED
- X has shitty UI ⇒ (¬ X has users)
-
What does any kind of quality matter that doesn't affect your customers?
What does any kind of customer matter if they don't affect Git developers' pockets?You know, money isn't the only thing in this world that matters.
-
A implies B does not equal B implies A. You are insane.
You know, money isn't the only thing in this world that matters.
Yeah, instead, lets litter the world with garbage!
-
Unless you are the only person who will ever use your software, you cannot possibly make an argument in favor of internal quality over external quality without being 100% pure unrefined front page material.
Available features is external quality. Neat and flexible abstract data model is external quality. Good data exchange protocol is external quality. Efficient storage is external quality. All of these matter, and Git does all of these right.
-
A implies B does not equal B implies A.
Where did I ever write that B implies A? All I did is take your statement, take well known fact, and make a perfectly valid logical proof. My proof is logically correct and you know it.
-
All of these matter, and Git does all of these right.
For a definition of 'right' that does not involve 'people find it easy and logical to use, with reasonable errors when there is a problem'.
Which is why you are a Fox-level complete moron.
-
Git having users will never imply that it has good usability. That has been and will always be my point. Dance all you want. You will always be wrong if you oppose that.
-
Yay flamewar in a General Help thread; mute.
I'll let Blakey add the flame emoji if he wants.
-
Gaska said he was going to force there to be one up at least 50 threads, despite the category, and despite being completely wrong in every way. Jeffing is the only thing that can save this thread in theory, but he'll come back.
-
For a definition of 'right' that does not involve 'people find it easy and logical to use, with reasonable errors when there is a problem'.
If we're not talking about UI (and I wasn't talking about UI), then you are wrong. I assure you that if the commands were easier to type and feedback was better, then people would have no problem at all using Git. In other words, the only thing that makes Git hard to use is UI and UI only. All the features are perceived by people as easy and logical to use at abstract level - and since it's all abstract, the part about errors doesn't apply. It's possible to make Git easy to use by changing UI and UI only, without touching any other part of the code at all. If the problems you mentioned applied to any other part of Git except UI, it wouldn't be possible to make Git easy by rewriting just UI and nothing else. That leaves us with just two possibilities:- Git has terrible, terrible UI, but the rest is quite good;
- Git is fundamentally broken and unusable by any means and nothing could possibly change it except for scrapping everything and having a completely fresh start.
I don't see you saying the latter despite many occasions to do so, so I assume you don't believe that's true (neither do I). Therefore, we must conclude that Git is good except for UI. How exactly shitty UI affects the overall quality is the kind of question you don't ask unless you want to waste time for literally nothing.
Git having users will never imply that it has good usability.
No one here claims that Git has good UI. @TimeBandit said that it's just, quote, NOT THAT BAD, end quote. "Good" and "not that bad" are very different things.
-
Gaska said he was going to force there to be one up at least 50 threads
I don't remember saying that. I'm fairly sure you're twisting my words and what I actually said is more like "I don't care if there's a flame war in this category or not", which is very different from "going to force it". About as different as "not that bad" is different from "good".Jeffing is the only thing that can save this thread
The thread is closed already! Haven't you heard?
-
Boomzilla has the opinion that the way I think about stuff is weird (apparently because I don't think a metaphor where branches extend from masters makes sense),
You're just incredibly mentally inflexible and kind of dumb. At least, that's how it comes off.
-
All of these matter, and Git does all of these right.
No it doesn't.
Available features is external quality.
Git lacks a TON of features compared to competing source control products; you've undoubtedly read my posts about that before.
Neat and flexible abstract data model is external quality. Good data exchange protocol is external quality.
Implementation details. Irrelevant. Definitely not a measure of "external" quality.
Efficient storage is external quality.
I'll keep that one in mind next time Git stops my work cold while doing it's 15-minute-long database cleanup whatever it does.
-
You're just incredibly mentally inflexible and kind of dumb. At least, that's how it comes off.
Fortunately, I don't give a fuck what you think of me.
-
You would if you were smarter than you are.
-
Call me stupid all you want, a metaphor that combines "masters" and "branches" doesn't make any sense. It really doesn't. Go ask an English teacher.
-
It's the master branch among all the branches. It makes perfect sense.
-
No it doesn't.
For the most part, it does. It has problem with very large repos, but besides this, it's doing good.Git lacks a TON of features compared to competing source control products; you've undoubtedly read my posts about that before.
The ones that turned out to be a lie, or the ones you haven't written yet because you can't find anything?Implementation details. Irrelevant. Definitely not a measure of "external" quality.
Details that actually affect the users. Data model defines semantics of various operations. And these semantics are what user has to learn to work efficiently with Git, in addition to syntax. Yes, syntax sucks, but semantics are very nice (at least compared to SVN - I never worked with any other VCS besides these two, though). And the protocol matters to people who want to write additional tools around Git, so for 99% of people it's irrelevant, but for 1% it's very relevant.I'll keep that one in mind next time Git stops my work cold while doing it's 15-minute-long database cleanup whatever it does.
I never experienced this kind of problem.
-
Call me stupid all you want, a metaphor that combines "masters" and "branches" doesn't make any sense. It really doesn't. Go ask an English teacher.
It's the master branch among all the branches. It makes perfect sense.
You're both wrong. It's the branch where the master copy of the product can be found.
-
You're both wrong. It's the branch where the master copy of the product can be found.
I don't see how that contradicts what I said.
-
Even if it doesn't contradict that, you can still be wrong. FWIW, @Buddy might be spilling bullshit too.
-
I never experienced this kind of problem.
I think he is (or maybe his colleagues are) putting large binary files in the repository, and using rebasing quite a bit (though he might not realise it if it's all hidden behind some smartass GUI). Do that, and you can get the need for major cleanup quite often.
Or maybe the hardware running the cleanup is shit, or the implementation of git for Windows is shit. I don't know. I just speculate.
-
The ones that turned out to be a lie, or the ones you haven't written yet because you can't find anything?
No file locking, no server-side stashes, no (practical) support for sparse repos. Probably a half-dozen more if I actually spent some time thinking about it.
Yes, yes, I know, now give me the common response whenever confronted with a feature Linux doesn't have: "well you don't really need it". I bet you were 2/3rds of the way through typing that as a knee-jerk reaction before you started reading this paragraph.
Details that actually affect the users. Data model defines semantics of various operations. And these semantics are what user has to learn to work efficiently with Git, in addition to syntax. Yes, syntax sucks, but semantics are very nice (at least compared to SVN - I never worked with any other VCS besides these two, though).
What the fuck are you talking about.
And the protocol matters to people who want to write additional tools around Git, so for 99% of people it's irrelevant, but for 1% it's very relevant.
It wouldn't be if Git's functionality was implemented in a shared library, as it should be.
I never experienced this kind of problem.
Ok. And yet, is is a problem, and I experience it about once a month or so.
-
Or maybe the hardware running the cleanup is shit, or the implementation of git for Windows is shit. I don't know. I just speculate.
Or maybe the entire product and ecosystem is shit.
Look, if it needs to do some kind of maintenance, here's a couple suggestions, a.k.a. "things you would do if you weren't a shitty incompetent developer":
- Create a Service to do the maintenance, so it doesn't block operations on the CLI client
- Instead of doing 100% of the maintenance at once and blocking the user for 15 minutes, just do 1% of the maintenance each operation
- Implement threading. Do maintenance in the free time the Git client has while it's waiting for the server to come back with info
Free ideas for improvement! Take one!
But of course, Git will never be improved, because they do not give a fuck.
-
No file locking
The distributed nature of Git makes it quite hard to imagine. We've been through this.no server-side stashes
There are. They're called branches.no (practical) support for sparse repos
Sorry, I don't quite remember what the problem was. Do you? If so, could you remind me of what that was?Yes, yes, I know, now give me the common response whenever confronted with a feature Linux doesn't have: "well you don't really need it". I bet you were 2/3rds of the way through typing that as a knee-jerk reaction before you started reading this paragraph.
You're lying. In the sense that it's not true.What the fuck are you talking about.
I'm talking about how in Git, I don't have to fuck with all these mergeinfos etc.It wouldn't be if Git's functionality was implemented in a shared library, as it should be.
Wouldn't be what?Ok. And yet, is is a problem, and I experience it about once a month or so.
Fair enough.Or maybe the entire product and ecosystem is shit.
Or maybe your workflow is shit.Create a Service to do the maintenance, so it doesn't block operations on the CLI client
That sounds like a good idea, except that a) it introduces additional overhead in every operation ever, even if you don't ever do cleanup; b) for most repos, cleanup is fast, so the number of users who would benefit from it is very small - and implementing a service would be much work, especially if you want to be multiplatform (they want) since there is no single common line of code handling system-wide services between major operating systems. It's simply not worth the effort.Instead of doing 100% of the maintenance at once and blocking the user for 15 minutes, just do 1% of the maintenance each operation
Yeah, that could work. If the work is divisible.Implement threading. Do maintenance in the free time the Git client has while it's waiting for the server to come back with info
Same as above. Communicating with server doesn't take long after all, and you don't want to wait for the cleanup thread to complete too long.Free ideas for improvement! Take one!
Ideas are worthless. If you sent them implementation, however (even incomplete and buggy one - or even not concrete code, just an in-depth design how to do it), I'm sure they'd be very happy and include those features in no time.But of course, Git will never be improved, because they do not give a fuck.
Yes, they do not give a fuck about a very rare problem. Neither does any software company in the world.
-
It probably didn't help that the Git for Windows was stuck on 1.9.5 for about 2 years before they finally updated it to 2.7 within the last 3 months.
Edit: Apparently there were betas for other 2.x versions, but their download page never showed them... so unless you knew to look through the git-for-windows releases list on GitHub, you would never have seen them.
-
There are. They're called branches.
You shouldn't be using a branch as an equivalent to stash :/
-
The distributed nature of Git makes it quite hard to imagine. We've been through this.
AND YET that doesn't change the fact that Git does not have the feature and its competitors do.
There are. They're called branches.
Meh. Not the same thing. Especially since Git does have something called a "stash" (which is explicitly NOT a branch), it just doesn't happen to be stored on the server. You can "kind of" use a branch as a stash, but it's definitely not the same thing as a stash.
A lot of Git setups like the one I'm using won't let you use branches unless they have an associated JIRA ticket (or whatever ticketing system you're using). This precludes using branches to serve the function of stashes.
And here's the part where you tell me my company is doing it wrong, well whatever, I don't care what you think.
Sorry, I don't quite remember what the problem was. Do you? If so, could you remind me of what that was?
I couldn't create a Git repo around Skyrim's Data folder to store my mods (but not the gigabytes and tens of thousands of files of Skyrim's data.) Honestly at the moment I can't remember WHY it didn't work, but I do remember THAT it didn't work.
I'm talking about how in Git, I don't have to fuck with all these mergeinfos etc.
What the fuck are you talking about. I don't even know what a "mergeinfo" is. A brand of breakfast cereal? Although I'm sure you're about to call me a moron for not knowing that.
and implementing a service would be much work,
"We're Git engineers, we won't solve problems the right way if it's slightly difficult! We're wussy wimp cowards! Waaaah I want my mommy!"
If you sent them implementation, however (even incomplete and buggy one - or even not concrete code, just an in-depth design how to do it), I'm sure they'd be very happy and include those features in no time.
Hahaha there's like 57 different types of "ain't gonna happen" in that sentence.
-
Jeffing is the only thing that can save this thread in theory
Well, you could stop replying to him.
-
You could stop spamming up the thread when I already changed the category to General.
-
You shouldn't be using a branch as an equivalent to stash
Why? I just want to push some changes to the server so I can access them elsewhere. Then remove the branch once I don't need it anymore. What's wrong about it?AND YET that doesn't change the fact that Git does not have the feature and its competitors do.
Yes. But remember that competitors lack Git's features too. That's the beautiful thing about competition - you have many different products to choose from and choose the one you like the most!Meh. Not the same thing.
It's not, but it accomplishes the task of "I want to put some code temporarily on the server so I can check it out somewhere else".A lot of Git setups like the one I'm using won't let you use branches unless they have an associated JIRA ticket (or whatever ticketing system you're using).
That's awful. Your management are idiots.And here's the part where you tell me my company is doing it wrong, well whatever, I don't care what you think.
This sounds like you actually like the way your management thinks about it. Which makes you an idiot too.I couldn't create a Git repo around Skyrim's Data folder to store my mods (but not the gigabytes and tens of thousands of files of Skyrim's data.)
Ah, yes, I remember that. Kinda. Sorta. Yes, your situation was special. Git didn't handle it well. It's not a good tool to use in this situation. But it doesn't mean Git sucks in its main use case, which is versioning the source code of a whole project.What the fuck are you talking about.
I'm talking about how Git's data model is way better than SVN's data model, and how it's very relevant to me and actually affects my work, as a proof that it's not just implementation detail.I don't even know what a "mergeinfo" is. A brand of breakfast cereal? Although I'm sure you're about to call me a moron for not knowing that.
No, I won't. But I'll call you an asshole for not stopping after first period.We're Git engineers, we won't solve problems the right way if it's slightly difficult!
Slightly? Implementing full-blown system-wide service to handle all the git repos scattered over your whole filesystem (and sometimes beyond) in one process, for each operating system separately, is "slightly" difficult?Hahaha there's like 57 different types of "ain't gonna happen" in that sentence.
I don't know what sentence you're referring to, since it's definitely not the one you quoted.
-
Yes. But remember that competitors lack Git's features too.
TFS doesn't. Not any I'm aware of.
That's the beautiful thing about competition - you have many different products to choose from and choose the one you like the most!
Except with source control, you can't. You have to use it as a condition of employment. Usually the decision to use it was made before you even started working there.
That's why it's TRIPLY important for software where people don't really have a choice but to use it to be quality and easy-to-use. Because otherwise, you're just making people hate computers. I hate when bad developers make people hate computers. People should love computers.
That's awful. Your management are idiots.
Oh hey look. Blakeyrat can predict the future.
Ah, yes, I remember that. Kinda. Sorta. Yes, your situation was special.
Works fine in Subversion. Works fine in TFS. Works fine in fucking CVS. It's just Git that's busted.
But it doesn't mean Git sucks in its main use case, which is versioning the source code of a whole project.
That was my use-case, idiot. The only catch is that Skyrim mods have to live in Skyrim's folder tree. (Frankly, not that weird of a "catch".) So the source code of my whole project just happened to be inside another software product's folder tree.
If Git's developers didn't consider that situation when they designed the software, they are incompetent. But we already knew that. Gaska just refuses to admit it.
I'm talking about how Git's data model is way better than SVN's data model, and how it's very relevant to me and actually affects my work, as a proof that it's not just implementation detail.
Yeah, well, you're wrong. It's implementation detail. Doesn't matter. Has zero to do with the user experience.
Slightly? Implementing full-blown system-wide service to handle all the git repos scattered over your whole filesystem (and sometimes beyond) in one process, for each operating system separately, is "slightly" difficult?
I proposed two other alternatives. Git hasn't done fucking anything at all to fix the problem.
-
It wouldn't be if Git's functionality was implemented in a shared library, as it should be.
They seem to have fixed this: https://libgit2.github.com/
I'll be trying it this weekend to see if it's any good. CLIs aren't APIs and people that call the command line from a program should be ashamed of themselves (and find better tools).
