Can I checkout a single file without altering index?

Can I checkout a certain file to a specific revision without also adding this 
content to the index? I only want to alter the working-tree - no modification of 
index or HEAD needed.

Here is why I need that: I see a bug in git controlled sources. I fix one source
file and also add one unit test in a separate file. I checked that the test
succeeds with my fix. The index now contains what I want to commit.
Now I want to see whether my test fails without my fix. I want to checkout HEAD
for the source file without destroying my index. In the end, after I saw that my
test fails without my fix, I just want to say "git commit" without having to.

Christian Halstrick venit, vidit, dixit 12.10.2010 12:03:

Can I checkout a certain file to a specific revision without also adding this 
content to the index? I only want to alter the working-tree - no modification of 
index or HEAD needed.

Here is why I need that: I see a bug in git controlled sources. I fix one source
file and also add one unit test in a separate file. I checked that the test
succeeds with my fix. The index now contains what I want to commit.
Now I want to see whether my test fails without my fix. I want to checkout HEAD
for the source file without destroying my index. In the end, after I saw that my
test fails without my fix, I just want to say "git commit" without having to.

I would recommend to work on top of a trial commit, i.e.

git commit -m TheFix
git checkout HEAD^ -- fixedfile.c
git reset --hard

and git commit --amend if needed. (Alternatively, use stash.)

You can also use

git show HEAD:fixedfile.c > fixedfile.c
git checkout fixed.file.c
git commit -m TheFix

but I find this more cumbersome.

Michael

On 10/12/2010 12:03 PM, Christian Halstrick wrote:

Can I checkout a certain file to a specific revision without also adding this 
content to the index? I only want to alter the working-tree - no modification of 
index or HEAD needed.

Here is why I need that: I see a bug in git controlled sources. I fix one source
file and also add one unit test in a separate file. I checked that the test
succeeds with my fix. The index now contains what I want to commit.
Now I want to see whether my test fails without my fix. I want to checkout HEAD
for the source file without destroying my index. In the end, after I saw that my
test fails without my fix, I just want to say "git commit" without having to.

commit the unit test first, and the fix as a second commit ?

Regards,
  Stefan
-- 
----------------------------------------------------------------
/dev/random says: Help endangered species - adopt a KGB operative.

On Tue, Oct 12, 2010 at 12:03, Christian Halstrick
[off-list ref] wrote:

Can I checkout a certain file to a specific revision without also adding this
content to the index? I only want to alter the working-tree - no modification of
index or HEAD needed.

"git show <revision-specification>:path/name > path/name" ?

On 10/12/10 5:39 PM, Alex Riesen wrote:

On Tue, Oct 12, 2010 at 12:03, Christian Halstrick
[off-list ref] wrote:

quoted

Can I checkout a certain file to a specific revision without also adding this
content to the index? I only want to alter the working-tree - no modification of
index or HEAD needed.

"git show <revision-specification>:path/name > path/name" ?

I heard that git-show doesn't apply filters to the file (smudge/clean or
any custom ones). Keep that in mind when using it.

tom

Stefan Naewe <stefan.naewe <at> atlas-elektronik.com> writes:

On 10/12/2010 12:03 PM, Christian Halstrick wrote:

quoted

Can I checkout a certain file to a specific revision without also adding 

this 

quoted

content to the index? I only want to alter the working-tree - no 

modification of 

quoted

index or HEAD needed.

Here is why I need that: I see a bug in git controlled sources. I fix one 

source

quoted

file and also add one unit test in a separate file. I checked that the test
succeeds with my fix. The index now contains what I want to commit.
Now I want to see whether my test fails without my fix. I want to checkout 

HEAD

quoted

for the source file without destroying my index. In the end, after I saw 

that my

quoted

test fails without my fix, I just want to say "git commit" without having 

to.

commit the unit test first, and the fix as a second commit ?

Regards,
  Stefan

Just to add to this, since you might not want the test and the fix in separate 
commmits: (as is implied in the message)
  1. commit unit test.
  2. commit fix.
  3. go to detchatched head at HEAD^
  4. run unit test to insure that it fails.
  5. checkout the branch again to where you have the fix.
  6. run unit test to insure that it doesn't fail.
  7. run `git rebase HEAD^` and merge squash the two commits. (optional)

Alternatively, as others have pointed out, the stash should work as well.

Thank's a lot for all your responses. I know now how to solve my problem. I'll
definitely not going to commit my unit-test before my fix and publish that
because then I would have commits in the history where tests fail. But other
suggested solutions do work.

Still, all that sounds like workarounds for a lacking feature. Checkout content
to the worktree without altering the index. What do you think, couldn't that be
added as an option to checkout?

-- Chris

"Christian Halstrick" [off-list ref] wrote in message 
news:loom.20101014T095743-275@post.gmane.org...

Thank's a lot for all your responses. I know now how to solve my problem. 
I'll
definitely not going to commit my unit-test before my fix and publish that
because then I would have commits in the history where tests fail. But 
other
suggested solutions do work.

