* Re: gitk: Turn short SHA1 names into links too
From: Brad King @ 2008-09-26 12:15 UTC (permalink / raw)
To: Mikael Magnusson
Cc: Wincent Colaiuta, Linus Torvalds, Paul Mackerras,
Git Mailing List
In-Reply-To: <237967ef0809260121w1c7cc516tceb3be2cbebb85bc@mail.gmail.com>
Mikael Magnusson wrote:
> 2008/9/26 Wincent Colaiuta <win@wincent.com>:
>> It's a shame that tcl/tk regular expressions don't appear to support
>> anchoring matches against word boundaries (ie. "\b").
>
> \y appears to achieve this;
>
> % regexp {abc\y} 'abc'
> 1
> % regexp {abc\y} 'abcd'
> 0
> % regexp {\yabc\y} 'uabc,d'
> 0
> % regexp {\yabc\y} 'u+abc,d'
> 1
>
> I have tcl/tk 8.5 so I cannot promise that isn't a new addition, I didn't
> look it up anywhere, but it's \y in some other implementations too, so I
> tried it.
It goes back at least as far as tcl/tk 8.2:
http://www.tcl.tk/man/tcl8.2.3/TclCmd/re_syntax.htm#M54
-Brad
^ permalink raw reply
* Re: mysterious error message
From: Johannes Schindelin @ 2008-09-26 12:01 UTC (permalink / raw)
To: Tom Sgouros; +Cc: git
In-Reply-To: <20593.1222378418@as220.org>
Hi,
On Thu, 25 Sep 2008, Tom Sgouros wrote:
> I receive the following error message when I try to do a 'git push':
>
> tomfool@toms-box:hpl$ git push
> updating 'refs/heads/master'
> from ad4ae7925d3dd23798e7c5b733d2d8f930f7410f
> to 5b5f5fae014a4f3535fa10b0f6e28b4bf3225dc3
> Also local refs/remotes/origin/master
> Generating pack...
> Done counting 10 objects.
> Deltifying 10 objects...
> error: pack-objects died with strange error
> unpack eof before pack header was fully read
> ng refs/heads/master n/a (unpacker error)
> error: failed to push to 'ssh://tomfool@as220.org/home/tomfool/hpl.git'
> tomfool@toms-box:hpl$
I got this message when I tried to push a project with submodules to a
server which had submodule-ignorant git installed. Maybe it's that?
Ciao,
Dscho
^ permalink raw reply
* git-sharp, was Re: Implementations of Git (was: re-licensing pkt-line.c code)
From: Johannes Schindelin @ 2008-09-26 11:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git list
In-Reply-To: <m3od2c2k29.fsf@localhost.localdomain>
Hi,
On Thu, 25 Sep 2008, Jakub Narebski wrote:
> P.S. Do you know what is the status of git#, implementation of Git in
> C#, which was one of this year Google Summer of Code projects?
As I suspected (hoping I would be wrong), the lack of communication (this
time with the Git community) did not help at all.
The latest commit is this:
http://code.google.com/p/mono-soc-2008/source/detail?r=471
implementing a diff algorithm.
>From what I can tell from the source (I do not have a working C#
environment), the implementation repeats a lot of what Shawn told us
earlier were his lessons from his first stab at JGit. For example, I saw
that the contents of blobs are read into memory when the blob is read. I
haven't checked closely, but I did not have the impression that there were
accessors making it easy to turn this into a lazy read.
Take-home message: if you think you should develop Open Source in a
secretive manner, you are almost certainly wrong, and your project will
almost certainly be slow or even fail (BTW I also see exactly this same
problem with Govind's try last year, which had a cool name, and then
another cool name, but not much to show for it).
Ciao,
Dscho
^ permalink raw reply
* Re: gitk: Turn short SHA1 names into links too
From: Marco Costalba @ 2008-09-26 10:41 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Linus Torvalds, Paul Mackerras, Git Mailing List
In-Reply-To: <BD7D0F18-32BD-4059-9190-A2C1B101B4C1@wincent.com>
On Fri, Sep 26, 2008 at 8:32 AM, Wincent Colaiuta <win@wincent.com> wrote:
>
> [regexp {\b[0-9a-f]{4,39}\b} $id]
>
> would mostly eliminate that kind of false positive.
This feature is already implemented in qgit from a long time. The most
difficult false positive I have found is the debug backtracing in the
log messages. Memory dumps are a big sources of false positives.
^ permalink raw reply
* Re: [QGit] Some suggestion
From: Marco Costalba @ 2008-09-26 10:37 UTC (permalink / raw)
To: Li Frank-B20596; +Cc: git
In-Reply-To: <7FD1F85C96D70C4A89DA1DF7667EAE9607A0D9@zch01exm23.fsl.freescale.net>
On Fri, Sep 26, 2008 at 7:43 AM, Li Frank-B20596 <Frank.Li@freescale.com> wrote:
>
> I have some suggestions.
> Option 1: Change "Rev List" to "Rev List Filtered"
This is the more correct but we don't have the space to write on what
files it is filtering
> Option 2: Change "Short Log" to "Short Log Filter On
> <Lib/blame.tcl>"
This is less correct because short log has nothing to do with
filtering, but here there is more space...
> Option 3: Add bar between tab and list, show current filter
> information
>
Too complicated and space wasteful IMO.
Marco
^ permalink raw reply
* Re: [RFC PATCH (GIT-GUI)] git-gui: Add more integration options to citool.
From: Alexander Gavrilov @ 2008-09-26 10:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20080924165201.GV3669@spearce.org>
On Wednesday 24 September 2008 20:52:01 Shawn O. Pearce wrote:
> Alexander Gavrilov <angavrilov@gmail.com> wrote:
> > - Make citool return nonzero exit code if it did not commit.
> > - Add a mode where it does not actually commit and simply
> > exits with zero code. Commit message is either disabled,
> > or simply dumped to GITGUI_EDITMSG before exiting.
> > - Add an option to immediately start it in amend mode.
> ...
> > I think this functionality might be useful, in particular for some of
> > my own scripts. But I'm not sure if this is the best way to do it.
>
> This looks good to me, but I think we may want to add this as a
> follow-up patch. Thoughts?
>
> --8<--
> git-gui: Hide commit related UI during citool --nocommit
>
> If the user started git-gui as "git citool --nocommit" then they
> don't need the new commit / amend commit radio buttons, or the sign
> off button in the UI. Rather than use up space with options the
> user cannot activate they are simply not installed into the UI.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
I believe that the 'Sign Off' button should better be controlled by the nocommitmsg
option; otherwise this looks good to me. But I'm not the best thinker at the
moment (had a cold).
Alexander
^ permalink raw reply
* Re: [PATCH] git-gui: Help identify aspell version on Windows too
From: Johannes Sixt @ 2008-09-26 9:31 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: git, spearce
In-Reply-To: <48DCA5F3.4090009@isy.liu.se>
Gustaf Hendeby schrieb:
> On 09/26/2008 08:29 AM, Johannes Sixt wrote:
>> Gustaf Hendeby schrieb:
>>> On windows, git gui fails to correctly extract the aspell version
>>> (experienced with aspell version 0.50.3) due to scilent white space at
>>> the end of the version string. Trim the obtained version string to
>>> work around this.
>> With this I've partial success here: Aspell 0.50.3 alpha (downloaded from
>> http://aspell.net/win32/) is recognized, but
>>
>> - it only ever checks the first line of the commit message;
>
> Hmm, strange, I just had it mark my whole first like red, I think it
> took an enter at the end of the line to get everything started though.
> Does it check the rest of the lines for you? I know spell checking is
> disabled for too early versions of Aspell, due to some change in the
> interface I think.
My situation is this: I fire up git-gui, and because I have some stale
.git/GITGUI_MSG file, the commit message box is not empty. Aspell begins
its work, and git-gui correctly marks spelling mistakes in the first line.
Even if I type new text, delete old text, or change the whole text by
clicking "Amend", no new spelling mistakes are marked for the whole session.
-- Hannes
^ permalink raw reply
* Re: [ANNOUNCE] Git-1.6.0.2-preview20080923
From: Peter Krefting @ 2008-09-26 9:27 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: msysGit, Git Mailing List
In-Reply-To: <B463062F-DD48-44A7-B2BB-8E5E0D177616@zib.de>
Hi!
Steffen Prohaska:
> I updated the installer to Git-1.6.0.2-preview20080923.
One issue that I see is that the installer does not seem to clean up
the previously installed version on upgrade. I installed over the
previous version to C:\Git, and I now have two git-add.exe files:
Directory of c:\git\bin
2008-06-22 18:41 925 184 git-add.exe
Directory of c:\git\libexec\git-core
2008-09-23 07:55 881 664 git-add.exe
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH] git-gui: Help identify aspell version on Windows too
From: Gustaf Hendeby @ 2008-09-26 9:05 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, spearce
In-Reply-To: <48DC815C.6030401@viscovery.net>
On 09/26/2008 08:29 AM, Johannes Sixt wrote:
> Gustaf Hendeby schrieb:
>> On windows, git gui fails to correctly extract the aspell version
>> (experienced with aspell version 0.50.3) due to scilent white space at
>> the end of the version string. Trim the obtained version string to
>> work around this.
>
> With this I've partial success here: Aspell 0.50.3 alpha (downloaded from
> http://aspell.net/win32/) is recognized, but
>
> - it only ever checks the first line of the commit message;
Hmm, strange, I just had it mark my whole first like red, I think it
took an enter at the end of the line to get everything started though.
Does it check the rest of the lines for you? I know spell checking is
disabled for too early versions of Aspell, due to some change in the
interface I think.
>
> - after I change the catalog in the Options, I can't "Save" (it does
> nothing), until I change to some other catalog. I haven't discovered the
> pattern, yet, when the "Save" succeeds.
>
> - At startup the correct catalog is used. But if I change the catalog
> during a session (if I succeed, see above), then the second-last picked
> catalog is used.
>
> Any idea how to debug this?
I have experienced some saving related issues I think, but I'm not sure.
Unfortunately I have very little understanding on what is going on in
the code, basically I don't know tcl/tk at all. I was just lucky to
find a solution to my problem that seemed to work for me.
>
>> @@ -80,7 +80,7 @@ method _connect {pipe_fd} {
>> error_popup [strcat [mc "Unrecognized spell checker"] ":\n\n$s_version"]
>> return
>> }
>> - set s_version [string range $s_version 5 end]
>> + set s_version [string range [string trim $s_version] 5 end]
>
> A strange indentation you have here.
Yep, sorry about that, seems I had a nonstandard tab-width setting. Too
bad not all projects can decide on the same tab width. :( Will resend
if there are no other comments to this, and at the same time fix the
spelling in the commit message...
/Gustaf
^ permalink raw reply
* Re: gitk: Turn short SHA1 names into links too
From: Mikael Magnusson @ 2008-09-26 8:21 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Linus Torvalds, Paul Mackerras, Git Mailing List
In-Reply-To: <BD7D0F18-32BD-4059-9190-A2C1B101B4C1@wincent.com>
2008/9/26 Wincent Colaiuta <win@wincent.com>:
> El 26/9/2008, a las 2:37, Linus Torvalds escribió:
>
>> On Thu, 25 Sep 2008, Linus Torvalds wrote:
>>>
>>> And the thing I wanted to work was to have the abbreviated SHA1's that
>>> have started to get more common in the kernel commit logs work as links
>>> in
>>> gitk too, just the way a full 40-character SHA1 link works.
>>
>> For a test-case, I just pushed out my current top-of-tree that finally
>> pushed me over the edge. I've seen this before, but I couldn't really
>> force me to do anything about it until now.
>>
>> So to see this in action, do
>>
>> gitk v2.6.26..6ef190c
>>
>> on the current kernel repo, and notice that "Commit ee1e2c82 ("IPoIB:
>> Refresh paths .." thing, where we want that 'ee1e2c82' to be a link even
>> though it's not a full SHA1.
>>
>> Of course, the matching could be better, it will now accept any random 6+
>> character sequence of hex characters, even if they are surrounded by
>> characters that make it clear that it's not a SHA1 ("Haahahhaaaaaa!"
>> would find the 'aaaaaa' and if you have a commit that starts with that,
>> link to it ;)
>
> I know nothing about tcl/tk, but will comment anyway:
>
> It's a shame that tcl/tk regular expressions don't appear to support
> anchoring matches against word boundaries (ie. "\b").
>
> If so, a regexp like:
>
> [regexp {\b[0-9a-f]{4,39}\b} $id]
>
> would mostly eliminate that kind of false positive. But from my reading of
> the wiki[1], looks like there's no "\b" escape sequence. Nor does it look
> like tcl/tk has support for lookahead/lookbehind assertions which could be
> used to the same effect.
\y appears to achieve this;
% regexp {abc\y} 'abc'
1
% regexp {abc\y} 'abcd'
0
% regexp {\yabc\y} 'uabc,d'
0
% regexp {\yabc\y} 'u+abc,d'
1
I have tcl/tk 8.5 so I cannot promise that isn't a new addition, I didn't
look it up anywhere, but it's \y in some other implementations too, so I
tried it.
--
Mikael Magnusson
^ permalink raw reply
* Re: mysterious error message
From: Uwe Kleine-König @ 2008-09-26 8:20 UTC (permalink / raw)
To: Tom Sgouros; +Cc: git
In-Reply-To: <20593.1222378418@as220.org>
Hello,
On Thu, Sep 25, 2008 at 05:33:38PM -0400, Tom Sgouros wrote:
> I receive the following error message when I try to do a 'git push':
>
> tomfool@toms-box:hpl$ git push
> updating 'refs/heads/master'
> from ad4ae7925d3dd23798e7c5b733d2d8f930f7410f
> to 5b5f5fae014a4f3535fa10b0f6e28b4bf3225dc3
> Also local refs/remotes/origin/master
> Generating pack...
> Done counting 10 objects.
> Deltifying 10 objects...
> error: pack-objects died with strange error
> unpack eof before pack header was fully read
> ng refs/heads/master n/a (unpacker error)
> error: failed to push to 'ssh://tomfool@as220.org/home/tomfool/hpl.git'
> tomfool@toms-box:hpl$
>
> I haven't been able to interpret this message, and haven't found it in
> the documentation, and google has let me down, too. Can anyone tell me
> what is causing it?
I think it's a problem on the pushing side. Maybe out of disk space (in
$GIT_DIR or $TMP_DIR)? Does git repack work?
HTH
Uwe
^ permalink raw reply
* bye
From: Pico Geyer @ 2008-09-26 8:11 UTC (permalink / raw)
To: git
unsubscribe git
^ permalink raw reply
* Re: [PATCH v2] gitk: Update swedish translation.
From: Peter Krefting @ 2008-09-26 7:59 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Paul Mackerras, Git Mailing List
In-Reply-To: <alpine.LNX.1.00.0809251413300.11806@localhost>
Mikael Magnusson:
> Signed-off-by: Mikael Magnusson <mikachu@gmail.com>
Acked-by: Peter Krefting <peter@softwolves.pp.se>
Here's another determined/undetermined form thing, that you could
consider for the next update:
> +#: gitk:3019
> +msgid "command failed:"
> +msgstr "kommando misslyckades:"
change to "kommandot misslyckades:"
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: git log and utf-u in filenames
From: Jakub Narebski @ 2008-09-26 7:31 UTC (permalink / raw)
To: Alex Riesen; +Cc: Joey Hess, Git Mailing List
In-Reply-To: <20080926063311.GA4939@blimp.localhost>
On Fri, 26 Sep 2008, Alex Riesen wrote:
> Jakub Narebski, Fri, Sep 26, 2008 01:15:58 +0200:
> >
> > Well, in gitweb we could use '-z' option for git-diff-tree and git-ls-tree,
> > but it has its disadvantages, like having to do actual parsing record after
> > record instead of simplys splitting outout on end of line ("\n") characters.
> >
>
> How about simply splitting output on end of line ("\0" NUL) characters?
> The "\n" NL you refer to is just as EOR as NUL.
Doesn't work for "git diff-tree -z [...]" output. When there is rename
or copy detected, NUL is used as separator between fields (beetween
source and destination unquoted filename), not only between records:
git diff-tree
.... <src qfilename> TAB <dst qfilename> LF
git diff-tree -z
.... <src filename> NUL <dst filename> NUL
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: gitk: Turn short SHA1 names into links too
From: Wincent Colaiuta @ 2008-09-26 7:29 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Linus Torvalds, Paul Mackerras, Git Mailing List
In-Reply-To: <48DC8E91.6080909@op5.se>
El 26/9/2008, a las 9:26, Andreas Ericsson escribió:
> Wincent Colaiuta wrote:
>> El 26/9/2008, a las 2:37, Linus Torvalds escribió:
>>> On Thu, 25 Sep 2008, Linus Torvalds wrote:
>>>>
>>>> And the thing I wanted to work was to have the abbreviated SHA1's
>>>> that
>>>> have started to get more common in the kernel commit logs work as
>>>> links in
>>>> gitk too, just the way a full 40-character SHA1 link works.
>>>
>>> For a test-case, I just pushed out my current top-of-tree that
>>> finally
>>> pushed me over the edge. I've seen this before, but I couldn't
>>> really
>>> force me to do anything about it until now.
>>>
>>> So to see this in action, do
>>>
>>> gitk v2.6.26..6ef190c
>>>
>>> on the current kernel repo, and notice that "Commit ee1e2c82
>>> ("IPoIB:
>>> Refresh paths .." thing, where we want that 'ee1e2c82' to be a
>>> link even
>>> though it's not a full SHA1.
>>>
>>> Of course, the matching could be better, it will now accept any
>>> random 6+
>>> character sequence of hex characters, even if they are surrounded by
>>> characters that make it clear that it's not a SHA1 ("Haahahhaaaaaa!"
>>> would find the 'aaaaaa' and if you have a commit that starts with
>>> that,
>>> link to it ;)
>> I know nothing about tcl/tk, but will comment anyway:
>> It's a shame that tcl/tk regular expressions don't appear to
>> support anchoring matches against word boundaries (ie. "\b").
>> If so, a regexp like:
>> [regexp {\b[0-9a-f]{4,39}\b} $id]
>> would mostly eliminate that kind of false positive. But from my
>> reading of the wiki[1], looks like there's no "\b" escape sequence.
>> Nor does it look like tcl/tk has support for lookahead/lookbehind
>> assertions which could be used to the same effect.
>
> It's not as if this will be a real problem anyway. gitk is designed to
> be used by humans, who can fortunately parse such things a trillion
> times better than any regex a billion monkeys could come up with in a
> billion years, even if one was to take evolution into account. ;-)
Of course it's never going to be a _real_ problem (ie. a deal-
breaker), but most technical users will look on it as sloppy
programming when the 'aaaaaa' in 'Haahahhaaaaaa!' gets turned into a
link.
Cheers,
Wincent
^ permalink raw reply
* Re: gitk: Turn short SHA1 names into links too
From: Andreas Ericsson @ 2008-09-26 7:26 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Linus Torvalds, Paul Mackerras, Git Mailing List
In-Reply-To: <BD7D0F18-32BD-4059-9190-A2C1B101B4C1@wincent.com>
Wincent Colaiuta wrote:
> El 26/9/2008, a las 2:37, Linus Torvalds escribió:
>
>> On Thu, 25 Sep 2008, Linus Torvalds wrote:
>>>
>>> And the thing I wanted to work was to have the abbreviated SHA1's that
>>> have started to get more common in the kernel commit logs work as
>>> links in
>>> gitk too, just the way a full 40-character SHA1 link works.
>>
>> For a test-case, I just pushed out my current top-of-tree that finally
>> pushed me over the edge. I've seen this before, but I couldn't really
>> force me to do anything about it until now.
>>
>> So to see this in action, do
>>
>> gitk v2.6.26..6ef190c
>>
>> on the current kernel repo, and notice that "Commit ee1e2c82 ("IPoIB:
>> Refresh paths .." thing, where we want that 'ee1e2c82' to be a link even
>> though it's not a full SHA1.
>>
>> Of course, the matching could be better, it will now accept any random 6+
>> character sequence of hex characters, even if they are surrounded by
>> characters that make it clear that it's not a SHA1 ("Haahahhaaaaaa!"
>> would find the 'aaaaaa' and if you have a commit that starts with that,
>> link to it ;)
>
> I know nothing about tcl/tk, but will comment anyway:
>
> It's a shame that tcl/tk regular expressions don't appear to support
> anchoring matches against word boundaries (ie. "\b").
>
> If so, a regexp like:
>
> [regexp {\b[0-9a-f]{4,39}\b} $id]
>
> would mostly eliminate that kind of false positive. But from my reading
> of the wiki[1], looks like there's no "\b" escape sequence. Nor does it
> look like tcl/tk has support for lookahead/lookbehind assertions which
> could be used to the same effect.
>
It's not as if this will be a real problem anyway. gitk is designed to
be used by humans, who can fortunately parse such things a trillion
times better than any regex a billion monkeys could come up with in a
billion years, even if one was to take evolution into account. ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git log and utf-u in filenames
From: Alex Riesen @ 2008-09-26 6:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Joey Hess, Git Mailing List
In-Reply-To: <m3fxnn3ji6.fsf@localhost.localdomain>
Jakub Narebski, Fri, Sep 26, 2008 01:15:58 +0200:
>
> Well, in gitweb we could use '-z' option for git-diff-tree and git-ls-tree,
> but it has its disadvantages, like having to do actual parsing record after
> record instead of simplys splitting outout on end of line ("\n") characters.
>
How about simply splitting output on end of line ("\0" NUL) characters?
The "\n" NL you refer to is just as EOR as NUL.
^ permalink raw reply
* Re: gitk: Turn short SHA1 names into links too
From: Wincent Colaiuta @ 2008-09-26 6:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mackerras, Git Mailing List
In-Reply-To: <alpine.LFD.1.10.0809251729440.3265@nehalem.linux-foundation.org>
El 26/9/2008, a las 2:37, Linus Torvalds escribió:
> On Thu, 25 Sep 2008, Linus Torvalds wrote:
>>
>> And the thing I wanted to work was to have the abbreviated SHA1's
>> that
>> have started to get more common in the kernel commit logs work as
>> links in
>> gitk too, just the way a full 40-character SHA1 link works.
>
> For a test-case, I just pushed out my current top-of-tree that finally
> pushed me over the edge. I've seen this before, but I couldn't really
> force me to do anything about it until now.
>
> So to see this in action, do
>
> gitk v2.6.26..6ef190c
>
> on the current kernel repo, and notice that "Commit ee1e2c82 ("IPoIB:
> Refresh paths .." thing, where we want that 'ee1e2c82' to be a link
> even
> though it's not a full SHA1.
>
> Of course, the matching could be better, it will now accept any
> random 6+
> character sequence of hex characters, even if they are surrounded by
> characters that make it clear that it's not a SHA1 ("Haahahhaaaaaa!"
> would find the 'aaaaaa' and if you have a commit that starts with
> that,
> link to it ;)
I know nothing about tcl/tk, but will comment anyway:
It's a shame that tcl/tk regular expressions don't appear to support
anchoring matches against word boundaries (ie. "\b").
If so, a regexp like:
[regexp {\b[0-9a-f]{4,39}\b} $id]
would mostly eliminate that kind of false positive. But from my
reading of the wiki[1], looks like there's no "\b" escape sequence.
Nor does it look like tcl/tk has support for lookahead/lookbehind
assertions which could be used to the same effect.
>
Cheers,
Wincent
[1] http://wiki.tcl.tk/396
^ permalink raw reply
* Re: [PATCH] git-gui: Help identify aspell version on Windows too
From: Johannes Sixt @ 2008-09-26 6:29 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: git, spearce
In-Reply-To: <1222378282-21757-1-git-send-email-hendeby@isy.liu.se>
Gustaf Hendeby schrieb:
> On windows, git gui fails to correctly extract the aspell version
> (experienced with aspell version 0.50.3) due to scilent white space at
> the end of the version string. Trim the obtained version string to
> work around this.
With this I've partial success here: Aspell 0.50.3 alpha (downloaded from
http://aspell.net/win32/) is recognized, but
- it only ever checks the first line of the commit message;
- after I change the catalog in the Options, I can't "Save" (it does
nothing), until I change to some other catalog. I haven't discovered the
pattern, yet, when the "Save" succeeds.
- At startup the correct catalog is used. But if I change the catalog
during a session (if I succeed, see above), then the second-last picked
catalog is used.
Any idea how to debug this?
> @@ -80,7 +80,7 @@ method _connect {pipe_fd} {
> error_popup [strcat [mc "Unrecognized spell checker"] ":\n\n$s_version"]
> return
> }
> - set s_version [string range $s_version 5 end]
> + set s_version [string range [string trim $s_version] 5 end]
A strange indentation you have here.
> regexp \
> {International Ispell Version .* \(but really (Aspell .*?)\)$} \
> $s_version _junk s_version
-- Hannes
^ permalink raw reply
* Re: [PATCH] builtin-commit: avoid using reduce_heads()
From: Miklos Vajna @ 2008-09-26 6:24 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
In-Reply-To: <20080926010312.GE6816@neumann>
[-- Attachment #1: Type: text/plain, Size: 676 bytes --]
On Fri, Sep 26, 2008 at 03:03:12AM +0200, SZEDER Gábor <szeder@ira.uka.de> wrote:
> Szia Miklós,
:)
> unfortunately it introduces a new one: t7502-commit.sh
> fails at me with the following:
>
>
> * ok 17: a SIGTERM should break locks
>
> * expecting success:
>
> git rev-parse second master >expect &&
> test_must_fail git merge second master &&
> git checkout master g &&
> EDITOR=: git commit -a &&
> git cat-file commit HEAD | sed -n -e "s/^parent //p" -e
> "/^$/q" >actual &&
> test_cmp expect actual
Uh-oh. I forgot to make test before git send-email. I'll have a look at
it later today.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Remove empty directories in recursive merge
From: Johannes Sixt @ 2008-09-26 5:58 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Anders Melchiorsen, Shawn O. Pearce, Junio C Hamano
In-Reply-To: <20080925201245.GB3959@blimp.localhost>
Alex Riesen schrieb:
> +test_expect_success 'merge removes empty directories' '
> +
> + git reset --hard master &&
> + git checkout -b rm &&
> + git rm d/e &&
> + git commit -mremoved-d/e &&
> + git checkout master &&
> + git merge -s recursive rm &&
> + test_must_fail test -d d
FWIW, 'test_must_fail' is intended for git commands only. Here,
! test -d d
would be just fine.
> +'
> +
> test_done
-- Hannes
^ permalink raw reply
* Small issue with rerere when one file fails to automatically merge
From: Mike Hommey @ 2008-09-26 5:55 UTC (permalink / raw)
To: git
Hi,
I recently got this issue with rerere, that can be reproduced with the
workflow below. The problem is that rerere does its job, but fails
to mark the files as being merged when one of the files auto merging
failed.
I haven't taken the time to look into rerere to fix this, though.
$ git init
Initialized empty Git repository in /tmp/test/.git/
[master]$ git config rerere.enabled true
[master]$ echo a > a
[master]$ echo b > b
[master]$ git add a b
[master]$ git commit -m 1
Created initial commit fb0ebe4: 1
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 a
create mode 100644 b
[master]$ git branch foo
[master]$ git branch foo2
[master]$ echo aa > a
[master]$ echo bb > b
[master]$ git commit -a -m 2
Created commit 69f9bf3: 2
2 files changed, 2 insertions(+), 2 deletions(-)
[master]$ git co foo
Switched to branch "foo"
[foo]$ echo ab > a
[foo]$ echo bc > b
[foo]$ git commit -a -m 3
Created commit 991c054: 3
2 files changed, 2 insertions(+), 2 deletions(-)
[foo]$ git merge master
Auto-merging a
CONFLICT (content): Merge conflict in a
Auto-merging b
CONFLICT (content): Merge conflict in b
Recorded preimage for 'a'
Recorded preimage for 'b'
Automatic merge failed; fix conflicts and then commit the result.
[foo]$ echo aab > a
[foo]$ echo bbc > b
[foo]$ GIT_EDITOR=cat git commit -a
<snip>
Recorded resolution for 'a'.
Recorded resolution for 'b'.
Created commit 98c88e2: Merge branch 'master' into foo
[foo]$ git co foo2
Switched to branch "foo2"
[foo2]$ echo ab > a
[foo2]$ echo bd > b
[foo2]$ git commit -a -m 4
Created commit 9c65461: 4
2 files changed, 2 insertions(+), 2 deletions(-)
[foo2]$ git merge master
Auto-merging a
CONFLICT (content): Merge conflict in a
Auto-merging b
CONFLICT (content): Merge conflict in b
Recorded preimage for 'b'
Resolved 'a' using previous resolution.
Automatic merge failed; fix conflicts and then commit the result.
[foo2]$ git status
a: needs merge
b: needs merge
# On branch foo2
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# unmerged: a
# unmerged: b
#
no changes added to commit (use "git add" and/or "git commit -a")
[foo2]$ cat a
aab
[foo2]$ cat b
<<<<<<< HEAD:b
bd
=======
bb
>>>>>>> master:b
One would expect a not to be unmerged.
Mike
^ permalink raw reply
* RE: [QGit] Some suggestion
From: Li Frank-B20596 @ 2008-09-26 5:43 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550809252215v72bb4633s17b5c1a8c39f55ff@mail.gmail.com>
I think orange color of "Working dir changes" in Rev List view is good.
"MAGIC WAND" is google feature.
I think the message of "Filter on <lib/blame.tcl>" at title omitted by
user early.
I have some suggestions.
Option 1: Change "Rev List" to "Rev List Filtered", or add
filter icon before "Rev List"
Option 2: Change "Short Log" to "Short Log Filter On
<Lib/blame.tcl>"
Option 3: Add bar between tab and list, show current filter
information
-----Original Message-----
From: Marco Costalba [mailto:mcostalba@gmail.com]
Sent: Friday, September 26, 2008 1:16 PM
To: Li Frank-B20596
Cc: git@vger.kernel.org
Subject: Re: [QGit] Some suggestion
On Fri, Sep 26, 2008 at 3:55 AM, Li Frank-B20596
<Frank.Li@freescale.com> wrote:
> Thank you for your support!
> Can I compare with other version at file view?
After selecting with CTRL+RIGHT CLICK as already descrived click on the
file name, you'll be pointed to the part of the diff related to your
file.
Another option is to choose one commit, click on a file name in the
right bottom pane, then press the MAGIC WAND button, then commits will
be reloaded with path limiter and you will see only commits that modify
the selected file. Toggle magic wand button to restore original view.
> I think highlight author at file view is not high light, can use
> different color?
What is the color you would like ? Possibly in RGB format.
Marco
^ permalink raw reply
* Re: [QGit] Some suggestion
From: Marco Costalba @ 2008-09-26 5:15 UTC (permalink / raw)
To: Li Frank-B20596; +Cc: git
In-Reply-To: <7FD1F85C96D70C4A89DA1DF7667EAE9607A00A@zch01exm23.fsl.freescale.net>
On Fri, Sep 26, 2008 at 3:55 AM, Li Frank-B20596 <Frank.Li@freescale.com> wrote:
> Thank you for your support!
> Can I compare with other version at file view?
After selecting with CTRL+RIGHT CLICK as already descrived click on
the file name, you'll be pointed to the part of the diff related to
your file.
Another option is to choose one commit, click on a file name in the
right bottom pane, then press the MAGIC WAND button, then commits will
be reloaded with path limiter and you will see only commits that
modify the selected file. Toggle magic wand button to restore original
view.
> I think highlight author at file view is not high light, can use
> different color?
What is the color you would like ? Possibly in RGB format.
Marco
^ permalink raw reply
* RE: [QGit] Some suggestion
From: Li Frank-B20596 @ 2008-09-26 1:55 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550809250934l47c48440m332764491ff5391@mail.gmail.com>
Thank you for your support!
Can I compare with other version at file view?
I think highlight author at file view is not high light, can use
different color?
-----Original Message-----
From: Marco Costalba [mailto:mcostalba@gmail.com]
Sent: Friday, September 26, 2008 12:34 AM
To: Li Frank-B20596
Cc: git@vger.kernel.org
Subject: Re: [QGit] Some suggestion
On Thu, Sep 25, 2008 at 4:20 PM, Li Frank-B20596
<Frank.Li@freescale.com> wrote:
> Marco:
>
> Ctrl +/- change font size, but how to change source code view
> font size.
>
Edit->Settings->Fixed width font
You can choose size, font family, bolding, etc...
File view and diff view are optimized for source code viewing so use
fixed pitch fonts, not system default one that normally it is not fixed
pitch.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox