* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-22 18:58 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.L FD.0.999.0707221031050.3607@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, 22 Jul 2007, David Kastrup wrote:
>>
>> So when we are talking about a repository tree _becoming_ empty, we
>> need the information whether or whether not we should remove it upon
>> becoming empty.
>
> You don't seem to realize - although I've told you now abotu a million
> times - that what you are talking about is:
>
> - technically exactly the same as ".gitignore", which for some
> unfathomable reason you cannot seem to accept.
Linus? Do both of us a favor and forget about the "." proposal.
Since I already dropped it, we can save time if you rant about the
proposal I have replaced it with and call me an idiot for a different
reason.
> Quite frankly, Junio would be a total idiot to take any patches that do
> what you want to do. Happily, he is anything but.
And he does not come across as one.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Johannes Schindelin @ 2007-07-22 19:00 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910707221148g69d7600bk632abb7452ce9c7c@mail.gmail.com>
Hi,
[culling lkml list, since this is really a Git problem]
On Sun, 22 Jul 2007, Jon Smirl wrote:
> It would really be useful if git diff had an option for suppressing
> diffs caused by CVS keyword expansion.
Looks to me slightly a bit like an XY problem.
How about using git-filter-branch to get rid of the expansions? Or even
better, if you have access to the CVS server, use the -k option to
cvsimport?
Hth,
Dscho
^ permalink raw reply
* Re: executing git from a non git directory
From: Patrick Aljord @ 2007-07-22 19:02 UTC (permalink / raw)
To: git
In-Reply-To: <20070722071136.GA346@coredump.intra.peff.net>
ok thanx to both of you Jeff and Shawn for the info.
On 7/22/07, Jeff King <peff@peff.net> wrote:
> git --work-tree=/path/to/my_git_dir --git-dir=/path/to/my_git_dir/.git status
>
> which is what you actually want.
ok, I'm going to try that, thanx.
Pat
^ permalink raw reply
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Linus Torvalds @ 2007-07-22 19:09 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List, lkml
In-Reply-To: <9e4733910707221148g69d7600bk632abb7452ce9c7c@mail.gmail.com>
On Sun, 22 Jul 2007, Jon Smirl wrote:
>
> It would really be useful if git diff had an option for suppressing
> diffs caused by CVS keyword expansion.
I really think it's not a "git diff" issue, but it might be a "import"
issue.
IOW, I think you'd be a *lot* better off just not importing those things
in the first place (which is what CVS does internally), or possibly
importing them as two trees (ie you'd have the "non-log" version and the
"log expansion" version, so that you can track and compare both).
Doing the thing at "diff" time is certainly possible, but this is simply
much better done as a totally independent preprocessing phase. The diff
handling is already some of the more complex parts (and very central), it
would be much simpler and efficient to not try to make that thing fancier,
and instead solve the problem at the front-end.
Linus
^ permalink raw reply
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Jon Smirl @ 2007-07-22 19:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0707221959100.14781@racer.site>
On 7/22/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> [culling lkml list, since this is really a Git problem]
>
> On Sun, 22 Jul 2007, Jon Smirl wrote:
>
> > It would really be useful if git diff had an option for suppressing
> > diffs caused by CVS keyword expansion.
>
> Looks to me slightly a bit like an XY problem.
>
> How about using git-filter-branch to get rid of the expansions? Or even
> better, if you have access to the CVS server, use the -k option to
> cvsimport?
No access to the server the people handing over the diffs and not
making things easy. You get diffs like this when asking companies to
turn over their changes for GPL compliance purposes. A big source is
from companies building embedded systems., Usually the diffs are
pretty worthless but every once in a while they contain very useful
nuggets (like inadvertently documenting secret hardware features). It
is hard to spot the nuggets in all of the noise.
>
> Hth,
> Dscho
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Jon Smirl @ 2007-07-22 19:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, lkml
In-Reply-To: <alpine.LFD.0.999.0707221205080.3607@woody.linux-foundation.org>
On 7/22/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Sun, 22 Jul 2007, Jon Smirl wrote:
> >
> > It would really be useful if git diff had an option for suppressing
> > diffs caused by CVS keyword expansion.
>
> I really think it's not a "git diff" issue, but it might be a "import"
> issue.
>
> IOW, I think you'd be a *lot* better off just not importing those things
> in the first place (which is what CVS does internally), or possibly
> importing them as two trees (ie you'd have the "non-log" version and the
> "log expansion" version, so that you can track and compare both).
>
> Doing the thing at "diff" time is certainly possible, but this is simply
> much better done as a totally independent preprocessing phase. The diff
> handling is already some of the more complex parts (and very central), it
> would be much simpler and efficient to not try to make that thing fancier,
> and instead solve the problem at the front-end.
These diffs are coming from companies doing GPL compliance without
really wanting to comply. CVS servers are not made available.
>
> Linus
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Johannes Schindelin @ 2007-07-22 19:15 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910707221210t2b2896b5ob4ce7bf95d4a707a@mail.gmail.com>
Hi,
On Sun, 22 Jul 2007, Jon Smirl wrote:
> On 7/22/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Sun, 22 Jul 2007, Jon Smirl wrote:
> >
> > > It would really be useful if git diff had an option for suppressing
> > > diffs caused by CVS keyword expansion.
> >
> > Looks to me slightly a bit like an XY problem.
> >
> > How about using git-filter-branch to get rid of the expansions? Or
> > even better, if you have access to the CVS server, use the -k option
> > to cvsimport?
>
> No access to the server the people handing over the diffs and not
> making things easy.
Ah yes, that's what I feared. Darn.
But still, I think that it would be much better not to put this into Git.
We do have diff gitattributes now, so that you can roll your own diff for
specific files, but I still think that this is more a task for a
standalone perl script. Possibly being called from filter-branch to be
done with the conversion once and for all times.
Ciao,
Dscho
^ permalink raw reply
* Re: diffutils: C labels misdetected as functions
From: Simon Arlott @ 2007-07-22 19:16 UTC (permalink / raw)
To: Paul Eggert
Cc: Matthew Wilcox, Denis Cheng, kernel-janitors, linux-kernel, git
In-Reply-To: <87abtogu6u.fsf@penguin.cs.ucla.edu>
On 22/07/07 19:38, Paul Eggert wrote:
> Simon Arlott <simon@fire.lp0.eu> writes:
>
>> The patch below stops diffutils treating C labels starting in column 1 as function names.
>
> That patch alone wouldn't suffice, since -p is documented as implying
> -F '^[[:alpha:]$_]'. If the behavior changes, we'd also have to
> change the documentation to match.
Ok.
> I'm not sure the change is a good idea. It would complicate the
> documentation and therefore the user interface, without that much
Complicated documentation means a bug shouldn't be fixed?
> benefit. And it wouldn't suffice in general, since it would still
> mishandle labels followed by comments or by white space.
Yes, the regexp needs changing further to ignore comments...
"[[:alpha:]$_][^:]*$" perhaps? Although that ignores functions with
comments on the same line containing a :.
> Also, for long C functions some people might rather see a top-level
> (unindented) label highlighted than the function name highlighted, so
> they might prefer the current behavior.
"-p --show-c-function Show which C function each change is in."
It's not "--show-c-function-or-label".
> Anyway, to work around your problem without changing "diff", you can
> use "diff -u -F '^[[:alpha:]$_](|.*[^:])$'" instead of "diff -u -p".
Perhaps git could do this (or similar) as a workaround? (Cc:ed)
> Or you can put a single space before the labels in question: they'll
> still stand out plenty.
The code should definitely not need to be modified to work around a
diff bug.
--
Simon Arlott
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Daniel Barkalow @ 2007-07-22 19:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707221956210.14781@racer.site>
On Sun, 22 Jul 2007, Johannes Schindelin wrote:
> A word of warning: switching to _same_ branch that is checked out in
> the other repository is asking for trouble. You are really working not
> only on the same object database, but also the same (i.e. not copied)
> refs namespace.
It's probably time to revive Junio's patch for keeping the
fully-dereferenced value of HEAD in the index, to make this safer.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: David Kastrup @ 2007-07-22 19:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Smirl, Git Mailing List, lkml
In-Reply-To: <alpine.LFD.0.999.0707221205080.3607@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, 22 Jul 2007, Jon Smirl wrote:
>>
>> It would really be useful if git diff had an option for suppressing
>> diffs caused by CVS keyword expansion.
>
> I really think it's not a "git diff" issue, but it might be a "import"
> issue.
>
> IOW, I think you'd be a *lot* better off just not importing those
> things in the first place (which is what CVS does internally), or
> possibly importing them as two trees (ie you'd have the "non-log"
> version and the "log expansion" version, so that you can track and
> compare both).
One problem is that those strings more often than not are involved in
some magic computation, like placing version and date information into
extracted output. While an import of the unexpanded version is really
the sanest option, it might render the resulting code inoperable.
CVS diff itself reports those differences, too (and it makes for a
good quota of merge problems even in CVS), so it is not like we are in
bad company here.
Uh, strike that.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Johannes Schindelin @ 2007-07-22 19:24 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707221511410.29679@iabervon.org>
Hi,
On Sun, 22 Jul 2007, Daniel Barkalow wrote:
> On Sun, 22 Jul 2007, Johannes Schindelin wrote:
>
> > A word of warning: switching to _same_ branch that is checked out in
> > the other repository is asking for trouble. You are really working not
> > only on the same object database, but also the same (i.e. not copied)
> > refs namespace.
>
> It's probably time to revive Junio's patch for keeping the
> fully-dereferenced value of HEAD in the index, to make this safer.
Yeah, probably.
Anyway, I will probably run with 'master'+this patch until 1.5.3 is
released.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] some feedbacks from the Italian Free Translation Project.
From: Johannes Schindelin @ 2007-07-22 19:35 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <20070722201942.609543f1@paolo-desktop>
Hi,
On Sun, 22 Jul 2007, Paolo Ciarrocchi wrote:
> Many thanks to the Italian Free Translation Project
>
> More patches in the following days.
>
> Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
Thanks. Both of your patches applied, although I had to fix non-UTF-8
encoding. This could well be a problem on my side.
Ciao,
Dscho
^ permalink raw reply
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Linus Torvalds @ 2007-07-22 19:37 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List, lkml
In-Reply-To: <9e4733910707221212v2f6cc1c4kf7a35e84f351e4cd@mail.gmail.com>
On Sun, 22 Jul 2007, Jon Smirl wrote:
> On 7/22/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >
> >
> > On Sun, 22 Jul 2007, Jon Smirl wrote:
> > >
> > > It would really be useful if git diff had an option for suppressing
> > > diffs caused by CVS keyword expansion.
> >
> > I really think it's not a "git diff" issue, but it might be a "import"
> > issue.
> >
> > IOW, I think you'd be a *lot* better off just not importing those things
> > in the first place (which is what CVS does internally), or possibly
> > importing them as two trees (ie you'd have the "non-log" version and the
> > "log expansion" version, so that you can track and compare both).
> >
> > Doing the thing at "diff" time is certainly possible, but this is simply
> > much better done as a totally independent preprocessing phase. The diff
> > handling is already some of the more complex parts (and very central), it
> > would be much simpler and efficient to not try to make that thing fancier,
> > and instead solve the problem at the front-end.
>
> These diffs are coming from companies doing GPL compliance without
> really wanting to comply. CVS servers are not made available.
That wasn't what I said.
You want to supporess the CVS keyword expansion.
I'm telling you that you should just do so.
But I'm *also* telling you that this has nothing to do with "git diff".
The way to get "git diff" to not show the CVS expansion is to *remove* the
CVS expansion. By simply running some pre-processing on the patches
*before* you put them into git in the first place (or, like Dscho
suggested: you could do it later too, by using git filter-branch).
Once you have the version that doesn't have the CVS log, "git diff" will
automatically do the rigth thing.
In other words, I'm just saying that you're trying to solve the wrong
problem. Once you solve the *right* problem, the wrong problem just goes
away.
Linus
^ permalink raw reply
* Test #7 in t9200-git-cvsexportcommit fails
From: Jason Sewall @ 2007-07-22 19:41 UTC (permalink / raw)
To: git, Junio C Hamano
This test fails for me on the current head (pulled just now) and where
the test was introduced (e86ad71fe).
All other tests pass.
I know almost nothing about how CVS works internally, so I don't have
any insight as to the cause of this problem - all I can see is that
the contents of CVS/Entries has the 'with spaces' files at 1.1 instead
of the expect 1.2.
I'm happy to provide more information if you can tell me how to get
it. In particular, I'd like to tell you about my version of perl-cvs
(or whatever it's called) but I have no idea how to do that...
Jason
P.S. I don't use this part of git at all, so this is not a priority
for me. I am using Fedora 7, which is definitely a mainstream distro,
so I imagine others might have this problem too.
^ permalink raw reply
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Jan Engelhardt @ 2007-07-22 19:47 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List, lkml
In-Reply-To: <9e4733910707221148g69d7600bk632abb7452ce9c7c@mail.gmail.com>
On Jul 22 2007 14:48, Jon Smirl wrote:
>
> It would really be useful if git diff had an option for suppressing
> diffs caused by CVS keyword expansion. I run into this problem over
> and over when trying to recover stuff out of old kernel sources that
> people checked into CVS and then posted CVS diffs to fulfill their GPL
> obligations. I sometimes wonder if vendors are doing this on purpose
> to make it more difficult to recover the changes they made to the
> code.
>
> To prevent this in the future, I'd love to see a patch removing all
> CVS keywords from the kernel sources.
I say: yes please. Even svn (which Linus dislikes very much) has cvs
keywords disabled by default. And at the same time, a patch to
CodingStyle not to include CVS tags, and a patch to checkpatch.pl
to enforce it :)
> Quick grep of kernel shows 1,535 $Id, 197 $Log, 441 $Revision, 144 $Date. I
> guestimate that this would remove about 5,000 lines form the kernel source
> and touch 1,700 files. Would this be accept or do those expansions contain
> useful info?
Common argument for $Id$ tags has been, that upon a problem, a user
can look into dmesg (or whatever log is appropraite - it's not
limited to the kernel) for the version string instead of figuring it
out himself (by means or rpm -q, or whatever hides it).
For the Linux kernel however, I do not think it is important, since:
- the code of a module changes faster than you can think (e.g.
a change in the network code touched a network filesystem). Result:
same $Id$ tag in the vendor's version AND the mainline version.
So the tag is useless.
- you know what version you are running, mingetty usually prints it
for you; uname -a also shows it.
- if you have a problem, people kindly ask you to bisect anyway, in
which case $Id$ numbers become irrelevant anyway, because you got
the git SHA1 ids.
Yep, that's pretty much it from my side. Conclusion: Remove CVS
tags from kernel.
Jan
--
^ permalink raw reply
* Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
From: Jon Smirl @ 2007-07-22 19:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0707222013200.14781@racer.site>
On 7/22/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> But still, I think that it would be much better not to put this into Git.
> We do have diff gitattributes now, so that you can roll your own diff for
> specific files, but I still think that this is more a task for a
> standalone perl script. Possibly being called from filter-branch to be
> done with the conversion once and for all times.
I can provide sample diffs if you want something to play with.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Initial Italian translation of git-gui.pot
From: Michael @ 2007-07-22 19:28 UTC (permalink / raw)
To: git; +Cc: Paolo Ciarrocchi
In-Reply-To: <20070722124236.47baacb1@paolo-desktop>
On Sunday 22 July 2007 12:42, Paolo Ciarrocchi wrote:
> Initial Italian translation
>
> Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
io userei queste parole:
merge unione, fusione/unire, fondere
commit salvataggio/salvare (forse troppo inflazionato)
amend correzione/correggere
hunk parte
fetch prendi da
Per il resto, avrei tradotto più o meno come segue. Che ne dici?
> ---
> po/it.po | 118 +++++++++++++++++++++++++++++++-------------------------------
> 1 files changed, 59 insertions(+), 59 deletions(-)
>
> diff --git a/po/it.po b/po/it.po
> index e8b8cdb..780519e 100644
> --- a/po/it.po
> +++ b/po/it.po
...
> #: git-gui.sh:1820 git-gui.sh:2176
> msgid "Rescan"
> -msgstr ""
> +msgstr "Analizza"
"Riesamina database"?
> #: git-gui.sh:2229
> msgid "Amended Commit Message:"
> -msgstr ""
> +msgstr "Annulla messaggio del Commit"
"Correzione del messaggio da salvare:"?
> #: git-gui.sh:2230
> msgid "Amended Initial Commit Message:"
> -msgstr ""
> +msgstr "Annulla messaggio iniziale del Commit"
"Correzione del messaggio iniziale:"?
> #: git-gui.sh:2231
> msgid "Amended Merge Commit Message:"
> -msgstr ""
> +msgstr "Annulla messaggio di incorporamento"
"Correzione messaggio dell'unione"?
> #: git-gui.sh:2431
> msgid "Decrease Font Size"
> -msgstr ""
> +msgstr "Diminuisci dimensione Font"
font -> carattere?
> #: git-gui.sh:2435
> msgid "Increase Font Size"
> -msgstr ""
> +msgstr "Aumenta dimensione Font"
>
> #: git-gui.sh:2440
> msgid "Show Less Context"
> -msgstr ""
> +msgstr "Mostra meno contenuto"
contenuto -> contesto?
> #: git-gui.sh:2447
> msgid "Show More Context"
> -msgstr ""
> +msgstr "Mostra più contenuto"
^ permalink raw reply
* [KORG] gitweb down?
From: Linus Torvalds @ 2007-07-22 20:19 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: webmaster, Git Mailing List
In-Reply-To: <46A39CEA.7020703@zytor.com>
Oops, what happened to
http://git.kernel.org/?p=git/git.git;a=summary
(same for the kernel, btw)?
The main git.kernel.org page loads about half-way (without any stated
errors, but it's definitely broken and not complete), but the summary
pages don't seem to load at all (some projects do, but git and kernel
don't - it looks like the *cache* may still be working, but anything new
gets a "500 Internal Server Error").
Linus
^ permalink raw reply
* [PATCH] fsck --lost-found: write blob's contents, not their SHA-1
From: Johannes Schindelin @ 2007-07-22 20:20 UTC (permalink / raw)
To: git, gitster
When looking for a lost blob, it is much nicer to be able to grep
through .git/lost-found/other/* than to write an inefficient loop
over the file names. So write the contents of the dangling blobs,
not their object names.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
While working on filter-branch, I inadvertently said
"git reset --hard" without having committed first. That's
when I was almost happy to have "git fsck --lost-found".
But when grepping through the "other" found objects, nothing
turned up... because there were only SHA-1s.
Documentation/git-fsck.txt | 6 ++++--
builtin-fsck.c | 12 +++++++++++-
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index 1a432f2..45c0bee 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -65,8 +65,10 @@ index file and all SHA1 references in .git/refs/* as heads.
Be chatty.
--lost-found::
- Write dangling refs into .git/lost-found/commit/ or
- .git/lost-found/other/, depending on type.
+ Write dangling objects into .git/lost-found/commit/ or
+ .git/lost-found/other/, depending on type. If the object is
+ a blob, the contents are written into the file, rather than
+ its object name.
It tests SHA1 and general object sanity, and it does full tracking of
the resulting reachability and everything else. It prints out any
diff --git a/builtin-fsck.c b/builtin-fsck.c
index 350ec5e..8d12287 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -152,7 +152,17 @@ static void check_unreachable_object(struct object *obj)
}
if (!(f = fopen(filename, "w")))
die("Could not open %s", filename);
- fprintf(f, "%s\n", sha1_to_hex(obj->sha1));
+ if (obj->type == OBJ_BLOB) {
+ enum object_type type;
+ unsigned long size;
+ char *buf = read_sha1_file(obj->sha1,
+ &type, &size);
+ if (buf) {
+ fwrite(buf, size, 1, f);
+ free(buf);
+ }
+ } else
+ fprintf(f, "%s\n", sha1_to_hex(obj->sha1));
fclose(f);
}
return;
--
1.5.3.rc2.32.g35c5b
^ permalink raw reply related
* Never mind (Re: [KORG] gitweb down?)
From: Linus Torvalds @ 2007-07-22 20:21 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: webmaster, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0707221316050.3607@woody.linux-foundation.org>
On Sun, 22 Jul 2007, Linus Torvalds wrote:
>
> The main git.kernel.org page loads about half-way (without any stated
> errors, but it's definitely broken and not complete), but the summary
> pages don't seem to load at all (some projects do, but git and kernel
> don't - it looks like the *cache* may still be working, but anything new
> gets a "500 Internal Server Error").
Ok, retried immediately after sending the email, and it's ok now. So never
mind - I probably tested just when some update was in progress..
Linus
^ permalink raw reply
* Re: Test #7 in t9200-git-cvsexportcommit fails
From: Alex Riesen @ 2007-07-22 20:21 UTC (permalink / raw)
To: Jason Sewall; +Cc: git, Junio C Hamano
In-Reply-To: <31e9dd080707221241j5c00aaaaqa79c12d3e2a3345b@mail.gmail.com>
Jason Sewall, Sun, Jul 22, 2007 21:41:53 +0200:
> This test fails for me on the current head (pulled just now) and where
> the test was introduced (e86ad71fe).
Aahh, the test where CVS failed to commit sub-second changes...
It never really succeeded.
> P.S. I don't use this part of git at all, so this is not a priority
> for me. I am using Fedora 7, which is definitely a mainstream distro,
> so I imagine others might have this problem too.
Just disable it:
$ echo "export GIT_SKIP_TESTS = t9200" >>config.mak
It'll never work, cvs does not commit changes made during one second,
as they have the same timestamp.
If you feel interested, try investigating the test by running it with
"-d -v", like this:
$ cd t
$ ./t9200-git-cvsexportcommit.sh -d -v -i
You'll have to run it multiple times, probably: the problem is
sometimes timing dependent and changed output conditions may make it
go away for a while. Just continue trying.
^ permalink raw reply
* Re: [PATCH] Initial Italian translation of git-gui.pot
From: Johannes Schindelin @ 2007-07-22 20:22 UTC (permalink / raw)
To: Michael; +Cc: git, Paolo Ciarrocchi
In-Reply-To: <200707222128.05884.barra_cuda@katamail.com>
Hi,
On Sun, 22 Jul 2007, Michael wrote:
> On Sunday 22 July 2007 12:42, Paolo Ciarrocchi wrote:
> > Initial Italian translation
> >
> > Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
>
> io userei queste parole:
>
> merge unione, fusione/unire, fondere
> commit salvataggio/salvare (forse troppo inflazionato)
> amend correzione/correggere
> hunk parte
> fetch prendi da
>
> Per il resto, avrei tradotto pi? o meno come segue. Che ne dici?
Mi piace, ma non sono Italiano...
Ciao,
Dscho
^ permalink raw reply
* Re: Never mind (Re: [KORG] gitweb down?)
From: H. Peter Anvin @ 2007-07-22 20:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: webmaster, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0707221320130.3607@woody.linux-foundation.org>
Linus Torvalds wrote:
>
> On Sun, 22 Jul 2007, Linus Torvalds wrote:
>> The main git.kernel.org page loads about half-way (without any stated
>> errors, but it's definitely broken and not complete), but the summary
>> pages don't seem to load at all (some projects do, but git and kernel
>> don't - it looks like the *cache* may still be working, but anything new
>> gets a "500 Internal Server Error").
>
> Ok, retried immediately after sending the email, and it's ok now. So never
> mind - I probably tested just when some update was in progress..
>
No, it ran out of disk space; I just cleaned it out.
-hpa
^ permalink raw reply
* Re: Test #7 in t9200-git-cvsexportcommit fails
From: Jason Sewall @ 2007-07-22 20:49 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20070722202121.GA3288@steel.home>
> It'll never work, cvs does not commit changes made during one second,
> as they have the same timestamp.
Why not add a delay in there, like this:
id=$(git rev-list --max-count=1 HEAD) && sleep 2
It makes the test work for me.
Jason
^ permalink raw reply
* Git tree for old kernels from before the current tree
From: Jon Smirl @ 2007-07-22 20:49 UTC (permalink / raw)
To: Git Mailing List, lkml
Continuing on with kernel archeology for embedded systems, any
interest in making a git tree with all of the kernel versions from the
beginning up to the start of the current git tree? No history in the
tree, just a simple way to quickly fetch and select a copy of all the
various old releases. I know they are all available ftp, git tree
would organize them all in one place and let you fetch them all at
once.
If this is small enough you could add it to the current kernel tree.
Git's super diffing performance might make this fairly small.
My dream system lets me checkout an ancient version, apply the diff
from the vendor (or expand a tarball), use git status to see what
files changed, and git diff to get detailed changes (all minus CVS
keyword expansion noise). Major bonus points if it can detect detect a
subsystem that has been backported.
--
Jon Smirl
jonsmirl@gmail.com
^ 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