3

I usually commit to a project from a macOS, and I didn't notice that leading and trailing space were embedded accidentally in folder names, but lately I tried to clone the repo from Windows, I get this error:

fatal: cannot create directory at 'FolderName /SubFolderName'
warning: Clone succeeded, but checkout failed.

Is there a way to checkout successfully from windows without modifying from the mac? What to do to prevent Leading and trailing spaces that cause checkout failure in Windows? Is there a way to force Finder to highlight all leading or trailing spaces in macOS ?, or even better: reject them for compatibility purposes?

Mohamed El-Nakeep
  • 6,580
  • 4
  • 35
  • 39
  • 2
    Is `FolderName` the repository dir, you've checked the repo into? To reject such things on OSX in the future, you can simply write a pre-commit hook, that checks the commit content (or only the directories) for spaces. – jhoepken Aug 29 '17 at 07:32
  • @Jens, No, it is not the repository directory, in fact it is multiple child directories that have leading spaces or trailing spaces or both. As you suggest, writing pre-commit hook would be the best solution, that does something as: https://stackoverflow.com/a/46035672/2008463 – Mohamed El-Nakeep Sep 04 '17 at 11:11

3 Answers3

5

Easiest would be to rename them in MacOS. But you can fix it in windows as well, using low-level commands:

  • Use sparse checkout to skip the broken path from checkout
  • Find out the dir's tree hash: git ls-tree HEAD:<parent dir> or git ls-tree HEAD if the directory is in toplevel, it would print something like "040000 tree df2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078 invalid_dir"
  • Add the tree as new name: git update-index --add --cacheinfo 040000,df2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078,valid_dir
  • Remove the older directory: git rm -r --cached 'invalid_dir '
  • Commit the rename: git commit -m 'Rename invalid direct'
  • Update worktree to checkout the valid directory: git reset --hard (NOTE: I assume you have not any work done yet in this instance, so there is nothing to lose)
max630
  • 8,762
  • 3
  • 30
  • 55
  • Thank you for answer. Wow, that is more complicated than I expected. You are right, changing the files from renaming the files from mac would me much easier. – Mohamed El-Nakeep Sep 04 '17 at 11:12
0

As a slight improvement on the previous answer.

Precondition: You have a git repository where the clone succeed and the checkout failed. The working directory is partly populated, you haven't yet done any work in it.

  1. If you already know a specific file or directory you need to fix, skip this step. Use git reset --hard or git restore -s@ -SW -- <some sub folder>. The former tries to fix your partly populated work directory and will fail once it encounters the first invalid file or directory. If the reset succeeds, proceed to step 7. If the git reset command takes a long time, you can instead use the git restore command on sub directories, fixing one after the other. It also lists invalid files, but doesn't abort on the first one.
  2. Find out its tree hash: git ls-tree HEAD:<parent dir>. Output should contain something along the lines of 040000 tree df2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078 <invalid name>
  3. Add the tree under a new name: git update-index --add --cacheinfo 040000,df2b8fc99e1c1d4dbc0a854d9f72157f1d6ea078,<new valid name>
  4. Remove the older directory: git rm -r --cached '<old invalid name>'
  5. Commit the rename: git commit -m 'Fixed filenames.'
  6. Go back to step 1.
  7. Optional: Squash all those commits into a single one. If it took you 5 commits: git reset --soft HEAD~5 and git commit -m "Fixed filenames."
Nobody
  • 192
  • 3
  • 12
0

On MacOS, before Git 2.31 (Q1 2021), a git restore (new checkout) after a clone could fail:
When commands are started from a subdirectory, they may have to compare the path to the subdirectory (called prefix and found out from $(pwd)) with the tracked paths.
On macOS, $(pwd) and readdir() yield decomposed path, while the tracked paths are usually normalized to the precomposed form, causing mismatch.
This has been fixed by taking the same approach used to normalize the command line arguments.

