Why is the file checked from another branch already installed?

Question

Regarding the Git workflow, we create a branch from the master, which we use for a particular sprint, and each work item in this sprint branch from it. So the branch / merge stream would be like this:

master | \ | sprint42________ | | \ \ | | item1 item2 | | ___/ / | |/ / | | _________/ | |/ | _____/ |/ | 

Now, in this thread, it turns out that the changes I made to one of the files in item1 should also be done in item2 (think about the utility to which I added a convenient function).

So, in accordance with the accepted answer to this question , I checked the item2 branch and continued to pull out the utilities file from the item1 branch, as follows:

 git checkout item2 git checkout item1 utilities.xyzzy 

However, when checking the git status it seems that this file was placed in the staging area, while I thought it would be more reasonable to consider it as a recently modified file:

 pax> git status On branch item2 Your branch is up-to-date with 'origin/item2'. Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: utilities.xyzzy 

Why was this done? How can I, by pulling a file from another branch into my current branch, get it just a modified file, which I will become ready?

Answer 1

Note: when I read the source line of the topic "Why is file pulled from ..." (now fixed), I thought you were referring to a git pull script. I find it worth mentioning specifically about git checkout here, used in the form: git checkout branch path .

Consulting documentation git checkout , we find this:

git checkout [-p|--patch] [<tree-ish>] [--] ...

When <paths> or --patch , git checkout does not switch branches. It updates named paths in the working tree from the index file or from the name <tree-ish> (most often a commit). In this case, the -b and --track options --track no sense and give either an error or an error. The <tree-ish> argument can be used to specify a specific ish tree (i.e. commit, tag or tree) before updating the index for the specified paths before updating the working tree.

I put the key bit in bold here: git first writes from the given "tree-ish" to the index (unless checked directly from the index), and then copies from the index to the work tree. That is why a new file is being installed. To undo a step, you must use git reset in the same way.

There is a way to get the file in the tree without copying it through the index using git show :

 git show item1:utilities.xyzzy > utilities.xyzzy 

The git show command will correctly print the specified object (in this case, this file) to standard output, and redirecting the output will commit the file. Note, however, that this bypasses any smudge filter that will modify the contents of the file during normal validation.

Answer 2

As I mentioned in git reset vs git reset HEAD "for git checkout <tree-ish> -- <paths> .

 git checkout <tree-ish> -- <pathspec> 

When <paths> set, git check does not switch branches.
It updates the named paths in the working tree from the index file or from the name <tree-ish> (most often this is a commit).

Since the index is directly updated, you get a file that is ready for execution.
Therefore, " Changes to be committed: " git status .