I've yet to work with a person who is confident with using git, most know the very basics and never move beyond that, I see it being used mostly through vs code, the command line is considered scary, only for advanced use, and even if I see someone use it like that it's again the very basics

I was explaining bisect to a colleague, showing how he can use a script to automate the process of finding which commit introduced the bug by running a simple test, his brain basically exploded when he realized that he can literally save hours of work by utilizing this very basic and introductory feature that git provides, I kinda thought that this would encourage him to dig deeper and learn the tool more, this was months ago and he hasn't advanced an inch, not even reading a single man page (does he know they exist?)

Anyways thanks for reading my blog faggot and please share any similar stories if you have them

I'm pretty sure git bisect is one of the better understood tools and your coworker is just retarded. But git is kind of like sudo, Photoshop, vim, in that 99% of its users only use 1% of its power sometimes out of ignorance but usually because they just don't need it. Behoov you to remember git was created for the linux kernel, you're not working on the linux kernel. If you've got checkout, stash, pop, merge, bisect, adog, diff, patch, squash, and rebase, you're more than good for 99% of codebases that have authoritative upstream repos.

>>105842185 (OP)
find something more meaningful to derive your ego from

it doesn't confuse me, it's just annoying and it shits itself in any nontrivial scenario. Have you ever tried rebasing on a branch with a conflict in a binary file?

>>105842185 (OP)
what's there to confuse except like rebasing?

>>105842185 (OP)
I just make a copy of my source files before I make sweeping changes. It just works and I don't sneed 3rd party tools. Idiots love complexity and piling more and more shit onto something that is already hard (writing code) under the guize of muh productivity, muh best practices <insert niggerlicous reason here why you need some dogshit tool/pattern/concept>. All you need is a text editor and a compiler/interpreter. Everything else is bloat.

>>105842230
>puting binary files in version control
are you one of those retards that doesn't use gitignore?

>>105842221
you may be right from a practical sense, but consider that git is one of the most used and dependent on tools in pretty much any setting, regardless of what kind of job you have or whateve, if git broke tomorrow the world go crazy, it will be such a problem that boomers and normalfags will hear about some random obscure program breaking on the news

if you think about it it's crazy that millions of people use this program and most of them have no clue how to use it or how it works, it's like knowing how to drive a car but can't parallel park

>>105842230
again, skill issue
what does rebasing have to the with the file being a binary file? choose choose the correct version of the file from on of the branches and use that, you can even configure git to diff the binary files with your script or something that knows what it means to diff the specific binary file you have

literally proving the point of op's post ...

>>105842221
>sudo
These should be USEFUL features.

>>105842226
you sound triggered, I'm literally trying to help brainlets by teaching them how to be good at using the thing they suck at so it's not ego

>>105842284
My job requires me to commit some binary files, and there's no reason why git couldn't just ask me to pick between two whole files instead of shitting itself and crying.

>>105842248
that may be true when you're writing your shell oneliners or python scripts that backup your hentai collection but that just doesn't cut it when you're doing something not trivial, having history with comments and being able to diff stuff and what not it's just better, simple as

>>105842392
here you go buddy https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes

>>105842326
>choose choose the correct version of the file from on of the branches and use that
But that's not what git presents me, it tries to make me resolve a merge conflict in the file as if it was ascii because it's a retard. To do what you're suggesting, I have to check out the branch I want and copy the relevant files out of the work tree manually and copy them back in during the rebase to commit. Which requires me to know in advance which files will have the conflict, something you don't always know or keep track of.
Once again, what would it cost git to have a simple CLI prompt to choose between the two versions while doing an --interactive rebase? Why must git shit itself and require manual intervention with commands you have to know in advance instead of showing a simple Y/n prompt like any sane CLI program whenever it needs the user to decide?
My pitiful lifespan is too short to "study" some unix weenie's magical realm in order to know every invocation and edge case. Unix brain damage is real.

