6 ms·

> The .git store is incredibly small (because it only > stores changes) git stores a complete copy of each revision, not changesets. (Well, it is my unders

• stormbrew 12y ago
  When git repacks[1], which it does periodically (but not on every commit), it will store objects in as compact a form that it can, which basically means that it looks for root objects that it can delta a given object against so it stores each chunk of text as few times as possible. What it doesn't do is store files as deltas explicitly against the previous or next revision of that file. It attempts to find a best fit dynamically. It also does something like this packing procedure when responding to a fetch to avoid sending more data than it needs to, btw. [1] https://www.kernel.org/pub/software/scm/git/docs/git-repack.html https://www.kernel.org/pub/software/scm/git/docs/git-repack....
• Someone1234 12y ago
  It stores a complete copy of the file, not a complete copy of the entire repository. So it keeps your .git fairly light weight since only changed files have duplicate copies. Essentially it is not line level, but file level, rather than complete repository level (e.g. like Team Foundation is).
  • josteink 12y ago
    > So it keeps your .git fairly light weight (... compared to ...) Team Foundation And you can tell from how the product is being used. Where I work, we use TFS and you literally need to have committee meetings before a new branch is made. You need to agree on long term strategies, you need to agree on branch hierarchy (because TFS cannot merge without one), you need to replicate all-the-things(tm) for your new branch, you need to adjust your versioning-strategy for this branch, and possibly future branches which may come and may not ever collide with this one, because TFS branches are massive and carved in stone. They are forever. Etc etc. You never branch more than once a year. In the world of TFS, doing such would be madness, haphazard. Or at least you would need a full team doing nothing but branching and merging and integration. And good luck trying to find qualified people willing to have that as their day-job. With git you branch every single time it makes sense, usually several times a day. And your life is nicer because of it. It's funny how such technical decisions results in such huge and enormous visible changes to how a product is being used. Somewhere deep in Microsoft there are probably one or more engineers crying right now seeing the effects of their (back then) seemingly innocent decision, as they themselves are forced to deal with TFS in their daily work and they see how nice the gitters have it.
    • stormbrew 12y ago
      Internally Microsoft largely uses a fork of Perforce called SourceDepot. Branching in P4 is about as easy and lightweight as any centralized version control system has ever managed, though still quite a bit heavier than git obviously.
      • cben 12y ago
        When I worked in Google a couple years ago, they were using Perforce and branching was extremely hard (it was P4 with extensive internal tooling around/underneath it, no idea how representative it was of normal P4). It took me about a year to realize how bad it really is: eventually I found my way to a "how to create a dev branch" document starting with: "Last year Dev Wossname wrote a useful mail showing how to create a dev branch and got most of the details right :-) This howto explains it in more detail and fixes a few points." Then followed a quite few pages with a dozen manual actions doing somewhat intimate things to levels of P4 I had not previously heard of... Oh, and it created the branch at the *company-wide root level*, e.g. `gmail/` -> `gmail_dev_branch_2012/`. No pressure !-) It then took a few more days until the horror of that opening sentence sunk in. Native large-scale branching was so rare that it was almost a lost art! [There were also several "lightweight" branch-like techniques based on symlink magic, FUSE filesystems and more magic. Those were routinely used for freezing a release build, with option to hot-patch it — but IIRC it was impossible to merge back onto the main tree.] In practice things weren't that bad because (A) Google got really good flow (especially continuous testing) for everybody working close to HEAD, (B) personal branches were easy and common: - Fresh checkout directories were cheap [should have been frightfully expensive but clever scripts and a FUSE filesystem fixed that]. - Every CL (commit progressing through code review iterations) was effectively a feature branch. - People who wanted more used a somewhat crazy, but very workable, internal tool mirroring a growable {time,space} subset of P4 into local a git repo and back onto P4.
        • stormbrew 12y ago
          My P4 is very rusty, but back when I used a vanilla install a branch was basically just a copy operation from one part of the namespace to another, and then setting up your view to point to that new spot (or setting up a separate view for it if you wanted). This was before any integration with git (or, indeed, the existence of git at all), as well. Subversion mostly copied the way p4 did it, but without the view control stuff (where there's a server-registered and quasi-versioned description of what local file paths map to what server paths) that perforce has/had.