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 <[email protected]> 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* <https://groups.google.com/d/msg/git-users/YfgaEuXJdvk/T09bHZpwAwAJ>. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
