Hi, I have been developing a gui application for git for gtk+/GNOME based on GitX (which in turn is based on gitk). I feel that it's reaching the point where it might potentially be useful for other people to use. It currently features: - Loading large repositories very fast - Show/browse repository history - Show highlighted revision diff - Browse file tree of a revision and export by drag and drop - Search in the revision history on subject, author or hash - Switch between history view of branches easily - Commit view providing per hunk stage/unstage and commit The project is currently hosted on github: http://github.com/jessevdk/gitg clone: git://github.com/jessevdk/gitg.git Please let me know what you think, With kind regards, -- Jesse van den Kieboom Personal: http://www.icecrew.nl Professional: http://www.novowork.com --
You are right. I forgot that test_commit creates an extra tag. By adding git tag -d B && after "test_commit B &&", you would expose the issue in the existing code. --
Hi Jesse, Great! I wanted to give it a try, but didn't want to install it, and experienced some problems. The following two patches should improve the situation a little bit, but it's still not a full-scale solution. Regards, Gábor --
From: SZEDER Gábor <szeder@fzi.de>
... that was caused by a short command line option.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
gitg/gitg.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitg/gitg.c b/gitg/gitg.c
index 1b33294..69c5b56 100644
--- a/gitg/gitg.c
+++ b/gitg/gitg.c
@@ -15,7 +15,7 @@ static gboolean commit_mode = FALSE;
static GOptionEntry entries[] =
{
- { "commit", '-c', 0, G_OPTION_ARG_NONE, &commit_mode, N_("Start gitg in commit mode") },
+ { "commit", 'c', 0, G_OPTION_ARG_NONE, &commit_mode, N_("Start gitg in commit mode") },
{ NULL }
};
--
1.6.1.2.362.g0f78
--
For loading the xml UI files 'gitg-ui.xml' and 'gitg-menus.xml' the
same function call and error handling were performed twice.
This patch introduces a helper function to remove this code
duplication.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
Not sure about putting the new function into gitg-utils.c; maybe it
would be better in gitg.c...
gitg/gitg-utils.c | 16 ++++++++++++++++
gitg/gitg-utils.h | 2 ++
gitg/gitg-window.c | 10 ++--------
gitg/gitg.c | 9 +--------
4 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/gitg/gitg-utils.c b/gitg/gitg-utils.c
index 5fb6772..cfce323 100644
--- a/gitg/gitg-utils.c
+++ b/gitg/gitg-utils.c
@@ -1,3 +1,4 @@
+#include <stdlib.h>
#include <string.h>
#include <glib.h>
@@ -417,3 +418,18 @@ gitg_utils_menu_position_under_tree_view (GtkMenu *menu,
tree);
}
}
+
+void
+gitg_builder_add_from_file(GtkBuilder *builder, const gchar *filename)
+{
+ GError *error = NULL;
+ gchar full_filename[PATH_MAX];
+
+ g_snprintf(full_filename, PATH_MAX, "%s%c%s", GITG_UI_DIR, G_DIR_SEPARATOR, filename);
+ if (!gtk_builder_add_from_file(builder, full_filename, &error))
+ {
+ g_critical("Could not open UI file: %s (%s)", full_filename, error->message);
+ g_error_free(error);
+ exit(1);
+ }
+}
diff --git a/gitg/gitg-utils.h b/gitg/gitg-utils.h
index 867fff7..46f8010 100644
--- a/gitg/gitg-utils.h
+++ b/gitg/gitg-utils.h
@@ -36,4 +36,6 @@ gint gitg_utils_sort_names(gchar const *s1, gchar const *s2);
void gitg_utils_menu_position_under_widget(GtkMenu *menu, gint *x, gint *y, gboolean *push_in, gpointer user_data);
void gitg_utils_menu_position_under_tree_view(GtkMenu *menu, gint *x, gint *y, gboolean *push_in, gpointer user_data);
+void gitg_builder_add_from_file(GtkBuilder *builder, const gchar *filename);
+
#endif /* __GITG_UTILS_H__ */
diff --git a/gitg/gitg-window.c b/gitg/gitg-window.c
index 8abdb9a..6f583d9 100644
--- a/gitg/gitg-window.c
+++ ...Currently, gitg looks for the UI xml files only at the paths where
they should have been installed. This makes hard to just give gitg a
try without actually installing it, as it simply errors out.
This patch makes running gitg from the root directory of the working
tree possible by checking whether those UI files can be found under
the 'gitg' directory relative to the current working directory if they
can't be found on their proper place.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
This should be further enhanced (e.g. by looking for those files
relative to the path of the gitg binary), because you can only browse
gitg's history that way; running gitg in an other git repository
without installing it still doesn't work.
gitg/gitg-utils.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/gitg/gitg-utils.c b/gitg/gitg-utils.c
index cfce323..95bccd2 100644
--- a/gitg/gitg-utils.c
+++ b/gitg/gitg-utils.c
@@ -429,7 +429,12 @@ gitg_builder_add_from_file(GtkBuilder *builder, const gchar *filename)
if (!gtk_builder_add_from_file(builder, full_filename, &error))
{
g_critical("Could not open UI file: %s (%s)", full_filename, error->message);
- g_error_free(error);
- exit(1);
+
+ g_snprintf(full_filename, PATH_MAX, "%s%c%s", "gitg", G_DIR_SEPARATOR, filename);
+ if (!gtk_builder_add_from_file(builder, full_filename, &error))
+ {
+ g_error_free(error);
+ exit(1);
+ }
}
}
--
1.6.1.2.362.g0f78
--
Op dinsdag 03-02-2009 om 14:08 uur [tijdzone +0100], schreef SZEDER This has already been fixed. -- Jesse van den Kieboom Personal: http://www.icecrew.nl Professional: http://www.novowork.com --
Not yet another one, please! I'm sorry, but that was my first thought. I lost count of how many half-finished GUIs we have, using tcl/tk, gtk, qt, you-name-it-tk. I still don't see any which provide a consistent, "modern", stable GUI for viewing *and* committing, i.e. a replacement for gitk and git-gui. The latter two still seem to be the most feature rich choices, but they suffer somewhat from their implementation language. Just look at the git survey and you know why nobody wants to work on them. So, while any effort in enhancing the git environment is appreciated (I do appreciate yours), we recently see an increased splitting of efforts (web site, doc, lib, gui,...) rather than collaborative work. Maybe we can create a "git-gui-ng community", or even two for gtk and qt if it must be, but not more? A new "standard" gui which focusses most talents and efforts? Cheers, Michael The current tk high score list according to git.or.cz, including yours: Qt3/4 : ****** GTK+ : *** Tcl/Tk: ** Cocoa : ** MFC : ** curses: * Of the more modern tks, qt should be the most cross-platform solution. Do we have a winner here? --
On Tue, Feb 3, 2009 at 8:58 AM, Michael J Gruber For what it's worth, GitX (OS X only) does both history viewing and committing, and seems to be rapidly approaching the feature set of gitk and git-gui combined. Unfortunately, I seem to inevitably hate cross-platform GUI's---they never feel right or work slickly enough. Sad, but true. If GitX and this newer project could share a lot of code base, then maybe their co-development would be accelerated and both would end up being slick, native, full-fledged GUIs for git. --
Op dinsdag 03-02-2009 om 11:43 uur [tijdzone -0800], schreef Stefan This is the reason why I'm developing gitg as a separate application, I try to follow the implementation of GitX very closely since it's the basis of the development of gitg (it happens to be that I know the developer of GitX very well). -- Jesse van den Kieboom Personal: http://www.icecrew.nl Professional: http://www.novowork.com --
"tk high score list"? -Miles -- "I distrust a research person who is always obviously busy on a task." --Robert Frosch, VP, GM Research --
[...] How it differs from other git GUI applications for GTK+/GNOME, If you feel it is ready to be used (or at least tested), could you add short information about this project in "Graphical Interfaces" section of http://git.or.cz/gitwiki/InterfacesFrontendsAndTools (preferable not using GUI edit, as it screws up formatting, unfortunately)? TIA -- Jakub Narebski Poland ShadeHawk on #git --
On Sat, Jan 31, 2009 at 10:05 PM, Jesse van den Kieboom And the obligatory screenshots? -- Felipe Contreras --
Op woensdag 04-02-2009 om 09:39 uur [tijdzone +0200], schreef Felipe The screenshots are on the website -- Jesse van den Kieboom Personal: http://www.icecrew.nl Professional: http://www.novowork.com --
Grin ;) At least I'm not the only one who didn't how to navigate the github page... In fact, reading the top line there in the first place would have made me hopeful that this is a unifying rather than splitting project. So, my best wishes (I'll try and compile)! Cheers, Michael --
On Wed, Feb 4, 2009 at 2:46 PM, Michael J Gruber I have several projects there, but I only use github for the vcs stuff, I never actually clicked the 'wiki' tab before. Anyway, I tried gitg and the history view looks very nice (like GitX), definitely much better than Giggle, but unfortunately it's still not usable for me (gitk addict). Keep up the good work :) -- Felipe Contreras --
Op woensdag 04-02-2009 om 16:12 uur [tijdzone +0200], schreef Felipe Could you explain to me what makes it unusable for your wrt your workflow in gitk? -- Jesse van den Kieboom Personal: http://www.icecrew.nl Professional: http://www.novowork.com --
First of all I always need to resize the window, and when I do that the columns are not updated so I need to resize the columns as well. Same thing with the division of the history and diff view. Then when navigating I can't click the arrows, so I have to scroll down until I see the parent of the commit. There are many other issues, like crashes, small format annoyances and the --all option, but those I bet are easy to fix, I could even do that myself. -- Felipe Contreras --
OK, played with it, looks nice. Some feedback: Bug:? After unstaged a staged file it does not reappear under "unstaged". It appears nowhere. Build: gitg can't run from the build dir, it needs to be installed. Reconfiguring with different --prefix does not rebuild (one needs to make clean manually). Features: Displaying the subject after the parent shas etc would be nice. Maybe forward/back buttons for taking you forward/back in your *browsing history*? Say, you click on a parent, and then you want to get back. Can one stage hunks somehow? Cheers, Michael --
Op woensdag 04-02-2009 om 15:29 uur [tijdzone +0100], schreef Michael J This is true, I got a patch to fix this, but I'm not sure it should go in (e.g. read data files from current working directory). It's not common to be able to run C/gtk+ apps from the build directory, you Showing the parent subject should be fairly easy to fix, I'll see if I can get that in. I have thought about a history-history, but I haven't felt the need to use it yet (also I don't think GitX has this), but it Yes, you can click on the hunk header @@...@@ when viewing the diff in the commit view. You can also rightclick on this header and revert a -- Jesse van den Kieboom Personal: http://www.icecrew.nl Professional: http://www.novowork.com --
I just compared with staging/reverting the single hunk I had in there, that works perfectly. The bug occurs only when unstaging from the list Sure, but just to try it out? Imagine me poor soul, going through all these GUIs and cloning, running autogen.sh/qmake-qt4/configure/make/setup.py depending on the tk, and finding I have to install in order to try it out (not to mention Uh, thanks, works like a charm. I had tried selecting and right-clicking the hunk itself... Cheers, Michael --
Op woensdag 04-02-2009 om 15:40 uur [tijdzone +0100], schreef Michael J Yeah I know, it's a hassle. But fixing this would involve quite some hacks in the code (it's not just the ui xml files, also icons and other installed data) to find this data. Unfortunately, autotools is not really friendly in this way. It might be possible to build binaries which have local resources (like OS X bundles) so it can be tried out -- Jesse van den Kieboom Personal: http://www.icecrew.nl Professional: http://www.novowork.com --
Cloning through http does not seem to work, I don't know why not, --
It must be a github bug ... I guess I'll to find some bug address there... Thanks, -Miles -- Christian, n. One who follows the teachings of Christ so long as they are not inconsistent with a life of sin. --
