What does Linus Torvalds mean when he says that Git “never ever” tracks a file? The 2019 Stack Overflow Developer Survey Results Are InGit workflow and rebase vs merge questionsHow to stop tracking and ignore changes to a file in Git?How to make Git “forget” about a file that was tracked but is now in .gitignore?In plain English, what does “git reset” do?Handling file renames in gitsrc refspec master does not match any when pushing commits in gitFind when a file was deleted in GitWhat does the term “porcelain” mean in Git?What does cherry-picking a commit with Git mean?Various ways to remove local Git changes

aging parents with no investments

Are there any other methods to apply to solving simultaneous equations?

Should I write numbers in words or as numerals when there are multiple next to each other?

Is there a name of the flying bionic bird?

Limit the amount of RAM Mathematica may access?

Access elements in std::string where positon of string is greater than its size

What is the steepest angle that a canal can be traversable without locks?

Pristine Bit Checking

Extreme, unacceptable situation and I can't attend work tomorrow morning

What does Linus Torvalds mean when he says that Git "never ever" tracks a file?

Monty Hall variation

Carnot-Caratheodory metric

Realistic Alternatives to Dust: What Else Could Feed a Plankton Bloom?

Lethal sonic weapons

Can distinct morphisms between curves induce the same morphism on singular cohomology?

What is the use of option -o in the useradd command?

Why don't Unix/Linux systems traverse through directories until they find the required version of a linked library?

Spanish for "widget"

Is "plugging out" electronic devices an American expression?

Why can Shazam do this?

Is bread bad for ducks?

How come people say “Would of”?

Is three citations per paragraph excessive for undergraduate research paper?

What do the Banks children have against barley water?



What does Linus Torvalds mean when he says that Git “never ever” tracks a file?



The 2019 Stack Overflow Developer Survey Results Are InGit workflow and rebase vs merge questionsHow to stop tracking and ignore changes to a file in Git?How to make Git “forget” about a file that was tracked but is now in .gitignore?In plain English, what does “git reset” do?Handling file renames in gitsrc refspec master does not match any when pushing commits in gitFind when a file was deleted in GitWhat does the term “porcelain” mean in Git?What does cherry-picking a commit with Git mean?Various ways to remove local Git changes



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








8















Quoting Linus Torvalds when asked how many files Git can handle during his Tech Talk at Google in 2007 (43:09):




…Git tracks your content. It never ever tracks a single file. You cannot track a file in Git. What you can do is you can track a project that has a single file, but if your project has a single file, sure do that and you can do it, but if you track 10,000 files, Git never ever sees those as individual files. Git thinks everything as the full content. All history in Git is based on the history of the whole project…




(Transcripts here.)



Yet, when you dive into the Git book, the first thing you are told is that a file in Git can be either tracked or untracked. Furthermore, it seems to me like the whole Git experience is geared towards file versioning. When using git diff or git status output is presented on a per file basis. When using git add you also get to choose on a per file basis. You can even review history on a file basis and is lightning fast.



How should this statement be interpreted? In terms of file tracking, how is Git different from other source control systems, such as VCS?










share|improve this question
























  • Context of words.. one tells git to 'track' a file by adding it to the files git cares about, but git doesn't internally 'track' a file.

    – user2864740
    3 hours ago












  • reddit.com/r/git/comments/5xmrkv/what_is_a_snapshot_in_git - "For where you are at the moment, I suspect what's more important to realize is that there's a difference between how Git presents files to users and how it deals with them internally. As presented to the user, a snapshot contains complete files, not merely diffs. But internally, yes, Git uses diffs to generate packfiles that efficiently store revisions." (This is sharp contrast to, eg. Subversion.)

    – user2864740
    3 hours ago







  • 1





    Git doesn't track files, it tracks changesets. Most version control systems track files. As an example of how / why this can matter, try to check in an empty directory to git (spolier: you can't, because that's an "empty" changeset).

    – Elliott Frisch
    3 hours ago












  • @ElliottFrisch That doesn't sound right. Your description is closer to what e.g. darcs does. Git stores snapshots, not changesets.

    – melpomene
    3 hours ago






  • 1





    Related: Randal Schwartz' followup to Linus' talk (also a Google Tech talk) - "... What Git is really all about ... Linus said what Git is NOT".

    – Peter Mortensen
    1 hour ago


















8















Quoting Linus Torvalds when asked how many files Git can handle during his Tech Talk at Google in 2007 (43:09):




…Git tracks your content. It never ever tracks a single file. You cannot track a file in Git. What you can do is you can track a project that has a single file, but if your project has a single file, sure do that and you can do it, but if you track 10,000 files, Git never ever sees those as individual files. Git thinks everything as the full content. All history in Git is based on the history of the whole project…




(Transcripts here.)



Yet, when you dive into the Git book, the first thing you are told is that a file in Git can be either tracked or untracked. Furthermore, it seems to me like the whole Git experience is geared towards file versioning. When using git diff or git status output is presented on a per file basis. When using git add you also get to choose on a per file basis. You can even review history on a file basis and is lightning fast.



How should this statement be interpreted? In terms of file tracking, how is Git different from other source control systems, such as VCS?










share|improve this question
























  • Context of words.. one tells git to 'track' a file by adding it to the files git cares about, but git doesn't internally 'track' a file.

    – user2864740
    3 hours ago












  • reddit.com/r/git/comments/5xmrkv/what_is_a_snapshot_in_git - "For where you are at the moment, I suspect what's more important to realize is that there's a difference between how Git presents files to users and how it deals with them internally. As presented to the user, a snapshot contains complete files, not merely diffs. But internally, yes, Git uses diffs to generate packfiles that efficiently store revisions." (This is sharp contrast to, eg. Subversion.)

    – user2864740
    3 hours ago







  • 1





    Git doesn't track files, it tracks changesets. Most version control systems track files. As an example of how / why this can matter, try to check in an empty directory to git (spolier: you can't, because that's an "empty" changeset).

    – Elliott Frisch
    3 hours ago












  • @ElliottFrisch That doesn't sound right. Your description is closer to what e.g. darcs does. Git stores snapshots, not changesets.

    – melpomene
    3 hours ago






  • 1





    Related: Randal Schwartz' followup to Linus' talk (also a Google Tech talk) - "... What Git is really all about ... Linus said what Git is NOT".

    – Peter Mortensen
    1 hour ago














8












8








8








Quoting Linus Torvalds when asked how many files Git can handle during his Tech Talk at Google in 2007 (43:09):




…Git tracks your content. It never ever tracks a single file. You cannot track a file in Git. What you can do is you can track a project that has a single file, but if your project has a single file, sure do that and you can do it, but if you track 10,000 files, Git never ever sees those as individual files. Git thinks everything as the full content. All history in Git is based on the history of the whole project…




(Transcripts here.)



Yet, when you dive into the Git book, the first thing you are told is that a file in Git can be either tracked or untracked. Furthermore, it seems to me like the whole Git experience is geared towards file versioning. When using git diff or git status output is presented on a per file basis. When using git add you also get to choose on a per file basis. You can even review history on a file basis and is lightning fast.



How should this statement be interpreted? In terms of file tracking, how is Git different from other source control systems, such as VCS?










share|improve this question
















Quoting Linus Torvalds when asked how many files Git can handle during his Tech Talk at Google in 2007 (43:09):




…Git tracks your content. It never ever tracks a single file. You cannot track a file in Git. What you can do is you can track a project that has a single file, but if your project has a single file, sure do that and you can do it, but if you track 10,000 files, Git never ever sees those as individual files. Git thinks everything as the full content. All history in Git is based on the history of the whole project…




(Transcripts here.)



Yet, when you dive into the Git book, the first thing you are told is that a file in Git can be either tracked or untracked. Furthermore, it seems to me like the whole Git experience is geared towards file versioning. When using git diff or git status output is presented on a per file basis. When using git add you also get to choose on a per file basis. You can even review history on a file basis and is lightning fast.



How should this statement be interpreted? In terms of file tracking, how is Git different from other source control systems, such as VCS?







git version-control






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 1 hour ago









Peter Mortensen

13.9k1987113




13.9k1987113










asked 3 hours ago









Simón Ramírez AmayaSimón Ramírez Amaya

879




