More stupid Git errors THIS TIME IN FIRST-PERSON!
-
What I'm missing is an autopilot.
And you won't learn the concepts of actually flying a plane simply by pushing buttons and twiddling knobs on a control console -- you need to get hands on with the plane to do that, to understand how pitch and power come together to get you an airspeed + climb/sink rate, and how bank and yaw interact with that as well.
Imagine if you could control a car simply by setting which way it was going and how fast; now, then take that and try to drive on Watkins Glen, in a badly mistuned car...
-
Hehe, so you should use git fetch instead of git pull because:
half the time it will trash your local repo
Not half the time. I'd say 0.00000001% of times.the other half of the time it will tell you to call git pull anyway...
Actually,git merge(orgit rebase).git fetchfollowed bygit pullis basicallygit fetch; git fetch; git merge- and the last bit is why it worked.There's also a fastforward.
I don't know how to do one, but that's a concept in git.
Fast-forward merge is the default thing git does. You surely did it at least once. It works only when there are no changes on one of branches - like, if branch foo contains commits A, B and C, and you make a branch bar from it, then make commits D and E, branch bar can now be ff-merged to foo because it's just an incremental change - and ff-merge works by changing foo's head to point to bar's head.When it says "it can be fast-forwarded", it means that either (a) your local branch has no commits that remote doesn't have, so
git pullwill do ff-merge, or (b) the remote has no commits you don't have on your local branch, sogit pushwill do ff-merge.
-
F1 car is useless for 98% of population too.
I hate this analogy. Git isn't an F1 car while SVN is a Geo Metro, or whatever the BS car analogy of the day is. SVN is a car. Git is also a car, but for some reason someone added a kitchen sink, turbolaser turret, abacus, third axle perpendicular to the first two axles, a bumper hitch duct-taped upside-down to the driver-side mirror, headlights with 24-bit color support, barbwire seatbelt straps, and the bottom half of a porta-john for passenger seats. And they removed the steering wheel and throttle pedal because those are fundamentally wrong, somehow. And the manual is an incomplete children's coloring page from Applebee's.
And us SVN guys stare at that and wonder how that's supposed to be an improvement, but all the Git guys can say is "Your SVN car doesn't even have an engine or wheels!! Ha ha!!"
-
My favorite thing about git is that every time you fuck something up, there's never any shortage of people willing to tell you that they would never have fucked up in the same way.
"What do you mean, you followed the instructions it printed on the screen? Are you some kind of idiot?"
-
Git isn't an F1 car while SVN is a Geo Metro, or whatever the BS car analogy of the day is.
Git is F1 car. It's useless to 98% of population. SVN is WRC car. It's useless to 97% of population. Professional tools will always be useless to people who don't know shit about the field.And us SVN guys stare at that and wonder how that's supposed to be an improvement, but all the Git guys can say is "Your SVN car doesn't even have an engine or wheels!! Ha ha!!"
The only one in this thread laughing that someone's toy doesn't have something his toy does is TFS guy.
-
My favorite thing about git is that every time you fuck something up, there's never any shortage of people willing to tell you that they would never have fucked up in the same way.
And I will be the guy who says "I frequently fuck up things in the same way as do, but I don't care because I can easily unfuck them. Here's how: (...)".
-
BTW. Why don't you want to use
git pull --rebase? There's nothing scary in it. Actually, the default behavior is much, much more scary. I'd hazard a guess that you ignoring my earlier advice to always pull with rebase is why you fucked up your repo.
-
I'm working with a project in Git that is 800MB in size
That is miniscule... I regularly work with clients who have a single TFS Team Project Collection (Source Control Repro) that is measured in multiple Terabytes. The primary repro at Microsoft was 14 terabytes - six years ago and has grown immensely since then [http://blogs.msdn.com/b/bharry/archive/2009/05/31/devdiv-tfs-database-sizes.aspx]
-
Fast-forward merge is the default thing git does. You surely did it at least once. It works only when there are no changes on one of branches - like, if branch foo contains commits A, B and C, and you make a branch bar from it, then make commits D and E, branch bar can now be ff-merged to foo because it's just an incremental change - and ff-merge works by changing foo's head to point to bar's head.
Which has the immediate problem that there were never a point in tie where foo contained only D...but it appears that there was.
-
BTW. Why don't you want to use
git pull --rebase? There's nothing scary in it. Actually, the default behavior is much, much more scary. I'd hazard a guess that you ignoring my earlier advice to always pull with rebase is why you fucked up your repo.I think I had mentioned I was considering using it, I'm just not 100% sure what the implications are.
If
git pull --rebaseis going to do what I want 100% of the time (which is for now, one single remote github repo on about 3-4 different local machines, one single branch, one single developer), then I'm willing to give it a try.But it just seems that almost every time I try to get smart or stray from my known-safe set of git interactions I end up getting my local repo into such a state that the quickest way to put it out of its misery is just to reclone the damn thing.
Although I am getting pretty good at nuking and recloning my local repos now, so...
-
Which has the immediate problem that there were never a point in tie where foo contained only D...but it appears that there was.
Usually that's not a problem - often even desired, especially with pulling/pushing. But if you really (need to) care about such details, you can always use --no-ff.I think I had mentioned I was considering using it, I'm just not 100% sure what the implications are.
The implications are that your branch's history won't contain random merges with itself.
-
Easier to just avoid making mega-repositories in the first place.
Consider a multinational company with tens of thousands of developers and the desire to have the ability to do a comprehensive audit across the entire base.
About one a year I get a call from such a company where some employee (usually senior and trusted) has done something, and they need to track everything that the person has touched. The person has moved project to project (division to division, etc) because of his role in the company.
Now try to find this in a DVCS (of any type)....Remember the person that pushed through the various levels to the different "masters" may not be the person who did the original work (on repro's that were on machines that may no longer exist).
-
@tar said:
I think I had mentioned I was considering using it, I'm just not 100% sure what the implications are.
The implications are that your branch's history won't contain random merges with itself.So when people are advising to use
git fetchinstead ofgit pullthey're really advising to usegit pull -rinstead ofgit pull?I feel like pointing out I did say this, but nobody replied to me at the time:
https://what.thedailywtf.com/t/more-stupid-git-errors-this-time-in-first-person/49928/270?u=tar
Well, I mean, my post actually had formatting in it, but whatevs, onebox...
-
So when people are advising to use git fetch instead of git pull they're really advising to use git pull -r instead of git pull?
No, people who are advising to usegit fetchinstead ofgit pullare not me. I'm advising something completely different, solving completely different problem.
-
Usually that's not a problem
Until it is a major problem (perhaps years later). Also there is no way (that I have been able to find) that can PREVENT the usage of -ff.
I also question the "desired" part. There should always be the ability to build code and get the exact same output at anypoint in time. The discrepancy allows the ability to build code that "appeared" do exist, but actually never did. Thus opening the door to problem (including liability/legal).
-
OK, now I find myself wondering if I should just do this: $ git config --global --bool pull.rebase true And carry on pretending that git fetch isn't a thing...
If you want, you might set this option - saves you three keystrokes every hour. But personally, I wouldn't do this, for the same reason I don't make any aliases and such - because when I sit at another computer, my muscle memory would surely fuck things up for ma and the owner.Until it is a major problem (perhaps years later).
What kind of problem, for example?
-
I also question the "desired" part. There should always be the ability to build code and get the exact same output at anypoint in time. The discrepancy allows the ability to build code that "appeared" do exist, but actually never did. Thus opening the door to problem (including liability/legal).
It DID exist. There IS a commit that contains the state of the whole codebase as it was the moment the change was commited. This commit has a timestamp and author, and references the commit it was based upon. The fact all of this happened on some other branch is pretty meaningless, because branches are nothing but pointers to a particular commit, that can change what they point to over time.That is in Git. In SVN, your complaint would be perfectly valid - but at the same time, fast-forward merge is impossible in SVN by design.
-
So when people are advising to use git fetch instead of git pull they're really advising to use git pull -r instead of git pull?
I like to use
git fetchinstead ofgit pull.git fetchwill update (for example) my origin/master branch so that I can do things likegit diff origin/master masterwhich will show me the differences between my master and origin's. Then, while on my master branch, I might dogit merge origin/masterto merge in origin's stuff.Alternatively I might do
git rebase origin/masterwhich will rearrange things so that my local master commits are now after everything on origin/master.That's an example of why/how you might use fetch, anyway.
-
Two people change the same SQL Server .mdf file simultaneously. Then try to merge their changes.
The obvious answer was to not store binary files in source code management but there's a social side to it as well. I'd rather know who are working on what around the same codebase than ignore everyone else because their work might be relevant to mine.
Actually talking with people also makes merging less painful if two or more people are working on the same source files and they have some sort of idea how their features will work together instead of everyone just doing their own thing and it's a race who checks in their work first to avoid resolving any conflicts.
Locking is not needed when people actually collaborate.
-
The fact all of this happened on some other branch is pretty meaningless, because branches are nothing but pointers to a particular commit, that can change what they point to over time.
If branches are used solely as you describe, then you are correct that it is not really a problem. Alas, nearly every client I have dealt with [that uses Git] has treated branches in the "classic" sense at least once.
-
I'd rather know who are working on what around the same codebase than ignore everyone else because their work might be relevant to mine.
Which is basically impossible with Git since you (typically) do not see what they are doing on their local repro.
-
@hifi said:
I'd rather know who are working on what around the same codebase than ignore everyone else because their work might be relevant to mine.
Which is basically impossible with Git since you (typically) do not see what they are doing on their local repro.
Regardless of the VCS you can like, talk with them? With DVCS feature branches can be pushed for everyone else to follow, review or contribute unlike the uncommitted mess you have with Subversion for example.
-
My own, personal, way of doing things is "git fetch" followed by "gitk --all". If git is a car, gitk is a GPS navigator. It shows me where I am and what is around, so that I can get where I want to go.
-
I had to look up what a .mdf file was. Holy crap, why would you want to have something like that?
Because you need reference data for the unit tests to operate on.
Is there a reason not to store stuff like that in text format as SQL and make it part of your build process to build something like that?
That sounds a trillion times more annoying than just having VS attach the DB file to the local DB before running the tests.
-
Regardless of the VCS you can like, talk with them?
Have you ever worked with large teams? There is definitely a time for talk (and in many case, ideally face to face), but there can also be so many details that getting the information efficiently can be "challenging" to use talk...
Consider: I a considering refactoring a class with heavy rename, reorders, and other things that will not merge. If I know what files people are "working on" right now [perhaps 100 developers in a half dozen time zones] I can pick and choose the ordering to not cause any conflicts (or at least those that would be hell to merge, using ANY system).
Remember I am not really talking about Git specifically, but the whole premise that "distributed" information is actually better when the environment is really centralized. If making it more difficult to have detailed coordination at many levels is a problem [and I believe that it is] then using a tool that limits the centralized knowledge can easily make things worse overall - regardless of the specific tool.
-
Several years ago.
Liar.
Git sucks with binary files. Everyone knows it, though some die-hard fans might not admit it. Git is terrible tool for versioning binary files.
Great, but, uh, that is a thing we need to do. So. We're just fucked. Whee. Thanks, Git.
I have no idea what ducking means in this context (Google only knows of this term referring to audio),
Right; video files never have audio tracks, so I must just be crazy.
This is the level of brainpower I'm debating with here, folks.
but I'm pretty sure you could somehow make this through use of ffmpeg (a command-line-based video editor).
"pretty sure"?
What could you do with AppleScript on MacOS Classic that you couldn't possibly on Lunix?
Script Microsoft Excel.
Just to save me from having to read the first thing in mind, let's say I have a program that can replay recorded input (mouse movements and clicks, keyboard strokes) installed on my Linux hardware.
Replaying recorded input is shit compared to what a real macro recorder does.
And you won't learn the concepts of actually flying a plane simply by pushing buttons and twiddling knobs on a control console -- you need to get hands on with the plane to do that, to understand how pitch and power come together to get you an airspeed + climb/sink rate, and how bank and yaw interact with that as well.
Ok but so what? I don't want to learn the concepts of actually flying the plane. I just want to get to Tulsa in a short amount of time. Millions of people every day fly in planes without learning the concepts of actually flying them.
I've never had, or expressed, any desire to learn the internals of Git.
Watkins Glen,
I don't know what that is.
in a badly mistuned car...
This is a new record in time-podding. He's writing from an era without commercial airflight and without electonics in cars.
-
Because you need reference data for the unit tests to operate on.
No, I understand why you'd want to have data. I just don't understand why you'd think a BLOB was a good way to do it.
That sounds a trillion times more annoying than just having VS attach the DB file to the local DB before running the tests.
In bizarro world. Is it a trillion times more annoying to have VS compile the code you get from your SCM before it runs those tests? No, no, you're right, it's much better to hammer those screws into the wood.
-
Ok but so what? I don't want to learn the concepts of actually flying the plane. I just want to get to Tulsa in a short amount of time. Millions of people every day fly in planes without learning the concepts of actually flying them.
I've never had, or expressed, any desire to learn the internals of Git.
And then you get on the plane and get arrested after ranting about how confusing the seat belt buckle is.
-
BTW. Why don't you want to use git pull --rebase? There's nothing scary in it. Actually, the default behavior is much, much more scary.
Then why the fuck is it the default?
Are you still trying to defend this piece of shit?
Locking is not needed when people actually collaborate.
Right; but they're working on different continents. And person B didn't know he'd have to touch the DB file until he was halfway through building his feature. And person D doesn't even know person B exists, because the company's growing pretty fast now-a-days.
Look, collaboration is fine. But it's not a solution to the problem. The solution is ancient and well-worn: have a way for the source control system to lock the damned file.
No, I understand why you'd want to have data. I just don't understand why you'd think a BLOB was a good way to do it.
How else do you do it?
In bizarro world. Is it a trillion times more annoying to have VS compile the code you get from your SCM before it runs those tests? No, no, you're right, it's much better to hammer those screws into the wood.
What are you talking about? Of course the code is built before the tests are run. What does that have to do with keeping the reference data in a DB?
And then you get on the plane and get arrested after ranting about how confusing the seat belt buckle is.
They actually explain in great detail how the seatbelt works.
-
Ok but so what? I don't want to learn the concepts of actually flying the plane. I just want to get to Tulsa in a short amount of time. Millions of people every day fly in planes without learning the concepts of actually flying them.
I've never had, or expressed, any desire to learn the internals of Git.
And you don't have to. In order to fly on a commercial plane to Tulsa, it is important to:
- Know what time you need to be there
- Know what/where the "gate" is
- Know you need your ticket and ID and how to check in
- Know what's OK and not OK to bring on a plane
- Know about baggage check and baggage claim and how to use it
- Actually want to go to Tulsa at this time
- And so much more!
None of these things are internal to how planes fly, but you're going to have a hard time and be all upset if you are missing any of them. And yet there are people who screw it up and get very angry. And it's [mostly] not because there's something wrong with air travel, it's just that these people are stupid or ignorant.
Being ignorant on purpose is even worse.
-
Git actually handles merges with heavy renames and reorders really well. If you want to attempt to wrap your head around how, look up gitdiffcore. It's an amazingly simple, yet powerful, sequence of events.
-
Look. I have a job. My job is to write back-end healthcare software.
Anything that has to be IN MY BRAIN that isn't related to the problem of writing back-end healthcare software makes me less productive as a programmer.
-
Well I hope you never have to fly anywhere for your job then.
-
This is a new record in time-podding. He's writing from an era without commercial airflight and without electonics in cars.
I was referring to suspension tuning -- and when I said fly a plane -- I was talking about doing it yourself, not paying for the two (much more experienced) folks at the pointy end of the plane to do it for you.
I don't know what that is.
-
If branches are used solely as you describe, then you are correct that it is not really a problem. Alas, nearly every client I have dealt with [that uses Git] has treated branches in the "classic" sense at least once.
What do you mean? What are the practical consequences of these tool working "differently" than official Git?Consider: I a considering refactoring a class with heavy rename, reorders, and other things that will not merge. If I know what files people are "working on" right now [perhaps 100 developers in a half dozen time zones] I can pick and choose the ordering to not cause any conflicts (or at least those that would be hell to merge, using ANY system).
Yeah, totally.
-
Anything that has to be IN MY BRAIN that isn't related to the problem of writing back-end healthcare software makes me less productive as a programmer.
But the issue is that you think the generic tools and concepts for developing software aren't related to that problem.
-
How else do you do it?
The way I already mentioned.
What are you talking about? Of course the code is built before the tests are run. What does that have to do with keeping the reference data in a DB?
It has to do with you not reading the stuff you reply to.
They actually explain in great detail how the seatbelt works.
I assumed that your listening skills were on par with your other communication skills.
-
Git actually handles merges with heavy renames and reorders really well.
It works a bit better than most....but not at all for the type of changes I am talking about. The "Test Case" that I use [in real life I sell a semantic merge tool that is really different then the lexical tools]
-
Create a C# class with about 50 members [methods, events, properties, fields]. User ProperCase for all identifier, and make sure that the members are in reverse-alphabetical order (regardless of type or visibility). Make sure there are plenty of intra and inter references of these members across the project.
-
Commit the above file.
-
Change all fields to use "m_" as a prefix [we are not debating if this is a good or bad convention!)
-
Rename all public members in some fashion.
-
Use something like ReSharper. to reorder the members by visibility and then type and then alpha order.
-
Commit this change...
Now "somewhere else" make a number of changes to the original file, and attempt to get a tool to do the merge.
That is just for starters....imagine this being done on a few dozen classes in a 500K++ LOC program, with a half dozen developers each doing the above sequence...
If everyone knows exactly what files are being worked on at each instant in time, it actually can be fairly painless.
-
-
What do you mean? What are the practical consequences of these tool working "differently" than official Git?
I mean people who also use branches to indicate what was v1.0, v1.1, v1.1a, v1.2, v2.0, v2.1...etc...
For these having a solid and atomic view of the history of each branch is critical without there ever being the appearance of an intermediate state which did not really exist.
-
I mean people who also use branches to indicate what was v1.0, v1.1, v1.1a, v1.2, v2.0, v2.1...etc...
Everyone who tags in svn?
-
Everyone who tags in svn?
Have you read all of the posts relevant to this sub-topic????
-
Great, but, uh, that is a thing we need to do. So. We're just fucked. Whee. Thanks, Git.
I feel you, bro.Right; video files never have audio tracks, so I must just be crazy.
I didn't say you're crazy. I said I don't know what you're talking about, which is caused by me never doing any video editing. FWIW, the ducking you were referring to could be screen fade-in/fade-out and make just as much sense to someone who doesn't know actual meaning of your post."pretty sure"?
Yes, pretty sure, because I didn't know what you were talking about at that point, and also I never edited any videos, via ffmpeg or otherwise.Script Microsoft Excel.
Yes, I can. That's because I can run Excel on Linux (via Wine) and all the scripting facilities of Excel work just fine, and BTW this has nothing to do with the operating system at all and you know it.Replaying recorded input is shit compared to what a real macro recorder does.
What does real macro recorder does, then? Would it be that it uses the proper interface of a program in a way a user would do it (click buttons instead of making mouseclicks in case of GUI, and entering commands instead of making keystrokes in case of CLI which Lunix mostly consists of)?Ok but so what? I don't want to learn the concepts of actually flying the plane. I just want to get to Tulsa in a short amount of time.
You're the developer. Your users want to get to Tulsa. You want to fly them there.Millions of people every day fly in planes without learning the concepts of actually flying them.
Millions of people every day stalk their friends on Facebook without learning a shit about webdev.Then why the fuck is it the default?
Because reasons. Why are you asking me? Ask Linus Torvalds, he made it so! I don't like this default either.Are you still trying to defend this piece of shit?
Only where it's actually good.Look. I have a job. My job is to write back-end healthcare software.
Anything that has to be IN MY BRAIN that isn't related to the problem of writing back-end healthcare software makes me less productive as a programmer.
How to use your tools is rather related.
-
@boomzilla said:
Everyone who tags in svn?
Have you read all of the posts relevant to this sub-topic????
Yes.
-
I mean people who also use branches to indicate what was v1.0, v1.1, v1.1a, v1.2, v2.0, v2.1...etc...
If you really need those particular branches to not have junk commits in them, then use --no-ff when merging. I do just that when merging my branches into trunk (though mostly because of commit hook that checks commit messages start with either IN, PR or US) and it works great.
-
I mean people who also use branches to indicate what was v1.0, v1.1, v1.1a, v1.2, v2.0, v2.1...etc...
For these having a solid and atomic view of the history of each branch is critical without there ever being the appearance of an intermediate state which did not really exist.
I'm honestly having a hard time understanding what the problem is here. I wouldn't personally use branches as tags. But assuming I did, I guess I would create a v2.0 branch at some point that points to the commit representing version 2. And then I'd just leave it alone. And it would always point to version 2.
Where's the intermediate state which did not really exist?
-
This post is deleted!
-
Boomzilla -
Then you should see how tags in SVN have no relevance to the ability to create a reliable branching mechanism in Git where each branch contains a pure point in time view of multiple concurrent development efforts with no information loss [such as caused by a rebase] or fraud [history points that did not really exist]
-
I can't wrap my brain around a branch being a pure point in time to begin with. And any time svn and reliable branching are in the same sentence there had better be a negation in there.
But I wouldn't let any of that get in the way of a cheap svn troll.
-
Where's the intermediate state which did not really exist?
We start at time 1 with a single "branch" (everything linear up to this point)....[call this A]
Then a branch is made for some purpose [call this B]. On B, changes 2 and 3 are made as distinct commits.
Some time later the latest version of B is brought over to A....
If a "FF" is done then it will appear that A has an intermediate state where 2 existed, but 3 did not.
-
Watkins Glen International - Wikipedia
