On Thu, 23 Mar 2017 16:31:40 -0700 (PDT) Igor Djordjevic <igor.d.djordje...@gmail.com> 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 <file ...>` -- 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.