879












  • Context of words.. one tells git to 'track' a file by adding it to the files git cares about, but git doesn't internally 'track' a file.

    – user2864740
    3 hours ago












  • reddit.com/r/git/comments/5xmrkv/what_is_a_snapshot_in_git - "For where you are at the moment, I suspect what's more important to realize is that there's a difference between how Git presents files to users and how it deals with them internally. As presented to the user, a snapshot contains complete files, not merely diffs. But internally, yes, Git uses diffs to generate packfiles that efficiently store revisions." (This is sharp contrast to, eg. Subversion.)

    – user2864740
    3 hours ago







  • 1





    Git doesn't track files, it tracks changesets. Most version control systems track files. As an example of how / why this can matter, try to check in an empty directory to git (spolier: you can't, because that's an "empty" changeset).

    – Elliott Frisch
    3 hours ago












  • @ElliottFrisch That doesn't sound right. Your description is closer to what e.g. darcs does. Git stores snapshots, not changesets.

    – melpomene
    3 hours ago






  • 1





    Related: Randal Schwartz' followup to Linus' talk (also a Google Tech talk) - "... What Git is really all about ... Linus said what Git is NOT".

    – Peter Mortensen
    1 hour ago


















  • Context of words.. one tells git to 'track' a file by adding it to the files git cares about, but git doesn't internally 'track' a file.

    – user2864740
    3 hours ago












  • reddit.com/r/git/comments/5xmrkv/what_is_a_snapshot_in_git - "For where you are at the moment, I suspect what's more important to realize is that there's a difference between how Git presents files to users and how it deals with them internally. As presented to the user, a snapshot contains complete files, not merely diffs. But internally, yes, Git uses diffs to generate packfiles that efficiently store revisions." (This is sharp contrast to, eg. Subversion.)

    – user2864740
    3 hours ago







  • 1





    Git doesn't track files, it tracks changesets. Most version control systems track files. As an example of how / why this can matter, try to check in an empty directory to git (spolier: you can't, because that's an "empty" changeset).

    – Elliott Frisch
    3 hours ago












  • @ElliottFrisch That doesn't sound right. Your description is closer to what e.g. darcs does. Git stores snapshots, not changesets.

    – melpomene
    3 hours ago






  • 1





    Related: Randal Schwartz' followup to Linus' talk (also a Google Tech talk) - "... What Git is really all about ... Linus said what Git is NOT".

    – Peter Mortensen
    1 hour ago

















Context of words.. one tells git to 'track' a file by adding it to the files git cares about, but git doesn't internally 'track' a file.

– user2864740
3 hours ago






Context of words.. one tells git to 'track' a file by adding it to the files git cares about, but git doesn't internally 'track' a file.

– user2864740
3 hours ago














reddit.com/r/git/comments/5xmrkv/what_is_a_snapshot_in_git - "For where you are at the moment, I suspect what's more important to realize is that there's a difference between how Git presents files to users and how it deals with them internally. As presented to the user, a snapshot contains complete files, not merely diffs. But internally, yes, Git uses diffs to generate packfiles that efficiently store revisions." (This is sharp contrast to, eg. Subversion.)

– user2864740
3 hours ago






reddit.com/r/git/comments/5xmrkv/what_is_a_snapshot_in_git - "For where you are at the moment, I suspect what's more important to realize is that there's a difference between how Git presents files to users and how it deals with them internally. As presented to the user, a snapshot contains complete files, not merely diffs. But internally, yes, Git uses diffs to generate packfiles that efficiently store revisions." (This is sharp contrast to, eg. Subversion.)

– user2864740
3 hours ago





1




1





Git doesn't track files, it tracks changesets. Most version control systems track files. As an example of how / why this can matter, try to check in an empty directory to git (spolier: you can't, because that's an "empty" changeset).

– Elliott Frisch
3 hours ago






Git doesn't track files, it tracks changesets. Most version control systems track files. As an example of how / why this can matter, try to check in an empty directory to git (spolier: you can't, because that's an "empty" changeset).

– Elliott Frisch
3 hours ago














@ElliottFrisch That doesn't sound right. Your description is closer to what e.g. darcs does. Git stores snapshots, not changesets.

– melpomene
3 hours ago





