* Re: [PATCH 0/7] Bisect dunno
From: Robin Rosenberg @ 2007-10-17 16:10 UTC (permalink / raw)
To: David Kastrup
Cc: David Symonds, Geert Bosch, Wincent Colaiuta, Johan Herland, git,
Marius Storm-Olsen, Christian Couder, René Scharfe,
Junio Hamano, Johannes Schindelin
In-Reply-To: <856417h9cj.fsf@lola.goethe.zz>
tisdag 16 oktober 2007 skrev David Kastrup:
> "David Symonds" <dsymonds@gmail.com> writes:
>
> > On 16/10/2007, David Kastrup <dak@gnu.org> wrote:
> >> Geert Bosch <bosch@adacore.com> writes:
> >>
> >> > On Oct 15, 2007, at 13:53, David Symonds wrote:
> >> >> That's also why I suggested "skip"; you might not be able to test a
> >> >> particular commit, but you might also not *want* to test a particular
> >> >> commit for some reason.
> >> >
> >> > Skip seems a great choice: it directly expresses the wish to
> >> > not consider a certain commit. The reason is unimportant.
> >>
> >> But it is an _action_, while "good" and "bad" are properties.
> >
> > "skipped", then.
>
> "good" and "bad" are descriptive. "to be skipped" would be necessary
> to fit it.
Yet another very short word: void.
I'm thinking about ticket copies that sometimes are marked "void" so you cannot use it.
-- robin
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git - Had a few questions on Qgit; I like the GUI.
From: Robin Rosenberg @ 2007-10-17 16:00 UTC (permalink / raw)
To: Marco Costalba
Cc: pete, piet.delaney, Linus Torvalds, VMiklos, free cycle, git,
piet.delaney, Piet Delaney
In-Reply-To: <e5bfff550710170030y7778e96ax146acea7a0e57a67@mail.gmail.com>
onsdag 17 oktober 2007 skrev Marco Costalba:
> On 10/17/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
> >
> > While I'm looking at the diffs for a file if I pull down External Diff
> > it launches 'kcompare' but for a file with a large change it seems
> > to be running extremely slow.
>
> qgit does not intergarte Kompare functionality, it just prepares the
> files and spawns a Kompare process.
>
> So there's seem nothing qgit can do about Kompare speed. You can try
> with different diff viewers, meld,...etc..
You could avoid the temporary files if you just pipe the diff to kompare. That
would require an option to tell qgit that the external viewer can read a git diff.
At the time qgit 1.5 was written, kompare could not handle git diffs.
-- robin
^ permalink raw reply
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-17 15:53 UTC (permalink / raw)
To: Luke Lu; +Cc: Christer Weinigel, Tom Tobin, git
In-Reply-To: <3A9408D5-2667-43A6-A0CE-C0720B3A3987@vicaya.com>
On Wed, 17 Oct 2007, Luke Lu wrote:
>
> Well, we just established that all-space is perfect, look-wise.
But we also established that an all-space model is not stable, because any
unix developers will start adding tabs instead of spaces.
> As I mentioned, an all-space policy is trivial to enforce.
Hell no, it's not.
More importantly, I can guarantee that certain developers will refuse to
be part of such a project with such an idiotic design that eats disk-space
for no gain, and makes it impossible for me to use my normal editor.
> But I still haven't seen any compelling arguments against the "all space"
> case, other than "people will screw it up into mixed spaces", which is really
> a straw man, as many multi-platform projects enforced the all-space policy
> easily by using a pre-commit hook in maintainers' repository.
Hey, you start your own projct, and you can enforce whatever idiotic rules
you want to.
But in the meantime, all-tab indentations are equally good, and are the
defacto rule. So *you* are the one who should show compelling arguments
for changing, and so far you haven't shown any.
Really: what is the problem with hardtabs? Absolutely none.
Linus
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: Andreas Ericsson @ 2007-10-17 15:50 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550710162357r2c3744b1me5138edf24a56090@mail.gmail.com>
Marco Costalba wrote:
> On 10/16/07, Andreas Ericsson <ae@op5.se> wrote:
>> Marco Costalba wrote:
>>> On 10/16/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>>>
>>>> Would it be worthwhile
>>>> to install Qt4 from src and try to use qgit-2.0?
>>>>
>>> Yes it is. There are a lot of new featrures, is almost as stable as
>>> the previous and if you are interested in file history (annotations)
>>> in qgit-2.0 this feature has been greatly speeded up.
>>>
>> The only thing I really, really, really don't like about qgit4 is the
>> fact that it fudges up the commit-message. I've been trying for two
>> days to get rid of the HTML output, but I just can't get it done
>> without the signed-off-by email being enclosed in <> tags.
>>
>
> You mean when you commit some changes or when you brows the revisions?
>
When I browse the revisions.
> If it is the highlighted title that annoy you I can try to remove the
> background color, or set as plain text as an option.
>
That does annoy me indeed, but the primary annoyance is the fact that
the subject is no longer listed with the rest of the commit message, but
rather above the ancestry links.
>> view without the colored box a lot more). The little arrows in the
>> commit window are also fairly annoying, as one quite quickly understands
>> that up-/down-arrows work much better for that sort of stuff anyway.
>>
>
> Little arrows should already be removable from settings->browse->'Show
> smart labels' , you can also add lateral tabs with
> settings->browse->'Show tabbed revisions' if you like.
>
Sweet. I'll have to look into it. Thanks for your gentle instruction, and
a great product :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Use exit 1 instead of die when req_Root fails.
From: Lars Hjemli @ 2007-10-17 15:39 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Morten Welinder, git, spearce
In-Reply-To: <DC3D43FD-F03D-4E0A-9C2B-DE56F9C16D60@silverinsanity.com>
On 10/17/07, Brian Gernhardt <benji@silverinsanity.com> wrote:
> The problem is that die can exit with varying exit codes, and exit
> codes >= 128 make the test suite assume something has gone wrong with
> the test.
This makes me wonder: what about all the other instances of die() in
git-cvsserver? Or in any of the other perl scripts, for that matter?
Should they all be fixed, or is it this particular test that is wrong?
--
larsh
^ permalink raw reply
* Re: git-gc --prune interferes cogito?
From: Petr Baudis @ 2007-10-17 15:38 UTC (permalink / raw)
To: MichaelTiloDressel@t-online.de; +Cc: git
In-Reply-To: <1IiA7L-1AWmmW0@fwd35.aul.t-online.de>
Hi,
On Wed, Oct 17, 2007 at 04:43:27PM +0200, MichaelTiloDressel@t-online.de wrote:
> I'm using git-1.5.3.2 and cogito-0.18.1.
>
> After I did a git-gc --prune cg-status didn't show my branches anymore.
> git-branch -a still showed the branches.
> I think that git-gc removed all files from .git/refs/heads/ except for
> origin. Git seams to be fine with the branches in
> .git/logs/refs/heads/.
>
> So should git-gc not be used together with cogito?
Cogito doesn't support packed heads - I guess setting gc.packrefs to
false should fix the issue. Cogito should support packed tags, I guess;
I don't know if there's a way to make git-gc pack only tags.
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: [PATCH] Use exit 1 instead of die when req_Root fails.
From: Brian Gernhardt @ 2007-10-17 15:16 UTC (permalink / raw)
To: Morten Welinder; +Cc: git, spearce
In-Reply-To: <118833cc0710170739i179e7389k1e44f70086ca88be@mail.gmail.com>
On Oct 17, 2007, at 10:39 AM, Morten Welinder wrote:
>> made it into your repo. It fixes test failures on my machine
>> that have
>> been plauging me for months.
>
> That sounds more like a reason to fix the test. "die" is the perl
> standard way of reporting an error. It will print the error message
> on stderr, not on stdout like your version does.
>
> IMHO, of course.
The problem is that die can exit with varying exit codes, and exit
codes >= 128 make the test suite assume something has gone wrong with
the test. In particular, because $! (errcode) and $? (previous shell
command return) are both 0, it returns 255. Or at least that's how
it works out on my system. I'm not sure why it doesn't do that on
others.
But the test is expecting a failure here and it appears to be failing
in the correct way, just with an error code test-lib.sh doesn't
like. I asked on list the best way to fix it and Frank Lichtenheld
said (and nobody objected until now) that this was the best way to
fix it.
Also, the not printing on STRERR is identical to another section of
code just below mine:
> unless ($line eq 'anonymous') {
> print "E Only anonymous user allowed via pserver\n";
> print "I HATE YOU\n";
> exit 1;
> }
However, amending my patch to print to STDERR is not difficult.
~~ Brian Gernhardt
^ permalink raw reply
* git-gc --prune interferes cogito?
From: MichaelTiloDressel @ 2007-10-17 14:43 UTC (permalink / raw)
To: git
Hi,
I'm using git-1.5.3.2 and cogito-0.18.1.
After I did a git-gc --prune cg-status didn't show my branches anymore.
git-branch -a still showed the branches.
I think that git-gc removed all files from .git/refs/heads/ except for
origin. Git seams to be fine with the branches in
.git/logs/refs/heads/.
So should git-gc not be used together with cogito?
Cheers,
Michael
^ permalink raw reply
* Re: SLES 10 git packages
From: Thomas Glanzmann @ 2007-10-17 14:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT
In-Reply-To: <20071017135202.GK18279@machine.or.cz>
Hello Petr,
>> SLES 10 packages
> there seem to be some in the build service:
> http://download.opensuse.org/repositories/devel:tools:scm/SLE_10
thanks a lot for the URL,
Thomas
^ permalink raw reply
* Re: [PATCH] Use exit 1 instead of die when req_Root fails.
From: Morten Welinder @ 2007-10-17 14:39 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git, spearce
In-Reply-To: <20071017140547.GA21691@Hermes.cust.hotspot.t-mobile.com>
> made it into your repo. It fixes test failures on my machine that have
> been plauging me for months.
That sounds more like a reason to fix the test. "die" is the perl
standard way of
reporting an error. It will print the error message on stderr, not on
stdout like
your version does.
IMHO, of course.
Morten
^ permalink raw reply
* [PATCH] Use exit 1 instead of die when req_Root fails.
From: Brian Gernhardt @ 2007-10-17 14:05 UTC (permalink / raw)
To: git, spearce
This was causing test failures because die was exiting 255.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
Shawn, I sent this in a couple weeks ago but it looks like it never
made it into your repo. It fixes test failures on my machine that have
been plauging me for months.
git-cvsserver.perl | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 13dbd27..0d55fec 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -145,8 +145,10 @@ if ($state->{method} eq 'pserver') {
}
my $request = $1;
$line = <STDIN>; chomp $line;
- req_Root('root', $line) # reuse Root
- or die "E Invalid root $line \n";
+ unless (req_Root('root', $line)) { # reuse Root
+ print "E Invalid root $line \n";
+ exit 1;
+ }
$line = <STDIN>; chomp $line;
unless ($line eq 'anonymous') {
print "E Only anonymous user allowed via pserver\n";
--
1.5.3.4.206.g0cef9
^ permalink raw reply related
* Re: SLES 10 git packages
From: Petr Baudis @ 2007-10-17 13:52 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20071016072742.GA11450@cip.informatik.uni-erlangen.de>
Hi,
On Tue, Oct 16, 2007 at 09:27:42AM +0200, Thomas Glanzmann wrote:
> is there someone out there who maintains up2date git packages for SuSE
> Linux Enterprise Server 10?
there seem to be some in the build service:
http://download.opensuse.org/repositories/devel:tools:scm/SLE_10
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: git update index question
From: Lars Hjemli @ 2007-10-17 13:30 UTC (permalink / raw)
To: Gonzalo Garramuno; +Cc: git
In-Reply-To: <47160706.2000706@filmaura.com>
On 10/17/07, Gonzalo Garramuno <gga@filmaura.com> wrote:
> I had incorrectly done a chmod a+x on the pre-commit hook when all my
> previous commits had not been using it, so I think the pre-commit was
> actually catching not my new fix but what was already in the repository.
That sounds wrong: the (default) pre-commit hook only verifies the
_new_ content, not the content in HEAD. Is there any chance your
.git/hooks/pre-commit script has been tampered with?
--
larsh
^ permalink raw reply
* Re: git update index question
From: Gonzalo Garramuno @ 2007-10-17 12:58 UTC (permalink / raw)
To: Lars Hjemli, git
In-Reply-To: <8c5c35580710170549n25c8b692w2466091ea56d641e@mail.gmail.com>
Lars Hjemli wrote:
> On 10/17/07, Gonzalo Garramuno <gga@filmaura.com> wrote:
>> what's the proper way to rebuild git's index file for all the files that
>> were to be committed but weren't due to the abort.
>
> Have you tried 'git commit -a'? It will run update-index on all
> modified files prior to executing the hook.
>
> Btw: If you want to inspect your changes for offending whitespace,
> 'git diff --color' and 'git diff --cached --color' are your friends.
> And if you give up, there is also 'git commit -a --no-verify'.
>
Thanks. I found out the root of my problem was actually something else.
I had incorrectly done a chmod a+x on the pre-commit hook when all my
previous commits had not been using it, so I think the pre-commit was
actually catching not my new fix but what was already in the repository.
git-commit -a had no effect due to that.
But it's good to know about the --no-verify option, thou.
--
Gonzalo Garramuño
Film Aura
A New Dawn in Media Companies
gga@filmaura.com
http://www.filmaura.com
^ permalink raw reply
* Re: Git User's Survey 2007 summary - git homepage improvements
From: Petr Baudis @ 2007-10-17 12:50 UTC (permalink / raw)
To: Jonas Fonseca
Cc: Shawn O. Pearce, Jan Hudec, Frank Lichtenheld, Jakub Narebski,
git
In-Reply-To: <20071017111136.GB23417@diku.dk>
On Wed, Oct 17, 2007 at 01:11:36PM +0200, Jonas Fonseca wrote:
> If the list decides that it could be a better official name or simply an
> alias (currently the case if I configured it correctly) to git.or.cz (or
> whatever the list comes up with) I will gladly act as a domain sponsor.
I have configured it on my side too. git-scm.org now works. Thanks!
I'd have personally preferred git-vcs.org, but git-scm.org is cool too.
:-)
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: git update index question
From: Lars Hjemli @ 2007-10-17 12:49 UTC (permalink / raw)
To: Gonzalo Garramuno; +Cc: git
In-Reply-To: <4715E2AB.4030900@filmaura.com>
On 10/17/07, Gonzalo Garramuno <gga@filmaura.com> wrote:
> what's the proper way to rebuild git's index file for all the files that
> were to be committed but weren't due to the abort.
Have you tried 'git commit -a'? It will run update-index on all
modified files prior to executing the hook.
Btw: If you want to inspect your changes for offending whitespace,
'git diff --color' and 'git diff --cached --color' are your friends.
And if you give up, there is also 'git commit -a --no-verify'.
--
larsh
^ permalink raw reply
* Re: Git User's Survey 2007 summary - git homepage improvements
From: Petr Baudis @ 2007-10-17 12:47 UTC (permalink / raw)
To: Jan Hudec; +Cc: Frank Lichtenheld, Jakub Narebski, git
In-Reply-To: <20071017000526.GG18279@machine.or.cz>
On Wed, Oct 17, 2007 at 02:05:26AM +0200, Petr Baudis wrote:
> On Tue, Oct 16, 2007 at 10:12:47PM +0200, Jan Hudec wrote:
> > Note, that none of the other vcs' have a homepage at theirname.org --
> > subversion is svn.tigris.org, bazaar is bazaaz-vcs.org, mercurial is
> > www.selenic.com/mercurial, svk is svk.bestpractical.com, monotone is
> > monotone.ca. So git-vcs.org would be quite good.
>
> If someone trustworthy in the community has the resources to sponsor the
> domain, I will only be happy and gladly set it up on my side (I can run
> the nameservers myself too, if required). But I don't have the
> resources for registering the domain myself, unfortunately.
Ok, it turns out that I can get a domain arranged even for free, so if
someone has some fancy idea...
I wonder who took git-vcs.org. :-( Maybe some evil competing VCS? ;-)
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: [PATCH 2/2] Quoting paths in tests
From: Johannes Sixt @ 2007-10-17 11:32 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: git, Jonathan del Strother
In-Reply-To: <11926134961275-git-send-email-maillist@steelskies.com>
Jonathan del Strother schrieb:
> --- a/t/lib-git-svn.sh
> +++ b/t/lib-git-svn.sh
> @@ -25,7 +25,7 @@ perl -w -e "
> use SVN::Core;
> use SVN::Repos;
> \$SVN::Core::VERSION gt '1.1.0' or exit(42);
> -system(qw/svnadmin create --fs-type fsfs/, '$svnrepo') == 0 or exit(41);
> +system(qw/svnadmin create --fs-type fsfs/, \"$svnrepo\") == 0 or exit(41);
Here you have to work harder: The reason is that this is part of a perl
expression (as opposed to an eval'd string), which does not have access to
$svnrepo of the shell by which it is invoked. The original version failed if
there were single-quotes in $svnrepo, the new version fails if it contains
double-quotes.
> " >&3 2>&4
> - svn import -m 'import for git-svn' . $svnrepo >/dev/null &&
> + svn import -m 'import for git-svn' . \"$svnrepo\" >/dev/null &&
This must be
svn import -m 'import for git-svn' . \"\$svnrepo\" >/dev/null &&
to be safe. Your version would break with names with double-quotes, because
$svnrepo would be expanded and then eval'd inside test_expect_*. This error
recurs numerous times until the end of the patch.
May I recommend that you run the test suite in a directory named like this:
$ mkdir \"\ \$GIT_DIR\ \'
$ ls
" $GIT_DIR '
> - ( mkdir -p $GIT_DIR/svn/\$ref/info/ &&
> - echo $svnrepo\$path > $GIT_DIR/svn/\$ref/info/url ) || exit 1;
> + ( mkdir -p \"$GIT_DIR\"/svn/\$ref/info/ &&
> + echo \"$svnrepo\"\$path > \"$GIT_DIR\"/svn/\$ref/info/url ) || exit 1;
I assume $path is under control of the test script, otherwise it must be
inside the double-quotes, too.
> test_expect_success ".rev_db auto-converted to .rev_db.UUID" "
> git-svn fetch -i trunk &&
> - expect=$GIT_DIR/svn/trunk/.rev_db.* &&
> + expect=\"\`find \"\$GIT_DIR\"/svn/trunk/ -name '.rev_db.*'\`\" &&
Why is this trickery with find needed? Isn't it easier to put the whole test
case in single-quotes instead?
-- Hannes
^ permalink raw reply
* Re: On Tabs and Spaces
From: Andy Parkins @ 2007-10-17 11:32 UTC (permalink / raw)
To: git; +Cc: David
In-Reply-To: <402731c90710162041q457c7dd3tf906ba0c6faf29ca@mail.gmail.com>
On Wednesday 2007 October 17, David wrote:
> The last two are extremely useful, especially if you're hacking on
> python. That's
> listchars=(less-than)tab(greater-than)(colon)(dot)(backslash)(space)
> (don't forget the space!).
On the subject of high-ascii chars. Here's my favourite for your .vimrc
execute 'set listchars+=tab:'.nr2char(187).nr2char(183)
187 is the "significantly greater than" symbol and 183 is a central dot. i.e.
every character of a tab is non-space. The actual characters used aren't
actually the point I wanted to make; the thing here is that two non-space
characters are used, so every column occupied by the tab is visible - this
makes it very easy to see where tabs end and spaces begin.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: On Tabs and Spaces
From: Michael Witten @ 2007-10-17 11:23 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: git
In-Reply-To: <dbfc82860710170321l458ebd1cr6bf619cef9bb7300@mail.gmail.com>
On 17 Oct 2007, at 6:21:30 AM, Nikolai Weibull wrote:
> According to this calculation the waste is 47808782 bytes, or about
> 45.6 MiB, for 8-spaces-wide tabs.
I concede my calculation was crude.
Interestingly, modifying my calculation to look
for tabs at the beginning of the line gives a
similar result:
# calculates the extra space required to
# use the given number of spaces/tab.
size()
{
count=`grep -RIo "^\`printf \"\t\"\`" . | wc -l`;
perl -e "print $count*$(($1-1))/1024/1024 . \" MiB\n\"";
}
size 8; => 49.7416791915894 MiB
and for git:
size 8; => 1.25082969665527 MiB
Anyway, thanks for the neat script.
mfwitten
^ permalink raw reply
* Re: Git User's Survey 2007 summary - git homepage improvements
From: Jonas Fonseca @ 2007-10-17 11:11 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Petr Baudis, Jan Hudec, Frank Lichtenheld, Jakub Narebski, git
In-Reply-To: <20071017002648.GH13801@spearce.org>
Shawn O. Pearce <spearce@spearce.org> wrote Tue, Oct 16, 2007:
> Petr Baudis <pasky@suse.cz> wrote:
> > On Tue, Oct 16, 2007 at 10:12:47PM +0200, Jan Hudec wrote:
> > > On Mon, Oct 15, 2007 at 00:56:18 +0200, Frank Lichtenheld wrote:
> > > > On Mon, Oct 15, 2007 at 12:05:22AM +0200, Jakub Narebski wrote:
> > > > > Generic:
> > > > > # Dedicated domain name / site name, e.g. git.org or git.com
> ...
> > > > (And I guess something like git-scm.org wouldn't qualify as more
> > > > "official", would it?)
> > >
> ...
> > If someone trustworthy in the community has the resources to sponsor the
> > domain, I will only be happy and gladly set it up on my side (I can run
> > the nameservers myself too, if required). But I don't have the
> > resources for registering the domain myself, unfortunately.
>
> "git" is a three letter word. I don't think there have been *any*
> three letter .com/.org/.net domains available for years.
>
> I see that Jonas Fonseca registered git-scm.org today... I wonder
> what his plans are for that domain...
The plan is to use it for git propaganda in some form or another. :-)
If the list decides that it could be a better official name or simply an
alias (currently the case if I configured it correctly) to git.or.cz (or
whatever the list comes up with) I will gladly act as a domain sponsor.
Also, as time permits, I would like to get more involved in creating a
great online resource for git users and what better way to do that than
"homesteading the websphere".
--
Jonas Fonseca
^ permalink raw reply
* Re: git-apply segfault
From: Pierre Habouzit @ 2007-10-17 11:10 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200710171100.01247.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 734 bytes --]
On Wed, Oct 17, 2007 at 10:00:01AM +0000, Andy Parkins wrote:
> Hello,
>
> I've not got time to investigate this further just now, I'll try later. In
> case anyone else wants to though; I just got this core dump when running git
> rebase using current git master (1.5.3.4.206.g58ba4):
It's not the current master, it's an old one, the fix is in:
90d16ec032b20f9f1146f3aceca12165aba3b6d6
You must fetch from spearce.git[0] that has taken maintainance interim
until junio comes back.
Cheers,
[0] git://repo.or.cz/git/spearce.git
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* git update index question
From: Gonzalo Garramuno @ 2007-10-17 10:23 UTC (permalink / raw)
To: git
Hi. I'm new to git but have been using it successfully for about three
months now and love it.
I've run into my first problem (or, more specifically) lack of
understanding.
I'm currently working on linux.
After some modifications of my source code with a script and doing a
commit with qgit, it seems some spaces at the end of those changed lines
got added.
Now, whenever I try to do a commit, the result is that git aborts with
* trailing whitespace (line XXX).
That is, it fails due to git's pre-commit perl hook.
Now, I've modified and changed the offending lines, but redoing the
commit the problem persists.
After loooking into it, I realized the issue is git's index file. If
git-diff-index is called without --cached, the diff matches what's on
disk and works as I expect. However, the pre-commit hook calls it with
--cached which leads to the problem.
Thus, since I don't want to modify the pre-commit hook, the question is
what's the proper way to rebuild git's index file for all the files that
were to be committed but weren't due to the abort.
I've tried git-update-index with most of the flags with no success. I
only got it to update the index properly when I specifically specified a
filename with the problem, but I have a lot of files with the issue and
git already knows about them so I was hoping for a better method.
--
Gonzalo Garramuño
Film Aura
A New Dawn in Media Companies
gga@filmaura.com
http://www.filmaura.com
^ permalink raw reply
* Re: [PATCH] Teach core.autocrlf to 'git blame'
From: Marius Storm-Olsen @ 2007-10-17 10:57 UTC (permalink / raw)
To: git, Shawn O. Pearce
In-Reply-To: <1191586411-7436-1-git-send-email-marius@trolltech.com>
[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]
Just a reminder of this one, as I didn't see it any "What's in"
reports, nor your http://repo.or.cz/w/git/spearce.git repo.
(It's normal git.git patch, not an msysgit patch :-)
--
.marius
Marius Storm-Olsen said the following on 05.10.2007 14:13:
> Pass the fake commit through convert_to_git, so that the
> file is adjusted for local line-ending convention.
>
> Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
> ---
> Added missing signoff in the previous mail.
>
> builtin-blame.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-blame.c b/builtin-blame.c
> index e3112a2..8432b82 100644
> --- a/builtin-blame.c
> +++ b/builtin-blame.c
> @@ -2059,6 +2059,7 @@ static struct commit *fake_working_tree_commit(const char *path, const char *con
> if (strbuf_read(&buf, 0, 0) < 0)
> die("read error %s from stdin", strerror(errno));
> }
> + convert_to_git(path, buf.buf, buf.len, &buf);
> origin->file.ptr = buf.buf;
> origin->file.size = buf.len;
> pretend_sha1_file(buf.buf, buf.len, OBJ_BLOB, origin->blob_sha1);
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] Fixing path quoting in git-rebase
From: Johannes Sixt @ 2007-10-17 10:41 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: git, Jonathan del Strother
In-Reply-To: <11926134961549-git-send-email-maillist@steelskies.com>
Jonathan del Strother schrieb:
> git-rebase used to fail when run from a path with a space in.
>
> Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
> ---
> git-rebase.sh | 26 +++++++++++++-------------
> 1 files changed, 13 insertions(+), 13 deletions(-)
Looks good and works. Thanks.
-- Hannes
^ 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