* Re: git doc build failure on OS X 10.5.6 (Leopard) during xmlto phase
From: Michael J Gruber @ 2009-03-11 16:27 UTC (permalink / raw)
To: Jay Soffian; +Cc: Tom Holaday, git
In-Reply-To: <76718490903110849x2ef48a89j3f17706390991eda@mail.gmail.com>
Jay Soffian venit, vidit, dixit 11.03.2009 16:49:
> On Wed, Mar 11, 2009 at 11:39 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
>> On Wed, Mar 11, 2009 at 11:12 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
>>> And your man pages still won't be perfect. Preformatted text will look
>>> like this:
>>>
>>> .ft C
>>> ...
>>> .ft
> I must be losing my mind. This is suddenly working, though I can't
> track it down to any change in git. I just rebuilt my man pages and
> this no longer is occurring, even though I still have a terminal
> window open with the output of "git help help" _showing this problem_
> and that's from man pages I built/installed just a few days ago. (And
> I haven't upgraded MacPorts lately.)
>
> Oh well.
>
> j.
FWIW: The effect you describe (which is different from the OP) occurs on
Fedora 10 as well, and not only for git man pages, also for others. I've
been meaning to look into this, just like I've been meaning to look into
so much stuff...
Michael
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: saurabh gupta @ 2009-03-11 16:21 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Johannes Schindelin, git
In-Reply-To: <49B7D84B.6080501@dawes.za.net>
On Wed, Mar 11, 2009 at 8:57 PM, Rogan Dawes <lists@dawes.za.net> wrote:
> saurabh gupta wrote:
>>>> However, I think in merging and notifying about the conflicts in the xml
>>>> files, other things can also be put forward. Like the GUI will show the
>>>> number of tags differing and what are the new tags added and even if any
>>>> tag is renamed with the content unchanged. If possible, how about
>>>> showing a tree like structure (just like DOM model) to compare (or diff)
>>>> the two xml files.
>>>
>>> This is a little bit too low-level for my liking. Taking the OpenOffice
>>> example again, the GUI should not expose XML at all...
>>
>> hmmmm.....I think I get your point somewhat. Let me do some research
>> over the formats and the background formats in which tools like
>> OpenOffice store the data in xml files. May be for docbooks by
>> OpenOffice, the best thing would be to give the *diff* output in terms
>> of lines.
>> I would also appreciate to know what you think and would like to see
>> the output in such case.
>
> I think that the implementation may make use of features inherent in the
> file format where possible. e.g. I suspect that OpenOffice has the
> ability to show "Tracked changes", and then allow the user to view the
> changes using the actual OpenOffice implementation.
>
> I suspect that that will get a lot more difficult with e.g. conflicts
> and merges, because I doubt that OOo has the ability to show changes
> from multiple versions.
>
> But I have to agree with Dscho, that the output would have to depend on
> the file type (OOo document), not just the data structure (e.g. XML)
> inside the file.
>
> A regular XML file diff could choose to ignore/collapse whitespace
> (pretty printing) when doing the comparison, to show things like moving
> a branch further down the tree.
>
> e.g.
>
> <i>text</i>
>
> vs
>
> <b><i>text</i></b>
>
> vs
>
> <b>
> <i>text</i>
> </b>
>
> For plain XML, a textual diff might choose to show it with each element
> un-indented, and a standard text diff output:
>
> + <b>
> <i>
> text
> </i>
> + </b>
>
> while a GUI diff might show the new element highlighted in a tree:
>
> #green#<b>#/green#
> <i>
> text
>
> I think that where reasonable that you should aim to have a text-only
> version that could be wrapped by a GUI. Obviously, this would be
> meaningless when diffing a JPG, for instance.
All right. I got what you mean to say.
>
> Ok, that was a bit rambling. I hope it helped more than it confused.
>
> Rogan
>
--
Saurabh Gupta
Senior,
Electronics and Communication Engg.
NSIT,New Delhi, India
^ permalink raw reply
* Re: After git svn clone master is tied to a branch in svn, howto set master to trunk
From: Svenn Are Bjerkem @ 2009-03-11 16:04 UTC (permalink / raw)
To: git
In-Reply-To: <09fb20f5-3722-49d4-9565-95a5b41d15ac@c36g2000yqn.googlegroups.com>
On Mar 11, 4:17 pm, Svenn Are Bjerkem <svenn.bjer...@googlemail.com>
wrote:
> Hi,
> after performing a
> $> git svn clone https://svnserver/svn/a/b/c-T trunk/current -t tags -
> b branches
> I find that the git master has been tied to one of the branches. It
> turns out that the highest svn revision number in the repository was
> tied to that branch.
[snip]
> I guess I could solve the problem by modifying a file in trunk on svn
> and commit so that the trunk will get the highest svn revision number
> again and redo the clone.
I just wanted to confirm this assumption: First I removed the complete
git-svn clone and modified a file in trunk and checked it into svn.
Then I re-performed the git svn clone as described above. The master
in the local git repository is now tied to the trunk of the svn
repository.
--
Svenn
^ permalink raw reply
* Re: [PATCH] Introduce a filter-path argument to git-daemon, for doing custom path transformations
From: Johannes Sixt @ 2009-03-11 15:58 UTC (permalink / raw)
To: Johan Sørensen; +Cc: git
In-Reply-To: <1236784647-71388-1-git-send-email-johan@johansorensen.com>
Johan Sørensen schrieb:
> The argument is an executable script that will receive the path to the repos
> the client wishes to clone as an argument. It is then the responsibility of the
> script to return a zero-terminated string on its stdout with the real path of
> the target repository.
>
> This buys us a lot of flexibility when it comes to managing different
> repositories, possibly located in many different dirs, but with a uniform
> url-structure to the outside world.
It's the first time that I see a deamon with this feature - except perhaps
Apache's ModRewrite. Are you sure you are not working around your problem
at the wrong place?
Doesn't --interpolated-path already solve your problem? If not, then you
at least you must describe in the documentation the use-cases when
--path-filter should be preferred.
Your implementation does not pass the target hostname to the script, but
it should; otherwise you lose flexibility (for virtual hosting).
> +static char *run_path_filter_script(char *requested_dir) {
> + pid_t pid;
> + char result[256]; /* arbitary */
> + char *real_path;
> + int pipe_out[2];
> + int exit_code = 1;
> +
> + pipe(pipe_out);
> +
> + loginfo("Executing path filter script: '%s %s'", path_filter_script, requested_dir);
> +
> + switch ((pid = fork())) {
> + case -1:
> + logerror("path filter script fork() failed: %s", strerror(errno));
> + return NULL;
> + case 0:
> + close(pipe_out[0]);
> + dup2(pipe_out[1], 1);
> + close(pipe_out[1]);
> +
> + execl(path_filter_script, path_filter_script, requested_dir, NULL);
Use start_command()/finish_command() instead of rolling your own fork/exec
combo.
-- Hannes
^ permalink raw reply
* Re: [PATCH JGIT] fix for 'negative position' error
From: Ruth Alkema @ 2009-03-11 15:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Robin Rosenberg, git
In-Reply-To: <20090311152442.GS11989@spearce.org>
On second thought, I think that my previous patch can still go wrong for large values in 'position'
I think the following patch should work.
Kind regards, I hope the email is according to the guidelines for submitting patches, I am new to git, I used 'amend previous commit', I am not sure if that is correct in this case.
Ruth Alkema
>From 5e7200f02f91d948278fb515be59bfe2db535b66 Mon Sep 17 00:00:00 2001
From: Ruth Alkema <ruth@diasoft.nl>
Date: Wed, 11 Mar 2009 16:42:45 +0100
Subject: [PATCH] fix for 'negative position' error
Signed-off-by: Ruth Alkema <ruth@diasoft.nl>
---
.../src/org/spearce/jgit/lib/WindowCache.java | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java b/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java
index 4b7e10d..597ad61 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java
@@ -253,7 +253,7 @@ private static synchronized final void getImpl(final WindowCursor curs,
releaseMemory();
runClearedWindowQueue();
- wp.allocWindow(curs, id, id << windowSizeShift, wsz);
+ wp.allocWindow(curs, id, (position >> windowSizeShift) << windowSizeShift, wsz);
final ByteWindow<?> e = curs.window;
e.chainNext = cache[idx];
cache[idx] = e;
--
1.6.0.6
Shawn O. Pearce wrote:
> Ruth Alkema <ruth@diasoft.nl> wrote:
>> diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java b/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java
>> index 4b7e10d..5340da9 100644
>> --- a/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java
>> +++ b/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java
>> @@ -253,7 +253,7 @@ private static synchronized final void getImpl(final WindowCursor curs,
>> releaseMemory();
>> runClearedWindowQueue();
>>
>> - wp.allocWindow(curs, id, id << windowSizeShift, wsz);
>> + wp.allocWindow(curs, id, ((long) id) << windowSizeShift, wsz);
>
> Ouch.
>
> Thanks for the fix!
>
^ permalink raw reply related
* Re: git doc build failure on OS X 10.5.6 (Leopard) during xmlto phase
From: Jay Soffian @ 2009-03-11 15:49 UTC (permalink / raw)
To: Tom Holaday; +Cc: git
In-Reply-To: <76718490903110839m17041c7bxd7912eb09496c81a@mail.gmail.com>
On Wed, Mar 11, 2009 at 11:39 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
> On Wed, Mar 11, 2009 at 11:12 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
>> And your man pages still won't be perfect. Preformatted text will look
>> like this:
>>
>> .ft C
>> ...
>> .ft
I must be losing my mind. This is suddenly working, though I can't
track it down to any change in git. I just rebuilt my man pages and
this no longer is occurring, even though I still have a terminal
window open with the output of "git help help" _showing this problem_
and that's from man pages I built/installed just a few days ago. (And
I haven't upgraded MacPorts lately.)
Oh well.
j.
^ permalink raw reply
* Re: git doc build failure on OS X 10.5.6 (Leopard) during xmlto phase
From: Jay Soffian @ 2009-03-11 15:39 UTC (permalink / raw)
To: Tom Holaday; +Cc: git
In-Reply-To: <76718490903110812t5e1723ebi28a84da680422d8a@mail.gmail.com>
On Wed, Mar 11, 2009 at 11:12 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
> And your man pages still won't be perfect. Preformatted text will look
> like this:
>
> .ft C
> ...
> .ft
Hmm. git-help.txt has this text:
---snip---
------------------------------------------------
[man]
viewer = konqueror
viewer = woman
------------------------------------------------
---snap---
Which gets translated to:
---snip---
<literallayout>
.ft C [man]
viewer = konqueror
viewer = woman .ft
</literallayout>
---snap---
While git-push has this text:
---snip---
+
--------------------------
git push public #1
git push --repo=public #2
--------------------------
+
---snap---
Which gets translated to:
---snip---
<screen>git push public #1
git push --repo=public #2</screen>
---snap---
Both appear to render identically after being transformed into html,
but the transformation to man pages leaves the ".ft C" and ".ft"
macros literally in the resultant text. This is using asciidoc 8.3.1
and docbook-xsl 1.74.0. Further investigation is in order, but the
transformation from asciidoc to man pages is currently deep magic to
me.
j.
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Johannes Schindelin @ 2009-03-11 15:38 UTC (permalink / raw)
To: saurabh gupta; +Cc: git
In-Reply-To: <ab9fa62a0903110713k2a21cefbj1e7cd3c126aca8f9@mail.gmail.com>
Hi,
On Wed, 11 Mar 2009, saurabh gupta wrote:
> On Wed, Mar 11, 2009 at 7:32 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > On Wed, 11 Mar 2009, saurabh gupta wrote:
> >
> >> What I think is to implement file formats other than text like that
> >> written on wiki i.e. latex, xml, or even any database file (db file).
> >> Another idea (although it can be weired also) is to implement the new
> >> file formats in the plug-in formats. For example, to incorporate the
> >> merger engine for a new file format, a plug-in is created and can be
> >> integrated with the present merger in the git. However, I am not sure
> >> how much valid is this idea to make the present merger in git to be
> >> compatible with the plug-ins for enabling newer file formats.
> >
> > I am not sure that a plugin structure is needed. Take, for example,
> > three different .xml based formats: OpenOffice documents, .svg files
> > and Ant build.xml files. They need very different user interfaces.
>
> okay. In that case, if they have a different user interfaces then
> separate plug-in would be needed for each of these. May be this will get
> more messy.
The thing is: "plugin" is an architecture issue, which I think we will
have plenty of time hashing out. "GUI" is the bigger problem, because if
we cannot come up with something that is worth implementing, we can stop
the project early.
> >> However, I think in merging and notifying about the conflicts in the
> >> xml files, other things can also be put forward. Like the GUI will
> >> show the number of tags differing and what are the new tags added and
> >> even if any tag is renamed with the content unchanged. If possible,
> >> how about showing a tree like structure (just like DOM model) to
> >> compare (or diff) the two xml files.
> >
> > This is a little bit too low-level for my liking. Taking the
> > OpenOffice example again, the GUI should not expose XML at all...
>
> hmmmm.....I think I get your point somewhat. Let me do some research
> over the formats and the background formats in which tools like
> OpenOffice store the data in xml files. May be for docbooks by
> OpenOffice, the best thing would be to give the *diff* output in terms
> of lines.
Actually, I think that the diff is not the issue. What is needed is a way
that is both intuitive and versatile enough that all kinds of merge
conflicts in OpenOffice documents can be resolved by a total computer
illiterate.
The same problem applies for SVG files, but the user interface would look
completely different.
As such, it might not be wise to have a common framework at all, but to
make the first an extension for OpenOffice, and the second a modification
of, say, inkscape.
Of course, David will then come and say: "But that is more appropriate a
project for OpenOffice and inkscape, then!".
The good thing is that this is Open Source, and we'll just ask them to
co-mentor this project.
> I would also appreciate to know what you think and would like to see the
> output in such case.
That's the thing: I do not know yet how it should look like.
Ciao,
Dscho
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Rogan Dawes @ 2009-03-11 15:27 UTC (permalink / raw)
To: saurabh gupta; +Cc: Johannes Schindelin, git
In-Reply-To: <ab9fa62a0903110713k2a21cefbj1e7cd3c126aca8f9@mail.gmail.com>
saurabh gupta wrote:
>>> However, I think in merging and notifying about the conflicts in the xml
>>> files, other things can also be put forward. Like the GUI will show the
>>> number of tags differing and what are the new tags added and even if any
>>> tag is renamed with the content unchanged. If possible, how about
>>> showing a tree like structure (just like DOM model) to compare (or diff)
>>> the two xml files.
>>
>> This is a little bit too low-level for my liking. Taking the OpenOffice
>> example again, the GUI should not expose XML at all...
>
> hmmmm.....I think I get your point somewhat. Let me do some research
> over the formats and the background formats in which tools like
> OpenOffice store the data in xml files. May be for docbooks by
> OpenOffice, the best thing would be to give the *diff* output in terms
> of lines.
> I would also appreciate to know what you think and would like to see
> the output in such case.
I think that the implementation may make use of features inherent in the
file format where possible. e.g. I suspect that OpenOffice has the
ability to show "Tracked changes", and then allow the user to view the
changes using the actual OpenOffice implementation.
I suspect that that will get a lot more difficult with e.g. conflicts
and merges, because I doubt that OOo has the ability to show changes
from multiple versions.
But I have to agree with Dscho, that the output would have to depend on
the file type (OOo document), not just the data structure (e.g. XML)
inside the file.
A regular XML file diff could choose to ignore/collapse whitespace
(pretty printing) when doing the comparison, to show things like moving
a branch further down the tree.
e.g.
<i>text</i>
vs
<b><i>text</i></b>
vs
<b>
<i>text</i>
</b>
For plain XML, a textual diff might choose to show it with each element
un-indented, and a standard text diff output:
+ <b>
<i>
text
</i>
+ </b>
while a GUI diff might show the new element highlighted in a tree:
#green#<b>#/green#
<i>
text
I think that where reasonable that you should aim to have a text-only
version that could be wrapped by a GUI. Obviously, this would be
meaningless when diffing a JPG, for instance.
Ok, that was a bit rambling. I hope it helped more than it confused.
Rogan
^ permalink raw reply
* [PATCH JGIT] fix for 'negative position' error
From: Ruth Alkema @ 2009-03-11 15:19 UTC (permalink / raw)
To: Shawn O. Pearce, Robin Rosenberg; +Cc: git
>From 78972d51ddd6bcbdf25bd49d2a033c005cf301b1
From: Ruth Alkema <ruth@diasoft.nl>
Date: Wed, 11 Mar 2009 15:49:22 +0100
Signed-off-by: Ruth Alkema <ruth@diasoft.nl>
---
.../src/org/spearce/jgit/lib/WindowCache.java | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java b/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java
index 4b7e10d..5340da9 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java
@@ -253,7 +253,7 @@ private static synchronized final void getImpl(final WindowCursor curs,
releaseMemory();
runClearedWindowQueue();
- wp.allocWindow(curs, id, id << windowSizeShift, wsz);
+ wp.allocWindow(curs, id, ((long) id) << windowSizeShift, wsz);
final ByteWindow<?> e = curs.window;
e.chainNext = cache[idx];
cache[idx] = e;
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH JGIT] fix for 'negative position' error
From: Shawn O. Pearce @ 2009-03-11 15:24 UTC (permalink / raw)
To: Ruth Alkema; +Cc: Robin Rosenberg, git
In-Reply-To: <49B7D683.1070805@diasoft.nl>
Ruth Alkema <ruth@diasoft.nl> wrote:
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java b/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java
> index 4b7e10d..5340da9 100644
> --- a/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java
> +++ b/org.spearce.jgit/src/org/spearce/jgit/lib/WindowCache.java
> @@ -253,7 +253,7 @@ private static synchronized final void getImpl(final WindowCursor curs,
> releaseMemory();
> runClearedWindowQueue();
>
> - wp.allocWindow(curs, id, id << windowSizeShift, wsz);
> + wp.allocWindow(curs, id, ((long) id) << windowSizeShift, wsz);
Ouch.
Thanks for the fix!
--
Shawn.
^ permalink raw reply
* [PATCH] Introduce a filter-path argument to git-daemon, for doing custom path transformations
From: Johan Sørensen @ 2009-03-11 15:17 UTC (permalink / raw)
To: git; +Cc: Johan Sørensen
The argument is an executable script that will receive the path to the repos
the client wishes to clone as an argument. It is then the responsibility of the
script to return a zero-terminated string on its stdout with the real path of
the target repository.
This buys us a lot of flexibility when it comes to managing different
repositories, possibly located in many different dirs, but with a uniform
url-structure to the outside world.
---
Documentation/git-daemon.txt | 7 ++++
daemon.c | 75 +++++++++++++++++++++++++++++++++++++++++-
2 files changed, 81 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index 36f00ae..1eca344 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -13,6 +13,7 @@ SYNOPSIS
[--strict-paths] [--base-path=path] [--base-path-relaxed]
[--user-path | --user-path=path]
[--interpolated-path=pathtemplate]
+ [--path-filter=executable]
[--reuseaddr] [--detach] [--pid-file=file]
[--enable=service] [--disable=service]
[--allow-override=service] [--forbid-override=service]
@@ -71,6 +72,12 @@ OPTIONS
After interpolation, the path is validated against the directory
whitelist.
+--path-filter=executable::
+ To support a more flexible directory layout a path filter script
+ can be used. The executable will receive the requested path from
+ the client as arg0. The executable must return a zero-terminated
+ string on stdout which is the real path 'git-daemon' should serve.
+
--export-all::
Allow pulling from all directories that look like GIT repositories
(have the 'objects' and 'refs' subdirectories), even if they
diff --git a/daemon.c b/daemon.c
index d93cf96..b2571df 100644
--- a/daemon.c
+++ b/daemon.c
@@ -22,6 +22,7 @@ static const char daemon_usage[] =
" [--strict-paths] [--base-path=path] [--base-path-relaxed]\n"
" [--user-path | --user-path=path]\n"
" [--interpolated-path=path]\n"
+" [--path-filter=path]\n"
" [--reuseaddr] [--detach] [--pid-file=file]\n"
" [--[enable|disable|allow-override|forbid-override]=service]\n"
" [--inetd | [--listen=host_or_ipaddr] [--port=n]\n"
@@ -58,6 +59,10 @@ static char *canon_hostname;
static char *ip_address;
static char *tcp_port;
+/* if defined, the script will be executed with the requested path on stdin
+ * and _must_ return with a successful exitcode and the new path on stdout */
+static char *path_filter_script;
+
static void logreport(int priority, const char *err, va_list params)
{
if (log_syslog) {
@@ -287,9 +292,62 @@ static int git_daemon_config(const char *var, const char *value, void *cb)
return 0;
}
+static char *run_path_filter_script(char *requested_dir) {
+ pid_t pid;
+ char result[256]; /* arbitary */
+ char *real_path;
+ int pipe_out[2];
+ int exit_code = 1;
+
+ pipe(pipe_out);
+
+ loginfo("Executing path filter script: '%s %s'", path_filter_script, requested_dir);
+
+ switch ((pid = fork())) {
+ case -1:
+ logerror("path filter script fork() failed: %s", strerror(errno));
+ return NULL;
+ case 0:
+ close(pipe_out[0]);
+ dup2(pipe_out[1], 1);
+ close(pipe_out[1]);
+
+ execl(path_filter_script, path_filter_script, requested_dir, NULL);
+
+ /* execl failed if we got here */
+ logerror("path filter script execl() failed: %s", strerror(errno));
+ return NULL;
+ default:
+ close(pipe_out[1]);
+
+ while(waitpid(pid, &exit_code, 0) < 0) {
+ switch(errno) {
+ case EINTR:
+ continue;
+ default:
+ logerror("path filter script waitpid() fail: %s", strerror(errno));
+ goto waitpid_error;
+ }
+ }
+ if (WIFEXITED(exit_code) && WEXITSTATUS(exit_code) == 0) {
+ read(pipe_out[0], result, sizeof(result) - 1);
+ loginfo("path filter script result: %s", result);
+ }
+ waitpid_error:
+ close(pipe_out[0]);
+ }
+
+ if (result) {
+ real_path = result;
+ return real_path;
+ }
+ return NULL;
+}
+
static int run_service(char *dir, struct daemon_service *service)
{
const char *path;
+ char *real_dir;
int enabled = service->enabled;
loginfo("Request %s for '%s'", service->name, dir);
@@ -299,8 +357,19 @@ static int run_service(char *dir, struct daemon_service *service)
errno = EACCES;
return -1;
}
+ loginfo("path_filter_script %s", path_filter_script);
+ if (!path_filter_script) {
+ real_dir = dir;
+ } else {
+ char *tdir;
+ if ((tdir = run_path_filter_script(dir))) {
+ real_dir = tdir;
+ } else {
+ real_dir = dir;
+ }
+ }
- if (!(path = path_ok(dir)))
+ if (!(path = path_ok(real_dir)))
return -1;
/*
@@ -1018,6 +1087,10 @@ int main(int argc, char **argv)
pid_file = arg + 11;
continue;
}
+ if (!prefixcmp(arg, "--path-filter=")) {
+ path_filter_script = arg + 14;
+ continue;
+ }
if (!strcmp(arg, "--detach")) {
detach = 1;
log_syslog = 1;
--
1.6.1
^ permalink raw reply related
* After git svn clone master is tied to a branch in svn, howto set master to trunk
From: Svenn Are Bjerkem @ 2009-03-11 15:17 UTC (permalink / raw)
To: git
Hi,
after performing a
$> git svn clone https://svnserver/svn/a/b/c -T trunk/current -t tags -
b branches
I find that the git master has been tied to one of the branches. It
turns out that the highest svn revision number in the repository was
tied to that branch.
For historical reasons we have subdirectories in trunk/ on svn, but I
inspected .git/config
[svn-remote "svn"]
url = https://svnserver/svn
fetch = a/b/c/trunk/current:refs/remotes/trunk
branches = a/b/c/branches/*:refs/remotes/*
tags = a/b/c/tags/*:refs/remotes/tags/*
And I assume it picked up the strange trunk correctly.
I have been googling around for a while looking for instructions how
to tell git that when I check out "master" it should be "trunk" from
svn and not "branches/next_gen", or more precisely how to move master
to trunk from branches/next_gen.
I guess I could solve the problem by modifying a file in trunk on svn
and commit so that the trunk will get the highest svn revision number
again and redo the clone.
--
Svenn
^ permalink raw reply
* Re: git doc build failure on OS X 10.5.6 (Leopard) during xmlto phase
From: Jay Soffian @ 2009-03-11 15:12 UTC (permalink / raw)
To: Tom Holaday; +Cc: git
In-Reply-To: <5e68abd90903110721o414283a4te188b58e0e4df8ad@mail.gmail.com>
On Wed, Mar 11, 2009 at 10:21 AM, Tom Holaday <tlholaday@gmail.com> wrote:
> Hello,
>
> On OS X 10.5.6 (Leopard), the command ...
>
> xmlto -m callouts.xsl man git-filter-branch.xml
>
> ... terminates with these errors:
Assuming you're using the MacPorts asciidoc, to build on OS X you need:
export ASCIIDOC8=YesPlease
export DOCBOOK_XSL_172=YesPlease
And your man pages still won't be perfect. Preformatted text will look
like this:
.ft C
...
.ft
I haven't had a chance to track down what is causing this. If you
build and install the html pages and use "help -w" those are formatted
fine. You may just want to install the prebuilt man-pages
(quick-install-doc or quick-install-man).
j.
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2009, #03; Wed, 11)
From: Jay Soffian @ 2009-03-11 15:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdqg5s17.fsf@gitster.siamese.dyndns.org>
On Wed, Mar 11, 2009 at 5:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
> * js/remote-improvements (Sun Mar 8 00:10:33 2009 -0800) 23 commits
> + builtin-remote.c: no "commented out" code, please
Thank you for catching this. I don't know how it slipped by me and the
rest of the list before it was applied. Sigh.
j.
^ permalink raw reply
* Re: [PATCH 1/3] bash completion: fix completion issues with fetch, pull, and push
From: Jay Soffian @ 2009-03-11 14:57 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Shawn O. Pearce, git, Markus Heidelberg, Sverre Rabbelier,
Junio C Hamano
In-Reply-To: <20090311190227.6117@nanako3.lavabit.com>
On Wed, Mar 11, 2009 at 6:02 AM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> While people's attention is on the completion, there is one case I wish the completion worked better.
> "git log origin..mas[TAB]" and "git log origin...mas[TAB]" work as expected, but the same completion does not work for "git diff". I don't miss the two-dot format but it's often useful to say "git diff origin...master".
I just looked and realized to fix this properly, __git_complete_file
and __git_complete_revlist need some refactoring, along with the
functions that use them.
So I'll add it to my todo list, since it's more than 5 minutes of
available time I have right now.
j.
^ permalink raw reply
* Re: git doc build failure on OS X 10.5.6 (Leopard) during xmlto phase
From: Michael J Gruber @ 2009-03-11 14:43 UTC (permalink / raw)
To: Tom Holaday; +Cc: git
In-Reply-To: <5e68abd90903110721o414283a4te188b58e0e4df8ad@mail.gmail.com>
Tom Holaday venit, vidit, dixit 11.03.2009 15:21:
> Hello,
>
> On OS X 10.5.6 (Leopard), the command ...
>
> xmlto -m callouts.xsl man git-filter-branch.xml
>
> ... terminates with these errors:
>
> xmlto: input does not validate (status 1)
> /git-1.6.2/Documentation/git-filter-branch.xml:431: parser error :
> PCDATA invalid Char value 7
> Clone it with <literal>git clone +++0+++</literal>. The clone
> ^
> /git-1.6.2/Documentation/git-filter-branch.xml:431: parser error :
> PCDATA invalid Char value 7
> Clone it with <literal>git clone +++0+++</literal>. The clone
That means that the xml file is incorrect already, which means it's an
asciidoc problem. What's your asciidoc version?
> ^
> make[1]: *** [git-filter-branch.1] Error 1
> make: *** [doc] Error 2
>
> What issue-tracker, if any, would be appropriate for this?
You should send a note to the mailing list ;)
Michael
^ permalink raw reply
* git doc build failure on OS X 10.5.6 (Leopard) during xmlto phase
From: Tom Holaday @ 2009-03-11 14:21 UTC (permalink / raw)
To: git
Hello,
On OS X 10.5.6 (Leopard), the command ...
xmlto -m callouts.xsl man git-filter-branch.xml
... terminates with these errors:
xmlto: input does not validate (status 1)
/git-1.6.2/Documentation/git-filter-branch.xml:431: parser error :
PCDATA invalid Char value 7
Clone it with <literal>git clone +++0+++</literal>. The clone
^
/git-1.6.2/Documentation/git-filter-branch.xml:431: parser error :
PCDATA invalid Char value 7
Clone it with <literal>git clone +++0+++</literal>. The clone
^
make[1]: *** [git-filter-branch.1] Error 1
make: *** [doc] Error 2
What issue-tracker, if any, would be appropriate for this?
-- Tom Holaday
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: saurabh gupta @ 2009-03-11 14:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0903111458340.10498@intel-tinevez-2-302>
On Wed, Mar 11, 2009 at 7:32 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 11 Mar 2009, saurabh gupta wrote:
>
>> What I think is to implement file formats other than text like that
>> written on wiki i.e. latex, xml, or even any database file (db file).
>> Another idea (although it can be weired also) is to implement the new
>> file formats in the plug-in formats. For example, to incorporate the
>> merger engine for a new file format, a plug-in is created and can be
>> integrated with the present merger in the git. However, I am not sure
>> how much valid is this idea to make the present merger in git to be
>> compatible with the plug-ins for enabling newer file formats.
>
> I am not sure that a plugin structure is needed. Take, for example, three
> different .xml based formats: OpenOffice documents, .svg files and Ant
> build.xml files. They need very different user interfaces.
okay. In that case, if they have a different user interfaces then
separate plug-in would be needed for each of these. May be this will
get more messy.
>
>> I am thinking of using gtk+ libraries to implement the GUI part (I am
>> quite comfortable with gtk+).
>
> I mentioned Tcl/Tk, because it is portable, but I'll also take gtk-based
> stuff ;-)
All right. We can think over this issue. Being honest, I have not
worked on Tcl/Tk yet but I have no problem in learning it and I am
sure that I will get my hands on Tcl/Tk within no time.
>> However, I think in merging and notifying about the conflicts in the xml
>> files, other things can also be put forward. Like the GUI will show the
>> number of tags differing and what are the new tags added and even if any
>> tag is renamed with the content unchanged. If possible, how about
>> showing a tree like structure (just like DOM model) to compare (or diff)
>> the two xml files.
>
> This is a little bit too low-level for my liking. Taking the OpenOffice
> example again, the GUI should not expose XML at all...
hmmmm.....I think I get your point somewhat. Let me do some research
over the formats and the background formats in which tools like
OpenOffice store the data in xml files. May be for docbooks by
OpenOffice, the best thing would be to give the *diff* output in terms
of lines.
I would also appreciate to know what you think and would like to see
the output in such case.
>
> Ciao,
> Dscho
>
>
--
Saurabh Gupta
Senior,
Electronics and Communication Engg.
NSIT,New Delhi, India
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Johannes Schindelin @ 2009-03-11 14:02 UTC (permalink / raw)
To: saurabh gupta; +Cc: git
In-Reply-To: <ab9fa62a0903110655y4a47ccfkde0984ecb46b3307@mail.gmail.com>
Hi,
On Wed, 11 Mar 2009, saurabh gupta wrote:
> What I think is to implement file formats other than text like that
> written on wiki i.e. latex, xml, or even any database file (db file).
> Another idea (although it can be weired also) is to implement the new
> file formats in the plug-in formats. For example, to incorporate the
> merger engine for a new file format, a plug-in is created and can be
> integrated with the present merger in the git. However, I am not sure
> how much valid is this idea to make the present merger in git to be
> compatible with the plug-ins for enabling newer file formats.
I am not sure that a plugin structure is needed. Take, for example, three
different .xml based formats: OpenOffice documents, .svg files and Ant
build.xml files. They need very different user interfaces.
> I am thinking of using gtk+ libraries to implement the GUI part (I am
> quite comfortable with gtk+).
I mentioned Tcl/Tk, because it is portable, but I'll also take gtk-based
stuff ;-)
> However, I think in merging and notifying about the conflicts in the xml
> files, other things can also be put forward. Like the GUI will show the
> number of tags differing and what are the new tags added and even if any
> tag is renamed with the content unchanged. If possible, how about
> showing a tree like structure (just like DOM model) to compare (or diff)
> the two xml files.
This is a little bit too low-level for my liking. Taking the OpenOffice
example again, the GUI should not expose XML at all...
Ciao,
Dscho
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: saurabh gupta @ 2009-03-11 13:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0903111353340.10498@intel-tinevez-2-302>
On Wed, Mar 11, 2009 at 6:28 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 11 Mar 2009, saurabh gupta wrote:
>
>> On Wed, Mar 11, 2009 at 5:28 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>
>> > On Wed, 11 Mar 2009, Saurabh Gupta wrote:
>> >
>> > > /*About GSoC GIT ideas; */Here are the ideas which I found to be
>> > > interested in. Although, I would like to discuss any other idea than
>> > > these in GIT organization.
>> > >
>> > > *1) Domain specific merge helpers* Intelligence in the merger can be
>> > > put which modifies the source file according the format. Different
>> > > file formats can be put in the merger to support.
>> >
>> > You said that you are interested in this project, but from your mails
>> > I do not see what are the specific reasons why.
>>
>> All right. May be I lacked in my mail to specify the reason for my
>> interest.
>
> Oh, sorry, I did not mean to imply any offense...
No, I didn;t mean that either too :-D
>
>> The reason is that from my past experience, I got the notion that this
>> project is according to my interest and is doable in the three months
>> time period.
>>
>> Another reason is that I have been using the versioning tools like svn
>> and now perforce for a long time and this added up to my interest.
>
> Sounds good!
>
>> > IMHO this project can only fly if you have a specific file format that
>> > you absolutely want to be able to merge; otherwise, it will be an
>> > uphill fight.
>>
>> Well, as suggested on the wiki, I would like to work on the xml file
>> formats as I have quite experience of working with xml files and parsing
>> them using msxml and nsxml libraries and some of personal wrappers.
>
> As I am known to not exactly like Microsoft's products, if you wanted to
> have me as a mentor, you'd need to use Open Source libraries to do the
> parsing.
Yeah, of course. I mentioned msxml and nsxml just to indicate that I
am comfortable with the xml parsing. I will, no doubt, go for open
source libraries to parse xml and write or reuse some of my own
wrappers to parse xml.
>> How about my idea of making the support of new file formats in the
>> plug-ins (suggested in my last post).
>
> Sorry, I missed that idea. Could you describe it again?
>
All right. This is the quote which I said in my last posts.
=>What I think is to implement file formats other than text like
that written on wiki i.e. latex, xml, or even any database file (db
file). Another idea (although it can be weired also) is to implement
the new file formats in the plug-in formats. For example, to
incorporate the merger engine for a new file format, a plug-in is
created and can be integrated with the present merger in the git.
However, I am not sure how much valid is this idea to make the present
merger in git to be compatible with the plug-ins for enabling newer
file formats.
>> > Personally, I would _love_ to see a good graphical tool (maybe written
>> > in Tcl/Tk) to help merging conflicts in LaTeX files, but I just do not
>> > have the time...
>>
>> Ok. What I am thinking is to implement something like that of
>> graphical *diff* command output but in these special file formats, it
>> ought to have intelligence to bring out the difference of two files
>> (like latex or xml) in a readable manner. For example, in case of xml
>> files, if one file contains an inner tag block , then merger GUI
>> should notify the user in a readable manner about this added tag
>> rather than only the difference in lines.
>
> A diff would be a first step, but the real issue are the merge helpers.
> And they need first and foremost a thought-through user interface design.
> The technical issues are all solveable, I am sure.
I got your point. I am thinking of using gtk+ libraries to implement
the GUI part (I am quite comfortable with gtk+). However, I think in
merging and notifying about the conflicts in the xml files, other
things can also be put forward. Like the GUI will show the number of
tags differing and what are the new tags added and even if any tag is
renamed with the content unchanged. If possible, how about showing a
tree like structure (just like DOM model) to compare (or diff) the two
xml files.
> Ciao,
> Dscho
>
>
--
Saurabh Gupta
Senior,
NSIT,New Delhi, India
^ permalink raw reply
* Re: [PATCH v2] connect.c: remove a few globals by using git_config callback data
From: Johannes Schindelin @ 2009-03-11 13:28 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Erik Faye-Lund, git
In-Reply-To: <40aa078e0903110617g60e0d7d0x1e0d94e44ef89f40@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1407 bytes --]
Hi,
On Wed, 11 Mar 2009, Erik Faye-Lund wrote:
> On Wed, Mar 11, 2009 at 12:52 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >> @@ -383,6 +381,8 @@ static int git_proxy_command_options(const char *var, const char *value,
> >> const char *for_pos;
> >> int matchlen = -1;
> >> int hostlen;
> >> + const char *rhost_name = cb;
> >> + int rhost_len = strlen(rhost_name);
> >
> > I see that you still calculate the length everytime
> > git_proxy_command_options() is called -- which is for every config
> > variable.
>
> Actually, the length-calculation is now moved inside the check for
> "core.gitproxy", so it should only trigger for each config variable
> that is "core.gitproxy". Hopefully, this should usually be just once
> ;)
>
> This change was suggested as a compromise by Junio.
Ah, okay, I am lacking time to read all emails today, so I missed that
one.
> >> + git_config(git_proxy_command_options, (void*)host);
> >
> > The (void *) should not be needed.
>
> Actually, it is - it casts away the const-ness of the string. Removing
> the cast generates a warning on my installation of GCC. Perhaps I
> should have made that clearer by casting to "char*" instead of
> "void*"?
Oh, that's why... Thanks for the clarification! Now only a space between
the void and the star, and I am happy!
Ciao,
Dscho
^ permalink raw reply
* Re: Generalised bisection
From: John Tapsell @ 2009-03-11 13:24 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Ealdwulf Wuffinga, Christian Couder, Git List, Ingo Molnar
In-Reply-To: <alpine.DEB.1.00.0903111358260.10498@intel-tinevez-2-302>
2009/3/11 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Wed, 11 Mar 2009, John Tapsell wrote:
>
>> 2009/3/11 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>
>> > On Wed, 11 Mar 2009, John Tapsell wrote:
>> >
>> >> There used to be a dependency on python. git-merge-recursive for
>> >> example, before it was converted to C.
>> >
>> > Not "for example". It was the only dependency of git.git on Python,
>> > and the rewrite of merge-recursive was only done to break that
>> > dependency, as I had a platform where I could not install Python.
>>
>> But installing perl was no problem? (Just curious)
>
> Perl was installed, albeit in an ancient version, and compiling Perl
> modules written in C was out. It just did not work.
I wonder if it would then be acceptable to have a python script for
this generalised bisect? Since it's not core functionality. Not
quite sure how it would fit in though (I'd rather it was called from
"git bisect" rather than adding another separate git command)
John
^ permalink raw reply
* Re: [PATCH v2] connect.c: remove a few globals by using git_config callback data
From: Erik Faye-Lund @ 2009-03-11 13:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Erik Faye-Lund, git
In-Reply-To: <alpine.DEB.1.00.0903111251160.10279@pacific.mpi-cbg.de>
Thanks for the feedback.
On Wed, Mar 11, 2009 at 12:52 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> @@ -383,6 +381,8 @@ static int git_proxy_command_options(const char *var, const char *value,
>> const char *for_pos;
>> int matchlen = -1;
>> int hostlen;
>> + const char *rhost_name = cb;
>> + int rhost_len = strlen(rhost_name);
>
> I see that you still calculate the length everytime
> git_proxy_command_options() is called -- which is for every config
> variable.
Actually, the length-calculation is now moved inside the check for
"core.gitproxy", so it should only trigger for each config variable
that is "core.gitproxy". Hopefully, this should usually be just once
;)
This change was suggested as a compromise by Junio.
>
>> + git_config(git_proxy_command_options, (void*)host);
>
> The (void *) should not be needed.
Actually, it is - it casts away the const-ness of the string. Removing
the cast generates a warning on my installation of GCC. Perhaps I
should have made that clearer by casting to "char*" instead of
"void*"?
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: Generalised bisection
From: Johannes Schindelin @ 2009-03-11 13:04 UTC (permalink / raw)
To: John Tapsell; +Cc: Ealdwulf Wuffinga, Christian Couder, Git List, Ingo Molnar
In-Reply-To: <43d8ce650903110508o3d12f32m8202fae750d215a@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1220 bytes --]
Hi,
On Wed, 11 Mar 2009, John Tapsell wrote:
> 2009/3/11 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Wed, 11 Mar 2009, John Tapsell wrote:
> >
> >> There used to be a dependency on python. git-merge-recursive for
> >> example, before it was converted to C.
> >
> > Not "for example". It was the only dependency of git.git on Python,
> > and the rewrite of merge-recursive was only done to break that
> > dependency, as I had a platform where I could not install Python.
>
> But installing perl was no problem? (Just curious)
Perl was installed, albeit in an ancient version, and compiling Perl
modules written in C was out. It just did not work.
But the good part was: after converting rerere to be a builtin, there
were no Perl scripts left that I wanted/needed to use.
These days, we only have these Perl scripts left: add--interactive,
archimport, cvsexportcommit, cvsimport, cvsserver, relink, send-email and
svn.
Ignoring the scripts to interact with other SCMs (which I can do on
another computer), that leaves add--interactive, relink (which could be
moved to contrib/ AFAIAC) and send-email.
I use "add -e" instead of "add -i", and stay away from send-email...
Ciao,
Dscho
^ 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