3 ms·

Well, this is Tower's blog, but stating that Git was "the first system that was deliberately built around" branching is too arrogant. Nevertheless, branches ar

Well, this is Tower's blog, but stating that Git was "the first system that was deliberately built around" branching is too arrogant. Nevertheless, branches are really just a (albeit nice) side-effect of the fact that Git (and Mercurial, for that matter) explicitly tracks _changesets_, not just _revisions_.

jlgreco 13y ago
How do you figure that git tracks changesets, not revisions?
- anton_gogolev 13y ago
  Let's define "revision" to be "what the entire codebase looked like at some particular point in time" and "changeset" to be "a list of changes between one specific revision and the next specific revision". Now, if we look at Subversion, we see that given a particular revision there's no way to reliably determine its' "parent", because the fact that r6 is followed by r7 doesn't mean that changes in r7 were based off of r6. If we look at any DVCS, each commit would have an explicit reference to its' parent(s), so there's always a non-ambiguous way to reconstruct the entire "chain" of relationships between commits.
  - jlgreco 13y ago
    > Let's define "revision" to be "what the entire codebase looked like at some particular point in time" and "changeset" to be "a list of changes between one specific revision and the next specific revision". Git tracks revisions then. Commits have a tree object that describes the codebase at the time of the creation of the commit. You don't need to transverse any previous commits to recreate that tree. Commits also have other commits objects listed as their parent commits, but they are not needed to examine the current state. Git doesn't use deltas in the way that Mercurial does.
    - tbrownaw 13y ago
      The only system I know of that truly tracks changesets rather than revisions is Darcs. But from a more practical standpoint, tracking changesets rather than just revisions means recording ancestry ("commits also have other commits objects listed as their parent commits") such that you can freely create merge revisions and the system will Do The Right Thing with minimal hand-holding. The internal repository format isn't really relevant here, it's about the way of thinking that the system is designed to support.
    - anton_gogolev 13y ago
      Mercurial storing deltas is just an optimization (sometimes it stores full snapshots): all manifests [1] refer to full file content, not deltas. Let's put it this way: the key feature of DVCSes is that they store explicit relationships between a particular commit and its parents. This makes it trivial to reconstruct actual changesets as per my definition, which in turn makes merge machinery much more reliable. [1]: http://mercurial.selenic.com/wiki/Manifest http://mercurial.selenic.com/wiki/Manifest
      - jlgreco 13y ago
        Okay, that I can agree with. I just think it is misleading to say they are based on change lists since changelists can be derived but are not actually stored. (And in the case of git at least, the changes you derive may not be changes that a human made, per se (in other words, those changes are the output of rebase.))
mhaymo 13y ago
> stating that Git was "the first system that was deliberately built around" branching is too arrogant. Do you have a counter-example?
- anton_gogolev 13y ago
  For one, Mercurial has branching as well. Although technically it was released 12 days later than Git, the motivation for both of them was that Linus Torvalds decided (for legal reasons) not to use BitKeeper for Linux kernel development and was in need for a replacement version control system. Besides Git, Mercurial and BitKeeper, there is also Monotone, which is also a DVCS.
  - stock_toaster 13y ago
    and Darcs. Which is more "patch based". Never used it much, but it has been around for quite a while (march 2003). arch/tla/ArX was also an early one (2001? 2003?). I recall it was distributed and had branching.
- EGreg 13y ago
  Bitkeeper?
- tbrownaw 13y ago
  Git was built to replace a proprietary branch-centric (or merge-centric) versioning system that the kernel devs had used previously, because none of the other available systems were suitable (including several DVCSs, which must be branch/merge centric due to the nature of distributedness). Also try looking into the history of the DaggyFixes idea (that a bug fix should be committed against the earliest revision to contain the bug and then merge into the active branches, rather than committed against current head).

jlgreco 13y ago

How do you figure that git tracks changesets, not revisions?

anton_gogolev 13y ago
Let's define "revision" to be "what the entire codebase looked like at some particular point in time" and "changeset" to be "a list of changes between one specific revision and the next specific revision". Now, if we look at Subversion, we see that given a particular revision there's no way to reliably determine its' "parent", because the fact that r6 is followed by r7 doesn't mean that changes in r7 were based off of r6. If we look at any DVCS, each commit would have an explicit reference to its' parent(s), so there's always a non-ambiguous way to reconstruct the entire "chain" of relationships between commits.
- jlgreco 13y ago
  > Let's define "revision" to be "what the entire codebase looked like at some particular point in time" and "changeset" to be "a list of changes between one specific revision and the next specific revision". Git tracks revisions then. Commits have a tree object that describes the codebase at the time of the creation of the commit. You don't need to transverse any previous commits to recreate that tree. Commits also have other commits objects listed as their parent commits, but they are not needed to examine the current state. Git doesn't use deltas in the way that Mercurial does.
  - tbrownaw 13y ago
    The only system I know of that truly tracks changesets rather than revisions is Darcs. But from a more practical standpoint, tracking changesets rather than just revisions means recording ancestry ("commits also have other commits objects listed as their parent commits") such that you can freely create merge revisions and the system will Do The Right Thing with minimal hand-holding. The internal repository format isn't really relevant here, it's about the way of thinking that the system is designed to support.
  - anton_gogolev 13y ago
    Mercurial storing deltas is just an optimization (sometimes it stores full snapshots): all manifests [1] refer to full file content, not deltas. Let's put it this way: the key feature of DVCSes is that they store explicit relationships between a particular commit and its parents. This makes it trivial to reconstruct actual changesets as per my definition, which in turn makes merge machinery much more reliable. [1]: http://mercurial.selenic.com/wiki/Manifest http://mercurial.selenic.com/wiki/Manifest
    - jlgreco 13y ago
      Okay, that I can agree with. I just think it is misleading to say they are based on change lists since changelists can be derived but are not actually stored. (And in the case of git at least, the changes you derive may not be changes that a human made, per se (in other words, those changes are the output of rebase.))

mhaymo 13y ago

> stating that Git was "the first system that was deliberately built around" branching is too arrogant. Do you have a counter-example?

anton_gogolev 13y ago
For one, Mercurial has branching as well. Although technically it was released 12 days later than Git, the motivation for both of them was that Linus Torvalds decided (for legal reasons) not to use BitKeeper for Linux kernel development and was in need for a replacement version control system. Besides Git, Mercurial and BitKeeper, there is also Monotone, which is also a DVCS.
- stock_toaster 13y ago
  and Darcs. Which is more "patch based". Never used it much, but it has been around for quite a while (march 2003). arch/tla/ArX was also an early one (2001? 2003?). I recall it was distributed and had branching.
EGreg 13y ago
Bitkeeper?
tbrownaw 13y ago
Git was built to replace a proprietary branch-centric (or merge-centric) versioning system that the kernel devs had used previously, because none of the other available systems were suitable (including several DVCSs, which must be branch/merge centric due to the nature of distributedness). Also try looking into the history of the DaggyFixes idea (that a bug fix should be committed against the earliest revision to contain the bug and then merge into the active branches, rather than committed against current head).