Hi all,
I'm seeing behavior that I *think* might be a bug in git (I'm running 2.2.2). At least I couldn't find anything about this anywhere, so here goes:
I'm trying to run git commands outside of the current working copy (e.g. inside another repo) from a pre-commit hook. However I'm encountering a very weird issue that occurs when a pathspec is provided when performing a commit.
More precisely, what I'm trying to do is check whether a repository beside the current repository is clean (no uncommitted changes) or not, from a pre-commit hook.
My repositories look like this on disk:
ContainerDirectory
|-- Repo1 (contains one untracked file)
|-- Repo2 (no uncommitted changes)
Repo1 has the following pre-commit hook:
#!/bin/bash
git -C "../Repo2" status --porcelain
I then commit in Repo1 using the following (this is actually ran by a GUI, I have no control over the commands themselves):
git add --force -- MyNewFile
git commit -m "My message" -o -- MyNewFile
This results in some very puzzling output. I would expect the hook to output nothing because Repo2 contains no changes. However, it returns the following:
D Repo2-File1.txt
D Repo2-File2.txt
D Repo2-File3.txt
?? Repo2-File1.txt
?? Repo2-File2.txt
?? Repo2-File3.txt
As you can see, the files are listed as both deleted and untracked, which makes no sense to me because there are in fact no uncommitted changes in that repo. There are only these three files in the repo. Removing the pathspec ("-- MyNewFile") from the commit command shows the expected output (nothing, because there are no changes in Repo2).
I have reproduced this behavior on OS X and Windows (with the latest git for Windows).
Can you explain what's going on?
Thanks in advance for any info!
Michaël Fortin
www.irradiated.net
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html