git-gui i18n / 0.9.x plans

git-gui i18n / 0.9.x plans

[Shawn O. Pearce]

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.

-- 
Shawn.

Re: git-gui i18n / 0.9.x plans

[Johannes Schindelin]

Hi,

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

> 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.

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).

>  - Hunk splitting/selection

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

Re: git-gui i18n / 0.9.x plans

[Jean-François Veillette]

Le 07-07-30 à 21:28, Shawn O. Pearce a écrit :
>  - UI for cherry-pick/revert
>  - Hunk splitting/selection

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

Re: git-gui i18n / 0.9.x plans

[Shawn O. Pearce]

Jean-Fran??ois Veillette <jean_francois_veillette@yahoo.ca> wrote:
> Le 07-07-30 à 21:28, Shawn O. Pearce a écrit :
> > - UI for cherry-pick/revert
> > - Hunk splitting/selection
> 
> 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

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

-- 
Shawn.

Re: git-gui i18n / 0.9.x plans

[Christian Stimming]

Am Dienstag, 31. Juli 2007 12:47 schrieb Johannes Schindelin:
> On Mon, 30 Jul 2007, Shawn O. Pearce wrote:
> > 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.

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.

> 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).

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

Christian