Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!

Bug 207067

Summary: NetBeans does not appear to understand git submodules
Product: versioncontrol Reporter: jessholle <jessholle>
Component: GitAssignee: Ondrej Vrabec <ovrabec>
Status: RESOLVED FIXED QA Contact: issues <issues.netbeans.org>
Priority: P3 CC: ain, git, markiewb, naitsirch, tmysik
Version: 7.1   
Target Milestone: 8.0   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Issue Type: ENHANCEMENT Exception Report:
Bug Depends on: 207073, 209839    
Bug Blocks: 237621    
Attachments: sample submodule repository
similar git repo on Windows 7 showing master and sub module layout

Description jessholle 2012-01-09 15:01:15 UTC
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.
Comment 1 Ondrej Vrabec 2012-01-09 15:08:10 UTC
True, git submodules are not supported. Some basic info about submodules can be found at: http://book.git-scm.com/5_submodules.html
Comment 2 jessholle 2012-01-09 15:16:24 UTC
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.
Comment 3 Ondrej Vrabec 2012-01-10 10:09:33 UTC
bug #207073 marked as fixed, file statuses should now be correctly determined.
Comment 4 jessholle 2012-02-07 21:14:13 UTC
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.
Comment 5 jessholle 2012-02-07 21:21:27 UTC
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...]
Comment 6 Ondrej Vrabec 2012-02-08 08:14:32 UTC
> 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.
Comment 7 jessholle 2012-02-08 09:12:53 UTC
I'll give the latest nightly a whirl and see how it goes.
Comment 8 jessholle 2012-02-08 13:41:03 UTC
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.
Comment 9 Ondrej Vrabec 2012-02-08 13:57:53 UTC
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.
Comment 10 jessholle 2012-02-08 14:08:02 UTC
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.
Comment 11 Ondrej Vrabec 2012-02-08 15:39:25 UTC
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
Comment 12 jessholle 2012-02-08 22:31:58 UTC
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.
Comment 13 jessholle 2012-02-08 22:33:19 UTC
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.
Comment 14 jessholle 2012-02-08 22:35:13 UTC
Created attachment 115534 [details]
similar git repo on Windows 7 showing master and sub module layout
Comment 15 Ondrej Vrabec 2012-02-09 12:06:21 UTC
(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)
Comment 16 jessholle 2012-02-09 12:14:13 UTC
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!
Comment 17 jessholle 2012-02-09 12:23:04 UTC
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.
Comment 18 Ondrej Vrabec 2012-02-13 12:35:45 UTC
*** Bug 208332 has been marked as a duplicate of this bug. ***
Comment 19 retiolum 2012-03-21 09:37:26 UTC
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').
Comment 20 jessholle 2012-03-21 11:36:45 UTC
(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.
Comment 21 jessholle 2012-04-03 20:22:02 UTC
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.
Comment 22 jessholle 2012-04-03 20:30:22 UTC
Actually it's now clear that Explore from Here is only half-broken in 7.2.  It works for folders but not individual files.
Comment 23 Ondrej Vrabec 2013-03-05 08:48:21 UTC
*** Bug 226959 has been marked as a duplicate of this bug. ***
Comment 24 Ondrej Vrabec 2013-06-21 09:17:45 UTC
*** Bug 231605 has been marked as a duplicate of this bug. ***
Comment 25 Quality Engineering 2013-10-24 02:39:29 UTC
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
Comment 26 Ondrej Vrabec 2013-10-24 12:35:21 UTC
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.
By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo