* 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
* Does GIT require property like Subversion?
From: Liu Yubao @ 2006-10-08 9:10 UTC (permalink / raw)
To: git
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.
BTW: I don't mean Subversion is better that GIT:-)
^ permalink raw reply
* Re: Why gitweb commitdiff NO diff output ?
From: Dongsheng Song @ 2006-10-08 8:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vwt7hnvsk.fsf@assigned-by-dhcp.cox.net>
> >> Not enough information.
There is gitweb address:
http://www.foresee.com.cn:8888/git/
bad output:
http://www.foresee.com.cn:8888/git/?p=gcc/.git;a=commitdiff;h=c977ee1b2e54d67bb379ce476f784431c32136d7
debian pkgs:
ii bash 3.1-5
The GNU Bourne Again SHell
ii cogito 0.17.3-2
version control system
ii diff 2.8.1-11
File comparison utilities
ii git-core 1.4.2.1-1
content addressable filesystem
ii git-cvs 1.4.2.1-1
content addressable filesystem (cvs interope
ii git-doc 1.4.2.1-1
content addressable filesystem (documentatio
ii git-email 1.4.2.1-1
content addressable filesystem (email add-on
ii git-svn 1.4.2.1-1
content addressable filesystem (svn interope
ii gitweb 1.4.2.1-1
content addressable filesystem (web interfac
ii kernel-image-2.4.27-2-686 2.4.27-12
Linux kernel image for version 2.4.27 on PPr
ii patch 2.5.9-4
Apply a diff file to an original
But the other debian 2.6.x kernel is OK!
^ permalink raw reply
* [RFC/PATCH] pack-refs --all
From: Junio C Hamano @ 2006-10-08 8:08 UTC (permalink / raw)
To: git
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?
builtin-pack-refs.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/builtin-pack-refs.c b/builtin-pack-refs.c
index 23d0d07..1087657 100644
--- a/builtin-pack-refs.c
+++ b/builtin-pack-refs.c
@@ -2,7 +2,7 @@ #include "cache.h"
#include "refs.h"
static const char builtin_pack_refs_usage[] =
-"git-pack-refs [--prune]";
+"git-pack-refs [--all] [--prune]";
struct ref_to_prune {
struct ref_to_prune *next;
@@ -68,6 +68,7 @@ int cmd_pack_refs(int argc, const char *
{
int fd, i;
struct pack_refs_cb_data cbdata;
+ int (*iterate_ref)(each_ref_fn, void *) = for_each_tag_ref;
memset(&cbdata, 0, sizeof(cbdata));
@@ -77,6 +78,10 @@ int cmd_pack_refs(int argc, const char *
cbdata.prune = 1;
continue;
}
+ if (!strcmp(arg, "--all")) {
+ iterate_ref = for_each_ref;
+ continue;
+ }
/* perhaps other parameters later... */
break;
}
@@ -88,7 +93,7 @@ int cmd_pack_refs(int argc, const char *
if (!cbdata.refs_file)
die("unable to create ref-pack file structure (%s)",
strerror(errno));
- for_each_ref(handle_one_ref, &cbdata);
+ iterate_ref(handle_one_ref, &cbdata);
fflush(cbdata.refs_file);
fsync(fd);
fclose(cbdata.refs_file);
^ permalink raw reply related
* [RFC/PATCH] Enhance core.logallrefupdates
From: Junio C Hamano @ 2006-10-08 8:02 UTC (permalink / raw)
To: git
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.
Opinions?
cache.h | 2 ++
config.c | 9 ++++++++-
refs.c | 7 ++++++-
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index 0565333..6029a1d 100644
--- a/cache.h
+++ b/cache.h
@@ -186,6 +186,8 @@ extern int use_legacy_headers;
extern int trust_executable_bit;
extern int assume_unchanged;
extern int prefer_symlink_refs;
+#define REF_LOG_ALL 1
+#define REF_LOG_HEADS 2
extern int log_all_ref_updates;
extern int warn_ambiguous_refs;
extern int shared_repository;
diff --git a/config.c b/config.c
index e8f0caf..c254a57 100644
--- a/config.c
+++ b/config.c
@@ -270,7 +270,14 @@ int git_default_config(const char *var,
}
if (!strcmp(var, "core.logallrefupdates")) {
- log_all_ref_updates = git_config_bool(var, value);
+ if (!strcasecmp(value, "heads"))
+ log_all_ref_updates = REF_LOG_HEADS;
+ else if (!strcasecmp(value, "all"))
+ log_all_ref_updates = REF_LOG_ALL;
+ else if (git_config_bool(var, value))
+ log_all_ref_updates = REF_LOG_ALL;
+ else
+ log_all_ref_updates = 0;
return 0;
}
diff --git a/refs.c b/refs.c
index 305c1a9..fa3c3d7 100644
--- a/refs.c
+++ b/refs.c
@@ -720,8 +720,13 @@ static int log_ref_write(struct ref_lock
unsigned maxlen, len;
char *logrec;
const char *committer;
+ int create_missing = log_all_ref_updates;
- if (log_all_ref_updates) {
+ if ((log_all_ref_updates == REF_LOG_HEADS) &&
+ strncmp(lock->ref_name, "refs/heads/", 11))
+ create_missing = 0;
+
+ if (create_missing) {
if (safe_create_leading_directories(lock->log_file) < 0)
return error("unable to create directory for %s",
lock->log_file);
^ permalink raw reply related
* Re: [RFC] move --show-cdup, --show-prefix, and --show-git-dir out of git-rev-parse.
From: Junio C Hamano @ 2006-10-08 5:43 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20061007213603.GB2871@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> I thought doing the same for these commands as for --help and --version
> but wanted to hear some opinions first...
>
> After all, the comment in front of --version talked about legacy,
> so I was afraid to add more legacy ;-)
Nothing to fear; legacy is about "version" vs "--version".
By the way, rev-parse is not about "refs" at all. It is about
"revs".
A possibly useless comment for people unfamiliar with history I
should add is that git-rev-parse serves two completely different
purposes. One is to separate command line parameters into four
category and output only specified kind. Four categories come
from flags vs non-flags and arguments related to revision
traversal vs other arguments. The "parse" in rev-parse actually
stands for this feature. Many git Porcelainish were implemented
as shell scripts that pipes rev-list output into diff-tree, and
rev-parse was originally invented as a helper for them.
We made many "rev-list | diff-tree --stdin" pattern into
built-in commands, by introducing revision.c, so this first
feature of rev-parse has become less useful.
But as a side-feature, when showing "non-flag, revision
traversal argument", it is told how to show the object name, and
also it acquired --verify option to make sure "extended sha1
expression" (refname, refname followed by ^n, ~n etc.) are
valid.
These days, the command is used primarily to get the object name
from an extended sha1 expression. But some commands (most
notably, bisect) still rely on the "parse" aspect of the
command.
However, in its history it has also become a kitchen sink
command. I think it may make sense to move these kitchen-sink
features such as --show-cdup etc. out of it and give it the
direct options to git wrapper these days. When these features
were added, git wrapper did not even exist.
^ permalink raw reply
* Re: [PATCH] [RFC] Make git-update-ref invoke the update and post-update hooks
From: Junio C Hamano @ 2006-10-08 5:00 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061008000808.1128.36962.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Someone raised a concern that the update and post-update hooks are not
> invoked at fetch time in the similar way as they are invoked at push
> time, and the idea sort of makes sense. But this patch goes further - it
> makes Git invoke those hooks each time a ref is updated in a repository
> using the git-update-ref command, which I believe makes a lot of sense as
> well - the behaviour is consistent with the current pushing behaviour
> and you suddenly finally get a hook where you can properly notify even
> about fast-forwards etc.
In principle I do not have problem with this approach per-se,
but I wonder if we were to do this we might want to make
receive-pack.c::update() and cmd_update_ref() call the same
underlying function, and make that underlying function implement
this "ask the hook if updating is ok" dance. It might even make
sense to have update-ref honor deny_non_fast_forwards for that
matter (I am mildly doubtful of this last point, though).
^ permalink raw reply
* Re: [RFC PATCH] Add WEBDAV timeout to http-fetch.
From: Junio C Hamano @ 2006-10-08 4:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Petr Baudis, Jakub Narebski
In-Reply-To: <Pine.LNX.4.63.0610080034490.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Actually, I do not think that anybody in her right mind would set this to
> different values for different repos or servers.
>
> I _know_ that if I hit that very problem, the next thing I'd do is set the
> timeout to 5 seconds _globally_.
Let's step back a bit.
The DAV request in question the one to remote_ls() in
http-fetch.c, which tries to read directly from objects/pack/
instead of using objects/info/packs, and it does not matter if
DAV request fails because it would fall back to non-DAV anyway.
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?
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Luben Tuikov @ 2006-10-08 1:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vmz87pxg6.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > --- Petr Baudis <pasky@suse.cz> wrote:
> >> Signed-off-by: Petr Baudis <pasky@suse.cz>
> >> ---
> >
> > First, this is a Unixism, and would confuse other OS users.
> > Second, "/" is after all _not part of the name_ of the tree/directory,
> > but part of the filesystem's path separator, let's not export it
> > to users of other OS's.
> > Third, directories/trees are already clearly
> > 1) underlined, and
> > 2) differently colored,
> > which makes it overly obvious what it what.
>
> I was actually hoping that we can get rid of the differences you
> cited above.
>
> Underlines make entries harder to read, and colouring is
> distracting; some people do not see all colours and to them it
> may not distracting but then they need another way to notice the
> differences between tree/blob.
I know, I've seen your email on that and have your patch with the
icons applied at work. But it is black and white and I'd rather
see some nice color and shading if we're going to change that.
I don't mind using nice warm color icons in the left-most column.
Luben
^ permalink raw reply
* Re: [PATCH 1/2] gitweb: Show snapshot links for tree entries in tree listing
From: Luben Tuikov @ 2006-10-08 1:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20061007191552.GG20017@pasky.or.cz>
--- Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Sat, Oct 07, 2006 at 08:52:53PM CEST, I got a letter
> where Luben Tuikov <ltuikov@yahoo.com> said that...
> > Another thing is that currently tree/directory entries' third (links)
> > column to be shortest of all, and this gives my eyes another indication
> > that this is a tree.
>
> What would people think about first listing all the trees, then all the
> blobs? Just like LANG=C ls does, as well as cvsweb and overally most of
> the rest of the relevant world.
I don't like it and the reason is that when I'm searching for something
I expect the listing to be alphabetically sorted, period.
Not type-then-alphabetical, which is greatly distracting and only makes
me lose 3-10 seconds looking for the item I'm looking at.
Bunching up the directories at the top and then listing the files at
the bottom is one of those great annoyances.
But, if you do implement that, please make it configurable, because
I'll resort to the current listing order.
Luben
^ permalink raw reply
* [PATCH] [RFC] Make git-update-ref invoke the update and post-update hooks
From: Petr Baudis @ 2006-10-08 0:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Someone raised a concern that the update and post-update hooks are not
invoked at fetch time in the similar way as they are invoked at push
time, and the idea sort of makes sense. But this patch goes further - it
makes Git invoke those hooks each time a ref is updated in a repository
using the git-update-ref command, which I believe makes a lot of sense as
well - the behaviour is consistent with the current pushing behaviour
and you suddenly finally get a hook where you can properly notify even
about fast-forwards etc.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-update-ref.txt | 3 ++
Documentation/hooks.txt | 12 ++++--
Makefile | 2 +
builtin-update-ref.c | 12 ++++++
hooks.c | 68 ++++++++++++++++++++++++++++++++++++
hooks.h | 15 ++++++++
receive-pack.c | 71 +-------------------------------------
7 files changed, 106 insertions(+), 77 deletions(-)
diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
index 71bcb79..bd20d05 100644
--- a/Documentation/git-update-ref.txt
+++ b/Documentation/git-update-ref.txt
@@ -51,6 +51,9 @@ for reading but not for writing (so we'l
ref symlink to some other tree, if you have copied a whole
archive by creating a symlink tree).
+Just before updating the reference, the update hook is invoked.
+After updating the reference, the post-update hook is invoked.
+
With `-d` flag, it deletes the named <ref> after verifying it
still contains <oldvalue>.
diff --git a/Documentation/hooks.txt b/Documentation/hooks.txt
index 517f49b..53fa270 100644
--- a/Documentation/hooks.txt
+++ b/Documentation/hooks.txt
@@ -99,8 +99,9 @@ update
This hook is invoked by `git-receive-pack` on the remote repository,
which happens when a `git push` is done on a local repository.
Just before updating the ref on the remote repository, the update hook
-is invoked. Its exit status determines the success or failure of
-the ref update.
+is invoked. It is also invoked on the local repository anytime a ref
+value is updated (that includes mainly fetches, merges, commits).
+Its exit status determines the success or failure of the ref update.
The hook executes once for each ref to be updated, and takes
three parameters:
@@ -135,9 +136,10 @@ post-update
-----------
This hook is invoked by `git-receive-pack` on the remote repository,
-which happens when a `git push` is done on a local repository.
-It executes on the remote repository once after all the refs have
-been updated.
+which happens when a `git push` is done on a local repository
+It is also invoked on the local repository anytime a ref value is
+updated (that includes mainly fetches, merges, commits). It executes
+on the repository once after all the refs have been updated.
It takes a variable number of parameters, each of which is the
name of ref that was actually updated.
diff --git a/Makefile b/Makefile
index 2962c2e..8e58585 100644
--- a/Makefile
+++ b/Makefile
@@ -263,7 +263,7 @@ LIB_OBJS = \
fetch-clone.o revision.o pager.o tree-walk.o xdiff-interface.o \
write_or_die.o trace.o list-objects.o grep.o \
alloc.o merge-file.o path-list.o help.o unpack-trees.o $(DIFF_OBJS) \
- color.o wt-status.o archive-zip.o archive-tar.o
+ color.o wt-status.o archive-zip.o archive-tar.o hooks.o
BUILTIN_OBJS = \
builtin-add.o \
diff --git a/builtin-update-ref.c b/builtin-update-ref.c
index b34e598..546cbb1 100644
--- a/builtin-update-ref.c
+++ b/builtin-update-ref.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "refs.h"
#include "builtin.h"
+#include "hooks.h"
static const char git_update_ref_usage[] =
"git-update-ref [-m <reason>] (-d <refname> <value> | <refname> <value> [<oldval>])";
@@ -11,6 +12,7 @@ int cmd_update_ref(int argc, const char
struct ref_lock *lock;
unsigned char sha1[20], oldsha1[20];
int i, delete;
+ struct command *cmd;
delete = 0;
setup_ident();
@@ -63,9 +65,17 @@ int cmd_update_ref(int argc, const char
lock = lock_any_ref_for_update(refname, oldval ? oldsha1 : NULL);
if (!lock)
return 1;
+ if (run_update_hook(refname, oldval, value)) {
+ unlock_ref(lock);
+ return 1;
+ }
if (write_ref_sha1(lock, sha1, msg) < 0)
return 1;
-
/* write_ref_sha1 always unlocks the ref, no need to do it explicitly */
+
+ cmd = xmalloc(sizeof(struct command) + strlen(refname) + 1);
+ strcpy(cmd->ref_name, refname);
+ run_update_post_hook(cmd);
+
return 0;
}
diff --git a/hooks.c b/hooks.c
new file mode 100644
index 0000000..efade2b
--- /dev/null
+++ b/hooks.c
@@ -0,0 +1,68 @@
+#include "cache.h"
+#include "run-command.h"
+#include "hooks.h"
+
+
+static char update_hook[] = "hooks/update";
+
+int run_update_hook(const char *refname, const char *old_hex, const char *new_hex)
+{
+ char *update_hook_p = git_path("%s", update_hook);
+ int code;
+
+ if (access(update_hook_p, X_OK) < 0)
+ return 0;
+ code = run_command(update_hook_p, refname, old_hex, new_hex, NULL);
+ switch (code) {
+ case 0:
+ return 0;
+ case -ERR_RUN_COMMAND_FORK:
+ return error("hook fork failed");
+ case -ERR_RUN_COMMAND_EXEC:
+ return error("hook execute failed");
+ case -ERR_RUN_COMMAND_WAITPID:
+ return error("waitpid failed");
+ case -ERR_RUN_COMMAND_WAITPID_WRONG_PID:
+ return error("waitpid is confused");
+ case -ERR_RUN_COMMAND_WAITPID_SIGNAL:
+ return error("%s died of signal", update_hook);
+ case -ERR_RUN_COMMAND_WAITPID_NOEXIT:
+ return error("%s died strangely", update_hook);
+ default:
+ error("%s exited with error code %d", update_hook, -code);
+ return -code;
+ }
+}
+
+
+static char update_post_hook[] = "hooks/post-update";
+
+void run_update_post_hook(struct command *cmd)
+{
+ char *update_post_hook_p = git_path("%s", update_post_hook);
+ struct command *cmd_p;
+ int argc;
+ const char **argv;
+
+ if (access(update_post_hook_p, X_OK) < 0)
+ return;
+ for (argc = 1, cmd_p = cmd; cmd_p; cmd_p = cmd_p->next) {
+ if (cmd_p->error_string)
+ continue;
+ argc++;
+ }
+ argv = xmalloc(sizeof(*argv) * (1 + argc));
+ argv[0] = update_post_hook_p;
+
+ for (argc = 1, cmd_p = cmd; cmd_p; cmd_p = cmd_p->next) {
+ char *p;
+ if (cmd_p->error_string)
+ continue;
+ p = xmalloc(strlen(cmd_p->ref_name) + 1);
+ strcpy(p, cmd_p->ref_name);
+ argv[argc] = p;
+ argc++;
+ }
+ argv[argc] = NULL;
+ run_command_v_opt(argc, argv, RUN_COMMAND_NO_STDIO);
+}
diff --git a/hooks.h b/hooks.h
new file mode 100644
index 0000000..8ddeca3
--- /dev/null
+++ b/hooks.h
@@ -0,0 +1,15 @@
+#ifndef HOOKS_H
+#define HOOKS_H
+
+int run_update_hook(const char *refname, const char *old_hex, const char *new_hex);
+
+struct command {
+ struct command *next;
+ const char *error_string;
+ unsigned char old_sha1[20];
+ unsigned char new_sha1[20];
+ char ref_name[FLEX_ARRAY]; /* more */
+};
+void run_update_post_hook(struct command *cmd);
+
+#endif
diff --git a/receive-pack.c b/receive-pack.c
index 1fcf3a9..9d5ece6 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -4,6 +4,7 @@ #include "pkt-line.h"
#include "run-command.h"
#include "commit.h"
#include "object.h"
+#include "hooks.h"
static const char receive_pack_usage[] = "git-receive-pack <git-dir>";
@@ -33,47 +34,8 @@ static void write_head_info(void)
}
-struct command {
- struct command *next;
- const char *error_string;
- unsigned char old_sha1[20];
- unsigned char new_sha1[20];
- char ref_name[FLEX_ARRAY]; /* more */
-};
-
static struct command *commands;
-static char update_hook[] = "hooks/update";
-
-static int run_update_hook(const char *refname,
- char *old_hex, char *new_hex)
-{
- int code;
-
- if (access(update_hook, X_OK) < 0)
- return 0;
- code = run_command(update_hook, refname, old_hex, new_hex, NULL);
- switch (code) {
- case 0:
- return 0;
- case -ERR_RUN_COMMAND_FORK:
- return error("hook fork failed");
- case -ERR_RUN_COMMAND_EXEC:
- return error("hook execute failed");
- case -ERR_RUN_COMMAND_WAITPID:
- return error("waitpid failed");
- case -ERR_RUN_COMMAND_WAITPID_WRONG_PID:
- return error("waitpid is confused");
- case -ERR_RUN_COMMAND_WAITPID_SIGNAL:
- return error("%s died of signal", update_hook);
- case -ERR_RUN_COMMAND_WAITPID_NOEXIT:
- return error("%s died strangely", update_hook);
- default:
- error("%s exited with error code %d", update_hook, -code);
- return -code;
- }
-}
-
static int update(struct command *cmd)
{
const char *name = cmd->ref_name;
@@ -127,37 +89,6 @@ static int update(struct command *cmd)
return 0;
}
-static char update_post_hook[] = "hooks/post-update";
-
-static void run_update_post_hook(struct command *cmd)
-{
- struct command *cmd_p;
- int argc;
- const char **argv;
-
- if (access(update_post_hook, X_OK) < 0)
- return;
- for (argc = 1, cmd_p = cmd; cmd_p; cmd_p = cmd_p->next) {
- if (cmd_p->error_string)
- continue;
- argc++;
- }
- argv = xmalloc(sizeof(*argv) * (1 + argc));
- argv[0] = update_post_hook;
-
- for (argc = 1, cmd_p = cmd; cmd_p; cmd_p = cmd_p->next) {
- char *p;
- if (cmd_p->error_string)
- continue;
- p = xmalloc(strlen(cmd_p->ref_name) + 1);
- strcpy(p, cmd_p->ref_name);
- argv[argc] = p;
- argc++;
- }
- argv[argc] = NULL;
- run_command_v_opt(argc, argv, RUN_COMMAND_NO_STDIO);
-}
-
/*
* This gets called after(if) we've successfully
* unpacked the data payload.
^ permalink raw reply related
* Re: [RFC PATCH] Add WEBDAV timeout to http-fetch.
From: Johannes Schindelin @ 2006-10-07 22:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git
In-Reply-To: <20061007223023.GI20017@pasky.or.cz>
Hi,
On Sun, 8 Oct 2006, Petr Baudis wrote:
> Dear diary, on Sat, Oct 07, 2006 at 07:32:25PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
>
> > HOWEVER, Junio pointed out that he'd like a finer grain than per-repo, and
> > .gitconfig is a coarser one!
>
> Actually, that doesn't matter. The point is that it is of _different_
> shape than this division. It's per remote server, even spanning several
> repositories. So you want to be able to set it up per the server, at the
> most global place possible for a regular user, so ~/.gitconfig might be
> good idea.
Actually, I do not think that anybody in her right mind would set this to
different values for different repos or servers.
I _know_ that if I hit that very problem, the next thing I'd do is set the
timeout to 5 seconds _globally_.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Junio C Hamano @ 2006-10-07 22:34 UTC (permalink / raw)
To: ltuikov; +Cc: Petr Baudis, git
In-Reply-To: <20061007184418.64881.qmail@web31812.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> --- Petr Baudis <pasky@suse.cz> wrote:
>> Signed-off-by: Petr Baudis <pasky@suse.cz>
>> ---
>
> First, this is a Unixism, and would confuse other OS users.
> Second, "/" is after all _not part of the name_ of the tree/directory,
> but part of the filesystem's path separator, let's not export it
> to users of other OS's.
> Third, directories/trees are already clearly
> 1) underlined, and
> 2) differently colored,
> which makes it overly obvious what it what.
I was actually hoping that we can get rid of the differences you
cited above.
Underlines make entries harder to read, and colouring is
distracting; some people do not see all colours and to them it
may not distracting but then they need another way to notice the
differences between tree/blob.
^ permalink raw reply
* Re: [PATCH 1/2] gitweb: Show snapshot links for tree entries in tree listing
From: Junio C Hamano @ 2006-10-07 22:31 UTC (permalink / raw)
To: Petr Baudis; +Cc: Luben Tuikov, git
In-Reply-To: <20061007191552.GG20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Sat, Oct 07, 2006 at 08:52:53PM CEST, I got a letter
> where Luben Tuikov <ltuikov@yahoo.com> said that...
>> Another thing is that currently tree/directory entries' third (links)
>> column to be shortest of all, and this gives my eyes another indication
>> that this is a tree.
>
> What would people think about first listing all the trees, then all the
> blobs? Just like LANG=C ls does, as well as cvsweb and overally most of
> the rest of the relevant world.
Mildly negative but I do not have strong preference.
BTW, I do not get what you mean by "LANG=C ls".
^ permalink raw reply
* Re: [RFC PATCH] Add WEBDAV timeout to http-fetch.
From: Petr Baudis @ 2006-10-07 22:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.63.0610071930300.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Dear diary, on Sat, Oct 07, 2006 at 07:32:25PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> Hi,
>
> On Sat, 7 Oct 2006, Jakub Narebski wrote:
>
> > Perhaps use undocumented (hint, hint! for whoever did code this)
> > per-user ~/.gitconfig?
>
> A good idea to use this (hint, hint! whoever finds out how it works can
> document it as well) feature.
>
> HOWEVER, Junio pointed out that he'd like a finer grain than per-repo, and
> .gitconfig is a coarser one!
Actually, that doesn't matter. The point is that it is of _different_
shape than this division. It's per remote server, even spanning several
repositories. So you want to be able to set it up per the server, at the
most global place possible for a regular user, so ~/.gitconfig might be
good idea.
--
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] Add WEBDAV timeout to http-fetch.
From: Junio C Hamano @ 2006-10-07 22:24 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: Sean, git, Nick Hengeveld
In-Reply-To: <20061007193559.GA27920@poseidon.issaris.org>
Panagiotis Issaris <takis.issaris@uhasselt.be> writes:
>> > Maybe the real solution is just to figure out and fix whatever is
>> > going on with the WEBDAV server and forget this patch.
>>
>> I think it is prudent to protect the client from a broken server
>> and it is independent from "fixing" the server side. It would
>>[...]
> Wouldn't most users ctrl-c the program before the two minute timeout occurs?
> Especially since their appears to be nothing happening?
I think we are talking about the same thing -- after you kill it
with C-c you would want to work it around. The question is how?
You would want to re-run with timeout value of 0 second (or
WEBDAV disabled, if we can have such an option); if it works
then you would want the tool to remember that you want to use
that particular settings but probably only when talking to that
remote.
^ permalink raw reply
* Re: [RFC] move --show-cdup, --show-prefix, and --show-git-dir out of git-rev-parse.
From: Martin Waitz @ 2006-10-07 21:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eg95a6$2v7$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 684 bytes --]
On Sat, Oct 07, 2006 at 11:14:34PM +0200, Jakub Narebski wrote:
> Martin Waitz wrote:
> > They don't really have anything to do with refs.
>
> But is it a good idea to add yet another command? We have too many of them
> already...
true
> I'd rather add one command, git-admin/git-config, or just move the options
> to the "git" command. So we would have "git --show-git-dir" in addition to
> "git --git-dir=<directory>".
I thought doing the same for these commands as for --help and --version
but wanted to hear some opinions first...
After all, the comment in front of --version talked about legacy,
so I was afraid to add more legacy ;-)
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: A Large Angry SCM @ 2006-10-07 21:31 UTC (permalink / raw)
To: ltuikov; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <20061007184418.64881.qmail@web31812.mail.mud.yahoo.com>
Luben Tuikov wrote:
> --- Petr Baudis <pasky@suse.cz> wrote:
>> Signed-off-by: Petr Baudis <pasky@suse.cz>
>> ---
>
> First, this is a Unixism, and would confuse other OS users.
> Second, "/" is after all _not part of the name_ of the tree/directory,
> but part of the filesystem's path separator, let's not export it
> to users of other OS's.
> Third, directories/trees are already clearly
> 1) underlined, and
> 2) differently colored,
> which makes it overly obvious what it what.
>
> In fact, my eyes only scan for the different color/underlined
> entries when I'm searching for a directory in tree view. I don't even
> look at the left-most column.
Not that I care that much, but
1) not all browsers show underlines (try some text mode browsers)
2) not all browsers show colors (try some text mode browsers)
2) not all people see all colors
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Jakub Narebski @ 2006-10-07 21:27 UTC (permalink / raw)
To: git
In-Reply-To: <20061007211531.GH20017@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Sat, Oct 07, 2006 at 10:38:51PM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> Petr Baudis wrote:
>>
>> > So, I'd like to either have the view links or the filenames in classical
>> > link style so that it's apparent they are clickable; I didn't post a
>> > patch since I didn't have time/energy to fight for it yet. ;-)
>>
>> There is a tradeout. Either have easily distinguishable directories and
>> files, by using both different color and decoration (underline), or we have
>> filename/directory name clearly marked as link. One or the other.
>>
>> That is why I'd rather have this "redundant" blob/tree link (perhaps in
>> separate column).
>
> As I suggested in another mail, perhaps the whole problem is wrong and
> you shouldn't have to dug for trees in a bunch of blobs in the first
> place - let's group all the trees at the top, as all the well-behaved
> directory listings do.
It is a good idea, although we would wither to have to read the directory
(tree) listing first into some array, then sort it directories first
(contrary to current output while reading, which reduces latency provided
that browser can properly display partial contents), or add some option
to git-ls-tree command to output tree entries (directories) first, instead
of sorting by filename.
>> But this is a matter of policy, unless we want to add theme support to
>> gitweb ;-))
>
> We _do_ have that - you can supply your own gitweb.css. But the defaults
> should be sensible.
Theme support, as to be able to choose theme, like style selectable from
web browser, and for example choosing if the tree/blob links are present
or not. Some of which might be done via CSS (display:none).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Petr Baudis @ 2006-10-07 21:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eg9378$rln$1@sea.gmane.org>
Dear diary, on Sat, Oct 07, 2006 at 10:38:51PM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Petr Baudis wrote:
>
> > So, I'd like to either have the view links or the filenames in classical
> > link style so that it's apparent they are clickable; I didn't post a
> > patch since I didn't have time/energy to fight for it yet. ;-)
>
> There is a tradeout. Either have easily distinguishable directories and
> files, by using both different color and decoration (underline), or we have
> filename/directory name clearly marked as link. One or the other.
>
> That is why I'd rather have this "redundant" blob/tree link (perhaps in
> separate column).
As I suggested in another mail, perhaps the whole problem is wrong and
you shouldn't have to dug for trees in a bunch of blobs in the first
place - let's group all the trees at the top, as all the well-behaved
directory listings do.
> But this is a matter of policy, unless we want to add theme support to
> gitweb ;-))
We _do_ have that - you can supply your own gitweb.css. But the defaults
should be sensible.
--
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] move --show-cdup, --show-prefix, and --show-git-dir out of git-rev-parse.
From: Jakub Narebski @ 2006-10-07 21:14 UTC (permalink / raw)
To: git
In-Reply-To: <20061007210429.GA2871@admingilde.org>
Martin Waitz wrote:
> They don't really have anything to do with refs.
But is it a good idea to add yet another command? We have too many of them
already...
I'd rather add one command, git-admin/git-config, or just move the options
to the "git" command. So we would have "git --show-git-dir" in addition to
"git --git-dir=<directory>".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [RFC] move --show-cdup, --show-prefix, and --show-git-dir out of git-rev-parse.
From: Martin Waitz @ 2006-10-07 21:04 UTC (permalink / raw)
To: git
They don't really have anything to do with refs.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
Makefile | 1 +
builtin-show-prefix.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++
builtin.h | 3 +++
git.c | 3 +++
4 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 2c7c338..c072162 100644
--- a/Makefile
+++ b/Makefile
@@ -298,6 +298,7 @@ BUILTIN_OBJS = \
builtin-rm.o \
builtin-runstatus.o \
builtin-show-branch.o \
+ builtin-show-prefix.o \
builtin-stripspace.o \
builtin-symbolic-ref.o \
builtin-tar-tree.o \
diff --git a/builtin-show-prefix.c b/builtin-show-prefix.c
new file mode 100644
index 0000000..ed46434
--- /dev/null
+++ b/builtin-show-prefix.c
@@ -0,0 +1,50 @@
+/*
+ * Show some information about the GIT repository
+ */
+
+#include "builtin.h"
+#include "cache.h"
+
+int cmd_show_prefix(int argc, const char **argv, const char *prefix)
+{
+ if (prefix)
+ puts(prefix);
+
+ return 0;
+}
+
+int cmd_show_cdup(int argc, const char **argv, const char *prefix)
+{
+ const char *pfx = prefix;
+
+ while (pfx) {
+ pfx = strchr(pfx, '/');
+ if (pfx) {
+ pfx++;
+ printf("../");
+ }
+ }
+ putchar('\n');
+
+ return 0;
+}
+
+int cmd_show_git_dir(int argc, const char **argv, const char *prefix)
+{
+ const char *gitdir = getenv(GIT_DIR_ENVIRONMENT);
+ static char cwd[PATH_MAX];
+
+ if (gitdir) {
+ puts(gitdir);
+ return 0;
+ }
+ if (!prefix) {
+ puts(".git");
+ return 0;
+ }
+ if (!getcwd(cwd, PATH_MAX))
+ die("unable to get current working directory");
+ printf("%s/.git\n", cwd);
+
+ return 0;
+}
diff --git a/builtin.h b/builtin.h
index f9fa9ff..fb313d8 100644
--- a/builtin.h
+++ b/builtin.h
@@ -49,6 +49,9 @@ extern int cmd_rev_parse(int argc, const
extern int cmd_rm(int argc, const char **argv, const char *prefix);
extern int cmd_runstatus(int argc, const char **argv, const char *prefix);
extern int cmd_show_branch(int argc, const char **argv, const char *prefix);
+extern int cmd_show_cdup(int argc, const char **argv, const char *prefix);
+extern int cmd_show_git_dir(int argc, const char **argv, const char *prefix);
+extern int cmd_show_prefix(int argc, const char **argv, const char *prefix);
extern int cmd_show(int argc, const char **argv, const char *prefix);
extern int cmd_stripspace(int argc, const char **argv, const char *prefix);
extern int cmd_symbolic_ref(int argc, const char **argv, const char *prefix);
diff --git a/git.c b/git.c
index b8e8622..3f2eada 100644
--- a/git.c
+++ b/git.c
@@ -255,6 +255,9 @@ static void handle_internal_command(int
{ "rm", cmd_rm, RUN_SETUP },
{ "runstatus", cmd_runstatus, RUN_SETUP },
{ "show-branch", cmd_show_branch, RUN_SETUP },
+ { "show-cdup", cmd_show_cdup, RUN_SETUP },
+ { "show-git-dir", cmd_show_git_dir, RUN_SETUP },
+ { "show-prefix", cmd_show_prefix, RUN_SETUP },
{ "show", cmd_show, RUN_SETUP | USE_PAGER },
{ "stripspace", cmd_stripspace },
{ "symbolic-ref", cmd_symbolic_ref, RUN_SETUP },
--
1.4.2.3
--
Martin Waitz
^ permalink raw reply related
* Spam on Git Wiki
From: Jakub Narebski @ 2006-10-07 21:01 UTC (permalink / raw)
To: git
There is spam revert war on Git Wiki, see history of
http://git.or.cz/gitwiki/gitwiki/gitwiki/gitwiki/GitWikiSuggestions
page. Could admins delete this page, please?
What is curious, the "commit message" is also used for link farming.
I'd rather not have to resort to need to register to add a page/make
changes, perhaps with some anti-spambot measurements.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Jakub Narebski @ 2006-10-07 20:38 UTC (permalink / raw)
To: git
In-Reply-To: <20061007191246.GF20017@pasky.or.cz>
Petr Baudis wrote:
> So, I'd like to either have the view links or the filenames in classical
> link style so that it's apparent they are clickable; I didn't post a
> patch since I didn't have time/energy to fight for it yet. ;-)
There is a tradeout. Either have easily distinguishable directories and
files, by using both different color and decoration (underline), or we have
filename/directory name clearly marked as link. One or the other.
That is why I'd rather have this "redundant" blob/tree link (perhaps in
separate column).
But this is a matter of policy, unless we want to add theme support to
gitweb ;-))
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: Support hiding of chosen repositories from project list
From: Junio C Hamano @ 2006-10-07 19:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061007123200.GY20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> (BTW, I privately consider /pub/git as completely specific to kernel.org
> setup and pure evil to have as default; I would much prefer to have the
> default something more standard and LHS-compliant like /srv/git (almost)
> is. Though I can see the possible pitfalls of changing the default at
> this point (though Google says that only tipc.cslab.ericsson.net uses
> the same path), this default leads to people inventing own random paths
> and chaos reigns: /var/git in Gentoo, /srv/git in SUSE, abomination like
> /var/cache/git (!) in Debian, others don't seem to bother with gitweb.)
While I share the same concern to some degree, distro's usually
use whatever path they want to be consistent with their layout
(which I hope to converge to LHS or something). As long as we
have it easily overridable from their build system (which we do)
it should not matter too much for them. For people who build
and install their own, I suspect most of them do so because they
do not either like the version installed by the sysadmin or they
cannot write into system-wide directories, so to them the path
needs to be redefined to point at elsewhere anyway and would not
be an issue either. But my guess might be grossly wrong.
^ 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