* Re: Does GIT require property like Subversion?
From: Jan-Benedict Glaw @ 2006-10-08 9:19 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <4528C09B.3030004@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 865 bytes --]
On Sun, 2006-10-08 17:10:51 +0800, Liu Yubao <yubao.liu@gmail.com> wrote:
> I want to know whether there is a plan to add this feature, or GIT doesn't
> require it at all.
>
> Properties like encoding (path name, file content), eol-style, mime-type
> are useful for editing.
GIT is a content tracker. It won't ever fiddle with your line
endings. You put data in there and it'll be conserved bit-by-bit. So
if you need to store file encodings, MIME types, automatic CR/CRLF/LF
converstion etc, you have to put this metadata into some additional
files, but GIT won't specifically handle that in any way.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481
Signature of: Eine Freie Meinung in einem Freien Kopf
the second : für einen Freien Staat voll Freier Bürger.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] Enhance core.logallrefupdates
From: Jakub Narebski @ 2006-10-08 10:03 UTC (permalink / raw)
To: git
In-Reply-To: <7vbqonkzfe.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> This enhances core.logallrefupdates by allowing it to take
> "heads" as the value as well, which causes git to create missing
> reflog files automatically only for branch heads. Usually tags
> are create-once-and-live-forever, and it is irritating to see
> reflog files created automatically every time a new tag is made.
>
> As before, boolean "true" means create missing reflog files for
> all refs.
>
> ---
>
> * Setting it to "tags" is not supported, as it does not make
> much sense wanting to log only tag updates.
>
> Come to think of it, it might make sense to change the
> meaning of "true" to do what this patch does. I do not think
> of reasons to create missing reflog for tags automatically
> anyway.
If we change meaning of "true", perhaps (just in case in case) we
should add "all" value?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC/PATCH] pack-refs --all
From: Jakub Narebski @ 2006-10-08 10:03 UTC (permalink / raw)
To: git
In-Reply-To: <7v4pufkz55.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> * Likes? Dislikes?
+1
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC/PATCH] pack-refs --all
From: Petr Baudis @ 2006-10-08 10:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pufkz55.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Oct 08, 2006 at 10:08:54AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> This changes 'git-pack-refs' to pack only tags by default.
> Branches are meant to be updated, either by committing onto it
> yourself or tracking remote branches, and packed entries can
> become stale easily, but tags are usually "create once and live
> forever" and benefit more from packing.
>
> ---
>
> * Likes? Dislikes?
Looks much saner, thanks. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: Does GIT require property like Subversion?
From: Jakub Narebski @ 2006-10-08 10:16 UTC (permalink / raw)
To: git
In-Reply-To: <20061008091900.GG30283@lug-owl.de>
Jan-Benedict Glaw wrote:
> On Sun, 2006-10-08 17:10:51 +0800, Liu Yubao <yubao.liu@gmail.com> wrote:
>> I want to know whether there is a plan to add this feature, or GIT doesn't
>> require it at all.
>>
>> Properties like encoding (path name, file content), eol-style, mime-type
>> are useful for editing.
>
> GIT is a content tracker. It won't ever fiddle with your line
> endings. You put data in there and it'll be conserved bit-by-bit. So
> if you need to store file encodings, MIME types, automatic CR/CRLF/LF
> converstion etc, you have to put this metadata into some additional
> files, but GIT won't specifically handle that in any way.
Mimetype has no place (I think) in SCM. We could in pronciple "borrow"
Mercurial idea of input/output filters
http://www.selenic.com/mercurial/wiki/index.cgi/EncodeDecodeFilter
which would (among others) enable to use constant eol-style in the shared
part of repository i.e. object database, while using OS native eol-style
(UNIX vs. Microsoft Windows vs. MacOS). eol-style doesn't matter much:
you can find good editors which are able to use any eol-style for any OS
nowadays.
File content encoding is something (if it is outside US-ASCII of course)
that you would want either to have some default convention, or have it
embedded in the file itself (like XML, HTML, or Emacs' file variables)
to be able to read file _outside_ SCM.
Path name encoding is something that is global property of a repository,
I think. We have i18n.commitEncoding configuration variable; we could
add i18n.pathnameEncoding quite easily I think (and some way for Git to
detect current filesystem pathname encoding, if possible). Although
BTW I think that i18n.commitEncoding information should be made persistent,
and copied when cloning repository.
But in fact the philosophy of Git _prohibits_ I think property bits.
Unless we add ability (which can be done fairly easy even now, but will
not be automatic) to save some metainfo (ACL, extended attributes,
Subversion-like properties) along with the file (blob) and/or tree
(directory).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Does GIT require property like Subversion?
From: Jakub Narebski @ 2006-10-08 10:26 UTC (permalink / raw)
To: git
In-Reply-To: <egaj49$424$1@sea.gmane.org>
Jakub Narebski wrote:
> We could in pronciple "borrow" Mercurial idea of input/output filters
> http://www.selenic.com/mercurial/wiki/index.cgi/EncodeDecodeFilter
> which would (among others) enable to use constant eol-style in the shared
> part of repository i.e. object database, while using OS native eol-style
> (UNIX vs. Microsoft Windows vs. MacOS). eol-style doesn't matter much:
> you can find good editors which are able to use any eol-style for any OS
> nowadays.
What's more important, that would enable to store in SCM files which format
is of archive of mix of _text_ and binary files, archive being compressed
and binary. Examples include OpenDocument (ODF), Java Archive (.jar),
Mozilla extension (.xpi)... well good XML aware diff would be also nice.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC/PATCH] pack-refs --all
From: Johannes Schindelin @ 2006-10-08 12:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pufkz55.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 8 Oct 2006, Junio C Hamano wrote:
> This changes 'git-pack-refs' to pack only tags by default.
Since there is not really a high cost attached, why not migrate towards
only-packed-refs? (Of course, this means that git-update-ref should learn
to update in-place)?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Add WEBDAV timeout to http-fetch.
From: Johannes Schindelin @ 2006-10-08 12:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis, Jakub Narebski
In-Reply-To: <7vbqonpfyl.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 7 Oct 2006, Junio C Hamano wrote:
> [...] But the repository owner ends up keeping up-to-date as a side
> effect of keeping info/refs up-to-date anyway (as I do not see a code to
> read that information over DAV), so there is no point doing this over
> DAV in practice.
Makes sense to me.
Ciao,
Dscho
^ permalink raw reply
* git-tar-tree & NEEDS_PREFIX
From: Jiri Slaby @ 2006-10-08 13:10 UTC (permalink / raw)
To: git-list
Hi,
is there any good reason to have NEEDS_PREFIX flag for git-tar-tree builtin?
I can't do --remote= tar-ing, but when I remove this flag from git.c, it seems
to work correctly (prefix seems not to be used in any way).
regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
^ permalink raw reply
* Re: [RFC PATCH] Add WEBDAV timeout to http-fetch.
From: Sean @ 2006-10-08 13:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Petr Baudis, Jakub Narebski
In-Reply-To: <7vbqonpfyl.fsf@assigned-by-dhcp.cox.net>
On Sat, 07 Oct 2006 21:52:02 -0700
Junio C Hamano <junkio@cox.net> wrote:
> Using DAV, if it works with the server, has the advantage of not
> having to keep objects/info/packs up-to-date from repository
> owner's point of view. But the repository owner ends up keeping
> up-to-date as a side effect of keeping info/refs up-to-date
> anyway (as I do not see a code to read that information over
> DAV), so there is no point doing this over DAV in practice.
>
> Perhaps we should remove call to remote_ls() from
> fetch_indices() unconditionally, not just protected with
> NO_EXPAT and be done with it?
That makes a lot of sense. A server really has to always provide
a objects/info/packs anyway, just to be fetchable today by clients
that are compiled with NO_EXPAT.
+1
Sean
^ permalink raw reply
* Re: [PATCH] gitweb: Cleanup Git logo and Git logo target generation
From: Jakub Narebski @ 2006-10-08 13:31 UTC (permalink / raw)
To: git
In-Reply-To: <200610061231.06017.jnareb@gmail.com>
Was this patch dropped? Postponed to after release?
Waiting for better patch (but this correct esc_html-ing URL...)?
--
Jakub Narebski
^ permalink raw reply
* Re: git-tar-tree & NEEDS_PREFIX
From: Rene Scharfe @ 2006-10-08 13:44 UTC (permalink / raw)
To: Jiri Slaby; +Cc: git-list
In-Reply-To: <4528F8AD.2040307@gmail.com>
Jiri Slaby schrieb:
> is there any good reason to have NEEDS_PREFIX flag for git-tar-tree
> builtin?
>
> I can't do --remote= tar-ing, but when I remove this flag from git.c, it
> seems to work correctly (prefix seems not to be used in any way).
Good point. However, git-tar-tree has been deprecated in favour of
git-archive. And NEEDS_PREFIX has been renamed to RUN_SETUP two months
ago, so an update might be in order. ;-)
René
^ permalink raw reply
* [PATCH] git-tar-tree: don't RUN_SETUP
From: Rene Scharfe @ 2006-10-08 13:44 UTC (permalink / raw)
To: Jiri Slaby, Junio C Hamano; +Cc: git-list
In-Reply-To: <4528F8AD.2040307@gmail.com>
Noted by Jiri Slaby, git-tar-tree --remote doesn't need to be run
from inside of a git archive. Since git-tar-tree is now only a
wrapper for git-archive, which calls setup_git_directory() as
needed, we should drop the flag RUN_SETUP.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
diff --git a/git.c b/git.c
index b8e8622..d7103a4 100644
--- a/git.c
+++ b/git.c
@@ -258,7 +258,7 @@ static void handle_internal_command(int
{ "show", cmd_show, RUN_SETUP | USE_PAGER },
{ "stripspace", cmd_stripspace },
{ "symbolic-ref", cmd_symbolic_ref, RUN_SETUP },
- { "tar-tree", cmd_tar_tree, RUN_SETUP },
+ { "tar-tree", cmd_tar_tree },
{ "unpack-objects", cmd_unpack_objects, RUN_SETUP },
{ "update-index", cmd_update_index, RUN_SETUP },
{ "update-ref", cmd_update_ref, RUN_SETUP },
^ permalink raw reply related
* Re: Does GIT require property like Subversion?
From: Robin Rosenberg @ 2006-10-08 15:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <egaj49$424$1@sea.gmane.org>
söndag 08 oktober 2006 12:16 skrev Jakub Narebski:
> File content encoding is something (if it is outside US-ASCII of course)
> that you would want either to have some default convention, or have it
> embedded in the file itself (like XML, HTML, or Emacs' file variables)
> to be able to read file _outside_ SCM.
Except for CR/LF, this is best solved outside of the SCM. There aren't that
may tools/users to warrant the complexity or performance hit I imagine to
solve it.
> Path name encoding is something that is global property of a repository,
> I think. We have i18n.commitEncoding configuration variable; we could
> add i18n.pathnameEncoding quite easily I think (and some way for Git to
> detect current filesystem pathname encoding, if possible). Although
> BTW I think that i18n.commitEncoding information should be made persistent,
> and copied when cloning repository.
*I* think git should use UTF-8 internally. Always. Clients could then have
the option to convert to local conventions.
Same for pathname. Internally all paths should be UTF-8 encoded. Encoding
commit info that way would make the i18n option obsolete also.
I have a patch for both these, but it's very ugly and probably has some memory
management problems, so I'll refrain from submitting for now. Knowing that it
exists may perhaps serve as starting point for discussion. It encodes
filenames in UTF-8 using LC_CTYPE as the local encoding, as well as commit
messages. An exception is when something looks like UTF-8, in which case it
will not convert input to git. When UTF-8 cannot be converted to the local
encoding on it's way out of git, the data remains in UTF-8 format. Branch and
tags names are not managed (yet, at least).
> But in fact the philosophy of Git _prohibits_ I think property bits.
I don't think so, but they aren't needed for the original purpose. Git already
does manage file permissions.
> Unless we add ability (which can be done fairly easy even now, but will
> not be automatic) to save some metainfo (ACL, extended attributes,
> Subversion-like properties) along with the file (blob) and/or tree
> (directory).
A problem with adding too much metadata is that there is a cost to this. We
like GIT much thanks to it's perforrmance. Git simply gets out of the way
thanks to this. ACL's aren't content at all. Extended attributes however are,
but who uses them?
-- robin
^ permalink raw reply
* Re: Does GIT require property like Subversion?
From: Petr Baudis @ 2006-10-08 16:24 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Jakub Narebski, git
In-Reply-To: <200610081752.10940.robin.rosenberg.lists@dewire.com>
Dear diary, on Sun, Oct 08, 2006 at 05:52:10PM CEST, I got a letter
where Robin Rosenberg <robin.rosenberg.lists@dewire.com> said that...
> *I* think git should use UTF-8 internally. Always. Clients could then have
> the option to convert to local conventions.
>
> Same for pathname. Internally all paths should be UTF-8 encoded. Encoding
> commit info that way would make the i18n option obsolete also.
There is a tradeoff here between independence of the data stored inside
Git on the system where you created it, and willingness to store any
awful garbage you feed inside. It goes down to a policy decision and Git
lefts it on the user and opting for garbage support, which gives it more
flexibility.
> söndag 08 oktober 2006 12:16 skrev Jakub Narebski:
> > But in fact the philosophy of Git _prohibits_ I think property bits.
> I don't think so, but they aren't needed for the original purpose. Git already
> does manage file permissions.
Incorrect, Git manages only the execute bit.
> > Unless we add ability (which can be done fairly easy even now, but will
> > not be automatic) to save some metainfo (ACL, extended attributes,
> > Subversion-like properties) along with the file (blob) and/or tree
> > (directory).
>
> A problem with adding too much metadata is that there is a cost to this. We
> like GIT much thanks to it's perforrmance. Git simply gets out of the way
> thanks to this. ACL's aren't content at all. Extended attributes however are,
> but who uses them?
Execute bit isn't content at all either if you look at it this way. But
it's meaningless anyway since you can define content whichever way you
want (this is also why I consider the argument for not tracking
directories dubious).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: Does GIT require property like Subversion?
From: Jakub Narebski @ 2006-10-08 16:40 UTC (permalink / raw)
To: git
In-Reply-To: <20061008162410.GK20017@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Sun, Oct 08, 2006 at 05:52:10PM CEST, I got a letter
> where Robin Rosenberg <robin.rosenberg.lists@dewire.com> said that...
>> söndag 08 oktober 2006 12:16 skrev Jakub Narebski:
>>> But in fact the philosophy of Git _prohibits_ I think property bits.
>> I don't think so, but they aren't needed for the original purpose. Git
>> already does manage file permissions.
>
> Incorrect, Git manages only the execute bit.
And symlinks.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: Cleanup Git logo and Git logo target generation
From: Junio C Hamano @ 2006-10-08 19:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <egauic$1l2$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Was this patch dropped? Postponed to after release?
> Waiting for better patch (but this correct esc_html-ing URL...)?
Pretty much the last one -- waiting for a patch directly
applicable from my e-mail client. As far as I can recall there
has been none in the thread.
^ permalink raw reply
* Re: [RFC/PATCH] Enhance core.logallrefupdates
From: Junio C Hamano @ 2006-10-08 19:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <egaibi$bb$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
>> Come to think of it, it might make sense to change the
>> meaning of "true" to do what this patch does. I do not think
>> of reasons to create missing reflog for tags automatically
>> anyway.
>
> If we change meaning of "true", perhaps (just in case in case) we
> should add "all" value?
Didn't I just say that I do not think of reasons to do so ;-)?
Saying "just in case" is not enough. You need to say at least
"this hypothetical workflow which requires to update refs/xxx
and doing automated reflog creation only under refs/heads makes
that workflow less convenient".
^ permalink raw reply
* Re: [RFC/PATCH] pack-refs --all
From: Junio C Hamano @ 2006-10-08 19:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0610081401000.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 8 Oct 2006, Junio C Hamano wrote:
>
>> This changes 'git-pack-refs' to pack only tags by default.
>
> Since there is not really a high cost attached, why not migrate towards
> only-packed-refs? (Of course, this means that git-update-ref should learn
> to update in-place)?
It indeed is tempting and I was tempted to do that and unify
that with ref-log when we were talking about packed refs before
I saw Linus's initial implementation.
^ permalink raw reply
* Re: [RFC PATCH] Add WEBDAV timeout to http-fetch.
From: Junio C Hamano @ 2006-10-08 19:56 UTC (permalink / raw)
To: Sean; +Cc: Johannes Schindelin, git, Petr Baudis, Jakub Narebski,
Nick Hengeveld
In-Reply-To: <BAYC1-PASMTP053FFB92C509E9427F85B0AE110@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
> On Sat, 07 Oct 2006 21:52:02 -0700
> Junio C Hamano <junkio@cox.net> wrote:
>
>> Using DAV, if it works with the server, has the advantage of not
>> having to keep objects/info/packs up-to-date from repository
>> owner's point of view. But the repository owner ends up keeping
>> up-to-date as a side effect of keeping info/refs up-to-date
>> anyway (as I do not see a code to read that information over
>> DAV), so there is no point doing this over DAV in practice.
>>
>> Perhaps we should remove call to remote_ls() from
>> fetch_indices() unconditionally, not just protected with
>> NO_EXPAT and be done with it?
>
> That makes a lot of sense. A server really has to always provide
> a objects/info/packs anyway, just to be fetchable today by clients
> that are compiled with NO_EXPAT.
And even for an isolated group where everybody knows that
everybody else runs DAV-enabled clients, they need info/refs
prepared for ls-remote and git-fetch script, which means you
will run update-server-info to keep objects/info/packs up to
date.
Nick, do you see holes in my logic?
-- >8 --
http-fetch.c: drop remote_ls()
While doing remote_ls() over DAV potentially allows the server
side not to keep objects/info/pack up-to-date, misconfigured or
buggy servers can silently ignore or not to respond to DAV
requests and makes the client hang.
The server side (unfortunately) needs to run git-update-server-info
even if remote_ls() removes the need to keep objects/info/pack file
up-to-date, because the caller of git-http-fetch (git-fetch) and other
clients that interact with the repository (e.g. git-ls-remote) need to
read from info/refs file (there is no code to make that unnecessary by
using DAV yet).
Perhaps the right solution in the longer-term is to make info/refs
also unnecessary by using DAV, and we would want to resurrect the
code this patch removes when we do so, but let's drop remote_ls()
implementation for now. It is causing problems without really
helping anything yet.
git will keep it for us until we need it next time.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/http-fetch.c b/http-fetch.c
index 8f251e7..396552d 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -4,35 +4,6 @@ #include "pack.h"
#include "fetch.h"
#include "http.h"
-#ifndef NO_EXPAT
-#include <expat.h>
-
-/* Definitions for DAV requests */
-#define DAV_PROPFIND "PROPFIND"
-#define DAV_PROPFIND_RESP ".multistatus.response"
-#define DAV_PROPFIND_NAME ".multistatus.response.href"
-#define DAV_PROPFIND_COLLECTION ".multistatus.response.propstat.prop.resourcetype.collection"
-#define PROPFIND_ALL_REQUEST "<?xml version=\"1.0\" encoding=\"utf-8\" ?>\n<D:propfind xmlns:D=\"DAV:\">\n<D:allprop/>\n</D:propfind>"
-
-/* Definitions for processing XML DAV responses */
-#ifndef XML_STATUS_OK
-enum XML_Status {
- XML_STATUS_OK = 1,
- XML_STATUS_ERROR = 0
-};
-#define XML_STATUS_OK 1
-#define XML_STATUS_ERROR 0
-#endif
-
-/* Flags that control remote_ls processing */
-#define PROCESS_FILES (1u << 0)
-#define PROCESS_DIRS (1u << 1)
-#define RECURSIVE (1u << 2)
-
-/* Flags that remote_ls passes to callback functions */
-#define IS_DIR (1u << 0)
-#endif
-
#define PREV_BUF_SIZE 4096
#define RANGE_HEADER_SIZE 30
@@ -90,30 +61,6 @@ struct alternates_request {
int http_specific;
};
-#ifndef NO_EXPAT
-struct xml_ctx
-{
- char *name;
- int len;
- char *cdata;
- void (*userFunc)(struct xml_ctx *ctx, int tag_closed);
- void *userData;
-};
-
-struct remote_ls_ctx
-{
- struct alt_base *repo;
- char *path;
- void (*userFunc)(struct remote_ls_ctx *ls);
- void *userData;
- int flags;
- char *dentry_name;
- int dentry_flags;
- int rc;
- struct remote_ls_ctx *parent;
-};
-#endif
-
static struct object_request *object_queue_head;
static size_t fwrite_sha1_file(void *ptr, size_t eltsize, size_t nmemb,
@@ -714,193 +661,6 @@ #endif
free(url);
}
-#ifndef NO_EXPAT
-static void
-xml_start_tag(void *userData, const char *name, const char **atts)
-{
- struct xml_ctx *ctx = (struct xml_ctx *)userData;
- const char *c = strchr(name, ':');
- int new_len;
-
- if (c == NULL)
- c = name;
- else
- c++;
-
- new_len = strlen(ctx->name) + strlen(c) + 2;
-
- if (new_len > ctx->len) {
- ctx->name = xrealloc(ctx->name, new_len);
- ctx->len = new_len;
- }
- strcat(ctx->name, ".");
- strcat(ctx->name, c);
-
- free(ctx->cdata);
- ctx->cdata = NULL;
-
- ctx->userFunc(ctx, 0);
-}
-
-static void
-xml_end_tag(void *userData, const char *name)
-{
- struct xml_ctx *ctx = (struct xml_ctx *)userData;
- const char *c = strchr(name, ':');
- char *ep;
-
- ctx->userFunc(ctx, 1);
-
- if (c == NULL)
- c = name;
- else
- c++;
-
- ep = ctx->name + strlen(ctx->name) - strlen(c) - 1;
- *ep = 0;
-}
-
-static void
-xml_cdata(void *userData, const XML_Char *s, int len)
-{
- struct xml_ctx *ctx = (struct xml_ctx *)userData;
- free(ctx->cdata);
- ctx->cdata = xmalloc(len + 1);
- strlcpy(ctx->cdata, s, len + 1);
-}
-
-static int remote_ls(struct alt_base *repo, const char *path, int flags,
- void (*userFunc)(struct remote_ls_ctx *ls),
- void *userData);
-
-static void handle_remote_ls_ctx(struct xml_ctx *ctx, int tag_closed)
-{
- struct remote_ls_ctx *ls = (struct remote_ls_ctx *)ctx->userData;
-
- if (tag_closed) {
- if (!strcmp(ctx->name, DAV_PROPFIND_RESP) && ls->dentry_name) {
- if (ls->dentry_flags & IS_DIR) {
- if (ls->flags & PROCESS_DIRS) {
- ls->userFunc(ls);
- }
- if (strcmp(ls->dentry_name, ls->path) &&
- ls->flags & RECURSIVE) {
- ls->rc = remote_ls(ls->repo,
- ls->dentry_name,
- ls->flags,
- ls->userFunc,
- ls->userData);
- }
- } else if (ls->flags & PROCESS_FILES) {
- ls->userFunc(ls);
- }
- } else if (!strcmp(ctx->name, DAV_PROPFIND_NAME) && ctx->cdata) {
- ls->dentry_name = xmalloc(strlen(ctx->cdata) -
- ls->repo->path_len + 1);
- strcpy(ls->dentry_name, ctx->cdata + ls->repo->path_len);
- } else if (!strcmp(ctx->name, DAV_PROPFIND_COLLECTION)) {
- ls->dentry_flags |= IS_DIR;
- }
- } else if (!strcmp(ctx->name, DAV_PROPFIND_RESP)) {
- free(ls->dentry_name);
- ls->dentry_name = NULL;
- ls->dentry_flags = 0;
- }
-}
-
-static int remote_ls(struct alt_base *repo, const char *path, int flags,
- void (*userFunc)(struct remote_ls_ctx *ls),
- void *userData)
-{
- char *url = xmalloc(strlen(repo->base) + strlen(path) + 1);
- struct active_request_slot *slot;
- struct slot_results results;
- struct buffer in_buffer;
- struct buffer out_buffer;
- char *in_data;
- char *out_data;
- XML_Parser parser = XML_ParserCreate(NULL);
- enum XML_Status result;
- struct curl_slist *dav_headers = NULL;
- struct xml_ctx ctx;
- struct remote_ls_ctx ls;
-
- ls.flags = flags;
- ls.repo = repo;
- ls.path = xstrdup(path);
- ls.dentry_name = NULL;
- ls.dentry_flags = 0;
- ls.userData = userData;
- ls.userFunc = userFunc;
- ls.rc = 0;
-
- sprintf(url, "%s%s", repo->base, path);
-
- out_buffer.size = strlen(PROPFIND_ALL_REQUEST);
- out_data = xmalloc(out_buffer.size + 1);
- snprintf(out_data, out_buffer.size + 1, PROPFIND_ALL_REQUEST);
- out_buffer.posn = 0;
- out_buffer.buffer = out_data;
-
- in_buffer.size = 4096;
- in_data = xmalloc(in_buffer.size);
- in_buffer.posn = 0;
- in_buffer.buffer = in_data;
-
- dav_headers = curl_slist_append(dav_headers, "Depth: 1");
- dav_headers = curl_slist_append(dav_headers, "Content-Type: text/xml");
-
- slot = get_active_slot();
- slot->results = &results;
- curl_easy_setopt(slot->curl, CURLOPT_INFILE, &out_buffer);
- curl_easy_setopt(slot->curl, CURLOPT_INFILESIZE, out_buffer.size);
- curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
- curl_easy_setopt(slot->curl, CURLOPT_FILE, &in_buffer);
- curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
- curl_easy_setopt(slot->curl, CURLOPT_URL, url);
- curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 1);
- curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_PROPFIND);
- curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, dav_headers);
-
- if (start_active_slot(slot)) {
- run_active_slot(slot);
- if (results.curl_result == CURLE_OK) {
- ctx.name = xcalloc(10, 1);
- ctx.len = 0;
- ctx.cdata = NULL;
- ctx.userFunc = handle_remote_ls_ctx;
- ctx.userData = &ls;
- XML_SetUserData(parser, &ctx);
- XML_SetElementHandler(parser, xml_start_tag,
- xml_end_tag);
- XML_SetCharacterDataHandler(parser, xml_cdata);
- result = XML_Parse(parser, in_buffer.buffer,
- in_buffer.posn, 1);
- free(ctx.name);
-
- if (result != XML_STATUS_OK) {
- ls.rc = error("XML error: %s",
- XML_ErrorString(
- XML_GetErrorCode(parser)));
- }
- } else {
- ls.rc = -1;
- }
- } else {
- ls.rc = error("Unable to start PROPFIND request");
- }
-
- free(ls.path);
- free(url);
- free(out_data);
- free(in_buffer.buffer);
- curl_slist_free_all(dav_headers);
-
- return ls.rc;
-}
-
-#endif
-
static int fetch_indices(struct alt_base *repo)
{
unsigned char sha1[20];
^ permalink raw reply related
* Re: [PATCH] gitweb: Cleanup Git logo and Git logo target generation
From: Petr Baudis @ 2006-10-08 20:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vwt7aio8l.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Oct 08, 2006 at 09:47:22PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Was this patch dropped? Postponed to after release?
> > Waiting for better patch (but this correct esc_html-ing URL...)?
>
> Pretty much the last one -- waiting for a patch directly
> applicable from my e-mail client. As far as I can recall there
> has been none in the thread.
Is there a problem with taking <200610061231.06017.jnareb@gmail.com>?
I think it's currently not worth the complexity and breakage of
backwards compatibility to do the more elaborate form you proposed.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [RFC/PATCH] Enhance core.logallrefupdates
From: Jakub Narebski @ 2006-10-08 20:15 UTC (permalink / raw)
To: git
In-Reply-To: <7vr6xiio02.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>>> Come to think of it, it might make sense to change the
>>> meaning of "true" to do what this patch does. I do not think
>>> of reasons to create missing reflog for tags automatically
>>> anyway.
>>
>> If we change meaning of "true", perhaps (just in case in case) we
>> should add "all" value?
>
> Didn't I just say that I do not think of reasons to do so ;-)?
>
> Saying "just in case" is not enough. You need to say at least
> "this hypothetical workflow which requires to update refs/xxx
> and doing automated reflog creation only under refs/heads makes
> that workflow less convenient".
If I remember correctly there was example of workflow which did
fetch remote heads to local tags. But I'm not sure if this reflog
made sense with that workflow.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] gitweb: Cleanup Git logo and Git logo target generation
From: Jakub Narebski @ 2006-10-08 20:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwt7aio8l.fsf@assigned-by-dhcp.cox.net>
Rename $githelp_url and $githelp_label to $logo_url and $logo_label to
be more obvious what they refer to; while at it add commented out
previous contents (git documentation at kernel.org). Add comment about
logo size.
Use $cgi->a(...) to generate Git logo link; it automatically escapes
attribute values when it is needed. Escape href attribute using
esc_url instead of (incorrect!) esc_html.
Move styling of git logo <img> element from "style" attribute to CSS
via setting class to "logo". Perhaps we should set it by id rather
than by class.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
I hope that this version is applicable...
gitweb/gitweb.css | 5 +++++
gitweb/gitweb.perl | 17 +++++++++--------
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 668e69a..3f62b6d 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -16,6 +16,11 @@ a:hover, a:visited, a:active {
color: #880000;
}
+img.logo {
+ float: right;
+ border-width: 0px;
+}
+
div.page_header {
height: 25px;
padding: 8px;
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3320069..a966f9f 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -46,13 +46,16 @@ our $home_text = "++GITWEB_HOMETEXT++";
# URI of default stylesheet
our $stylesheet = "++GITWEB_CSS++";
-# URI of GIT logo
+# URI of GIT logo (72x27 size)
our $logo = "++GITWEB_LOGO++";
# URI of GIT favicon, assumed to be image/png type
our $favicon = "++GITWEB_FAVICON++";
-our $githelp_url = "http://git.or.cz/";
-our $githelp_label = "git homepage";
+# URI and label (title) of GIT logo link
+#our $logo_url = "http://www.kernel.org/pub/software/scm/git/docs/";
+#our $logo_label = "git documentation";
+our $logo_url = "http://git.or.cz/";
+our $logo_label = "git homepage";
# source of projects list
our $projects_list = "++GITWEB_LIST++";
@@ -1376,11 +1379,9 @@ EOF
print "</head>\n" .
"<body>\n" .
"<div class=\"page_header\">\n" .
- "<a href=\"" . esc_html($githelp_url) .
- "\" title=\"" . esc_html($githelp_label) .
- "\">" .
- "<img src=\"$logo\" width=\"72\" height=\"27\" alt=\"git\" style=\"float:right; border-width:0px;\"/>" .
- "</a>\n";
+ $cgi->a({-href => esc_url($logo_url),
+ -title => $logo_label},
+ qq(<img src="$logo" width="72" height="27" alt="git" class="logo"/>));
print $cgi->a({-href => esc_url($home_link)}, $home_link_str) . " / ";
if (defined $project) {
print $cgi->a({-href => href(action=>"summary")}, esc_html($project));
--
1.4.2.1
^ permalink raw reply related
* Re: [PATCH] gitweb: Cleanup Git logo and Git logo target generation
From: Junio C Hamano @ 2006-10-08 20:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git
In-Reply-To: <20061008201031.GL20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Is there a problem with taking <200610061231.06017.jnareb@gmail.com>?
>
> I think it's currently not worth the complexity and breakage of
> backwards compatibility to do the more elaborate form you proposed.
I agree with that, except that the 72x27 dimension bit troubles
me.
^ permalink raw reply
* Re: [PATCH] gitweb: Cleanup Git logo and Git logo target generation
From: Jakub Narebski @ 2006-10-08 20:54 UTC (permalink / raw)
To: git
In-Reply-To: <7vbqomim46.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
>> Is there a problem with taking <200610061231.06017.jnareb@gmail.com>?
>>
>> I think it's currently not worth the complexity and breakage of
>> backwards compatibility to do the more elaborate form you proposed.
>
> I agree with that, except that the 72x27 dimension bit troubles
> me.
First, that's the problem for the future. The 72x27 was there, I have not
introduced this.
Second, 72x27 is size override, so although logo would better be 72x27,
but if it is not it will be scaled to given size.
http://www.w3.org/TR/html401/struct/objects.html#visual
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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