I fully agree with @torek's comment, the easiest way to deal with conflicts between files that are untracked in your sandbox but exist in a branch is to try the merge or the checkout, and deal with the problem if a problem is reported. Git produces excellent error messages, read them carefully and use them well!
That being said, it's not that hard to script the query you are asking about.
Step 1 - list all the untracked files
git status
will give you a list of untracked files, although not in a script friendly output. However, with --porcelain
, you can get output that can be reliably used for scripting:
git status --porcelain --ignored | grep '^??' | sed 's/^.. //'
will list the names of untracked files. Caveat: untracked files located in untracked directories don't actually get listed, this is a bit of a problem with my solution.
@torek suggests a better command, git ls-files --other
, but as far as I can tell, it only lists untracked files under the current directory. But if you know you're working from the root of the sandbox, then this will be better:
git ls-files --other
Step 2 - list all the files in your target branch
git ls-tree --full-tree --name-only -r <branch> | cut -f2
will list all the files in <branch>
.
Step 3 - Use grep to compare
If the lists produced in steps 1 and 2 have any overlap, you have a conflict between an local untracked file and a tracked file in <branch>
.
You can use grep
to find that overlap:
git ls-tree --full-tree --name-only -r <branch> | grep -F -x -f <(git status --porcelain --ignored | grep '^??' | sed 's/^.. //')
Better yet, if run from the root of the sandbox:
git ls-tree --full-tree --name-only -r <branch> | grep -F -x -f <(git ls-files --other)
Caveats
If somedir/somefile
exists in <branch>
but no file in somedir/
is tracked in your current branch, my git ls-tree
will show somedir/somefile
, while my git status
will just show somedir/
, so that conflict won't get found by my command. @torek's git ls-files --other
fixes that, as long as you're working from the root of the sandbox.
Any other corner case I didn't think of could cause problems too.
So, after all this, I go back to @torek's original recommendation: I don't think you should use this. But I found it informative to try to solve it, and I hope you find my write up informative too.
Edit
Following @torek's feedback, I added the git ls-files --other
variant.