Issue #9191 invalid

directory structure "flattened" upon cloning repository

Hari Jayaram
created an issue

I have been a very happy user of bitbucket git repositories. Just today I ran into a problem with a private repository for a django project.

The source tree on my bitbucket page (attaching screenshot) reflects the correct tree for my django project

                                          001_....all my migrations

Once I clone this repository called "strucinfo.git". The entire tree structure is flattened and messed up.

Upon cloning into my home directory with

"git clone" 

here is what I get

haris-macbook:strucinfo hari$ tree
├── StrucInfo
│   ├──
│   ├── migrations
│   │   ├──
│   │   ├──
│   │   ├──
│   │   ├──
│   │   ├──
│   │   ├──
│   │   ├──
│   │   ├──
│   │   ├──
│   │   ├──
│   │   └──
│   ├──
│   ├── settings
│   │   ├──
│   │   ├──
│   │   └──
│   ├──
│   ├──
│   ├──
│   └──
├── data_migration_scripts
│   ├── NoneCgnumber.txt
│   ├──
│   ├──
│   └──

I can make the repository public or allow access briefly to help troubleshoot. I have never had this problem with other django projects on bitbucket before.

Comments (10)

  1. Erik van Zijst staff

    This sounds more like a support request and so it might be better to email (which will allow us to privately discuss the details).

    However, I had a look at your repository and I don't really see a problem. The structure seems identical to what your tree command displays. I also don't see any flattening, either on our end on your tree output:

    $ git ls-tree -r HEAD
    100644 blob 223d337eba727c5edb4e615b99d92e4cd2d627c7    .gitignore
    100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    StrucInfo/
    100644 blob e0b983463c34480c1af1a8ee89791210f1e685f9    StrucInfo/settings/
    100644 blob 4d24595ce0b46a2dfc7ce0b4483d437d10306747    StrucInfo/settings/
    100644 blob afb16560227898dbdc45ea2bbbf6a923f4191c9c    StrucInfo/settings/
    100644 blob 2774774a10f90cae5af2eb97597d8eef40864197    StrucInfo/
    100644 blob fc46a3d836724f32610921ab15369a14e8e27681    StrucInfo/
    100644 blob 4ff88240e30ed1d07898d27e062eafecb03e99d7    data_migration_scripts/
    100644 blob 726c072c0ac518ef5e3dc0ff4a5e4305b10dea67    data_migration_scripts/NoneCgnumber.txt
    100644 blob b55a5d4fe8320e0b138c4798c9709475693f1e55    data_migration_scripts/
    100644 blob 4b53be7c08b53147084102726b84ca44c27f52f8    data_migration_scripts/
    100644 blob 79ffa20e4d81157fee9a695364e39c9a451c3fc1    data_migration_scripts/
    100644 blob fb468bc7a41844e4c2dc27b11420c976793b7bdb
    100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    strucinfo/
    100644 blob 15d6ccb126262afcb05a3faab6c02a6c8191f646    strucinfo/migrations/
    100644 blob 705ca5beae0232c92f62c34eb6e83f74ac614be6    strucinfo/migrations/
    100644 blob 07094ef354ee3b3d9ae1bdbab7fa71c2bc4d13de    strucinfo/migrations/
    100644 blob 2f3dbf584bcc002e1bb7ede4223177bdbc7f9b3f    strucinfo/migrations/
    100644 blob 3d9d9a386ea6df1a11b0c1cea7716f999c9bde26    strucinfo/migrations/
    100644 blob a1caf87f9a5827e9e5fa8a8f4dac11eb0a2c834f    strucinfo/migrations/
    100644 blob dc2edeb7287cc5fb7952904297371d610da0251c    strucinfo/migrations/
    100644 blob 3307dc2f5a0cfa10c06f8a9c6fd0238c56ae20a4    strucinfo/migrations/
    100644 blob b310eced6a1f8d3da037a5626bd838262ea1ed4c    strucinfo/migrations/
    100644 blob 73f11af9144487c16e38d65aecbc0b80713026f8    strucinfo/migrations/
    100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    strucinfo/migrations/
    100644 blob e3a7bdf3a57395afea4783cd59c916d6c192289d    strucinfo/
    100644 blob 501deb776c16733b19f3509d86e125df78958261    strucinfo/
    100644 blob 60f00ef0ef347811e7b0c0921b7fda097acd9fcc    strucinfo/

    Can you be more specific about which files are in wrong places?

  2. Chris Lasher

    Are you cloning on OS X? If so, the problem likely stems from the fact that the default filesystem on OS X is case-insensitive, and thus treats the two intended subdirectories "StrucInfo" and "strucinfo" as the same directory, and so the contents of the two will be checked out to the same directory on the filesystem. In other words, /path/to/StrucInfo is the same thing as /path/to/strucinfo, as far as your filesystem is concerned.

    Since "strucinfo" (all lowercase) contains a Django app, and "StrucInfo" (camel-case) seems to contain your site files, try renaming, on a case-sensitive filesystem (e.g., a Linux box), the directory "StrucInfo" to "StrucInfoSite", committing the rename, pushing, and then cloning again on your Mac.

    You may alternatively try doing

    git config --global core.ignorecase false

    on your Mac prior to cloning, but I suspect that this won't help because of the case-insensitive filesystem issue.

  3. Erik van Zijst staff

    Ah, well sure. HFS+ is case-aware (preserving case), but not case sensitive and so you cannot have both structinfo and StructInfo in the same directory.

    If you want that, you'll need either be on a properly case-sensitive file system (like any Linux fs), or re-create your HFS+ filesystem and manually setting it to be case-sensitive (HFS+ can be case-sensitive, but by default it is merely case-aware), but that will require a full reinstall of your machine, or you'd have to create a separate volume.

    In either case, I'm afraid there's very little we can do about this. Does that make sense?

  4. Hari Jayaram reporter

    Thanks Chris and Erik...the things you learn after using a Mac for 10 years . I didnt realize that on OSX case-aware and case sensitive had a nuance in Directory naming.

    I was able to clone the repository correctly on Linux-ext4 , so I assumed that the git client on OSX was at fault. After reading Eriks reply , I think when I reinstalled the OS on this Macbook after an SSD upgrade , I must have picked some default which made it only case-aware. My other mac may be both case sensitive and case aware which is why I was stumped and did not come across this anytime before.

    Lesson learned!

    So in Future I will follow the brief from Chris and always pick unique names for my Django projects and "apps" within projects so that such weirdness will not affect my project structure.

  5. Log in to comment