Still, all that sounds like workarounds for a lacking feature. Checkout 
content
to the worktree without altering the index. What do you think, couldn't 
that be
added as an option to checkout?

-- Chris

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.  Therefore, when you checkout the blob, 
it first gets copied from the object-store to your index and then from the 
index to your work-tree.

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.  None the 
less, this "exception" in the git-commit manpage does seem to set the 
precedent, so maybe it is also conceivable to copy objects directly from the 
object-store to the work-tree by totally bypassing the index.

Please note that I am responding because I am interested in the discussion 
and not because I know the answer.  I am not a git programmer so my 
observations only symptomatic and/or theoretical as a user.

v/r,
Neal 

Hi Neal,

Neal Kreitzinger wrote:

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

What option is this?  I thought "git commit --include" added content
to the index.

On Fri, Oct 15, 2010 at 01:43:02PM -0500, Jonathan Nieder wrote:

Neal Kreitzinger wrote:

quoted

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

What option is this?  I thought "git commit --include" added content
to the index.

git commit -o|--only, which is the same as "git commit <paths>". Of
course it still uses an index, to create the tree, but it uses a
temporary one based on HEAD instead of the current index contents.

-Peff

"Jonathan Nieder" [off-list ref] wrote in message 
news:20101015184302.GA22990@burratino...

Hi Neal,

Neal Kreitzinger wrote:

quoted

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

What option is this?  I thought "git commit --include" added content
to the index.

From the git-commit manpage (1.7.1.2):

"3.  by listing files as arguments to the commit command, in which case the 
commit will ignore changes staged in the index, and instead record the 
current content of the listed files (which must already be known to git); "

(I haven't tried it myself because to me the index is a key technology of 
git so I'm not sure why I would want to bypass it.)

v/r,
Neal 

Jeff King wrote:

On Fri, Oct 15, 2010 at 01:43:02PM -0500, Jonathan Nieder wrote:

quoted

Neal Kreitzinger wrote:

quoted

quoted

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

What option is this?  I thought "git commit --include" added content
to the index.

git commit -o|--only, which is the same as "git commit <paths>". Of
course it still uses an index, to create the tree, but it uses a
temporary one based on HEAD instead of the current index contents.

Ah, it's stranger than that.

	 * A partial commit.
	 *
	 * (0) find the set of affected paths;
	 * (1) get lock on the real index file;
	 * (2) update the_index with the given paths;
	 * (3) write the_index out to the real index (still locked);
	 * (4) get lock on the false index file;
	 * (5) reset the_index from HEAD;
	 * (6) update the_index the same way as (2);
	 * (7) write the_index out to the false index file;
	 * (8) return the name of the false index file (still locked);

The net effect being that the index will match the work tree for the
listed paths when the operation is over, while other files are
untouched.
-- 8< --
Subject: Documentation: clarify "commit --only" description

From the current description, one might imagine that "git commit

<pathspec>" bypasses the index completely.  Clarify what it does
do to the index:

 - paths matching <pathspec> are updated to match the work tree
 - paths not matching <pathspec> are left alone

so readers can have a better idea of what the index represents
before and after such an operation.

Signed-off-by: Jonathan Nieder <redacted>
---
 I'm not so happy with the wording.  Hopefully this gives the idea...

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 42fb1f5..6bb3eff 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt

@@ -191,9 +191,10 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
 --only::
 	Make a commit only from the paths specified on the
 	command line, disregarding any contents that have been
-	staged so far. This is the default mode of operation of
-	'git commit' if any paths are given on the command line,
-	in which case this option can be omitted.
+	staged so far.  The state of other files in the index is
+	preserved and will not affect the commit.  This is the
+	default mode of operation of 'git commit' if any paths are given
+	on the command line, in which case this option can be omitted.
 	If this option is specified together with '--amend', then
 	no paths need to be specified, which can be used to amend
 	the last commit without committing changes that have

On Fri, Oct 15, 2010 at 02:32:52PM -0500, Jonathan Nieder wrote:

quoted

git commit -o|--only, which is the same as "git commit <paths>". Of
course it still uses an index, to create the tree, but it uses a
temporary one based on HEAD instead of the current index contents.

Ah, it's stranger than that.

	 * A partial commit.
	 *
	 * (0) find the set of affected paths;
	 * (1) get lock on the real index file;
	 * (2) update the_index with the given paths;
	 * (3) write the_index out to the real index (still locked);
	 * (4) get lock on the false index file;
	 * (5) reset the_index from HEAD;
	 * (6) update the_index the same way as (2);
	 * (7) write the_index out to the false index file;
	 * (8) return the name of the false index file (still locked);

The net effect being that the index will match the work tree for the
listed paths when the operation is over, while other files are
untouched.

Well, yeah, it does have to update those files in the regular index. Any
other semantics would be insane; the change would appear reverted
looking at the difference between HEAD and the index.

With respect to your proposed change:

I always assumed that "disregarding any contents that have been staged"
meant "we will leave unmentioned paths alone". But I don't think it
hurts to be explicit. So your change looks fine to me.

-Peff