See commit 5c32750 (03 Feb 2021) by Torsten Bögershausen (tboegi).
(Merged by Junio C Hamano -- gitster -- in commit 8b25dee, 12 Feb 2021)

MacOS: precompose_argv_prefix()

Reported-by: Daniel Troger
Helped-By: Philippe Blain
Signed-off-by: Torsten Bögershausen

The following sequence leads to a "BUG" assertion running under MacOS:

DIR=git-test-restore-p
Adiarnfd=$(printf 'A\314\210')
DIRNAME=xx${Adiarnfd}yy
mkdir $DIR &&
cd $DIR &&
git init &&
mkdir $DIRNAME &&
cd $DIRNAME &&
echo "Initial" >file &&
git add file &&
echo "One more line" >>file &&
echo y | git restore -p .

Initialized empty Git repository in `/tmp/git-test-restore-p/.git/` 
BUG: [`pathspec.c`](https://github.com/git/git/blob/5c327502dbf7a27c8784c20037851206a87857c1/pathspec.c):495: 
error initializing `pathspec_item` 
Cannot close git diff-index --cached --numstat
[snip]

The command git restore(man) is run from a directory inside a Git repo.
Git needs to split the $CWD into 2 parts: The path to the repo and "the rest", if any.
"The rest" becomes a "prefix" later used inside the pathspec code.

As an example, "/path/to/repo/dir-inside-repå" would determine "/path/to/repo" as the root of the repo, the place where the configuration file .git/config is found.

The rest becomes the prefix ("dir-inside-repå"), from where the pathspec machinery expands the ".", more about this later.
If there is a decomposed form, (making the decomposing visible like this), "dir-inside-rep°a" doesn't match "dir-inside-repå".

Git commands need to:

  • (a) read the configuration variable "core.precomposeunicode"
  • (b) precocompose argv[]
  • (c) precompose the prefix, if there was any

The first commit, 76759c7 (git on Mac OS and precomposed unicode, 2012-07-08, Git v1.7.12-rc0 -- merge listed in batch #6) git on Mac OS and precomposed unicode addressed (a) and (b).

The call to precompose_argv() was added into parse-options.c, because that seemed to be a good place when the patch was written.

Commands that don't use parse-options need to do (a) and (b) themselves.

The commands diff-files, diff-index, diff-tree and diff learned (a) and (b) in commit 90a78b8 (diff: run arguments through precompose_argv, 2016-05-13, Git v2.9.0-rc0 -- merge) "diff: run arguments through precompose_argv"

Branch names (or refs in general) using decomposed code points resulting in decomposed file names had been fixed in commit 8e712ef (Honor core.precomposeUnicode in more places, 2019-04-25, Git v2.22.0-rc1 -- merge) "Honor core.precomposeUnicode in more places"

The bug report from above shows 2 things:

  • more commands need to handle precomposed unicode
  • (c) should be implemented for all commands using pathspecs

Solution: precompose_argv() now handles the prefix (if needed), and is renamed into precompose_argv_prefix().

Inside this function the config variable core.precomposeunicode is read into the global variable precomposed_unicode, as before.
This reading is skipped if precomposed_unicode had been read before.

The original patch for preocomposed unicode, 76759c7, placed precompose_argv() into parse-options.c

Now add it into git.c::run_builtin() as well.
Existing precompose calls in diff-files.c and others may become redundant, and if we audit the callflows that reach these places to make sure that they can never be reached without going through the new call added to run_builtin(), we might be able to remove these existing ones.

But in this commit, we do not bother to do so and leave these precompose callsites as they are.
Because precompose() is idempotent and can be called on an already precomposed string safely, this is safer than removing existing calls without fully vetting the callflows.

There is certainly room for cleanups - this change intends to be a bug fix.
Cleanups needs more tests in e.g. t/t3910-mac-os-precompose.sh, and should be done in future commits.

Cf. git-bugreport-2021-01-06-1209.txt (git can't deal with special characters)

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250