@ElliottFrisch That doesn't sound right. Your description is closer to what e.g. darcs does. Git stores snapshots, not changesets.

– melpomene
3 hours ago




1




1





Related: Randal Schwartz' followup to Linus' talk (also a Google Tech talk) - "... What Git is really all about ... Linus said what Git is NOT".

– Peter Mortensen
1 hour ago






Related: Randal Schwartz' followup to Linus' talk (also a Google Tech talk) - "... What Git is really all about ... Linus said what Git is NOT".

– Peter Mortensen
1 hour ago













2 Answers
2






active

oldest

votes


















16














In CVS, history was tracked on a per-file basis. A branch might consist of various files with their own various revisions, each with it's own version number. CVS was based off RCS, which tracked individual files in a similar way.



On the other hand, Git takes snapshots of the state of the whole project. Files are not tracked and versioned independently; a revision in the repository refers to a state of the whole project, not one file.



When Git refers to tracking a file, it means simply that it is to be included in the history of the project. Linus's talk was not referring to tracking files in the Git context, but was contrasting the CVS and RCS model with the snapshot-based model used in Git.






share|improve this answer






























    5














    I agree with brian m. carlson's answer (and have upvoted it): Linus is indeed distinguishing, at least in part, between file-oriented and commit-oriented version control systems. But I think there is more to it than that.



    In my book, which is stalled and might never get finished, I tried to come up with a taxonomy for version control systems. In my taxonomy the term for what we're interested here is the atomicity of the version control system. See what is currently page 22. When a VCS has file-level atomicity, there is in fact a history for each file. The VCS must remember the name of the file and what occurred to it at each point.



    Git doesn't do that. Git has only a history of commits—the commit is its unit of atomicity, and the history is the set of commits in the repository. What a commit remembers is the data—a whole tree-full of file names and the contents that go with each of those files—plus some metadata: for instance, who made the commit, when, and why, and the internal Git hash ID of the commit's parent commit. (It is this parent, and the directed acycling graph formed by reading all commits and their parents, that is the history in a repository.)



    Note that a VCS can be commit-oriented, yet still store data file-by-file. That's an implementation detail, though sometimes an important one, and Git does not do that either. Instead, each commit records a tree, with the tree object encoding file names, modes (i.e., is this file executable or not?), and a pointer to the actual file content. The content itself is stored independently, in a blob object. Like a commit object, a blob gets a hash ID that is unique to its content—but unlike a commit, which can only appear once, the blob can appear in many commits. So the underlying file content in Git is stored directly as a blob, and then indirectly in a tree object whose hash ID is recorded (directly or indirectly) in the commit object.



    When you ask Git to show you a file's history using:



    git log [--follow] [starting-point] [--] path/to/file


    what Git is really doing is walking the commit history, which is the only history Git has, but not showing you any of these commits unless:



    • the commit is a non-merge commit, and

    • the parent of that commit also has the file, but the content in the parent differs, or the parent of the commit doesn't have the file at all

    (but some of these conditions can be modified via additional git log options, and there's a very difficult to describe side effect called History Simplification that makes Git omit some commits from the history walk entirely). The file history you see here does not exactly exist in the repository, in some sense: instead, it's just a synthetic subset of the real history. You'll get a different "file history" if you use different git log options!






    share|improve this answer























      Your Answer






      StackExchange.ifUsing("editor", function ()
      StackExchange.using("externalEditor", function ()
      StackExchange.using("snippets", function ()
      StackExchange.snippets.init();
      );
      );
      , "code-snippets");

      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "1"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader:
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      ,
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













      draft saved

      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55602748%2fwhat-does-linus-torvalds-mean-when-he-says-that-git-never-ever-tracks-a-file%23new-answer', 'question_page');

      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      16














      In CVS, history was tracked on a per-file basis. A branch might consist of various files with their own various revisions, each with it's own version number. CVS was based off RCS, which tracked individual files in a similar way.



      On the other hand, Git takes snapshots of the state of the whole project. Files are not tracked and versioned independently; a revision in the repository refers to a state of the whole project, not one file.



      When Git refers to tracking a file, it means simply that it is to be included in the history of the project. Linus's talk was not referring to tracking files in the Git context, but was contrasting the CVS and RCS model with the snapshot-based model used in Git.






      share|improve this answer



























        16














        In CVS, history was tracked on a per-file basis. A branch might consist of various files with their own various revisions, each with it's own version number. CVS was based off RCS, which tracked individual files in a similar way.



        On the other hand, Git takes snapshots of the state of the whole project. Files are not tracked and versioned independently; a revision in the repository refers to a state of the whole project, not one file.



        When Git refers to tracking a file, it means simply that it is to be included in the history of the project. Linus's talk was not referring to tracking files in the Git context, but was contrasting the CVS and RCS model with the snapshot-based model used in Git.






        share|improve this answer

























          16












          16








          16







          In CVS, history was tracked on a per-file basis. A branch might consist of various files with their own various revisions, each with it's own version number. CVS was based off RCS, which tracked individual files in a similar way.



          On the other hand, Git takes snapshots of the state of the whole project. Files are not tracked and versioned independently; a revision in the repository refers to a state of the whole project, not one file.



          When Git refers to tracking a file, it means simply that it is to be included in the history of the project. Linus's talk was not referring to tracking files in the Git context, but was contrasting the CVS and RCS model with the snapshot-based model used in Git.






          share|improve this answer













          In CVS, history was tracked on a per-file basis. A branch might consist of various files with their own various revisions, each with it's own version number. CVS was based off RCS, which tracked individual files in a similar way.



          On the other hand, Git takes snapshots of the state of the whole project. Files are not tracked and versioned independently; a revision in the repository refers to a state of the whole project, not one file.



          When Git refers to tracking a file, it means simply that it is to be included in the history of the project. Linus's talk was not referring to tracking files in the Git context, but was contrasting the CVS and RCS model with the snapshot-based model used in Git.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered 3 hours ago









          brian m. carlsonbrian m. carlson

          2,051312




          2,051312























              5














              I agree with brian m. carlson's answer (and have upvoted it): Linus is indeed distinguishing, at least in part, between file-oriented and commit-oriented version control systems. But I think there is more to it than that.



              In my book, which is stalled and might never get finished, I tried to come up with a taxonomy for version control systems. In my taxonomy the term for what we're interested here is the atomicity of the version control system. See what is currently page 22. When a VCS has file-level atomicity, there is in fact a history for each file. The VCS must remember the name of the file and what occurred to it at each point.



              Git doesn't do that. Git has only a history of commits—the commit is its unit of atomicity, and the history is the set of commits in the repository. What a commit remembers is the data—a whole tree-full of file names and the contents that go with each of those files—plus some metadata: for instance, who made the commit, when, and why, and the internal Git hash ID of the commit's parent commit. (It is this parent, and the directed acycling graph formed by reading all commits and their parents, that is the history in a repository.)



              Note that a VCS can be commit-oriented, yet still store data file-by-file. That's an implementation detail, though sometimes an important one, and Git does not do that either. Instead, each commit records a tree, with the tree object encoding file names, modes (i.e., is this file executable or not?), and a pointer to the actual file content. The content itself is stored independently, in a blob object. Like a commit object, a blob gets a hash ID that is unique to its content—but unlike a commit, which can only appear once, the blob can appear in many commits. So the underlying file content in Git is stored directly as a blob, and then indirectly in a tree object whose hash ID is recorded (directly or indirectly) in the commit object.



              When you ask Git to show you a file's history using:



              git log [--follow] [starting-point] [--] path/to/file


              what Git is really doing is walking the commit history, which is the only history Git has, but not showing you any of these commits unless:



              • the commit is a non-merge commit, and

              • the parent of that commit also has the file, but the content in the parent differs, or the parent of the commit doesn't have the file at all

              (but some of these conditions can be modified via additional git log options, and there's a very difficult to describe side effect called History Simplification that makes Git omit some commits from the history walk entirely). The file history you see here does not exactly exist in the repository, in some sense: instead, it's just a synthetic subset of the real history. You'll get a different "file history" if you use different git log options!






              share|improve this answer



























                5














                I agree with brian m. carlson's answer (and have upvoted it): Linus is indeed distinguishing, at least in part, between file-oriented and commit-oriented version control systems. But I think there is more to it than that.



                In my book, which is stalled and might never get finished, I tried to come up with a taxonomy for version control systems. In my taxonomy the term for what we're interested here is the atomicity of the version control system. See what is currently page 22. When a VCS has file-level atomicity, there is in fact a history for each file. The VCS must remember the name of the file and what occurred to it at each point.



                Git doesn't do that. Git has only a history of commits—the commit is its unit of atomicity, and the history is the set of commits in the repository. What a commit remembers is the data—a whole tree-full of file names and the contents that go with each of those files—plus some metadata: for instance, who made the commit, when, and why, and the internal Git hash ID of the commit's parent commit. (It is this parent, and the directed acycling graph formed by reading all commits and their parents, that is the history in a repository.)



                Note that a VCS can be commit-oriented, yet still store data file-by-file. That's an implementation detail, though sometimes an important one, and Git does not do that either. Instead, each commit records a tree, with the tree object encoding file names, modes (i.e., is this file executable or not?), and a pointer to the actual file content. The content itself is stored independently, in a blob object. Like a commit object, a blob gets a hash ID that is unique to its content—but unlike a commit, which can only appear once, the blob can appear in many commits. So the underlying file content in Git is stored directly as a blob, and then indirectly in a tree object whose hash ID is recorded (directly or indirectly) in the commit object.



                When you ask Git to show you a file's history using:



                git log [--follow] [starting-point] [--] path/to/file


                what Git is really doing is walking the commit history, which is the only history Git has, but not showing you any of these commits unless:



                • the commit is a non-merge commit, and

                • the parent of that commit also has the file, but the content in the parent differs, or the parent of the commit doesn't have the file at all

                (but some of these conditions can be modified via additional git log options, and there's a very difficult to describe side effect called History Simplification that makes Git omit some commits from the history walk entirely). The file history you see here does not exactly exist in the repository, in some sense: instead, it's just a synthetic subset of the real history. You'll get a different "file history" if you use different git log options!






                share|improve this answer

























                  5












                  5








                  5







                  I agree with brian m. carlson's answer (and have upvoted it): Linus is indeed distinguishing, at least in part, between file-oriented and commit-oriented version control systems. But I think there is more to it than that.



                  In my book, which is stalled and might never get finished, I tried to come up with a taxonomy for version control systems. In my taxonomy the term for what we're interested here is the atomicity of the version control system. See what is currently page 22. When a VCS has file-level atomicity, there is in fact a history for each file. The VCS must remember the name of the file and what occurred to it at each point.



                  Git doesn't do that. Git has only a history of commits—the commit is its unit of atomicity, and the history is the set of commits in the repository. What a commit remembers is the data—a whole tree-full of file names and the contents that go with each of those files—plus some metadata: for instance, who made the commit, when, and why, and the internal Git hash ID of the commit's parent commit. (It is this parent, and the directed acycling graph formed by reading all commits and their parents, that is the history in a repository.)



                  Note that a VCS can be commit-oriented, yet still store data file-by-file. That's an implementation detail, though sometimes an important one, and Git does not do that either. Instead, each commit records a tree, with the tree object encoding file names, modes (i.e., is this file executable or not?), and a pointer to the actual file content. The content itself is stored independently, in a blob object. Like a commit object, a blob gets a hash ID that is unique to its content—but unlike a commit, which can only appear once, the blob can appear in many commits. So the underlying file content in Git is stored directly as a blob, and then indirectly in a tree object whose hash ID is recorded (directly or indirectly) in the commit object.



                  When you ask Git to show you a file's history using:



                  git log [--follow] [starting-point] [--] path/to/file


                  what Git is really doing is walking the commit history, which is the only history Git has, but not showing you any of these commits unless:



                  • the commit is a non-merge commit, and

                  • the parent of that commit also has the file, but the content in the parent differs, or the parent of the commit doesn't have the file at all

                  (but some of these conditions can be modified via additional git log options, and there's a very difficult to describe side effect called History Simplification that makes Git omit some commits from the history walk entirely). The file history you see here does not exactly exist in the repository, in some sense: instead, it's just a synthetic subset of the real history. You'll get a different "file history" if you use different git log options!






                  share|improve this answer













                  I agree with brian m. carlson's answer (and have upvoted it): Linus is indeed distinguishing, at least in part, between file-oriented and commit-oriented version control systems. But I think there is more to it than that.



                  In my book, which is stalled and might never get finished, I tried to come up with a taxonomy for version control systems. In my taxonomy the term for what we're interested here is the atomicity of the version control system. See what is currently page 22. When a VCS has file-level atomicity, there is in fact a history for each file. The VCS must remember the name of the file and what occurred to it at each point.



                  Git doesn't do that. Git has only a history of commits—the commit is its unit of atomicity, and the history is the set of commits in the repository. What a commit remembers is the data—a whole tree-full of file names and the contents that go with each of those files—plus some metadata: for instance, who made the commit, when, and why, and the internal Git hash ID of the commit's parent commit. (It is this parent, and the directed acycling graph formed by reading all commits and their parents, that is the history in a repository.)



                  Note that a VCS can be commit-oriented, yet still store data file-by-file. That's an implementation detail, though sometimes an important one, and Git does not do that either. Instead, each commit records a tree, with the tree object encoding file names, modes (i.e., is this file executable or not?), and a pointer to the actual file content. The content itself is stored independently, in a blob object. Like a commit object, a blob gets a hash ID that is unique to its content—but unlike a commit, which can only appear once, the blob can appear in many commits. So the underlying file content in Git is stored directly as a blob, and then indirectly in a tree object whose hash ID is recorded (directly or indirectly) in the commit object.



                  When you ask Git to show you a file's history using:



                  git log [--follow] [starting-point] [--] path/to/file


                  what Git is really doing is walking the commit history, which is the only history Git has, but not showing you any of these commits unless:



                  • the commit is a non-merge commit, and

                  • the parent of that commit also has the file, but the content in the parent differs, or the parent of the commit doesn't have the file at all

                  (but some of these conditions can be modified via additional git log options, and there's a very difficult to describe side effect called History Simplification that makes Git omit some commits from the history walk entirely). The file history you see here does not exactly exist in the repository, in some sense: instead, it's just a synthetic subset of the real history. You'll get a different "file history" if you use different git log options!







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered 2 hours ago









                  torektorek

                  199k18248330




                  199k18248330



























                      draft saved

                      draft discarded
















































                      Thanks for contributing an answer to Stack Overflow!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid


                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.

                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55602748%2fwhat-does-linus-torvalds-mean-when-he-says-that-git-never-ever-tracks-a-file%23new-answer', 'question_page');

                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Can not update quote_id field of “quote_item” table magento 2Magento 2.1 - We can't remove the item. (Shopping Cart doesnt allow us to remove items before becomes empty)Add value for custom quote item attribute using REST apiREST API endpoint v1/carts/cartId/items always returns error messageCorrect way to save entries to databaseHow to remove all associated quote objects of a customer completelyMagento 2 - Save value from custom input field to quote_itemGet quote_item data using quote id and product id filter in Magento 2How to set additional data to quote_item table from controller in Magento 2?What is the purpose of additional_data column in quote_item table in magento2Set Custom Price to Quote item magento2 from controller

                      How to solve knockout JS error in Magento 2 Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?(Magento2) knockout.js:3012 Uncaught ReferenceError: Unable to process bindingUnable to process binding Knockout.js magento 2Cannot read property `scopeLabel` of undefined on Product Detail PageCan't get Customer Data on frontend in Magento 2Magento2 Order Summary - unable to process bindingKO templates are not loading in Magento 2.1 applicationgetting knockout js error magento 2Product grid not load -— Unable to process binding Knockout.js magento 2Product form not loaded in magento2Uncaught ReferenceError: Unable to process binding “if: function()return (isShowLegend()) ” magento 2

                      Nissan Patrol Зміст Перше покоління — 4W60 (1951-1960) | Друге покоління — 60 series (1960-1980) | Третє покоління (1980–2002) | Четверте покоління — Y60 (1987–1998) | П'яте покоління — Y61 (1997–2013) | Шосте покоління — Y62 (2010- ) | Посилання | Зноски | Навігаційне менюОфіційний український сайтТест-драйв Nissan Patrol 2010 7-го поколінняNissan PatrolКак мы тестировали Nissan Patrol 2016рвиправивши або дописавши її