Giggle 0.4.90
Lennart just poked me if it isn't about time to make a Giggle release. There are more than 248 commits since the last release, seems he is right.
Code, wiki and bug tracker have been moved from Immendio to github, live.gnome.org and bugzilla.gnome.org.
What has changed since 0.4? Quite alot. Most important changes are those:
- The user interface has been cleaned up dramatically.
- The file browing view was restored and has annotation support now.
- The compact view is gone.
- There are the basics of a plugin system now.
- The revision view shows avatars retreived from Gravatar.
Note that this is an unstable development release. It still contains quite some bugs and reggressions.
Tarballs are are ftp.gnome.org:
- giggle-0.4.90.tar.bz2 md5sum: 6d7094ef9cdca85fddd0167cf9aedf08
- giggle-0.4.90.tar.gz md5sum: be8e72a782ebcd38dccda6d760d0f3cd
Yay!
Giggle's user interface has definitely improved. But are you aware of gitg ( http://wiki.github.com/jessevdk/gitg )? The feature set of both tools is similar, yet gitg's user interface is clearer IMHO.
I dislike that Giggle no longer shows the entire commit in the history view but only individual changes. If you showed the entire commit, you could still use the buttons to jump to the start of each change.
Wooow, I didn't knew that I wanted this until I found it on planet gnome.
I'm gonna give it a try!
Raphael: IMHO showing the entire diff is just confusing and unhelpful. Using the buttons just for jumping between changes but still showing the full diff wouldn't help.
Well, but I aggree that it would be annoying if you only could navigate the patch, that's why those buttons can be activated with <Alt>Up and <Alt>Down.
Regarding gitg: Just found it recently, but I think its UI has some serious issues. Well, not that giggle doesn't have its own issues. The loading speed of gitg is impressive, but I did some measurements recently and giggle also knows the project's history quickly. It just seems to waste quite some time with building the revisions graph. Nothing that can't be fixed.
Thanks :)
I always wanted to try the new giggle, but was afraid to build from source and break sth.
GitG: Wow, that's really close. Maybe you should share something, but I guess when libgit2 comes out the whole situation changes anyway...
You say it fetches gravatars?
History view does not even show author's name for me. Just blank.
ellen: your timezone is western of greenwich. see commit 0600e48f:
http://github.com/hasselmm/giggle/com...
Would you like to elaborate on the serious issues with the gitg GUI?
Jesse:
- Critique of gitg's commit view: http://bugzilla.gnome.org/show_bug.cg...
- gitg complicated patch-view widget just confuses me, we are moving into opposite directions here
- putting the file-view under command of the full history list doesn't allow convenient browsing of a file's history. you don't easily see in which revisions the file really was changed
- showing tags in the history view has some merits and i also think about it, but __please__ don't show them that way, that the shortlog messages jump widly. this really just hurts eyes. hint: you also can pack that tag name renderer at the end of a column
- the search box in the top right looks nice, but it doesn't give feed back why some commit matches. also: were are find prev/find next?
- i'd expected you search box to operate as filter
- ...
1) You argue that doign a commit is an action and as such should be a dialog rather than a view (should I mention you find a view "complety wrong"). The fact is though that with git, the process of preparing a commit is _exactly_ manipulating a certain state, and not a single action. I often find myself staging and unstaging, browsing back the history, changing some files again, and switching back to commit. One point I can take from this is that perhaps the name 'Commit view' is wrong.
Showing singular chunks instead of a full patch you find overwhelming and confusing and in general not usefull. I tend to disagree here also. Chunks in itself do not necessarily represent meaningful pieces of code. I do not feel very strong about this point, but in my personal opinion I like to be able to view the full patch and quickly get the full overview of a patch.
Showing chunks in a tree view, not sure. Since in gitg a full patch is prefered, the way to stage single chunks is to simply click on the chunk headers
2) Already discussed
3) I disagree again. I don't think showing ref labels this way is so problematic as you put it. I don't find it hurts my eyes. Actually, it gives me a very quick overview of where my branches are at the moment. Please don't patronize me with comments on gtk+ capabilities, or if this wasn't your intend, please formulate your hints differently
4/5) Ah, something we do agree on :)! The search functionality is not really developed and definately needs work (next/prev you can do with arrow keys for now btw.)
Nice to see Giggle going forward. Unfortunately the bad performance, compared to gitk, is still making it unusable for me. But maybe you can tackle that as well some day.
Markus: Definitely have to. The bad performance affects me by my self everyday... ;-)