When did Git become terrible? Let's track down the specific commit...
-
A cant find the original, but earlier there was a comment about "understanding" the software when it came to merges. The common tools have no clue because they are lexical rather than semantic. For the past 3-5 year I have been involved in an effort to have machine based semantic understanding and the results have been pretty darn good [no commercial products yet].
Consider the following old and new lines
old: int f(int A, int B);
new: int f(int B, int A);Does that represent a "swap" of the parameters? Or does it represent a "rename" of the parameters?
In the first case, all of the calling code would be modified, but not the internal. In the later case, all of the internal code would be changed, but not the calls.
Now imagine someone added in a new call somewhere in the codebase where this was still "old" and it was a parameter swap...... A truly intelligent semantic merge would alter the code being merged!!!! We are quite a ways away from this.
On the other hand, with a true robust centralized system the timeframes cane be made so small (minutes) that with proper work coordination (via the backlogs and work definitions) that the problem is minimized. However when practices may have this information localized (on a dev box, or even in a branch) the problem is quite real.
-
@wharrgarbl said in When did Git become terrible? Let's track down the specific commit...:
I had to control source with RCS.
When I started, we had filling cabinets with fan-fold paper tape <yes, we did>
Also VSS was actually a good product in its original days. IT was advances that occurred after the creation/release [back when it was a product from One Tree Software] which were never incorporated that led to it being such a problematic situation.
-
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
@wharrgarbl said in When did Git become terrible? Let's track down the specific commit...:
I had to control source with RCS.
No, he didn't say that.
-
@masonwheeler said in When did Git become terrible? Let's track down the specific commit...:
Does that explain what I was saying any more clearly?
You claimed that the master copy of the source code is its own backup. There is no amount of explanation that would allow that to make sense.
@masonwheeler said in When did Git become terrible? Let's track down the specific commit...:
Because what I said only makes sense if you're familiar with the way source control interoperates with build machines, which I assumed was the case based on what you said, because what you said only makes sense in the context of a build machine.
I know how a build system works. That is how I know you're talking absolute horseshit.
-
@raceprouk said in When did Git become terrible? Let's track down the specific commit...:
You claimed that the master copy of the source code is its own backup.
No I didn't. Where did I say that? (Hint: you can't find it, because it's not there.). Seriously, ??? I would have expected this degree of shoulder-alienry from , but you always seemed a bit more level headed than that.
I know how a build system works. That is how I know you're talking absolute horseshit.
Assertion failure: supporting reasoning not found
-
@masonwheeler said in When did Git become terrible? Let's track down the specific commit...:
No I didn't. Where did I say that? (Hint: you can't find it, because it's not there.).
Right here:
@masonwheeler said in When did Git become terrible? Let's track down the specific commit...:
@raceprouk said in When did Git become terrible? Let's track down the specific commit...:
TIL the definitive master version of a project's code is also a backup.
Of course it is.
Also here:
@masonwheeler said in When did Git become terrible? Let's track down the specific commit...:
That's what a "repository for your code" is: a backup system that's versioned (maintains history) and integrated (allows multiple people to add to it in an orderly fashion).
-
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
old: int f(int A, int B);
new: int f(int B, int A);
Does that represent a "swap" of the parameters?Given the new doesn't have that emoji, it's not just a swap.
-
@raceprouk Notably missing from either citation: the "its own" part.
-
@masonwheeler If you're going to deny your own words, then this conversation can serve no further purpose.
-
@raceprouk I'm denying the absurd words you imputed to me. Obviously a source control repository is not its own backup; that's a contradiction in terms. It's a versions, integrated backup of the developers' code.
-
-
@raceprouk said in When did Git become terrible? Let's track down the specific commit...:
@masonwheeler said in When did Git become terrible? Let's track down the specific commit...:
That's what a "repository for your code" is: a backup system that's versioned (maintains history) and integrated (allows multiple people to add to it in an orderly fashion).
TIL the definitive master version of a project's code is also a backup.
-
@masonwheeler said in When did Git become terrible? Let's track down the specific commit...:
No I didn't. Where did I say that? (Hint: you can't find it, because it's not there.). Seriously, ??? I would have expected this degree of shoulder-alienry from , but you always seemed a bit more level headed than that.
Yes, because you say stupid shit that would be fine as a throw away joke but then you keep defending it for reals and everyone starts to wonder about you.
-
@greybeard said in When did Git become terrible? Let's track down the specific commit...:
No, he didn't say that.
Yes, I copied from quoted text within wharrgarbl's post...
-
@masonwheeler said in When did Git become terrible? Let's track down the specific commit...:
Does that explain what I was saying any more clearly?
I think maybe you're confusing what it does with why it does what it does...?
In other words, you're using a particular implementation to try to describe the purpose...?
-
@boomzilla OK, here's the sequence of events as I see it:
- @RaceProUK inserted two spurious words ("its own") into my reasoning, turning a perfectly cromulent statement into a logical absurdity, and then accused me of saying things that don't make sense.
- I challenged her to cite where I had said that.
- She provided two citations, neither of which contained the two problematic words.
- I pointed out this discrepancy.
- She accused me of denying my own words, after I clearly explained that they were her words that I had never said.
Did any part of that not happen?
-
@djls45 said in When did Git become terrible? Let's track down the specific commit...:
I think maybe you're confusing what it does with why it does what it does...?
In other words, you're using a particular implementation to try to describe the purpose...?Hmm... what do you mean?
-
@masonwheeler said in When did Git become terrible? Let's track down the specific commit...:
@djls45 said in When did Git become terrible? Let's track down the specific commit...:
I think maybe you're confusing what it does with why it does what it does...?
In other words, you're using a particular implementation to try to describe the purpose...?Hmm... what do you mean?
I'm not sure, exactly (hence, the question marks). It just seems to me that your and the others' argument/definitions might fall under that kind of distinction. You're both saying that a VCS saves files and preserves history, but you're disagreeing about what falls under the definition of "backup" and how much a DVCS's build repo is similar to a CVCS's central repo. Is that accurate? (Does my summary make sense?)
-
-
@djls45 said in When did Git become terrible? Let's track down the specific commit...:
what falls under the definition of "backup"
This might be part of it.
OK, to me, the definition of "backup" is "putting a copy of your files somewhere else, independent of the machine that contains your working copy, such that failure, destruction, or other loss of your working machine does not mean loss of your files."
As such, source control definitely qualifies, and as it's a piece of functionality that makes source control useful for all projects, even single-developer ones, (which the integration functionality does not,) IMO it's reasonable to call the backup, and not the integration, the most important feature.
-
@masonwheeler said in When did Git become terrible? Let's track down the specific commit...:
the integration functionality
"integration" does not mean what you seem to think it does. The primary dfinmition is "to form, coordinate, or blend into a functioning or unified whole". Thus if you have to switch tools, you are not integrated.
So give me one tool where I can see everything about my system with active linkage between all the artifacts.
Let me be in an editor looking at a method in a file. Lets me see:
- The history of that method
- What was being worked on when that method was changed
- Why it was being worked on as an increment of value [User Story or PBI], then the Business level [Feature] and Corporate Management [Epic] levels
- What were the Acceptance Tests? How were these tests refined/altered over time
- What Bugs have been involved in this code? That elements (stories,features, epics) did they impact
- What Unit Level tests are associated with the code
- What builds has each version of the code been in
- [For In House] What systems is this code (specific versions of it) currently deployed to
I could keep going, but the above 8 items should start to give an idea of what "integrated" actually means.
-
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
"integration" does not mean what you seem to think it does. The primary dfinmition is "to form, coordinate, or blend into a functioning or unified whole". Thus if you have to switch tools, you are not integrated.
Different context. You're talking about integrating multiple development features; I'm talking about integrating code from multiple developers, which source control does handle per your stated definition.
-
@masonwheeler said in When did Git become terrible? Let's track down the specific commit...:
I'm talking about integrating code from multiple developers, which source control does handle per your stated definition.
That is commonly referred to as "merging", not "integration".
It also can occur with a single developer. For example working on different aspects of a large codebase concurrently.
-
@masonwheeler said in When did Git become terrible? Let's track down the specific commit...:
Did any part of that not happen?
None of this happened because you're not real, this forum is all on my imagination
-
@wharrgarbl said in When did Git become terrible? Let's track down the specific commit...:
@masonwheeler said in When did Git become terrible? Let's track down the specific commit...:
Did any part of that not happen?
None of this happened because you're not real, this forum is all on my imagination
Are youAm I a solipsist? How could I possibly tell?
-
@djls45 said in When did Git become terrible? Let's track down the specific commit...:
@wharrgarbl said in When did Git become terrible? Let's track down the specific commit...:
@masonwheeler said in When did Git become terrible? Let's track down the specific commit...:
Did any part of that not happen?
None of this happened because you're not real, this forum is all on my imagination
Are youAm I a solipsist? How could I possibly tell?Yes, you are a solipsist because I am a solipsist and I believe you are a solipsist. You will know that is true when I believe you know that is true
-
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
That is commonly referred to as "merging", not "integration".
It's known as integration as well, since that also covers the case of unrelated changes that have to be consolidated into one codebase, while "merging" generally means changes to the same area of the code that have to be integrated.
Hence why it's called Continuous Integration, not Continuous Merging. Nobody wants to merge continuously.
-
@yamikuronue said in When did Git become terrible? Let's track down the specific commit...:
Hence why it's called Continuous Integration, not Continuous Merging. Nobody wants to merge continuously.
While that was the original definition when Grady Booch coined the term back in 1991, it has evolved in the past 25+ years.
The most common working definition is:
Continuous integration (CI) is a software engineering practice in which isolated changes are immediately tested and reported on when they are added to a larger code base. The goal of CI is to provide rapid feedback so that if a defect is introduced into the code base, it can be identified and corrected as soon as possible. Continuous integration software tools can be used to automate the testing and build a document trail.
Thus the items in my previous bullet list all are part of CI using modern definitions.
-
@thecpuwizard and a CI tool isn't a source control tool unless both categorys only include TFS. CI tools communicate with source control and add CI functionality on top.
-
@masonwheeler said in When did Git become terrible? Let's track down the specific commit...:
Did any part of that not happen?
I'm not going back through all that to adjudicate your spat. I'm still just making fun of you for defending blakey's misuse of git.
-
@yamikuronue said in When did Git become terrible? Let's track down the specific commit...:
@thecpuwizard and a CI tool isn't a source control tool unless both categorys only include TFS. CI tools communicate with source control and add CI functionality on top.
My entire point is that when there is segregation between functionality [A "source control" tool and a set of "CI tools"] then there is not integration. So much work was done in developing properly integrated tools in the 2003-2012 time frame.
For environments where this integration provides value [which I believe is nearly all business/corporate environments] the trend away from comprehensive integrated tooling is "terrible". This [IMPO] transcends all of (or at least the vast majority) of other aspects in a discussion around Git.
-
@thecpuwizard But code integration can be achieved separate from tool integration. Just like both can be achieved separate from the financial integration between my and my husband's bank accounts.
-
@yamikuronue said in When did Git become terrible? Let's track down the specific commit...:
But code integration
Actual production code can be less than 10% of the cost/value/work of a system. Focusing on that, rather than all of the considerations from concept thru end-of-life and all of those involved has been documented as the root cause of many failures.
-
@thecpuwizard I don't think you're actually reading what I'm writing at this point. All I'm saying is they're different. I prefer a well-integrated IDE myself.
-
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
My entire point is that when there is segregation between functionality [A "source control" tool and a set of "CI tools"] then there is not integration. So much work was done in developing properly integrated tools in the 2003-2012 time frame.
You seem to be asserting that the only way that there can be integration is when there is a single tool. That's manifestly not true; there is exact contradictory evidence available for anyone to examine who cares to (e.g., the cluster of services centred around github). You've most certainly not got a single tool or a single service, but rather a plethora of them, but you've got integration anyway.
-
@dkf said in When did Git become terrible? Let's track down the specific commit...:
You seem to be asserting that the only way that there can be integration is when there is a single tool. That's manifestly not true; there is exact contradictory evidence available for anyone to examine who cares to (e.g., the cluster of services centred around github). You've most certainly not got a single tool or a single service, but rather a plethora of them, but you've got integration anyway.
A fair conclusions based upon what I have posted. But that is a small sample, so please let me expound.
One definitely can (from a physical possibility perspective) achieve great integration with disparate tools. I have one client that did so. Their environment is awesome, better than anything I have ever seen from any single toolset, or combination at other sites. The thing is it cost them over $2M to develop and over $250K/yr to support.
It is much more common when I encounter multiple tools put together (especially without direct vendor support) is a combination of gaps and friction. The friction often asserts itself when one tool upgrades and another is still at an older version. As vendors move from updates every few years down to updates every few weeks, these points of friction become more common.
Even with the above, we are still not back to my original point. While "distributed" is great for certain things, any delay or gap in information access is problematic in environments (like most corporations) where there is a single "centralized" set of goals and objectives.
Git shines when distribution is key [see my previous post on the organization with distribution from local chapters to international level -0 each with their own sets of goals and objectives].
Also Git can be coerced into acting like a mock centralized system, with varying degrees of success. I believe Blaky's situation is one where "centralized" concepts are in play is at least a partial cause of the problems - but I do not have enough detailed knowledge of that situation to be sure. My question in these cases, is why try to force a system designed for loosely coupled/distributed to act like a tightly coupled/centralized system, when there are multiple systems that are designed with those goals in mind.
If you want to have some fun to see how well "integrated" a team is (both across the people and across the tools)... Have one person do a simple thing, every night: Use ReSharper (or equiv) to restructure the code (alphabetize or sort by access or...) and commit the changes to main. In a perfectly integrated environment (it does not exist) there would be zero impact on the workflow. As the "Segmentation" (potentially caused by many things) increases, the project will quickly fall apart.
-
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
If you want to have some fun to see how well "integrated" a team is (both across the people and across the tools)... Have one person do a simple thing, every night: Use ReSharper (or equiv) to restructure the code (alphabetize or sort by access or...) and commit the changes to main.
And then the murders began.
In a perfectly integrated environment (it does not exist) there would be zero impact on the workflow.
Sure, aside from the murders and all.
-
@boomzilla said in When did Git become terrible? Let's track down the specific commit...:
Sure, aside from the murders and all.
A few death threats, the assault charges of '09, the international incident of '12....sure. But so far no actual murders
But look at the flip side. How many times has "we cant change that because it might break something" or "we changed this and it broke that" been the root subject of TheDailyWTF???
If one can get to the point where things have really come together, then those problems are non-existent.
-
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
But so far no actual murders
-
@asdf said in When did Git become terrible? Let's track down the specific commit...:
@blakeyrat said in When did Git become terrible? Let's track down the specific commit...:
Maybe, but I've yet to work with a company that'll allow a branch without JIRA (or whatever) issue number in the name of it.
You work at shitty companies with overly restrictive rules.
Meh, our (small) team decided to do something similar, we require it on commits, not branches. Doesn't seem that painful. Company doesn't require it.
-
@blakeyrat said in When did Git become terrible? Let's track down the specific commit...:
And there's no way to give that copy to another person without being required to write an asinine commit message.
and/or
git diff
?git diff-index -p
Granted, it doesn't send the patch for you, but you can send them the diff.
-
@jazzyjosh So at the end of the day I'm supposed to run this bullshit command and then email the resulting to someone?
Well that's certainly frictionless compared to VSTS, where to solve the same problem you follow these steps:
-
@blakeyrat said in When did Git become terrible? Let's track down the specific commit...:
So at the end of the day I'm supposed to run this bullshit command and then email the resulting to someone?
Huh? You wanted to give something to someone and that's a simple way to do it.
@blakeyrat said in When did Git become terrible? Let's track down the specific commit...:
Well that's certainly frictionless compared to VSTS, where to solve the same problem you follow these steps:
So...it automatically saves the state of your working copy and notifies people at the end of the day? It seems like that would get annoying.
-
@blakeyrat said in When did Git become terrible? Let's track down the specific commit...:
@jazzyjosh So at the end of the day I'm supposed to run this bullshit command and then email the resulting to someone?
You stated there was no way to do this. I provided a way. I'm not saying it's a good way.
I'm not sure why creating a commit is a problem though.
My workflow is to create a branch on my fork, make some quickhand messaged commits, when I'm done working rebase and use appropriate messages, push, then open a PR from my fork to the main repository.
-
@jazzyjosh said in When did Git become terrible? Let's track down the specific commit...:
I'm not sure why creating a commit is a problem though.
Creating a commit isn't a problem.
Having to give the commit a name is. Because there's no good name other than "opps didn't finish and I'm done for the day will pick it up on Monday".
Then later when you have to get rid of that commit message, it's a torturous error-prone horrible user experience that could potentially lose all your work and makes you long for death.
So:
- You have to create a bullshit commit message
- Getting rid of it later is horrible
The solution is fixing one of those two bullets. With stashes I don't need to enter any commit message at all, so those would be perfect, but they don't get stored on the server.
-
Rebases aren't that terrible, assuming you aren't pushing to a shared repository. If you're concerned about losing work, just create another branch where you're at and push it before doing any rebasing. Congratulations, you now have a pointer to your previous work you can restore to without using the reflog.
Alternatively, don't rebase at all, just create the commit, push to a separate branch, then
git reset HEAD~1
orgit reset HEAD^
whichever floats your boat. Bam, commit gone and you didn't have to do any rebasing nor force pushing, and if you somehow manage to fuck that up your remote branch is still around to pull from.
-
@jazzyjosh said in When did Git become terrible? Let's track down the specific commit...:
Rebases aren't that terrible,
You are incorrect.
There actually isn't any operation in Git I'd classify as "not terrible".
-
@blakeyrat said in When did Git become terrible? Let's track down the specific commit...:
Creating a commit isn't a problem.
Having to give the commit a name is.Every commit to a source control should have a link to some type of tracking system. With Git this is "#nnn" [which sucks in its own right, but another gripe] - so there is inherently that in a comment.
"opps didn't finish and I'm done for the day will pick it up on Monday" is generally indicative of a bigger problem. If Tasks are broken down properly, they should be started and finished with in a day 99% of the time. If it is near the end of the day and there is not sufficient time to (have a very high probability) of completion then it is usually considered a better practice to do something else.
-
@blakeyrat said in When did Git become terrible? Let's track down the specific commit...:
There actually isn't any operation in Git I'd classify as "not terrible".
Cloning isn't that terrible. Just specify the URL and you get a Git repo-- oh. End result's the terrible part, not the process itself on that one.
-
@thecpuwizard said in When did Git become terrible? Let's track down the specific commit...:
"opps didn't finish and I'm done for the day will pick it up on Monday" is generally indicative of a bigger problem. If Tasks are broken down properly, they should be started and finished with in a day 99% of the time. If it is near the end of the day and there is not sufficient time to (have a very high probability) of completion then it is usually considered a better practice to do something else.
In what fucking world do you live in where any problem can be solved within a day?