* 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
* Re: [PATCH] Introduce a filter-path argument to git-daemon, for doing custom path transformations
From: Johan Sørensen @ 2009-03-19 13:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0903190107001.10279@pacific.mpi-cbg.de>
2009/3/19 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> I actually was hoping (especially we have Dscho on Cc: list) that somebody
>> like you would start suggesting a "plug in" approach to load .so files,
>> which would lead to a easy-to-port dso support with the help from msysgit
>> folks we can use later in other parts of the system (e.g. customizable
>> filters used for diff textconv, clean/smudge, etc.)
>
> I do not like that at all. Dynamic libraries -- especially on Windows --
> are a major hassle.
>
> However, I cannot think of anything Johan might want to do that would not
> be possible using a bunch of regular expressions together with
> substitions.
Let me reiterate my use-case then: I need to dynamically substitute
one path with another. Perhaps "map" paints a better picture than
"substitute" here. Please refer to my second mail in this thread for
more details.
The only way I can see regexps work, is that if they're read, on a
per-request basis (reloading git-daemon every time they change is just
silly), from somewhere outside the git-daemon. Then, you might as well
take the full-on approach this patch provides.
Cheers,
JS
>
> FWIW I have experimental code in my personal tree that sports
> strbuf_regsub(), a function to replace matches of a regular expression
> (possibly with groups) by a given string (which may contain \0 .. \9,
> being replaced with the respective group's contents).
>
> Ciao,
> Dscho
>
^ permalink raw reply
* Re: Gnome chose Git
From: Michael J Gruber @ 2009-03-19 13:33 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git
In-Reply-To: <877i2lbvt7.fsf@iki.fi>
Teemu Likonen venit, vidit, dixit 19.03.2009 12:23:
> FYI: The Gnome release team just announced that Gnome will migrate from
> Subversion to Git:
>
> http://thread.gmane.org/gmane.comp.gnome.infrastructure/1134
Good choice :)
Interestingly, they seem to go the svn-all-fast-export route.
Also, they need push tracking for pushing through ssh, which is a common
requirement for many large projects. Do we have something to support
that? git-notes comes to my mind.
Their current approach is writing to a single log file (receive-hook).
That may support a linear push history best, but looking up who pushed
what, given "what"?
Michael
^ permalink raw reply
* gitk-git/Makefile install: mkdir missing
From: Andreas Gruenbacher @ 2009-03-19 13:46 UTC (permalink / raw)
To: git
I needed this change to get "make install DESTDIR=..." to work here:
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
index e1b6045..3021be0 100644
--- a/gitk-git/Makefile
+++ b/gitk-git/Makefile
@@ -40,6 +40,7 @@ endif
all:: gitk-wish $(ALL_MSGFILES)
install:: all
+ $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
$(INSTALL) -m 755 gitk-wish '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(msgsdir_SQ)'
$(foreach p,$(ALL_MSGFILES), $(INSTALL) -m 644
$p '$(DESTDIR_SQ)$(msgsdir_SQ)' &&) true
Andreas
^ permalink raw reply related
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