threads / discuss / 50985

Checkout file without changing index?

Subject: Checkout file without changing index?

## tl;dr

6 messages between Apr 24, 2019 and Apr 25, 2019.

replies: 5people: 4as markdown or json

Piotr Krukowiecki· Apr 24, 2019, 13:37 UTC · lore
Hi,
what is the standard/recommended way for updating a file to given version?
I was familiar with "git checkout revision -- file".

But it updates both working tree and index. I had some changes in index (staged) and "git checkout HEAD -- file" silently overwritten it. Well, probably my mistake, it's documented.

After searching a bit I found "git show revision:file > file". But
it's problematic:
1. works only for 1 file. "git show revision -- file" does something else
2. requires full path, so you need to specify "git show
revision:relative/to/top/dir/file"

If there's no other easy way, maybe we could add "--no-index" to checkout: "git checkout --no-index revision -- file" (or similar - maybe use options from git-reset).

My use case: I had some changes prepared in index and wanted to compare the prepared version with some older version. The file was a zip file plus we use LFS so there was no other way than to "checkout" the file, unpack it and diff it.

-- 
Piotr Krukowiecki
Junio C Hamano· Apr 24, 2019, 13:46 UTC · re: Piotr Krukowiecki · lore

Re: Checkout file without changing index?

Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:
Show 5 quoted lines
> I was familiar with "git checkout revision -- file".
>
> But it updates both working tree and index. I had some changes in
> index (staged) and "git checkout HEAD -- file" silently overwritten
> it. Well, probably my mistake, it's documented.
We'd invite you to live on the leading edge and try
    $ git restore --source=<revision> <pathspec>

which by default checks things out only to the working tree, but not to the index (you say --staged if you want to restore to the index, and you say --worktree if you want to restore to the working tree, or you can say both, which would be the same as "git checkout").

I think the new command is now on the 'pu' branch, but in a few weeks hopefully it will appear on the 'next' branch.

Piotr Krukowiecki· Apr 24, 2019, 18:15 UTC · re: Junio C Hamano · lore

Re: Checkout file without changing index?

On Wed, Apr 24, 2019 at 3:46 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 17 quoted lines
>
> Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:
>
> > I was familiar with "git checkout revision -- file".
> >
> > But it updates both working tree and index. I had some changes in
> > index (staged) and "git checkout HEAD -- file" silently overwritten
> > it. Well, probably my mistake, it's documented.
>
> We'd invite you to live on the leading edge and try
>
>     $ git restore --source=<revision> <pathspec>
>
> which by default checks things out only to the working tree, but not
> to the index (you say --staged if you want to restore to the index,
> and you say --worktree if you want to restore to the working tree,
> or you can say both, which would be the same as "git checkout").

Thanks, looks nice. git-checkout is a bit inconsistent at what it does, and I understand the git-restore and git-switch are a better replacement for it.

> I think the new command is now on the 'pu' branch, but in a few
> weeks hopefully it will appear on the 'next' branch.
Is it possible to get a Windows build?
-- 
Piotr Krukowiecki
Philip Oakley· Apr 24, 2019, 20:16 UTC · re: Piotr Krukowiecki · lore

Re: Checkout file without changing index?

Hi Piotr
On 24/04/2019 19:15, Piotr Krukowiecki wrote:
>> I think the new command is now on the 'pu' branch, but in a few
>> weeks hopefully it will appear on the 'next' branch.
> Is it possible to get a Windows build?

Dscho maintains a relatively recent merge with pu at his https://github.com/git-for-windows/git  shears/pu branch

https://public-inbox.org/git/nycvar.QRO.7.76.6.1904051528130.41@tvgsbejvaqbjf.bet/ ref [1]

Philip
Sitaram Chamarty· Apr 25, 2019, 03:40 UTC · re: Junio C Hamano · lore

Re: Checkout file without changing index?

On 24/04/2019 19.16, Junio C Hamano wrote:
Show 19 quoted lines
> Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:
> 
>> I was familiar with "git checkout revision -- file".
>>
>> But it updates both working tree and index. I had some changes in
>> index (staged) and "git checkout HEAD -- file" silently overwritten
>> it. Well, probably my mistake, it's documented.
> 
> We'd invite you to live on the leading edge and try
> 
>     $ git restore --source=<revision> <pathspec>
> 
> which by default checks things out only to the working tree, but not
> to the index (you say --staged if you want to restore to the index,
> and you say --worktree if you want to restore to the working tree,
> or you can say both, which would be the same as "git checkout").
> 
> I think the new command is now on the 'pu' branch, but in a few
> weeks hopefully it will appear on the 'next' branch.

I'm not in a position to use either of those on at least some of my systems, but meanwhile, I thought I'd ask this: what is the difference between this and "git show REF:PATH > PATH", in terms of side-effects.

(I.e., any differences other than looking cleaner, not having to repeat "PATH" etc.)

thanks sitaram

Junio C Hamano· Apr 25, 2019, 04:02 UTC · re: Sitaram Chamarty · lore

Re: Checkout file without changing index?

Sitaram Chamarty <sitaramc@gmail.com> writes:
Show 6 quoted lines
> I'm not in a position to use either of those on at least some of my
> systems, but meanwhile, I thought I'd ask this: what is the difference
> between this and "git show REF:PATH > PATH", in terms of side-effects.
>
> (I.e., any differences other than looking cleaner, not having to repeat
> "PATH" etc.)
For that matter, what's the difference between these two and
	git cat-file --filters REF:PATH >PATH
;-)

I think the major difference is that checkout and restore are facing an end-user who is typing the command to the terminal interactively, so it does not make it easy to deposit the contents to an arbitrary path while taking pathspecs to allow multiple files to be checked out. On the other hand, these "get content for a single path out of the odb and then write it out to wherever I want to" may be more suited for scripting.

Between the two that are for the-content-at-a-single-path, I would further expect "git show REF:PATH" output would be less reliable over time, as we reserve the right to add frills to the output from the command to make it a more pleasant experience to humans (e.g. it is not totally inconceivable for the command to notice "ah, this is a JavaScript source file, so let's pass it through a syntax-aware highligher), as opposed to placing more emphasis on the byte for byte fidelity, which is desired for components used in scripts. Those who would want the latter should be using the plumbing cat-file.

← back to recent threads