17 replies to this topic

[dave]

We’ve just released GitJungle, a small, beautiful Git repository browser using our Plastic SCM Branch Explorer (BrEx) visualization technology that basically lets you look at your Git repo from… well, a different angle.

Find all the details on this blog post announcement:

http://codicesoftwar...-to-jungle.html

And in the official Labs page for the project:

http://www.plasticsc.../gitjungle.aspx

Enjoy!

Dave

[jfrisby]

Feedback:

- Default window size exceeds height of common Mac hardware -- you probably want to reduce the total default window height to 778 pixels or less to avoid this (the 1280x800 resolution is common on Mac, and the menu bar is 22 pixels tall in that configuration).

- Use of what I presume is WinForms is exceptionally annoying and problematic under Mono and on Mac in particular as it requires the use of an X server and introduces a number of visual defects, and input problems (no mousewheel / trackpad-scrolling support, pressing shift and using arrow keys to select text elements replaces/inserts + or * depending on the direction chosen, positioning artifacts affecting your custom scrollbar graphics, etc). You may wish to look into Gtk# or another alternative that provides a better experience for non-Windows systems.

- Clicking a root commit shouldn't present an error dialog; simply noting that a diff is meaningless in the area where the diff would be shown would be an example of a more suitable behavior.

- Clicking on a file in the changed-files list of a root commit generates the error "Object reference not set to an instance of an object".

- A branch that refers to a commit within another branch should not be broken off into a separate and unconnected graph; this implies incorrectly that the broken-out commit is not a part of the larger branch AND in this case visually presents in a manner that suggests that the commit is in fact part of a separate DAG when it is not. A common example of where the present behavior is just flatly and totally misleading/wrong is when showing tracking branches.

- Actually, come to think of it, NO branches are showing up as being connected to other branches -- they all appear to be disconnected DAGs. So basically in addition to scrollbars displaying wrong on Mac, your graph edges aren't showing up *at all*.

[psantosl]

Hi jfrisby,

Thanks for your feedback, please find my answers below:

Feedback:
- Default window size exceeds height of common Mac hardware -- you probably want to reduce the total default window height to 778 pixels or less to avoid this (the 1280x800 resolution is common on Mac, and the menu bar is 22 pixels tall in that configuration).

Ok, yes, an easy fix that will definitely solve some issues. Will do!

- Use of what I presume is WinForms is exceptionally annoying and problematic under Mono and on Mac in particular as it requires the use of an X server and introduces a number of visual defects, and input problems (no mousewheel / trackpad-scrolling support, pressing shift and using arrow keys to select text elements replaces/inserts + or * depending on the direction chosen, positioning artifacts affecting your custom scrollbar graphics, etc). You may wish to look into Gtk# or another alternative that provides a better experience for non-Windows systems.

Yes, we've put a lot of effort into WinForms and submitted a good number of fixes, reviewed some of them and done a lot of testing over the last years, but definitely it seems WinForms will never be a solid contender on the Mac. We'll be using MonoMac soon.

- Clicking a root commit shouldn't present an error dialog; simply noting that a diff is meaningless in the area where the diff would be shown would be an example of a more suitable behavior.

Fine.

- Clicking on a file in the changed-files list of a root commit generates the error "Object reference not set to an instance of an object".

Could you please send us the url to your repo so we can test it? We're not aware of this issue.

- A branch that refers to a commit within another branch should not be broken off into a separate and unconnected graph; this implies incorrectly that the broken-out commit is not a part of the larger branch AND in this case visually presents in a manner that suggests that the commit is in fact part of a separate DAG when it is not. A common example of where the present behavior is just flatly and totally misleading/wrong is when showing tracking branches.

