"Neal Kreitzinger" <neal@xxxxxxxx> writes:
> FWIW, my understanding of the index is that it is the middle-man for moving
> things from your work-tree to the object-store AND for moving things from
> the object-store to your work-tree.
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.
> However, there is an option in git-commit to copy files directly from the
> working-tree to the object-store by totally bypassing the index, but no one
> seems to do this or recommend doing this as normative practice.
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html