>>105842392
>My job requires me to commit some binary files
Your job is managed by idiots and you are an idiot

>and there's no reason why git couldn't just ask me to pick between two whole files
It can do that, but it's meaningless to use it for binary files which you probably use for testing
If you build it then there is no need to commit it

>>105842392
I'm just curious, why does your job do that?
...and git definitely can do that, but if you're using a GUI or other interface it may make it more difficult.

There was a time at work where se used SourceTree and then Git Kraken, as if it was somehow necessary.
I just used the command line instead, it's much better for everything except browsing the commit history.

>>105842411
See this is the shit I'm talking about. Should I be required to study astronomy and make my prayers to the earth's great spider king before I begin work? Well fuck that. And for the record I tried different combinations of "theirs" and "ours" and it resulted in git shitting itself and crying once again because merge and rebase for some reason do not support the same strategy set, and nothing I punched in worked.

>>105842478
>my prayers to the earth's great spider king before I begin work?

lol

someone's getting devoured by the million young by EOY....

>>105842452
>Your job is managed by idiots
Every job is and I am not giving them the source file that generated this binary because it's the only thing that guarantees I even continue getting paid. Said source file is itself binary anyway.

>>105842474
>I'm just curious, why does your job do that?
It's just easier. Are we about to have a stack exchange moment with everyone pointing fingers at me and screaming over there being binary files in the work tree in the first place? Shit happens, real work environments are filthy, and I'm not paid to solve this for them.

git is a very technical solution to a mostly people/communication problem

>>105842230
SVN doesn't have this problem, btw

>>105842377
have sex

>>105842478
are you mad that git is configurable? should it handle all possible scenarios for you? and even then if it did that you would complain that it didn't handle it how you expected it to

it takes less than 30 seconds to configure it to handle your exact scenario ...

>>105842502
His jaws can dissolve ANYTHING

>>105842503
Like I said, I'm curious.

I had a git repo with binaries once too. These were simple exe files (third party) that were shipped to the customer, and as such never change.
It was a bad idea then, I shouldn't have done it, but I did because it was easy. The file is still there and serving in production.
I made a new solution but it's not in place everywhere yet.

As for what you're paid for, who cares?

>>105842558
It's literally not worth the time out of my lifespan "learning" trivia like this, and it's only 30 seconds if you know it in advance. See, this is what I'm talking about, unix weenies have autism and lack theory of mind, they cannot conceptualize someone not knowing the things they do, so they will start rambling what sounds like nonsense to others expecting everyone else to know what they mean by fucking telepathy.
Give me a Y/N choice in the same terminal I invoked the rebase in or fuck off. I am not learning your weenie rituals.

>>105842588
>As for what you're paid for, who cares?
Do you volunteer to do shit you weren't asked to do at your job? Do you clean up after others expecting a raise or something from your alcoholic psychopath boss? What a good little drone you are, one day your efforts will surely be rewarded.

>>105842185 (OP)

>tfw I tell people "just pull the patch and compile it yourself, retard" all the time
>tfw I have no idea how to do that and I just wait for it to get merged along with the other retards

>>105842614
so you're willing to spend time "fixing" this thing that annoys you every time you try to rebase or merge but you're not willing to spent of bit of time to learn something that can effectively make your problem go away and save you way more time in the long run from your precious lifespan than literally doing nothing and just re-fixing the problem every time

npc level logic, truly

>>105842630
>Do you clean up after others expecting a raise or something from your alcoholic psychopath boss?
why do you work for alcoholic psychopaths?

>What a good little drone you are, one day your efforts will surely be rewarded.
Excellence is reward in of itself, you obviously are too much focused on this world

>>105842185 (OP)
tools should be simple to use, like TV, so people in the community can have good jobs

>>105842630
>Do you volunteer to do shit you weren't asked to do at your job?

Yes, not only do I do that, I straight up do stuff I want to do myself.

wasnt the hilary email leak in an empty/deleted git repo and all you had to do was revert the last commit that deleted everything?