Well, yes, you know Git has some issues tracking branches (it is easy to get to a point where there's no way to know where a cset was created on) and since our graph is totally branch oriented we had to make some choices.

- Actually, come to think of it, NO branches are showing up as being connected to other branches -- they all appear to be disconnected DAGs. So basically in addition to scrollbars displaying wrong on Mac, your graph edges aren't showing up *at all*.

Same as above, but yes, showing relationships between branches is something we can do.

Thanks!!

pablo

[jfrisby]

- Clicking on a file in the changed-files list of a root commit generates the error "Object reference not set to an instance of an object".

Could you please send us the url to your repo so we can test it? We're not aware of this issue.

This happens on all repos with non-empty initial commits. Make sure you de-select any selected file first.

Issuing the following commands creates a repo that reproduces the problem reliably for me:

mkdir GitJungleBug
cd GitJungleBug/
git init .
echo "This is here to demonstrate a bug in GitJungle." > README.md
git add README.md 
git commit -m "Initial commit, with a file just to tickle GitJungle."
echo "Some more text because GitJungle won't show us the diff-view pane unless we have a commit that doesn't produce errors." >> README.md 
git add README.md
git commit -m "Second commit because diff-view pane doesn't *open* when clicking commit with no parent."

- A branch that refers to a commit within another branch should not be broken off into a separate and unconnected graph; this implies incorrectly that the broken-out commit is not a part of the larger branch AND in this case visually presents in a manner that suggests that the commit is in fact part of a separate DAG when it is not. A common example of where the present behavior is just flatly and totally misleading/wrong is when showing tracking branches.

Well, yes, you know Git has some issues tracking branches (it is easy to get to a point where there's no way to know where a cset was created on) and since our graph is totally branch oriented we had to make some choices.

That's not so much an "issue" as a "fundamental philosophical decision in the design of the system". The idea being to preserve linearity of history over the long term, while allowing things like topic-branching in the short term, and not make assumptions about how people actually work while coding. While they could have perhaps annotated commit data with branch-origin information, this could easily lead to a lot of cluttered workflows and visualizations and would fall apart rapidly in the face of things like interactive rebasing.

This of course means there is a fairly fundamental impedance mismatch between your graphing system's assumptions and git. Generally speaking, I can't say I'm a big fan of tools that try to wedge a round peg into a square hole. If you want to make a history visualizer around your own SCM, that's all well and good but when making a tool for a different ecosystem you only make your product less useful by not adhering to the norms, conventions, and expectations of that ecosystem.

This is especially true when the behavior you choose for that tool is wrong in the context of said ecosystem. In this case you have commits that are a part of multiple branches and you're showing them as not belonging to one of those branches. On top of that, you're choosing to NOT show them in the branch that is very likely the most important one for them to be reflected in -- the longer-lived of the branches.

Of course it's your tool and you can do with it as you see fit, but for me -- that's a deal-breaker.

-JF

[dave]

This of course means there is a fairly fundamental impedance mismatch between your graphing system's assumptions and git.

This is wrong. GitJungle will draw the branches with the information in your repo as it is NOW. If a series of commits are no longer reachable from the current heads, they are not drawn. If they were at some point and since then they have been fast forwarded, or merged, then they will appear on the target branch.

On top of that, you're choosing to NOT show them in the branch that is very likely the most important one for them to be reflected in -- the longer-lived of the branches.

As you said above, "The idea being... not make assumptions about how people actually work while coding". If it doesn't fit your workflow, don't use it, stay with gitk or whatever. The "very likely branch" depends a lot on you and how you use git.

[stereopticon]

The app starts for me, but will not let me access any of my GIT repos. I get the error "The type initializer for 'NGit.Util.FS' threw an exception.".

Windows 7 / git version 1.7.3.1.msysgit.0

[jgonzalez]

Hi,

Please, can you check your PATH variable when running gitjungle?
If the PATH has a double quote character, the error is shown.

It seems to be a problem with the NGit library, used by the gitjungle application.

cheers,

-Jesús M.

[jgonzalez]

Hi,

We have just published a new version of gitjungle, which fixes the TypeInitializationException reported in this thread.

The problem was an interaction between NGit library and Sharpen library calculating the PATH environment
variable on Windows OS's.

Both libraries are used by gitjungle.

Here are the links to the new version:
http://www.codicesof...e-0.8.4-win.zip (windows).

http://www.codicesof...ungle-0.8.4.zip (linux and mac)

-Jesús M.

[flsobral]

Hi,

I just got the latest version (0.8.4) and got the error described by stereopticon: "The type initializer for 'NGit.Util.FS' threw an exception."

TIA.

[luis]

Hi:

I'll talk with the expert in this field and come back to you soon.

Best,
Luis

[jgonzalez]

Hi,

Can you post the value of your current PATH environtment variable?

Also, some info about your OS version could be helpful.

Thanks,
-Jesús M.

[flsobral]

Windows XP SP3

PATH

C:\Arquivos de programas\PC Connectivity Solution\;%systemroot%\system32;%systemroot%;%systemroot%\system32\wbem;C:\cygwin\bin;C:\Arquivos de programas\IDM Computer Solutions\UltraEdit-32;C:\CYGWIN\GNUARM\BIN;C:\PALM;%ANT_HOME%\bin;C:\Arquivos de programas\Arquivos comuns\Roxio Shared\DLLShared;C:\Arquivos de programas\Arquivos comuns\Roxio Shared\9.0\DLLShared;C:\WINDOWS\system32\WindowsPowerShell\v1.0;%TOTALCROSS_HOME%\dist\vm\win32;%LITEBASE_HOME%\dist\lib\win32;C:\Arquivos de programas\QuickTime\QTSystem\;C:\Arquivos de programas\ZipGenius 6\;C:\Arquivos de programas\Arquivos comuns\Roxio Shared\DLLShared\;C:\Arquivos de programas\Arquivos comuns\Roxio Shared\9.0\DLLShared\;C:\Arquivos de programas\IVT Corporation\BlueSoleil\Mobile;C:\WINDOWS\system32\Wbem;C:\Arquivos de programas\Git\bin;%JAVA_HOME%\bin;%ANDROID_HOME%/platform-tools;C:\Arquivos de programas\MySQL\MySQL Server 5.5\bin

[jgonzalez]

Ok,

Maybe you can try the following to discard the PATH variable issue:
1-open a new prompt shell window
2-type

SET PATH=C:\WINDOWS

and ensure the PATH variable is correctly set:

ECHO %PATH%

(the ouptut should be "C:\WINDOWS" only)
3-run the gitjungle.exe from the same prompt shell window
4-type the path of your git repository local directory on the top-left textbox
5-click on GO button

Tell me how it goes, please
Thanks,
-Jesús M.

[flsobral]

worked like a charm, thanks!

[jgonzalez]

We have to find out why such a PATH variable makes gitjungle throwing that error.

There should be a problem with some characters on the PATH variable different than
the quote character.

BTW, you can use the attached batch script to execute gitjungle.exe with a modified
PATH variable.
Usage:

gitjungle.bat (path to git repository local directory)

(Rename the file to "gitjungle.bat")
Thanks,

-Jesús M.

Attached Files

•  gitjungle.bat.txt   177bytes   5 downloads

[ryanp]

I decided to try this out, and it does look cool, but it has some issues with reading my git history.

 gitjungle-issues.png   64.5K   8 downloads

The biggest issue here is that the branch dev-cc-charge actually has exactly one commit in it, the highlighted one. All of the previous commits are on master, which instead is somehow floating off by itself with only one commit. My current branch, enterprise-sync, correctly shows one commit, but is not attached to anything else. And gitjungle shows dev-michael-broken and remotes/origin/dev-michael-broken - both my local and the remote contain the exact same commits.

Also there's a minor UI issue with the vertical scrollbar - very minor though, I didn't even notice it until I was scrubbing my name from the screenshot.

So overall it looks promising, but it's not something I can really use at this point.

[manu]

Hello ryanp,

thanks for your feedback! Would it be possible to send us a git fast-export -no-data to check how your repository looks like in Plastic and also in GitJungle?

Or you can also, if you have time, fast-export your git repository and put it into Plastic.

[psantosl]

Yeah, we've some issues locating some commits since git commits are sort of "not tied to a branch" while the branch explorer was definitely designed for the underlying plastic scm model.

Take a look at our newer branch explorer: http://www.plasticsc.../4/dbrex08.png

Would you like to have something similar for git?