Re: [git-users] Updating a staged file makes it dissappear

[Konstantin Khomoutov]

On Thu, 23 Mar 2017 16:31:40 -0700 (PDT)
Igor Djordjevic  wrote:

[...]
> I am still new to Git myself, but as far as I know, one doesn`t
> usually checkout a single file from a remote branch in order to work
> on it - instead, you should either create a local branch out of the
> remote branch (if you don`t have it already), or just fetch/merge
> with your local branch (to update it if you already have it). Then
> you can work on the file as it is, in your local branch, being a part
> of the original commit and following the original history, eventually
> making a commit on the local branch and doing a push to update the
> remote branch with your changes.

Checking out individual file or files into the working tree from a
commit different from HEAD is perfectly legal for situations like
answering a question "whether the (currently buggy) state of the project
will be fixed if we compile it with such and such files taken from that
(known to be good) revision?".

Of course it means you'll revert the contents of these files back to
HEAD afterwards.  Or keep just the changes which had apparently fixed
the problem (by, say, running
`git checkout --patch HEAD -- path/to/file` on each of them to get rid
of unwanted changes) etc.

It's even OK to actually _use_ the contents of those files from another
revision (after properly `git add`-ing these changes and committing
them): after all, it does not matter how exactly particular changes
ended up in the files ;-)

I think it all boils down to having proper mental model of how Git
maintains the history, what's in a commit, what a branch is and so on.
This can only be gained through self-education and practice.

Having said that, I'd note that you're absolutely correct in

> one doesn`t usually checkout a single file from a remote branch in
> order to work on it - instead, you should either create a local
> branch out of the remote branch (if you don`t have it already), or
> just fetch/merge with your local branch (to update it if you already
> have it).

This highlights a crucial thing to understand about the model pervasive
through all Git does: it does not consider individual files to be of any
importance and always deals with the state of the whole project being
managed.  For instance, it's impossible to "commit a single file".
Even though there's a shortcut for this -- `git commit ` --
it's just a handy way to do the sequence

  1) Save the index away.
  2) Make it look as HEAD.
  3) `git add` the indicated file(s).
  4) `git commit` the resulting state of the index.
  5) Restore the index back.
  6) Update it with what was `git add`-ed on step (3).

…and thus a "normal" commit, snapshotting the whole project, is
recorded.  In the same venue, it's impossible to push a single file or
fetch a single file's changes, and so on.

Hope this will help the OP to get their Git mental model right ;-)

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Updating a staged file makes it dissappear

[Igor Djordjevic]

Hi AD S,

On Wednesday, March 22, 2017 at 4:22:22 AM UTC+1, AD S wrote:
>
>
> On Tuesday, March 21, 2017 at 4:53:51 PM UTC+10, Gergely Polonkai wrote:
>>
>> Could you show us how you ran checkout? It’s strange to me it staged your 
>> file.
>>
>> If you have a file in the index and adding modifications makes the file 
>> disappear, that means the changes added later negates the changes in the 
>> index.
>>
>> Try it: add a line to an unmodified file, add to the index. Now remove 
>> the file and add again. The index is now empty. This is Git’s way to 
>> prevent you making empty commits.
>>
>> If I were you, I would do the checkout again, and check the contents of 
>> the index with git diff --cached. That may give you a hint on what’s going 
>> on.
>>
>> Gergely
>>
>> On Tue, Mar 21, 2017, 05:07 AD S  wrote:
>>
>>> I made a mistake in the code on a file on a remote repo and so used 
>>> `checkout` to bring it into my branch to fix it. Running `git status` 
>>> immediately after, I see the file is modified and staged.
>>>
>>> I then make my changes to fix the code and run `git status` again and 
>>> see 2 'versions' of the same file - one staged and one not. Makes sense, 
>>> all I got to do is `git add` the unstaged one and it will update the one in 
>>> stage.
>>>
>>> I do this and `git status` again but now stage is now empty. I get the 
>>> message `nothing to commit (working directory clean)`.
>>>
>>> To experiment, I run through the commit, push, merge process and check 
>>> the remote repo, but, of course, the buggy code is still there.
>>>
>>> Would anyone know what's going on here?
>>>
>>
> It's ok, I think I know why this happened, though there are still some 
> questions.
>
> The issue was that I had already fixed the code on my branch sometime 
> earlier, so when I checked-out the file and fixed it again Git could not 
> see any difference between the code held on my branch and the file I had 
> just fixed, so it saw there was no changes and thus nothing to commit.
>
> That's fine.
>

That may not be fine -- I`d say it`s a bit unusual that you "already had 
fixed code on your branch" but not in the working directory (thus you had 
to "fix it again"). But this can probably be explained by your original 
e-mail, saying that you actually checked-out _a file_ from a different 
branch (replacing your existing _and fixed_ file)...? While this may be 
justified, you should really know what you`re doing, and what you may 
expect in return -- as previously discussed in *your other topic* 
.
 

> However, the question now is: if my branch was already up-to-date with the 
> fixed code, why was I not able to merge it with the remote repo that still 
> had the buggy code? When I tried to merge it seemed to work seamlessly - no 
> error messages or conflicts.
>

This may be explained by your checking-out a file from a different branch 
as well, where you can eventually end up with a merge that does not really 
do what you wanted -- and the error in that case is probably on your end, 
might be in your work flow.

I am still new to Git myself, but as far as I know, one doesn`t usually 
checkout a single file from a remote branch in order to work on it - 
instead, you should either create a local branch out of the remote branch 
(if you don`t have it already), or just fetch/merge with your local branch 
(to update it if you already have it). Then you can work on the file as it 
is, in your local branch, being a part of the original commit and following 
the original history, eventually making a commit on the local branch and 
doing a push to update the remote branch with your changes.

Regards,
Buga

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Updating a staged file makes it dissappear

[AD S]

On Tuesday, March 21, 2017 at 4:53:51 PM UTC+10, Gergely Polonkai wrote:
>
> Could you show us how you ran checkout? It’s strange to me it staged your 
> file.
>
> If you have a file in the index and adding modifications makes the file 
> disappear, that means the changes added later negates the changes in the 
> index.
>
> Try it: add a line to an unmodified file, add to the index. Now remove the 
> file and add again. The index is now empty. This is Git’s way to prevent 
> you making empty commits.
>
> If I were you, I would do the checkout again, and check the contents of 
> the index with git diff --cached. That may give you a hint on what’s going 
> on.
>
> Gergely
>
> On Tue, Mar 21, 2017, 05:07 AD S > 
> wrote:
>
>> I made a mistake in the code on a file on a remote repo and so used 
>> `checkout` to bring it into my branch to fix it. Running `git status` 
>> immediately after, I see the file is modified and staged.
>>
>> I then make my changes to fix the code and run `git status` again and see 
>> 2 'versions' of the same file - one staged and one not. Makes sense, all I 
>> got to do is `git add` the unstaged one and it will update the one in stage.
>>
>> I do this and `git status` again but now stage is now empty. I get the 
>> message `nothing to commit (working directory clean)`.
>>
>> To experiment, I run through the commit, push, merge process and check 
>> the remote repo, but, of course, the buggy code is still there.
>>
>> Would anyone know what's going on here?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Git for human beings" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to git-users+...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

It's ok, I think I know why this happened, though there are still some 
questions.

The issue was that I had already fixed the code on my branch sometime 
earlier, so when I checked-out the file and fixed it again Git could not 
see any difference between the code held on my branch and the file I had 
just fixed, so it saw there was no changes and thus nothing to commit.

That's fine. However, the question now is: if my branch was already 
up-to-date with the fixed code, why was I not able to merge it with the 
remote repo that still had the buggy code? When I tried to merge it seemed 
to work seamlessly - no error messages or conflicts.

 

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Updating a staged file makes it dissappear

[Gergely Polonkai]

Could you show us how you ran checkout? It’s strange to me it staged your
file.

If you have a file in the index and adding modifications makes the file
disappear, that means the changes added later negates the changes in the
index.

Try it: add a line to an unmodified file, add to the index. Now remove the
file and add again. The index is now empty. This is Git’s way to prevent
you making empty commits.

If I were you, I would do the checkout again, and check the contents of the
index with git diff --cached. That may give you a hint on what’s going on.

Gergely

On Tue, Mar 21, 2017, 05:07 AD S  wrote:

> I made a mistake in the code on a file on a remote repo and so used
> `checkout` to bring it into my branch to fix it. Running `git status`
> immediately after, I see the file is modified and staged.
>
> I then make my changes to fix the code and run `git status` again and see
> 2 'versions' of the same file - one staged and one not. Makes sense, all I
> got to do is `git add` the unstaged one and it will update the one in stage.
>
> I do this and `git status` again but now stage is now empty. I get the
> message `nothing to commit (working directory clean)`.
>
> To experiment, I run through the commit, push, merge process and check the
> remote repo, but, of course, the buggy code is still there.
>
> Would anyone know what's going on here?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Git for human beings" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to git-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Updating a staged file makes it dissappear

[AD S]

I made a mistake in the code on a file on a remote repo and so used 
`checkout` to bring it into my branch to fix it. Running `git status` 
immediately after, I see the file is modified and staged.

I then make my changes to fix the code and run `git status` again and see 2 
'versions' of the same file - one staged and one not. Makes sense, all I 
got to do is `git add` the unstaged one and it will update the one in stage.

I do this and `git status` again but now stage is now empty. I get the 
message `nothing to commit (working directory clean)`.

To experiment, I run through the commit, push, merge process and check the 
remote repo, but, of course, the buggy code is still there.

Would anyone know what's going on here?

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.