>>105842840
that's hilarious but sounds fake and gay

>>105842885
it wasnt a git repo like on github it was what i believed her tech used to smuggle them out

im sure you heard of seth rich and his random murder

>>105842185 (OP)
Okay I'll admit that I've never heard of git bisect, but how much more time are you saving using git bisect and how much signal there is to a simple binary search algorithm for finding bugs

>>105843066
git bisect is a binary search, you could save a ton simply because you can automate it by scripting it

>>105842185 (OP)
it gets confusing when people start using it for shit it was not designed for

nobody's "scared" of command line, people avoid it because it's obnoxious and inconvenient compared to user interfaces from this century

>>105842185 (OP)
as a brainlet.
1. Using a visual looking git is nice. Why would I not use it for checking changes, adding changes and merging which cover 99% of uses?
2. I didn't know about bisect, but that seems to be useful if the project is a black box to you.
3. Why should I learn more about git? Most uses are covered by GUI buttons. Also git isn't what I want to think about. I want to think about the code.

>>105842185 (OP)
Learning a tool, specially a command line tool, is sizeable effort and even if that saves time down the road, but many people just care about what they can do right now. Same reason most devs don't bother learning Vim or Emacs even though those editors are far supperior than any GUI editor out there. Now Git can be a massive rabbit hole and I don't recommend spending twenty hours learning it, but I agree more people should at least watch a few tutorials on youtube.
That said, the hardest part of git is not even the tool itself, but team management.

>>105842221
> git bisect, find the checkin

Git is for applying patches from internet randos.

I work in an office, i just stand up and say “whoever was messing with io_defs.h yesterday had better fix it before I get back”

If nobody says anything, rather than spending a day dicking around with graphs and bisect, I just go in there and fucking fix it myself, and check in with -f, and let darwinism work.

>>105842284
I put binaries in git
Why not
Have to store binary somewhere. Only alternative in company is sharepoint and fuck that for a laugh.

>>105842185 (OP)
>be single dev on project
>never make any mistakes code always works
>only get to use most basic git functions
Life just isn't fair sometimes.

Here are all the git commands I use
>git status
>git add
>git commit -m "comment about commit"
>git restore .
>git switch
>git fetch
>git checkout
You should be doing git status and git add and git commit the most often.

but anything more than that is genuinely homosexual level behavior with branch management.

You are a software engineer, you are supposed to design and write software. You are not supposed to be the faggot who spends time choosing the prettiest manila folders to put files in.

So using git bisect is homosexual behavior. YOU CAN FIND THE BUG IF YOU HAVE GRANULAR AND CLEARLY LABELED COMMITS ANYWAYS

Imagine having a fucked shitty enteprise codebase with 5 gorillion contributors and you need to use git bisect to find the root cause of a bug

just fucking lmfao

>>105843177
>1. Using a visual looking git is nice. Why would I not use it for checking changes, adding changes and merging which cover 99% of uses?
Usually the command line is easier and faster. No need for clicking. Especially if you add aliases.
But sure, nothing beats a graphical overview for searching and querying.

>3. Why should I learn more about git? Most uses are covered by GUI buttons. Also git isn't what I want to think about. I want to think about the code.
Like in point 1, it may be easier and faster once you get the hang of it.
There's also the functions that GUI doesn't cover.

To be honest? I don't use all too much except

checkout (with -b to create a new branch as well)
commit
tag
status
rebase
cherry-pick
reflog (for when I fuck up)
describe (useful for scripting)

I leave merging and whatnot to the gitlab repository software, gitlab, github etc..

>Also git isn't what I want to think about. I want to think about the code.

Expand your mind a bit, is my advice. Git is also code, software, well designed too. Learning how it works or how it's used can really help you design your own.

>>105843262
> binaries
Never let people start doing that.
Our repo was getting ridiculously large, looked through it and found:
- movies
- vm disks and snapshots
- zipped backups of git’s own source tree
- .iso s of various versions of windows
- entire customer directories zipped up
- internet explorer. That one was shipping in our product.

