Do you really understand git? I'm not talking about the usual operations like merge, branch, tag, reset hard and revert

> t. NEET
totally ignored

You start with
>the program is there to fulfill a certain purpose
as if there's one purpose and it should only be judged on that, not the plumbing and customization.
And then you go
>from my regular usage of it, i find git to be an excellently [...]

Seriously, make up your mind instead of talking without saying anythin.

i think it's normal not too use many of gits features much, at least as a private user. many seem more useful for advanced administering of collaborations. it's a pro tool.

git internals are surprisingly simple and straightforward. I understand them, and so I am not afraid of any of it's commands.
youtu.be/GYnOwPl8yCE

A lot of the plumbing is just simple scripts, you guys have only seen the porcelain and think it's magic or some shit.

I feel like I do. Once you understand that Git is all about pointers to nodes in a linked list, and you understand how the index works, it all becomes pretty easy.

Oh and as for the design, I like it primarily because of its decentralized nature and the amount of control it gives you over your workspace. It would be quite a pain to do all the branching, merging, etc. that Git can do very easily in something like TFS. And the fact that you can work entirely offline.

What?
If you're serious why not just make some 2line bullshit script and use that to "test" git

>“Good documentation is condescendingly terse, and Git’s documentation is like an art critic who giggles at you. (The description of git-rebase is “Forward-port local commits to the updated upstream head”. Oh, fuck off.)”
t. Ted Dziuba

>It stores diffs
Nice try gitlet, literally the first thing you said is wrong.

Git stores entire files with each revision. Go on, look it up

>Go on, look it up
I tried, but all I found was "git gc --aggressive"

Nope.

I don't know most of the details, but I think I get the big picture. It's the only VCS that seems sane to me. Mercurial is okay, but it's basically just a dummied-down verison of git.

>Git stores entire files with each revision
It only stores the most recent version of each file. Other than that, it is all diffs. Are you seriously this new? How do you think merging even works?

You must be one of the guys who "learn linux"

I never bothered to find out what rebase actually did, and this makes perfect sense honestly. It's documentation that describes what the software does, not a learning guide that hand-holds people who are using it for the first time.

literally every part of this comment is wrong, thereby proving right
What an absolute fucking farce of a board

That user is retarded. If you actually look at the documentation for rebase it even goes as far as to show you node trees to help you visualize it: git-scm.com/docs/git-rebase

I don't know why people have a hard time with understanding rebase. Let's say you clone from a repo, make some commits, and then want to have your code merged upstream. If your coworkers have made changes since then, your copy is out of date. Your changes are in terms of the diffs between what you started with and what you have now. That is incompatible with what is upstream. You use rebase to temporarily undo your changes, fast forward to what is available upstream, and then put your changes on top of that. This allows you to resolve any conflicts or other issues locally. Then, when you ensure everything is correct, you can push your changes upstream and it will be a simple fast-forward.

It's essentially just special object containing a pointer to the original data plus the diff and some header info. Now fuck off with your ignorance: git-scm.com/book/en/v2/Git-Internals-Git-Objects

>git-scm.com/book/en/v2/Git-Internals-Git-Objects
I forgot to mention you'll want to read that whole chapter from there on. At the very minimum, you have to read as far as the end of 10.4 "Packfiles"

Far easier to just maintain a local main branch that's always up-to-date, then merge my branch into it.

Only works on solo projects. As soon as you have a group project with a centralized repository (like at almost any job), you'll find that rebase is a necessity.

That's how it works at my company though. I don't understand the necessity to have only one branch at all times.

I think I misunderstood what you were saying. I think I understand now. The difference between what you described and a rebase is that it requires more commands and branches to accomplish the same thing. Just to make sure I understand, I think you are suggesting this:
git pull
git checkout new-branch
git commit -am "some change"
git checkout original-branch
git pull
git merge new-branch
git push origin original-branch

With rebase the same process looks like this
git pull
git commit -am "some change"
git rebase
git push origin original-branch

>git checkout -b new-branch
fixed

>It stores diffs representing the changes between each version of every file.
so your answer to OP's question is "no"

see and fuck off

>It only stores the most recent version of each file
each commit is an entire snapshot you fucking retard, that's why most operations are almost instant and don't take years to patch diffs on top of diffs like SVN did
read a fucking book nigger

Everyone works on the same branch at your company? What if one guy fucks up something and the mistake was discovered during testing? Do you have to roll it all the way back to the commit before the bad commit and undo every change that was made after the bad commit?

it literally says on that same link that snapshots are stored

>Everyone works on the same branch at your company?
No. I'm not sure what made you think that. I'm simply stating that it's stupid to make a new branch specifically for the purpose of merging changes together. You make a new branch for new features/fixes, then you rebase before pushing those fixes.

snapshots in this context consist of a pointer to original data plus diff and a header. Read about packfiles like I told you. Dumb fucking retards.

>that's why most operations are almost instant
The reason for that is you have the full copy of the most up-to-date version of each file and generally work with those.

I forgot to mention: it's not a entirely new branch, just a cloned branch from the repo. My company has multiple branches for the codebase, one for testing, one for release, etc. When we work on features, it's always a new branch from the testing branch, which then gets merged back to the testing branch after the pull request is reviewed. With your method, I don't see where the review process could occur.

jwiegley.github.io/git-from-the-bottom-up/

user, I learned evperything i needed to know about Git from this site

I see. I once worked in an environment which operated similarly. We had a production, staging, and multiple dev environments. At first, new changes would be developed in branches based on the dev environment assigned to the group. Then when the feature was complete, it would be merged into the dev branch, and eventually get promoted up through staging and then production. However, this eventually proved to be a pain in the ass since not all features were ready to move from dev to staging at the same time, or from staging to production. Eventually, what worked a lot better for us, was to base our new branches off of production. This makes it easier to separate your changes from other changes which were already added to the dev branch in the event that you need to promote your change up the chain independently. Unfortunately, doing it that way means you have to deal with merge conflicts up the ass, so having a GUI tool to manually select what to keep and what to toss is useful. However, even in that way of doing things, you rebase with production before putting your changes into dev.

Meant to reply to