Re: Can I checkout a single file without altering index?

"Neal Kreitzinger" <neal@rsss.com> writes:

While there is nothing technically incorrect in the above, it probably is easier to explain/understand why it works in the direction from the object store and to the working tree if you state it this way instead:

  The index is where you build the contents for your next commit.

   - You build your next commit starting from the current commit,
     so when you do "checkout" from the object store, both the
     index and the working tree are populated with the blob.

   - You then modify that state in your working tree, hopefully
     testing, reviewing, and thinking about your change while
     doing so.

   - There may be good changes, not good enough changes, and
     perhaps only for debugging changes in your working tree.  You
     can decide to make commits out of only the good bits, leaving
     others uncommitted.  You add only good bits to your next
     commit, and the command to do so is naturally called "git
     add" (and "git add -p" for add changes to a file partially by
     picking patch hunks).

   - There may be a time where you regret that some changes you
     made to your working tree are not good, and want to start
     over.  You may even do so after you added some changes to
     the index (i.e. your next commit).  By checking the path
     out of the current commit would give you the original
     version of the path both in the index and in the working
     tree file to help you start over.

   - After making that commit, you will keep working to create
     the commit next to that commit you created.  To help you
     work incrementally, the index at that point contains what
     you committed.
 

This is wrong.  People do this all the time with "git commit $path".

What happens behind the scene is:

 - git prepares a temporary index that matches the contents of the
   current commit;

 - the contents for $path from the working tree is then added to that
   temporary index;

 - a new commit is written out of that temporary index; and

 - the $path is also added to the real index (this is a very important
   detail---otherwise the next commit will lose the change to $path).

Notice that in no step the index is really bypassed. Everything literally goes through the index.

If you want to bypass the index, you can do so with cat-file or show; it just is not a useful operation in a normal workflow of building the next commit on top of the current one, and that is the only reason why there is no option such as "checkout --no-index HEAD~47 path". If somebody can write a convincing use case that shows why it is useful, such an option shouldn't be very hard to add. But I don't think of any. For example, this is not it:

    I start from a clean slate and start working.

    $ git checkout
    $ edit; git diff; compile; test; git add path ;# repeat

    At this point I have some cooked contents added for the next commit
    in the index for path.  But I realize that the contents of that path
    in another branch might be even better.  But I do not want to lose
    the state I arrived at, which might be better than that alternative.
    I cannot decide, so I'll keep that in the index for now.

    $ git checkout --no-index the-other-branch path
    $ edit; compile; test; ...

    case I. yes the other one indeed is better
    $ git add path

    case II. no the other one is inferiour
    $ git checkout path ;# out of index

While superficially this looks promising, this is unwieldy. For one thing, you cannot easily check what you changed anymore, as "git diff path" would show the difference between the index, i.e. a version that was modified in a different way from the current version, and the working tree, i.e. another version that was modified starting from a totally different version in the-other-branch.