git-gui i18n / 0.9.x plans

Now that git-gui 0.8.0 has been released I have updated both the maint and master branches to 0.8.0. maint will carry the 0.8.0 development forward, and is strictly for bug fixes to the current non-i18n codebase. I'm unlikely to make changes here except to address current critical issues.

Regarding future development for the off-in-the-future 0.9.0 release I'd like to see the i18n work merge in before we do anything else major to git-gui. I'm likely to shift my focus to fast-import this week, which means git-gui will probably see no major activity from me for about the next two weeks. As soon as the i18n team has something rebased onto current master that is ready for merging, I'll bring it over. Yes, that's a promise on my part to try and keep my tree frozen for a little while. :)

Other things I'd like to do in 0.9.0, but may or may not actually do myself:

 - Automatically refetch tracking branches in merge
 - Text mode log viewer:
   `git-log`, `git-log -g`
 - File monitor on WinNT (to avoid costly Rescan on large projects)
 - Remove more porcelain shell dependencies:
   `git-merge`, `git-repack`, `git-remote prune`
 - UI for cherry-pick/revert
 - Generational GC for 'Compress Database'
 - Integration with git-stash
 - Hunk splitting/selection
 - UI for git-tag
 - Push specific tags by name (rather than by --tags)
 - Pull from arbitrary URL/branch pair

Those are roughly ordered by how much I think myself and my fellow day-job coworkers want these features, so that's probably roughly the order I'll try to work through them after the i18n current changes are merged in. Of course patches are also welcome. :)

I haven't yet settled on whether the first i18n enabled version would be 0.9.0 or a 0.8.1/2. That's one reason why I want to get the i18n changes merged early. If we have a few high quality translations ready to go I'd rather ship them in a 0.8.x maint release than hang onto them for another 1-2 months while the major features of the 0.9.0 release get worked on and stablized.

Hi,

On Mon, 30 Jul 2007, Shawn O. Pearce wrote:

Very good! As it happens, I pushed an update this morning. temp-rebase-to-shawns-master is the branch which forward-ported all patches to the current master of git-gui.git.

As I understand, Christian will find and mark all strings lacking [mc ...] and update the .pot file. Then we'll kindly ask the good translators (thanks everyone!) to review the changes, and after that I'll prepare some submittable patch series (no need to have several patches per language).

Yeah, I am personally interested in this, so time permitting I will continue on that part. Regarding your idea from another post of yours: IMHO selections are only meaningful if they take whole lines. But that's almost like hunk splitting, so it should be easy to support with the code I wrote and will have written.

Ciao, Dscho

Am Dienstag, 31. Juli 2007 12:47 schrieb Johannes Schindelin:

That sounds very good. Of course I'm very interested in having a i18n'ized git-gui available as soon as possible. In the git-gui-i18n.git code I think we've by now covered really all of the strings that appear throughout the program. Thanks to Johannes' maintenance work, the i18n patches are based on your (almost) latest master. Once the translation will actually be accepted into git-gui.git, I will also spend some weeks on final polish for the glossary and the German translation. I think it will be possible for you to offer at least a few language in complete translations in a 0.8.x release.

Yes, this is how this should work. I'm looking forward to a fully i18n'ized git-gui! Thanks for this great program.

Christian

Le 07-07-30 à 21:28, Shawn O. Pearce a écrit :

It would be nice to use the configured external merge tool (git  
mergetool) to help here (in my case os-x:opendiff/FileMerge).
Having a visual diff between
- the repository and the index
- the index and the workarea
- the repository and the workarea

Sorry, I can't contribute (never touched tcl/tk), I can only suggest ... and hope for the best.

- jfv

Jean-Fran??ois Veillette <jean_francois_veillette@yahoo.ca> wrote:

Hmm.  According to the manual[1]:

   opendiff file1 file2 [-ancestor ancestorFile] [-merge mergeFile]

what should be the file1/file2/ancesorFile here?

Another problem is this paragraph:

  opendiff exits immediately after the comparison request has been
  sent to FileMerge.

Uhhhh... how does git-gui know the user is done and the mergeFile should be staged?

I'm also on OS X (its my primary development system for git-gui) so I might consider working on this, but after looking at the manpage I'm not so sure...

[1] http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/opendiff.1.html