Dozens of people were doing this over a decade.
Getting it out is very fucking difficult. Only thing we managed to get out was the movies, the rebuild took days.

My vote was to just get the cleaned files from a checked out head and check them into a freshly inited repo and make a clean break.
The thing is such a mess you can’t do anything in the history anyway, and nobody really uses it.

>>105843333
Just start over at that point.

>>105843333
>Our repo was getting ridiculously large, looked through it and found:
>- movies
>- vm disks and snapshots
>- zipped backups of git’s own source tree
>- .iso s of various versions of windows
>- entire customer directories zipped up
>- internet explorer. That one was shipping in our product.
cant make this shit up
lmaaooooo

is the company jeet managed?

git really is terrible if you are working with people that don't know how to use it. It was a lot easier when we could just push everything to master, but because of a change in processes, we need to make branches and merge them with develop and then merge it in master and then sometimes merge master back in develop?
I'm not even sure why we do that song and dance like that, and then you have guys making branches for every tiny story even when that story links to other similar stories for the same feature, and then you have separate guys working on that and then we spend a day resolving merge conflicts everywhere and repeated code in different areas.

It's just a mess.

>>105842526
> SVN doesn't have this problem
Svn is all most people need.
Git is a meme, I don’t know how it became popular
We had the guys that suggested git spend weeks of company time every month fixing git shit that constantly broke.
As someone else here said, focus on the code or the product. Git is supposed to be a tool to help.
When it is no longer useful, ditch it.
Emacs lock files in a shared directory is better.
Git is not a “thing unto itself” as many hyper-religious git zealots think it is.
But, to be honest, those people are better in their self-determined “git flow procedure nazis” roles rather than checking in source code.

>>105843349
> Indian managed?
No. Mostly regular white people. Maybe only 1 or 2 Indians.
We’d go onsite to help other companies, and even to actual india, and come back with such horror stories it makes what we were doing look like the original bell labs team that invented unix.

We were working with an Oracle product, and the fucking setup program installed the two guy’s home directories (that presumably wrote the the thing).

I’m surprised the complexity of git hasn’t wiped out the entire nation.

>>105842221
>authoritative upstream repos
What other kind is there? I can't really imagine non-authoritative repos. At the end someone's gotta decide what goes and what stays, right?
t. noob

>>105842226
kek this

>>105842639
I fucking knew it.

>>105842185 (OP)
>checkout
>commit
>push
>reset
>rebase
only things I need. simple as. using the GUI, too, cause why not.

>>105843580
It's more about technology selection. Let's say you, as VP Engineering, are happy with libfoo-2.1.3. It meets your use cases, it's internally used by your code, maybe you've done some tweaking here or there, etc. But now in libfoo-land Mr USE CASE? comes along and his band of retards start a CoC AIDS rewrite, v3.0.0, with half the performance and your USE CASE doesn't work well any more. Now your former upstream is only upstream for critical fixes, and whoever maintains this library internally is the company's upstream. Let's say he comes up with a 50% performance boost, but his changes still need to be rolled out and tested internally.

From the perspective of a random dev, that would still be an upstream change, something you didn't do yourself that doesn't pertain to your immediate concerns, but still needs to be absorbed nonetheless.

>>105843734
I see, that makes sense thank you

>>105843333
>Look inside repo
>The entire Lord of the Rings Extended Trilogy is there in 4K

>>105842185 (OP)
i'm not a brainlet, it confuses me

>>105843734
> CoC rewrite.
VP Eng. here.
Never knew there was a rewrite.
We never upgraded since libfoo-1.10 17 years ago since the new version broke bio and ssleay.

>>105842185 (OP)
it's simple.
nobody WANTS to learn to use git.
it's an inconvenience by its very existence.
i don't care if you think git is cool; people want to close their editor and the code is saved and backed up.

