Hi,

On Mon, 4 Feb 2008, Kirill wrote:

> > -----Original Message-----
> > From: Johannes Schindelin [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, February 03, 2008 6:58 PM
> 
> > On Sat, 2 Feb 2008, Kirill wrote:
> >
> > > TODO: decide on a structure and actions of added menu items.
> >
> > Yep.  I think a good starting point is to look at what 
> > TortoiseCVS/TortoiseSVN provide.
>
> I thought you were not in favour of that because git has a very powerful 
> feature - index. Did I miss something?

Yes... I meant it as a starting point.  Of course, where Tortoise only has 
one diff, we will have a few.

> > Personally, the thing I used most (back when I still had to work with 
> > CVS on Windows), was the diff operation. Another really nice thing was 
> > to see the history of a file (I guess this would be "gitk HEAD -- 
> > <file>").
>
> Totally agree on both points!
> 
> > > @@ -147,13 +224,11 @@ static STDMETHODIMP invoke_command(void *p,
> > >           STARTUPINFO si = { sizeof(si) };
> > >           PROCESS_INFORMATION pi;
> > >
> > > -         TCHAR command[1024];
> > > +         char command[1024];
> > >           const char *wd;
> > >           DWORD dwAttr, fa;
> > >
> > > -         wsprintf(command, TEXT("wish.exe \"%s/bin/git-gui\""),
> > > -                  msys_path());
> > > -
> > > +         sprintf(command, "wish.exe \"%s/bin/git-gui\"",
> > > +               msys_path());
> > >
> > 
> > This line should be empty, but has white space.
>
> I'm not sure, what you are referring to? But nevertheless, I'll keep 
> empty lines empty.

If you look through your commit with "git show --check <commit>" (this is 
also possible before committing, with "git diff --check", you will see red 
line endings.  These are spaces or tabs at the end of the line.  Usually 
we do not allow them.

> > Besides, this whole hunk is unrelated to the commit message, correct?
> > 
> > > @@ -202,7 +277,7 @@ static STDMETHODIMP get_command_string(void *p,
> > UINT id,
> > >
> > >
> > >   if (flags & GCS_HELPTEXT) {
> > > -         LPCTSTR text = _T("Launch the GIT Gui in the local or
> > chosen directory.");
> > > +         char *text = "Launch the GIT Gui in the local or chosen
> > directory.";
> > 
> > Same goes for this hunk...
>
> Oops! Sorry! These two changes are asking for a completely separate
> discussion. Feel free to take it to another thread, but because they showed
> up...
> 
> I'm not quite sure how it's handled on Unix or in git.git for this matter,
> but the TCHAR existence is somewhat artificial. IIRC, Microsoft introduced
> TCHAR (and _T() macro) in their environment quite some time ago to simplify
> a migration from MBCS to Unicode. Basically, the idea is to have a type that
> is defined differently #ifdef UNICODE. Now, it seems like in Cheetah, TCHAR
> sometimes is used as a synonym to wchar_t, which it is not, unless I
> overlooked something obvious in gcc behaviour. And sometimes it just seems
> like a copy-and-paste from a different universe.
> Hence, under the assumption that gcc does not auto-magically defines UNICODE
> and TCHAR is indeed MS-specific:
> - I have no idea how the first hunk (with wsprintf(char *, char *, char *);)
> ever worked;
> - as of the second hunk (with LPCTSTR), given that Cheetah is mostly written
> to be MBCS, I don't see a point to use MS-specific, transitional version of
> const char * (that's what LPCTSTR boils down to) in only one-or-two places.
> 
> So, a big question of the day: do we write Cheetah as MBCS? or as Unicode?
> or in transitional fashion, using TCHAR & Co.?

I am in no position to contribute to that discussion, as I just imitated 
what I saw, and did not really understand what TCHAR is.

Experts, speak up?

> > Okay, reading my comments again, it seems like all of them are
> > negative. Please bear in mind, though...
>
> Yeah! Without this part, I was almost ready to declare the week completely
> ruined (nobody likes my code :) Seriously:
> - I greatly appreciate all the efforts!
> 
> - I greatly appreciate style comments! I guess I'll need to find out what's
> wrong with C++-style comments, and overcome an urge to put couple "extra"
> spaces... But bear with me, would you? Please?

Heh, of course!

> - a quote from someone of the great "I am a lazy bastard..." is applicable
> to me too.
> 
> Oh, well... the last one was not totally serious, but... like a local
> comercial for Wal-Mart says "It's tru-u-ue"

Yep, we are lazy bastards.  That's why we use git, which makes some things 
incredibly much more easy than other SCMs ;-)

Ciao,
Dscho

Reply via email to