#69 ✓resolved
 Marcus S

GitX suddenly can't open repository

Reported by Marcus S | January 26th, 2009 @ 11:21 PM

I have been using GitX for a few weeks to visualize the commits I have in my repository, and today, all of a sudden, after commiting and a few merges between local branches, GitX complains it cannot open my repository.

It gives me a popup which says: The document "RepoName" could not be opened.

I ran "git fsck --full", and there were only a few unimportant dangling blobs, which I pruned. It still would not work. I downloaded gitnub, and that is able to open my repo fine. Finnally, I clones my repo into another directory, and opened the clone with GitX, and that works without a problem.

Any suggestions as to what may be causing this?

If the problem is not obvious, what are the risks to must moving on with the clone? Would any data be lost?

Comments and changes to this ticket

  • Johannes Gilger

    Johannes Gilger January 27th, 2009 @ 01:47 AM

    Hi,

    first of all, if it is possible it would be nice if the GitX developers could have a look at that strange repo.

    As for cloning: Cloning is safe as long as you know that unreachable objects don't get cloned as well (just because you deleted all the branches that point to a commit doesnt mean it is unreachable, check git reflog expire).

  •  Marcus S

    Marcus S January 27th, 2009 @ 02:25 AM

    I will gladly submit the repository to the developers, but I'd rather not make it public.

    What is the best way to compress it/package it without losing the relevant information?

  • Johannes Gilger

    Johannes Gilger January 27th, 2009 @ 09:18 AM

    The easiest way would be to tarball the whole directory and mail the tarball. In OS X you can do it from command-line like this: tar czf broken_repo.tar.gz <your-repo-dir> Where <your-repo-dir> is your broken repo (not just the .git dir but the whole worktree). If the resulting tarball isn't to big (ls -lh) you can submit it via email to Pieter and if you want CC me (frimATfrim.nl and heipeiAThackvalue.de).

  •  Marcus S

    Marcus S January 27th, 2009 @ 05:29 PM

    In the process of getting the repo ready to send to you, I removed a directory with data files (they numerical simulation outputs, and thus very large), and checked whether the problem with GitX still existed, and sure enough it was gone. If I moved the data files back in, however, the problem returned.

    These amount to many megabytes of data, spread across a dozen directories or so, so packaging the whole thing and sendingit over seems a bit excessive. However, this data directory (which is a subdirectory of the source directory) seems to be the culprit. I am not sure if it is the shear size of these files, or if it is the file names that are causing some sort of the problem.

    If I move the data directory to another repository, that repository becomes unopenable with GitX -- mind you, the data files are in the .gitignore list.

    The data files have names based on the date of the simulation.

    For example, this is the directory listing in the data directory (src/data):

    $ ls 2009-01-23-1615 2009-01-25-1559 2009-01-26-1227 2009-01-26-1257 2009-01-26-1536 2009-01-26-1612 2009-01-25-1544 2009-01-26-1108 2009-01-26-1244 2009-01-26-1423 2009-01-26-1552

    and for each of these directories, I have a different file for each simulation run (these are stochastic simulations), and the files names are

    run-1.output run-2.output ... avg.out

    Does this give an indication of what the problem may be?

  • Pieter de Bie

    Pieter de Bie January 27th, 2009 @ 05:33 PM

    Are you ignoring these files in Git? If not, GitX may stumble on the amount of files. Size of files shouldn't really matter.

    Can you try removing all but a few of the files, does the problem then still stay? If you empty the files, does the problem go away? If it doesn't, can you email the output of 'find .'? How many files are we talking about anyway?

    Oh, btw, I'd prefer GitX email to arrive at frimmirf+gitx@gmail.com

  •  Marcus S

    Marcus S January 27th, 2009 @ 05:45 PM

    I was not ignoring the data files in git originally, but I am now. However, even after I added them to .gitignore, the problem did not go away (although I did not restart GitX, which I am not sure if it is necessary).

    As for the number of files, each simulation has 1000 runs right now, so that makes it 1001 files for each of those dated directories. Total, that makes it about 11k files.

    If I remove the files, the problem goes away. If I remove some of the files, the problem goes away as well (before, when I did not have so many simulations, the problem never appeared).

    I am now trying to introduce the different simulation directories one at a time to see if it still breaks (after having restarted GitX after updateing .gitignore), and I will update you with what I find.

  •  Marcus S

    Marcus S January 27th, 2009 @ 06:03 PM

    I reintroduced the directories one by one, and tried opening the repo on GitX after each reintroduction, and everything worked.

    I supposed GitX needed a restart after modifying .gitignore. Thanks for the feedback! I greatly appreciate it!

    Would it be possible to have GitX display an error message, which indicates why it is not able to open the repository? ("Error: too many files" or something like that).

    Also, I did not run into any problem with git itself, and gitnub was also able to open repo before when the data files were not in .gitignore, so why does GitX run into this difficulty?

  • Jason Adams

    Jason Adams January 27th, 2009 @ 10:43 PM

    I had the exact same problem. An already ignored log file had gotten to be 1.5 GB in size. Removing it allowed GitX to open the repo again.

  • john

    john March 3rd, 2009 @ 02:24 AM

    • Assigned user cleared.

    Same problem - glad this discussion was already up though! Allowed me to solve it quickly by ignoring/re/moving the offending files.

  • Sharebear

    Sharebear March 5th, 2009 @ 12:50 PM

    Hmmmm, maybe this is the same as my problem in http://gitx.lighthouseapp.com/pr...

    find . | wc -l tells me there are almost 44000 files and du -h tells me they total 1.1G unfortunately I don't think I have the luxury of deleting anything.

    What are the limits of GitX at the moment?

  • golgote

    golgote March 23rd, 2009 @ 08:31 AM

    When I cannot open my repository in GitX, I do: sudo chmod -R 755 and it can open it again. So I guess there might be problems with GitX and file permissions. FYI, the other Git GUI works fine, even without the chmod.

    I can have files written in a /logs and a /tmp directories in my repository directory which I have added to the exclude list. They store files generated by the web server and that cannot be read by other users than www.

  • Sharebear

    Sharebear March 23rd, 2009 @ 09:37 AM

    I can confirm that chmod -R 755 works for me too, although I'm not really willing to commit a filemode change to 10000 files just so that my tools work correctly.

  • Sharebear

    Sharebear March 23rd, 2009 @ 11:16 AM

    Looks like it's enough to just chmod the directories therefore nothing needs to change in the repo.

    $ find . -type d -exec chmod 755 {} \;

    Anyone got an explanation for why this might be an issue? Surely if the git binary itself has enough permissions to see the files then GitX should as well.

  • Benoit Cerrina

    Benoit Cerrina June 20th, 2009 @ 04:52 PM

    • Assigned user set to “Pieter de Bie”

    I think it may be a dup of
    http://gitx.lighthouseapp.com/projects/17830/tickets/154-unable-to-...
    which is a problem with large directories

  • Pieter de Bie

    Pieter de Bie June 20th, 2009 @ 09:54 PM

    • State changed from “new” to “resolved”

    Yes, I think using the URL instead of FileWrapper is a good change anyway, so let's try that and see what happens.

    Marcus: if the same thing still happens after 0.7 is released, please reopen this bug.

  • April Russell

    April Russell February 18th, 2018 @ 07:50 PM

    My guess is that something is wrong in the path (de)serializer. Unfortunately I didn't create that code. It's not very high on my priority list (as you may have seen there's a HUGE number of open tickets :( ), but I'll keep this open for when I encouter it again. juegos friv gratis online

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

GitX is the nice-looking gitk clone for OS X

Tags

Referenced by

Pages