>>105842221
what the fuck is adog

>>105843409
git was designed for completely decentralized development.
but MOST PEOPLE don't use git like that. Most people use it as if it were centralized. Most people are on Github or a company Gitlab.
Git SUCKS at being centralized.

git wastes more time and effort than it saves.

Anyone work in a large org that gives all devs the ability to merge to the main branch? I do and many of my colleagues say it's crazy and not normally done like this (we get merge races that break builds fairly often). Do some places only merge compartmentalized feature branches full of commits validated to work together to the main branch, or have some useless program manager type guy merge a bunch different devs commits at the same time?

>>105845304
ever heard of a pull request?

>>105845319
What exactly do you think happens after a pull request? Do you think hundreds of people all contributing their own code review every PR at the company and quickly recognize things like merge races won't happen when the commit is merged?

>>105845328
ok good, now have you heard of ci?

>>105845342
You don't seem to understand how a large project works, or have never worked at a large org that outputs a lot of code. Sure, if you are on a team of 30 slow people on a web app that rebase every day and merge a few commits a week passing builds and tests is enough before merging to not run into problems. I'm sure it's working fine for your Rust shopping list, but I was specifically asking people that work at large orgs.

>>105845359
interesting, very good. now have you heard of submodules?

>>105842185 (OP)
Many people - and I include myself here - basically require a graphical interface. There's no point storing in my own memory something that the computer can store on screen. I'm not going to read a man page, remember what a command does, and then implement it if I can have the command and its obvious consequences laid out as a "physical" interaction - click this button and the thing happens.

It's also known that people don't care for reading manuals - which is fine with a graphical tool that has an undo feature because you can just experiment, but when it comes to a command line without an undo feature, you're fucked. You have a zero percent chance of stumbling upon a useful feature when your search-space is "any possible combination of any possible number of characters"

>>105845359
I work at a large org.
>>105845304
>that gives all devs the ability to merge to the main branch?
Not even a remote chance.
>my colleagues say it's crazy and not normally done like this
It is crazy, and it's not usually done like that.
>we get merge races that break builds fairly often
Of course you do Parallel development can produce changes A that work, and changes B that work, but changes A + B don't work, and unless you strategically combine A and B before they hit main, you won't ever know about it until everything turns red and it's "nobody's" fault.
>have some useless program manager type guy merge
You want skilled, careful types merging, and they need to be able to force two groups of potentially mutually antagonistic people to cooperate.

>>105842688
if it takes 20 minutes to learn and half a second to hit y/n from muscle memory, you'd have to hit y/n 2400 times before it's more efficient to learn than to just eat the loss.

>>105845370
I've only ever used the CLI, but my colleague uses Jetbrains and was showing me grabbing a bunch of different commits and putting them into his own local branch in seconds, definitely a lot nicer than cherrypicking them in the CLI and then later looking which you have and stripping them back out, I'm tempted to try to switch for a while. It's annoying to deal with the GUIs though if you need to troubleshoot someone elses git problem and they are in the midst of doing who knows what with some GUI you aren't familiar with.

>>105845411
version control software packages used to be all GUI based.
linux kernelites who worship the unix shell and shitty email chains forced their lobotomy on everyone else.

>>105845411
you can use git rebase -i OR cherry pick with A..B to do this.

>>105845402
Yeah that all makes sense, and many of my colleagues agree, but we've always done it this way. I also didn't mention, it's not just your own PR that you can merge if it passes builds/reviews, it's anyones. You can also set a PR to automerge the second all conditions pass.
>Of course you do Parallel development can produce changes A that work, and changes B that work, but changes A + B don't work, and unless you strategically combine A and B before they hit main, you won't ever know about it until everything turns red and it's "nobody's" fault.
If you think that's bad, these merge races can also break other upstream branches that enforce automerge rules in a different way than they broke main, so sometimes when these things break different fixes have to target different branches and then merge in quick succession to unfuck everything. And before I'm accused at working at some Accenture type chop shop, this is at a $500b+ mcap company renowned for software engineering.

>>105845493
>this is at a $500b+ mcap company renowned for software engineering.
so you have tons of indian coworkers that microwave their smelly lunch in front of you while talking loudly on their cell phone to their smelly wife

>>105845509
I work at home so that would be quite strange if that happened, maybe that's where we are going with this new America Party though

>>105845493
Typically this kind of thing is caused by a widespread misunderstanding of git that is a carryover from the previous system and where many of the key stakeholders don't know any better, and perhaps the ones that do tolerate it because they benefit from it. Think about it. What is main? It's just a hash of a commit that has a "pointer" to a tree, or the entire state of a filesystem subdirectory tree. Any other string besides "main" can point to the exact same commit, exactly identical.

So what is the point of main? You really want it to be a tracker of "yep, works great", every single commit. You want it to be "stuff that is known to be solid". Because any string can be exactly the same as main, you just use another string, or any number of these strings to keep track of shit until you have established its fundamental goodness, at which point, because the entire purpose of main is to track goodness, you point main at the new good thing (the filesystem state, the tree) and there you go, just leave the temporary strings by the side of the road if you ever need to do archaeological work.

A lot of pain results from misunderstanding the actual game.

I'm afraid to go anything besides commit because I think I might lose work.

>>105842314
Last time I parallel parked was during my driving test, 10 years ago.

>>105845576
For us though it isn't main breaking that is the specific issue, hundreds of people are merging into the same development branch which effectively is just "main" with a time window, and most feature branches that aren't being used for pure R&D are set up to auto merge content from that branch as well otherwise they will be falling out of date by thousands of commits and face heinous merge conflicts if they try to cherrypick/rebase over those thousands of commits later with their own hundreds to thousands of commits. Main already is just kind of a voodoo doll thing, sure it could be set up to be stable via careful merging but why, it's not really used for anything like you said other than a health indicator.

>>105845276
Not much. What's up with you?

>>105842709
lol

>>105842709
I know what you're doing, but she was right. In 99% of cases a tool is difficult to use not because it has to be, but because making it easy to use is too much work for the developer.

>>105845642
You said previously main, not a development branch which effectively is just main with a time window. While your setup is stupid, imo, it's relatively simple, because if shit's going to hit the fan have it hit quick and in a designated street shitting dev branch with some "through the tree branches" ad hoc wiring thrown in. Whatever.

The reason this is not ideal is because you get faster feature development with less churn. In other words, known working, extremely solid branch X gets feature Y, and it can be proven that Y is exactly equivalent to X in everything, performance, stability, latency, memory use, CPU use, whatever, except it now has feature Y. This helps quantify integration risk. If there are dozens of these where everything is proven to the best of the organization's ability, then these combined should still have the same property. If not, then why?

Your system will work better if it's all just random brownian motion, and the street where everyone shits is either green or red. But it won't lead to high quality outcomes, which may not even be important anyways. Which is ironic, because it's not recursive; if the networking gear powering your street shitting sessions broke all the time it would be a fucking intolerable outrage.

>>105845411
You can use VSC for GUI + terminal for handling git. Shit was like the first gitgui that could even display submodules successfully its not bad.
I need a GUI to handle checking a metric shitload of changes anyways/being lazy sometimes, and I need CLI when I need to do git shit that has no graphical representation or is odd.
So there you go bro

>>105842185 (OP)
The command names are unintuitive. Some of the most common actions require multiple commands to perform. A few commands are most of what people need in 99% of the cases, and most people are too busy doing actual work to spend time learning esoteric options that they only use once in their career.

>Want to delete a branch
git branch -d
>Want to create a branch
git checkout -b

Different commands for no discernable reason. Everything is like that in git.

>>105842185 (OP)
git pull
git commit
git push
if anything hoes wrong ask that one coworker who is a nerd.

