* Re: [PATCH] Documentation: reworded the "Description" section of git-bisect.txt.
From: Michael J Gruber @ 2009-03-19 10:12 UTC (permalink / raw)
To: David J. Mellor; +Cc: gitster, git
In-Reply-To: <1237446012-4533-1-git-send-email-dmellor@whistlingcat.com>
David J. Mellor venit, vidit, dixit 19.03.2009 08:00:
> Added fixes missing from 2364259.
>
> Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
> ---
> Documentation/git-bisect.txt | 17 +++++++++--------
> 1 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
> index 51d06c1..1a4a527 100644
> --- a/Documentation/git-bisect.txt
> +++ b/Documentation/git-bisect.txt
> @@ -114,21 +114,22 @@ $ git bisect view --stat
> Bisect log and bisect replay
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> -The good/bad input is logged, and:
> +After having marked revisions as good or bad, then:
>
> ------------
> $ git bisect log
> ------------
>
> -shows what you have done so far. You can truncate its output somewhere
> -and save it in a file, and run:
> +shows what you have done so far. If you discover that you made a mistake
> +in specifying the status of a revision, you can save the output of this
> +command to a file, edit it to remove the incorrect entries, and then issue
> +the following commands to return to a corrected state:
>
I guess his tells me that I should not have taken the following
(http://article.gmane.org/gmane.comp.version-control.git/113568) literally:
David J. Mellor venit, vidit, dixit 18.03.2009 03:54:
> On 03/17/2009 02:18 AM, Michael J Gruber wrote:
>> One minor reoccurring issue is the following type of construct:
>>
>> ###
>> The good/bad input is logged, and:
>>
>> ------------
>> $ git bisect log
>> ------------
>>
>> shows what you have done so far.
>> ###
>>
>> The first line is not a complete sentence.
>
> I agree. I will send a revised patch (patch 2 in this sequence) that
> corrects this.
Again, I think the patch improves the documentation nicely, I just don't
think that construct is helpful.
> ------------
> +$ git bisect reset
> $ git bisect replay that-file
> ------------
>
> -if you find later that you made a mistake specifying revisions as good/bad.
> -
> Avoiding testing a commit
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>
> @@ -141,7 +142,7 @@ want to find a nearby commit and try that instead.
> For example:
>
> ------------
> -$ git bisect good/bad # previous round was good/bad.
> +$ git bisect good/bad # previous round was good or bad.
> Bisecting: 337 revisions left to test after this
> $ git bisect visualize # oops, that is uninteresting.
> $ git reset --hard HEAD~3 # try 3 revisions before what
> @@ -149,7 +150,7 @@ $ git reset --hard HEAD~3 # try 3 revisions before what
> ------------
>
> Then compile and test the chosen revision. Afterwards the revision
> -is marked as good/bad in the usual manner.
> +is marked as good or bad in the usual manner.
>
> Bisect skip
> ~~~~~~~~~~~~
> @@ -240,7 +241,7 @@ before compiling, run the real test, and afterwards decide if the
> revision (possibly with the needed patch) passed the test and then
> rewind the tree to the pristine state. Finally the script should exit
> with the status of the real test to let the "git bisect run" command loop
> -to determine the eventual outcome of the bisect session.
> +determine the eventual outcome of the bisect session.
>
> EXAMPLES
> --------
^ permalink raw reply
* Re: Advice wanted to set up GIT repository manually sync'ed form SVN
From: Michael J Gruber @ 2009-03-19 10:16 UTC (permalink / raw)
To: Aaron Gray; +Cc: Git Mailing List
In-Reply-To: <79BA5EFC11BE4E06A78D39D06D1549AF@HPLAPTOP>
Aaron Gray venit, vidit, dixit 18.03.2009 21:46:
> Hi,
>
> I am a realitive GIT newbie, ie I have not used GIT on a project but have
> read quite a lot of documentation on it, over the last year or so.
>
> We are wanting to have a git and git-web repository that is synced to a main
> SVN repository, wh only want to read the SVN repository at this stage. I am
> planning on using git-svn raw, and do fetch'es by hand.
>
> Is there any advice that I should know at this point before proceeding ?
Read-only access should be mostly pain-free, unless the structure of the
svn repo is unfriendly. If it exists already and is large I'd suggest to
do a few test conversions with limited revision range first, adjust the
config, optionally set up an author map and then go live.
Michael
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Johannes Schindelin @ 2009-03-19 10:19 UTC (permalink / raw)
To: Caleb Cushing; +Cc: saurabh gupta, david, Junio C Hamano, git
In-Reply-To: <81bfc67a0903182330q786ef01ai9148e41664a3471a@mail.gmail.com>
Hi,
On Thu, 19 Mar 2009, Caleb Cushing wrote:
> On Wed, Mar 18, 2009 at 7:16 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > In my humble opinion, we should focus on the data types we want to be
> > able to support at the end of the summer first.
>
> my 2 cents don't support xml, support sgml start at the least common
> denominator and refine from there.
Sorry, by "data type" I tried to refer to the nature of the file. I
should have said "file type".
Ciao,
Dscho
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Johannes Schindelin @ 2009-03-19 10:24 UTC (permalink / raw)
To: david; +Cc: saurabh gupta, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.10.0903190129110.4560@asgard.lang.hm>
Hi,
On Thu, 19 Mar 2009, david@lang.hm wrote:
> all three formats mentioned here (OOXML, ODF, SVG) are XML-based formats
> and a single flexible XML merge driver could potentially handle all
> three (as well as other formats). for that matter, the ODF specs cover
> multiple types of data, and I suspect that appropriate conflict markers
> for text could well end up being different than the ones for
> spreadsheets.
You are misunderstanding me.
The fact that all three are XML based has nothing to do with the _real_
goal of the project.
IOW a user trying to 3-way-merge ODF files could not care less if the
underlying technical details involve having an extra merge driver for XML
files or not.
The user cares about the ease of use, about the user interface. That is
what I want to focus on.
And if we end up with a beautiful XML merge driver at the end of the
summer that nobody uses, I will be not only a little disappointed.
So let's look at the _nature_ of the data at hand, i.e. text, marked-up
text, images (we could include UML, which is also XML-based, and where the
XML merge driver is as relevant for the user experience as for the
others), and how to make it _easy_ to resolve merge conflicts there.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 04/10] test-lib: Replace uses of $(expr ...) by POSIX shell features.
From: Johannes Schindelin @ 2009-03-19 10:27 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <49C1F673.9050500@viscovery.net>
Hi,
On Thu, 19 Mar 2009, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
>
> > On Wed, 18 Mar 2009, Johannes Sixt wrote:
> >
> >> In particular:
> >>
> >> - Test case counting can be achieved by arithmetic expansion.
> >>
> >> - The name of the test, e.g. t1234, can be computed with ${0%%} and
> >> ${0##}.
> >>
> >> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> >
> > I guess this makes the tests less slow on Windows? Do you have
> > numbers?
>
> Actually, while reading through test-lib.sh I found those expr
> expressions quite difficult to understand, and my primary intent was to
> make the code more readable. Furthermore, as you can see in the hunk
> that touches test_known_broken_{ok,failure}_ that the $(( )) construct
> is already in use, so it's also a change to improve consistency.
>
> The shorter runtime (primarily on Windows) is just a nice side effect,
> although the gain probably vanishes in the noise.
Actually, I should not have written that mail that late at night: 'expr'
is a bash builtin.
> > FWIW I run the tests on Windows with -j10 these days, and they take
> > about 15 minutes on a quad core 3GHz machine (which I may use from
> > time to time; the machine is not mine, otherwise it would run Linux).
>
> Last time I tried -j<something> it bailed out early. I didn't try again
> since then. Sequential tests finish in 30-40 minutes here, but I don't
> run SVN tests.
In msysGit, I updated the /share/msysGit/run-tests.sh script to make use
of -j5. If you work on a newer branch than 'devel', you most probably
need the changes from 'release-preview', as my
test-results/<basename>-<pid> patch broke the original assumption of
run-tests.sh.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 02/10] test suite: Use 'say' to say something instead of 'test_expect_success'
From: Johannes Schindelin @ 2009-03-19 10:29 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <49C1F8D6.1060309@viscovery.net>
Hi,
On Thu, 19 Mar 2009, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
>
> > I see that you exchanged one "say_color" by "say". What is the
> > difference?
>
> The color. It's a change towards consistency. I figured that the command
> to use by the tests is "say", while "say_color" is an implementation
> detail of test-lib.sh.
Fair enough. Could you say that in the commit message, too, so that
morons like me do not have to ask? ;-)
Thanks,
Dscho
^ permalink raw reply
* [PATCH] Define a version of lstat(2) with posix semantics
From: Alex Riesen @ 2009-03-19 10:27 UTC (permalink / raw)
To: Git Mailing List
Cc: Johannes Sixt, Jeff King, layer, Johannes Schindelin,
Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 972 bytes --]
So that Cygwin port can continue work around its supporting
library and get access to its faked file attributes.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
2009/3/18 Junio C Hamano <gitster@pobox.com>:
> Yuck; that's a bit too ugly for generic code. Will there be other places
> that this needs to be used? If so, we'd probably need to encourage its
> use where appropriate, which is even uglier but we cannot avoid it...
You are damn right! I suggest providing posix_lstat, which has the posix
semantics regarding x-bit in st_mode. Maybe even posix_stat is need, too.
There are other places which went broken recently in this regard (lstat
cache patches?). Some will have to use this posix_lstat (the
copy_templates_1), the others have to get a careful core.filemode
handling (like check_remove in diff-lib.c, which isn't just about
removed files).
git-compat-util.h | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
[-- Attachment #2: 0001-Define-a-version-of-lstat-2-with-posix-semantics.diff --]
[-- Type: application/octet-stream, Size: 1068 bytes --]
From b0e3710e7e60d8f81bf252ff9987e17ece4a3be3 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Thu, 19 Mar 2009 11:17:01 +0100
Subject: [PATCH] Define a version of lstat(2) with posix semantics
So that Cygwin port can continue work around its supporting
library and get access to its faked file attributes.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
git-compat-util.h | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 1906253..2401f84 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -85,11 +85,16 @@
#undef _XOPEN_SOURCE
#include <grp.h>
#define _XOPEN_SOURCE 600
+static inline int posix_lstat(const char *file_name, struct stat *buf)
+{
+ return lstat(file_name, buf);
+}
#include "compat/cygwin.h"
#else
#undef _ALL_SOURCE /* AIX 5.3L defines a struct list with _ALL_SOURCE. */
#include <grp.h>
#define _ALL_SOURCE 1
+#define posix_lstat lstat
#endif
#else /* __MINGW32__ */
/* pull in Windows compatibility stuff */
--
1.6.2.142.gaf8db
^ permalink raw reply related
* [PATCH] git clone needs to know executability of template files
From: Alex Riesen @ 2009-03-19 10:28 UTC (permalink / raw)
To: Git Mailing List
Cc: Johannes Sixt, Jeff King, layer, Johannes Schindelin,
Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 169 bytes --]
Use posix_lstat for template source.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
builtin-init-db.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
[-- Attachment #2: 0002-git-clone-needs-to-know-executability-of-template-fil.diff --]
[-- Type: application/octet-stream, Size: 814 bytes --]
From e7b9002e3157607aa251b85e4f94f5866d9bf375 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Thu, 19 Mar 2009 11:17:59 +0100
Subject: [PATCH 2/4] git clone needs to know executability of template files
Use posix_lstat for template source.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
builtin-init-db.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index ee3911f..0b6dc16 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -66,7 +66,7 @@ static void copy_templates_1(char *path, int baselen,
else
exists = 1;
- if (lstat(template, &st_template))
+ if (posix_lstat(template, &st_template))
die("cannot stat template %s", template);
if (S_ISDIR(st_template.st_mode)) {
--
1.6.2.142.gaf8db
^ permalink raw reply related
* Re: t5505-remote fails on Windows
From: Johannes Schindelin @ 2009-03-19 10:36 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, Jay Soffian, Git Mailing List
In-Reply-To: <20090319044313.GA341@coredump.intra.peff.net>
Hi,
On Thu, 19 Mar 2009, Jeff King wrote:
> @@ -163,9 +163,15 @@ static int cmp_items(const void *a, const void *b)
> return strcmp(one->string, two->string);
> }
>
> +void sort_string_list_with_fn(struct string_list *list,
> + int (*fn)(const void *, const void *))
> +{
> + qsort(list->items, list->nr, sizeof(*list->items), fn);
> +}
> +
Do we really want an API for that? Calling qsort() directly should be
obvious enough, no?
Ciao,
Dscho
^ permalink raw reply
* Re: Google Summer of Code 2009 - Accepted!
From: Johannes Schindelin @ 2009-03-19 10:39 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git
In-Reply-To: <20090319062906.GA13943@coredump.intra.peff.net>
Hi,
On Thu, 19 Mar 2009, Jeff King wrote:
> On Wed, Mar 18, 2009 at 10:21:05PM +0100, Johannes Schindelin wrote:
>
> > > Mentors for Git are really needed. I'm going to be too busy this
> > > summer to mentor a student myself. If we have no mentors, we'll
> > > have to pull out late, upsetting everyone, including my boss, and
> > > worse, LH.
> >
> > I think you need not be scared of a mentor shortage. In any case, I
> > am available.
>
> I can probably mentor, too. Is there anything mentors should be doing at
> this point, or do we just wait for applications?
Prospect mentors can add ideas to the ideas page. They can nudge possible
students to apply. And they can be ready to answer questions on the
list...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v3 0/2] cvsimport: add test illustrating a bug in cvsps
From: Michael J Gruber @ 2009-03-19 10:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Heiko Voigt, Michael Haggerty, ydirson, git
In-Reply-To: <7vfxhag07g.fsf@gitster.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 18.03.2009 19:22:
> Heiko Voigt <git-list@hvoigt.net> writes:
>
>> This is an updated version of the first patch and an addition to ensure
>> correct handling of branches in fixes.
>
> I've already merged the first one to 'next' so this needs to be turned
> into an incremental update if we were to continue building on top in the
> git project.
>
> I however have a bigger issue with this, perhaps because I do not have the
> feeling that I fully understand where these patches are going.
>
> Your approach seems to me to:
>
> - add tests to git test suite that expose issues the current cvsimport
> that runs on an unpatched cvsps has;
>
> - diagnose and fix
>
> - the issues in cvsimport, if the problem is because cvsimport is
> mishandling correct output from cvsps; or
>
> - the issues in cvsps (and adjust cvsimport to patched cvsps if
> necessary), if the problem is because output from cvsps is incorrect.
>
> That all feels sane, and having the tests to verify the end result would
> help the people who collaborate on these tasks.
>
> But how much of the actual fix will be made to cvsps, and how much to
> cvsimport? If the majority of the changes are to happen on cvsps (which
> is not unexpected, given that many people who tried and wrote various cvs
> importers put blame on the shortcomings of its output), I am afraid that
> it would not help majority of git users until the fixes to cvsps that come
> out of this effort hit their distros for me to keep these tests in the
> git.git repository. I do not build and install custom cvsps (because I
> haven't had to work with complex history in CVS that your improvements to
> cvsps are need to deal with correctly), and I suspect many others are in
> the same boat. In addition, if your tests are in the git.git repository,
> they need to say test_expect_success for people with patched cvsps and
> test_expect_failure for people without, and because I suspect that the
> majority of git developers do not run bleeding edge cvsps, it does not do
> anything but slowing down the test suite.
>
> It feels as if you are scratching my feet through my shoes while I still
> am wearing them. I wonder if it would be more direct and simpler approach
> to add tests to cvsps and handle these improvements as part of the cvsps
> maintenance/development effort, not as part of cvsimport fixes, at least
> initially.
>
> I think it is great that you started actively working on identifying and
> fixing issues with cvsps, that many others have gave up and gone to
> different avenues, and I certainly do not mind keeping the new tests in
> 'pu' for wider exposure, in order to make it easier for other people who
> use cvsimport and want to collaborate with you improving it through
> improving cvsps.
>
> But I am starting to think that it was a mistake on my part to have merged
> the initial set of tests to 'next'.
>
> Thoughts?
I second this, especially now that we've even got cvsps patches coming
to the git list. cvsps development should procede wherever all cvsps
developers can participate. It's not a central component of git.
In fact, the way git cvsimport uses cvsps may even mask some of cvsps's
behaviour. So, exposing cvsps bugs really only makes sense in a pure
cvsps test suite.
If git cvsimport is supposed to work around cvsps shortcomings then that
is supposed to be tested for in the git suite.
Right now this really seems to be going in the direction of: Make
everyone feel uneasy about working with git on cvs repos at all (aka
guerilla git), because git cvsimport still seems to be "recommended" or
"the standard", we have all this talk about how bad it is, and no clear
alternative.
I wish we had something saying: "If your cvs repo fulfills these
conditions you can use cvsimport. If not watch out for the following
(cvsps related) caveats. If you don't need two-way sync you're better of
with..."
Unfortunately, I'm not cvs(ps)-competent enough to spell out those
recommendations in detail.
Michael
^ permalink raw reply
* Re: [PATCH] Define a version of lstat(2) with posix semantics
From: Johannes Schindelin @ 2009-03-19 10:57 UTC (permalink / raw)
To: Alex Riesen
Cc: Git Mailing List, Johannes Sixt, Jeff King, layer, Junio C Hamano
In-Reply-To: <81b0412b0903190327l7745bf01i479fb84fae777af0@mail.gmail.com>
Hi,
On Thu, 19 Mar 2009, Alex Riesen wrote:
> So that Cygwin port can continue work around its supporting
> library and get access to its faked file attributes.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ---
[patch not inlined: therefore you'll have to guess what I am referring to]
It seems quite wrong to define something for other platforms when only
Cygwin is affected.
I'd rather just disable WIN32_STAT for Cygwin, because otherwise, we will
keep running into issues.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git clone needs to know executability of template files
From: Johannes Schindelin @ 2009-03-19 10:57 UTC (permalink / raw)
To: Alex Riesen
Cc: Git Mailing List, Johannes Sixt, Jeff King, layer, Junio C Hamano
In-Reply-To: <81b0412b0903190328n17007b4alcf5d91db562db62b@mail.gmail.com>
Hi,
On Thu, 19 Mar 2009, Alex Riesen wrote:
> Use posix_lstat for template source.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ---
As this patch builds on top of your earlier patch, you should have made a
patch series.
But as I said, I think it is wrong.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v3 0/2] cvsimport: add test illustrating a bug in cvsps
From: Johannes Schindelin @ 2009-03-19 11:00 UTC (permalink / raw)
To: Michael J Gruber
Cc: Junio C Hamano, Heiko Voigt, Michael Haggerty, ydirson, git
In-Reply-To: <49C22166.3000807@drmicha.warpmail.net>
Hi,
On Thu, 19 Mar 2009, Michael J Gruber wrote:
> cvsps development should procede wherever all cvsps developers can
> participate. It's not a central component of git.
You are forgetting a central fact to this discussion: cvsps is not
actively developed anymore.
Virtually all the "recent" patches going into cvsps (IIRC all patches
between the last two releases) were coming directly from the Git
community.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/3] document --force-rebase
From: Sverre Rabbelier @ 2009-03-19 11:01 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git, gitster
In-Reply-To: <1237399558-27289-2-git-send-email-barra_cuda@katamail.com>
Heya,
On Wed, Mar 18, 2009 at 19:05, Michele Ballabio <barra_cuda@katamail.com> wrote:
> Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
> ---
> Documentation/git-rebase.txt | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
Awesome, thanks! Perhaps you could, for extra brownie points, add a
line to the --whitespace=fix documentation that it implies
--force-rebase?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: t5505-remote fails on Windows
From: Junio C Hamano @ 2009-03-19 11:02 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Johannes Sixt, Jay Soffian, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0903191135530.10279@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 19 Mar 2009, Jeff King wrote:
>
>> @@ -163,9 +163,15 @@ static int cmp_items(const void *a, const void *b)
>> return strcmp(one->string, two->string);
>> }
>>
>> +void sort_string_list_with_fn(struct string_list *list,
>> + int (*fn)(const void *, const void *))
>> +{
>> + qsort(list->items, list->nr, sizeof(*list->items), fn);
>> +}
>> +
>
> Do we really want an API for that? Calling qsort() directly should be
> obvious enough, no?
I think so. If it were done like this (notice the lack of double
indirection in the cmp_fn signature):
typedef int string_list_item_cmp_fn(const struct string_list_item *, const struct string_list_item *);
void sort_string_list_with_fn(struct string_list *list, string_list_item_cmp_fn *);
it would have made more sense, though.
^ permalink raw reply
* Re: git svn unhandled.log compression
From: Sverre Rabbelier @ 2009-03-19 11:06 UTC (permalink / raw)
To: Tim Blechmann, Eric Wong; +Cc: git
In-Reply-To: <gps05u$905$1@ger.gmane.org>
Heya
[full message quoted as now ccing Eric]
On Thu, Mar 19, 2009 at 00:30, Tim Blechmann <tim@klingt.org> wrote:
> is there a way to compress the unhandled.log files, generated by git svn?
> tracking several projects with git svn, the unhandled.log files are
> larger, than the actual data ...
>
> e.g. the mirror of the svn repository of the boost library gives me:
> 135M .git/objects
> 283M .git/svn
>
> the unhandled.log files can be compressed at pretty high rates, these
> are the differently compressed files from the trunk of boost svn:
> 9.0M unhandled.log
> 584K unhandled.log.gz
> 396K unhandled.log.bz2
> 344K unhandled.log.lzma
>
> i am not familiar with the git svn codebase, so i am not sure, whether
> it is feasible to implement a compression of the unhandled.log files,
> but it would definitely save me quite a lot of hd space ...
On that note, Eric, what does the unhandled.log file do in the first
place? It's name would suggest it lists all revisions that aren't
handled yet, but the contents of the file seem to only grow over time,
what gives?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Google Summer of Code 2009 - Accepted!
From: Sverre Rabbelier @ 2009-03-19 11:16 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Shawn O. Pearce, git
In-Reply-To: <20090319062906.GA13943@coredump.intra.peff.net>
Heya,
On Thu, Mar 19, 2009 at 07:29, Jeff King <peff@peff.net> wrote:
> I can probably mentor, too. Is there anything mentors should be doing at
> this point, or do we just wait for applications?
You can apply to become a mentor for Git here [0], that is, by
clicking "Apply to become a mentor" in the GSoC2009 menu, and then
selecting Git as an organization.
[0] http://socghop.appspot.com/mentor/request/google/gsoc2009/git
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 02/10] test suite: Use 'say' to say something instead of 'test_expect_success'
From: Junio C Hamano @ 2009-03-19 11:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <alpine.DEB.1.00.0903191128120.10279@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Thu, 19 Mar 2009, Johannes Sixt wrote:
>
>> Johannes Schindelin schrieb:
>>
>> > I see that you exchanged one "say_color" by "say". What is the
>> > difference?
>>
>> The color. It's a change towards consistency. I figured that the command
>> to use by the tests is "say", while "say_color" is an implementation
>> detail of test-lib.sh.
>
> Fair enough. Could you say that in the commit message, too,...
Have done so already.
^ permalink raw reply
* Re: [PATCH v3 0/2] cvsimport: add test illustrating a bug in cvsps
From: Michael J Gruber @ 2009-03-19 11:22 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Heiko Voigt, Michael Haggerty, ydirson, git
In-Reply-To: <alpine.DEB.1.00.0903191159110.10279@pacific.mpi-cbg.de>
Johannes Schindelin venit, vidit, dixit 19.03.2009 12:00:
> Hi,
>
> On Thu, 19 Mar 2009, Michael J Gruber wrote:
>
>> cvsps development should procede wherever all cvsps developers can
>> participate. It's not a central component of git.
>
> You are forgetting a central fact to this discussion: cvsps is not
> actively developed anymore.
>
> Virtually all the "recent" patches going into cvsps (IIRC all patches
> between the last two releases) were coming directly from the Git
> community.
Well, then I guess "wherever all cvsps developers can participate" is de
facto here...
Still it's not in the git codebase. git cvsimport may expose cvsps short
comings, but testing cvsps in git's test suite does not seem right.
Michael
^ permalink raw reply
* Gnome chose Git
From: Teemu Likonen @ 2009-03-19 11:23 UTC (permalink / raw)
To: git
FYI: The Gnome release team just announced that Gnome will migrate from
Subversion to Git:
http://thread.gmane.org/gmane.comp.gnome.infrastructure/1134
^ permalink raw reply
* Re: Gnome chose Git
From: Sverre Rabbelier @ 2009-03-19 11:29 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git
In-Reply-To: <877i2lbvt7.fsf@iki.fi>
Heya,
On Thu, Mar 19, 2009 at 12:23, Teemu Likonen <tlikonen@iki.fi> wrote:
> FYI: The Gnome release team just announced that Gnome will migrate from
> Subversion to Git:
>
> http://thread.gmane.org/gmane.comp.gnome.infrastructure/1134
Sweet, now how long until my university starts offering git hosting
and my fellow students start using it in their projects? :P
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Gnome chose Git
From: Mike Ralphson @ 2009-03-19 11:33 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git
In-Reply-To: <877i2lbvt7.fsf@iki.fi>
2009/3/19 Teemu Likonen <tlikonen@iki.fi>:
> FYI: The Gnome release team just announced that Gnome will migrate from
> Subversion to Git:
>
> http://thread.gmane.org/gmane.comp.gnome.infrastructure/1134
There does seem to be a typo in the release though.
"We realize that git is not perfect, and that the transition will
require significant and important changes to many GNOME processes."
s/ not//
There, fixed that.
Seriously, they should be advocating a c) there, contributing
improvements back to git (and whichever svn migration tool they used)
for the benefit of all, which I'm sure we'll see.
Mike
^ permalink raw reply
* Re: git svn unhandled.log compression
From: Tim Blechmann @ 2009-03-19 12:18 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Eric Wong, git
In-Reply-To: <fabb9a1e0903190406r31396bbao2717f94d7269b50a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 612 bytes --]
>> i am not familiar with the git svn codebase, so i am not sure, whether
>> it is feasible to implement a compression of the unhandled.log files,
>> but it would definitely save me quite a lot of hd space ...
>
> On that note, Eric, what does the unhandled.log file do in the first
> place? It's name would suggest it lists all revisions that aren't
> handled yet, but the contents of the file seem to only grow over time,
> what gives?
according to the man page, it logs unhandled svn properties
tim
--
tim@klingt.org
http://tim.klingt.org
art is short - life is long
Jack Kerouac
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] git-gui: various French translation fixes
From: Sam Hocevar @ 2009-03-19 12:49 UTC (permalink / raw)
To: Christian Couder; +Cc: Git List, Alexandre Bourget
In-Reply-To: <20090319075855.GJ27280@zoy.org>
On Thu, Mar 19, 2009, Sam Hocevar wrote:
> On Thu, Mar 19, 2009, Christian Couder wrote:
> > > > #: git-gui.sh:2484 lib/index.tcl:410
> > > > msgid "Revert Changes"
> > > > -msgstr "Annuler les modifications (revert)"
> > > > +msgstr "Révoquer les modifications"
> > >
> > > I am not sure that "Révoquer" is better than "Annuler".
> >
> > Perhaps "Inverser"?
>
> I suggested "révoquer" because it was close enough to "revert" that
> there was no need to specify "(revert)" in the translation itself.
> It's what the French Wikipedia interface used to say to revert edits.
> But I see they now use "défaire" (undo), so apparently they deemed
> it inappropriate for some reason. I have no strong preference for
> "Inverser" or even "Annuler", I just want it to be consistent and to get
> rid of the "(revert)" at the end of this message.
Sorry, I misread the Wikipedia interface because I wasn't logged in
and only admins can truly revert edits. So it does have "revert" (to
cancel an edit) and "undo" (to perform the opposite edit of a given
edit), which get translated to "révoquer" and "défaire". I therefore
think "révoquer" is just as good as the others.
--
Sam.
^ 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