This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I have a git repository checked out on my machine and submodules updated and inited therein. NetBeans shows appropriate information for files in the master module, but indicates that all files in submodules have been newly added. git status shows no changes, however, and a clean status. It would be great for NetBeans to provide a front-end to submodule update/init, but that's secondary. What I really need is for NetBeans to (1) show proper status for submodule files and (2) properly handle commits/pushes in this case. I don't even know if #2 is an issue yet -- as #1 is really not only my immediate, but also by far my top concern. Lack of at least passable submodule support in NetBeans 7.1 would be an enormous gap.
True, git submodules are not supported. Some basic info about submodules can be found at: http://book.git-scm.com/5_submodules.html
The documentation should explicitly state that NetBeans does not support submodules if it is going to leave this out -- as this is a huge omission! Can we please expedite NetBeans showing proper diffs/histories/change-bars for files in submodules? Addressing that piece of this gap would help hugely. If not, I guess I'll just have to disable NetBeans' git support -- as it is currently worse than useless for those using submodules, since it provides consistently incorrect information.
bug #207073 marked as fixed, file statuses should now be correctly determined.
I note: > bug #207073 marked as fixed, file statuses should now be correctly determined. Does this mean that for file in submodules NetBeans will: 1) show appropriate file statuses (added, modified, or unchanged), 2) show appropriate Git history, or 3) show appropriate demarcations in the editor to uncommitted changes, or some combination of these?? If it does not do all of these correctly for files in submodules, then I believe this should be P2, not P3 -- this is a critical gap! If it does all of these, then I'd agree that having git submodule update --init, git submodule foreach, etc, functionality is a lower priority. P3 is fine for that. As it is now, however, I don't know what remains unaddressed.
Also if bug #207073 addresses some of all of these issues, when will the fix be available from an update center? [NetBeans has nice update center capabilities, but updates from normal update center sites seem to be rather slow an infrequent...]
> Does this mean that for file in submodules NetBeans will: > 1) show appropriate file statuses (added, modified, or unchanged), > 2) show appropriate Git history, or > 3) show appropriate demarcations in the editor to uncommitted changes, > or some combination of these?? Yes, i believe all those work correctly with 207073 being fixed. But it's up to you to test it in development builds and report any results back. If you find additional problems, i will fix them. > As it is now, however, I don't know what remains unaddressed. Neither do i, i tried to fix everything i could, but maybe i missed something. Again, it would be great if you tested it in http://bits.netbeans.org/download/trunk/nightly/latest/ > Also if bug #207073 addresses some of all of these issues, when will the fix be available from an update center? It's scheduled for 7.2, so it will be part of 7.2 release. We could add it to the upcoming 7.1.1 patch release, but you would have to test my fix.
I'll give the latest nightly a whirl and see how it goes.
Build 201202060400 showed no signs of improvement. All files within submodules were still considered newly added in the project tree. In the editor such files show a single change bar adding all contents of the file. Clicking on the history button for such a file results in an indefinite "Loading, please wait..." Of course command-line "git xxx" commands from the directory containing the file simply give the correct results, so something is clearly amiss under the covers here. I don't care which bug is left open and given P2 or high priority, but some bug should be as the Git module currently fails to do the following for files in submodules: 1) show proper status for files in the projects/files trees, 2) show proper change bars on files in the editor, and 3) show proper history for the history button for a file. Those are the bare minimum required understanding/handling of submodules from a Git module. Without those the Git module is worse than useless to us -- worse than useless in that folk waste time with it and get confused by its behavior. Having equivalents of "git submodule update --init", etc, is a P3 enhancement, though -- that can be approached *much* later as far as I'm concerned.
I tried to setup a git repo with a single submodule, fixed issue for that case. I suppose there is more in your setup i'm probably missing. A git submodule has its own .git folder, right? So the final setup should look as followed? local repository | +- .git folder +- repo sources +- submodule folder +- .git folder Right? I tried on this scenario and the files from the submodule were correctly recognized as being from the submodule and with correct status. Were there already both .git folders when you started the IDE? I mean, you might have created (or cloned) the submodule while already being in the IDE. Did you try to restart the IDE? I would like you to prepare a test case project i can test this for. So please create a dummy repository with a submodule and attach it here.
I have never seen a git submodule look like: local repository | +- .git folder +- repo sources +- submodule folder +- .git folder on Windows. It may look like that on Linux/UNIX variants, though I'd *guess* the .git folder is actually a symbolic link to the folder in that case. On Windows, a git submodule looks like: local repository | +- .git folder +- repo sources +- submodule folder +- .git *FILE* The .git file contains a single line: gitdir: d:/git-repos/myRepo/.git/modules/PATH/OF/SUBMODULE On Linux/UNIX variants the submodule's .git may well be a symbolic link to a directory in .git/modules rather than a weird file pointing to it, but on Windows it's this weird gitdir: file.
Created attachment 115527 [details] sample submodule repository (In reply to comment #10) > On Linux/UNIX variants the submodule's .git may well be a symbolic link to a > directory in .git/modules rather than a weird file pointing to it, but on > Windows it's this weird gitdir: file. No, it is not a symbolic link on Linux and on Windows it is also a normal folder. See the attachment... What i did: i setup a submodule repository at submodule, a parent repository at module. I added the submodule via: git submodule add path_to_submodule_repo (C:\LocalRepo\git\submodules\submodule) in my case git commit -m "Adding submodule" in the parent repo git clone module module_clone cd module_clone git submodule init git submodule update and the submodule was cloned and the result is in module_clone/submodule - you can see the .git folder is a normal folder It would really help if you could setup the same and send me your test repo. Thanks
See http://linux.die.net/man/5/gitrepository-layout. It notes that: It is also possible to have a working tree where .git is a plain ascii file containing gitdir: <path>, i.e. the path to the real git repository. Why Git is choosing to do this automatically for submodules on my machine is unclear, but it does so consistently of its own volition. I am apparently not the only one seeing this either. See http://stackoverflow.com/questions/8435738/git-folders-appearing-as-git-file. I did nearly what you did below (actually another developer set up the repo on a Linux box and I cloned it to my Windows box as that's my normal usage pattern here). I'll attach that.
Note that the original test repo (on Linux) had a .git *directory* in the submodule -- and cloning it to another Linux box gave the same result.
Created attachment 115534 [details] similar git repo on Windows 7 showing master and sub module layout
(In reply to comment #14) I am sorry, what can i say? We simply do not support external repository gitfolder. It always has to reside in the repository's work tree root. And it is not specific only to submodules, any repository with such a setup will fail in NetBeans. You can try to move the gitfolder back to the submodule's root (.git folder)
Manually working around a failure on the part of NetBeans' Git plug-in to recognize what is clearly a perfectly valid Git module layout is not a solution. Note that we have 100's of submodules. All of these are automatically created with a .git file in my case. This is not behavior I chose -- this is the way Git is behaving automatically in my case without any configuration on my part to this effect. As seen in the links sited, I'm not the only one who is seeing this behavior. Failing to handle this module layout isn't really an option from a Git plug-in!
Note that handling the .git file case can't be that hard. You still look for a .git File, it's just that if you find that it's a normal file rather than a directory that you open it, and read the actual directory location. That should be a rather small snippet of code to add.
*** Bug 208332 has been marked as a duplicate of this bug. ***
As I'm experiencing the same problem, I took a little time to see why some users have .git folders while others only have a .git file in a submodule. As the release notes for git say, this behaviour was changed in git 1.7.8 (see http://code.google.com/p/git-core/source/browse/Documentation/RelNotes/1.7.8.txt and search for 'submodule').
(In reply to comment #19) > As I'm experiencing the same problem, I took a little time to see why some > users have .git folders while others only have a .git file in a submodule. As > the release notes for git say, this behaviour was changed in git 1.7.8 (see > http://code.google.com/p/git-core/source/browse/Documentation/RelNotes/1.7.8.txt > and search for 'submodule'). So according to that link the change is: > When populating a new submodule directory with "git submodule init", > the $GIT_DIR metainformation directory for submodules is created inside > $GIT_DIR/modules/<name>/ directory of the superproject and referenced > via the gitfile mechanism. This is to make it possible to switch > between commits in the superproject that has and does not have the > submodule in the tree without re-cloning. So according to this note, this is how submodules should always be created in git 1.7.8. Unless this behavior has changed since, this means it is doubly critical for NetBeans to support this configuration.
The resolution of bug 209839 made a huge difference in NetBeans' Git usability. I now see proper history, in-editor change bars, and status for files managed by Git submodules. I do notice that many things beyond this seems not to function as expected, though. For instance, I modified a file and Git and NetBeans agreed on that. I tried to revert the changes via both Revert and Checkout in NetBeans -- neither worked. The command line worked great, though. I'm happy using the command-line a fair amount, but I note that the critically important "explore from here" plug-in (http://plugins.netbeans.org/plugin/15619/explore-from-here) does not work in 7.2 right now. This makes hopping out to use the command line where needed a real pain.
Actually it's now clear that Explore from Here is only half-broken in 7.2. It works for folders but not individual files.
*** Bug 226959 has been marked as a duplicate of this bug. ***
*** Bug 231605 has been marked as a duplicate of this bug. ***
Integrated into 'main-silver', will be available in build *201310240001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/8532fad64f0f User: Ondrej Vrabec <ovrabec@netbeans.org> Log: #207067 - NetBeans does not appear to understand git submodules - better handling of submodules. IDE recognizes commits in submodules and marks the submodule's folder as modified, allowing users to commit changes in the parent repository
marking as fixed. IDE should now correctly show changes in submodules and allow you to commit them. I intent to implement bug #237621, please file any other requests and problems as separate issues.