>>105842185 (OP)
Anon, nobody gives a fuck about masturbating over whatever command line options some source control tool has.

>>105845893
It's this way because checkout was used to literally "check out" aka examine the filesystem state of something. And you might want to go a different direction because the original author was a faggot, just add -b newbranch and off you go on newbranch. It's like seeing where things go with a chick instead of
>I DECLARE I WILL ENDEAVOR TO PUT MY PENIS IN YOU M'LADY
whereas git branch -d is
>I know you already consider yourself my girlfriend
>bbbbut this just isn't working out for me
>sad face

git is easy. just make evetyone an admin.

>>105846126
Everyone is an admin

>>105846123
Creating a new branch should probably be something like git branch --new <branch_name> instead. The problem is that git is full of stupid design decisions where two related actions have completely different syntaxes for no obvious reason when it should just be the same command with a different argument. There are also plenty of actions where the reasonable thing to do in most situations should just be a one-liner but turns out to be several commands whereas you have some single commands for some super obscure use cases that 99% of developers will only encounter a handful of times in their careers.

Not to mention the fact that the command line is pretty bad at visualizing anything in your repository beyond the absolute basics, so you are pretty much forced to use a GUI if you want to be productive in a work environment.

Git sure is powerful but in terms of UX it is a total disaster.

>>105846443
>stupid design decisions
Decisions made by a decider of fate, not a follower of those men, like you. Your thoughts are inconsequential.

>>105846786
That was a bit over the top, but hey.

>>105846786
Being a leader doesn't make your decisions good. It just enforces your stupid decisions on others and results in bad output. I simply chose not to learn git and if I fuck up the repo I will make it everyone else's problem. I can't wait to get out of the hell that is modern software development. I unironically understand why every tech bro takes up woodworking and retires off-grid.

if you know more than clone, checkout, branch, commit and push then you need to touch sex immediately

>>105843333
>movies in the Git repo
How does this kind of thing make it past review?

>>105847242
I can describe a hypothetical process that leads to that.
>Code relies on a certain binary blob to work
>Binary blob needs to be shared with anyone who has access to the code
>Company has no convenient artifact repository for this purpose
>Dev doesn't anticipate to be sharing many binary blobs in the future
>Setting up an artifact repository for this one file seems like a waste of time and other resources
>Binary blob goes into the repo
Short answer: because the code needs the artifact to work and there was nowhere else to store it at the time.

As for why a movie though, my best bet is that there was no review and it got committed by accident.

>>105842185 (OP)
FossilGODS don't have this problem

Like most linusshit it hides its simplicity behind poor abstractions. It's just a graph of states, so why go to so much effort to let people play makebelieve with changing the history and rearranging the graph and adding\removing files (but NEVER folders)? It's a graph of states, let people treat it like that, make the commands acknowledge that and even dummies will find it easy to use.

>>105847514
> why a movie
I can answer that.
The frog was boiled slowly.

One of the products is web based. Company also has many web sites. Both use certain pantone colors but people sometimes didn’t know that and pick a random green colour. Web sites and corporate communication is run by marketing.
From C level: marketing and swdev shall stop duplicating work and use the same source code control system.
So now we have marketing staff and random contractors approving their own check-ins. Separate directory… I never even looked in there unless getting linking to official corporate bitmaps.
We start putting training videos and advertisements on the website. Social media posts, 30 second spots… etc. the ecosystem had started to collapse…
The testing and customer satisfaction depts got access and would drop customer videos (of bugs happening) in git directories with all the collected bug material and repro steps.

Do a du of everything one morning and it’s in the TB.

>>105846443
>Creating a new branch should probably be something like git branch --new <branch_name> instead
It is literally `git branch <branch>`

>>105848836
In light of my previous comment, let me inform you that you are an opinionated brainlet.

>>105849497
>Create a branch but don't switch to it.
>There are at least three ways of creating a new branch.
>All of them do slightly different things
This is why no one wants to learn git