* Re: [PATCH] gitk: UTF-8 support
From: Pavel Roskin @ 2005-11-24 4:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git
In-Reply-To: <7v64qi50sw.fsf@assigned-by-dhcp.cox.net>
Hello!
Quoting Junio C Hamano <junkio@cox.net>:
> Pavel Roskin <proski@gnu.org> writes:
>
> > Add gitencoding variable and set it to "utf-8". Use it for converting
> > git-rev-list output.
>
> Sounds good, but is it necessary? Unless I am grossly mistaken,
> I am opposed to this patch.
>
> When I run gitk with LANG and/or LC_CTYPE set to ja_JP.utf8 (I
> suspect *whatever*.utf8 would work the same way) on git.git
> repository, I see Lukas's name (originally in iso8859-1 but my
> commit objects have it in utf8) and Yoshifuji-san's name
> (iso2022 converted to utf8) just fine.
I see. I always use C locale.
> And when I run gitk with LANG and/or LC_CTYPE set to ja_JP.ujis
> (that is another name for EUC-JP) on a toy repository I have
> commit log messages in EUC-JP (I am not recommending that, just
> pointing out a possibility), I can see them just fine. In that
> test repository, setting locale to *.utf8 would not work.
Then what would you do to work with a repository using utf-8 if the current
locale is not utf-8?
> So I suspect your change breaks projects that use local
> encodings, without fixing or adding anything new.
I'll be away from any sane OS until Monday, but I assume my patch should help
those whose locale is set to an encoding other than utf-8 if they want to use a
repository using utf-8.
Anyway, I see your point. Not ever git repository uses utf-8. It is not
enforced by git.
So we have two solutions. One is to enforce utf-8 locale in git and force all
"offenders" to convert. That's probably too intrusive for now.
The other solution is to have a publicly available file under .git that would
keep the encoding name for the metadata (user names, logs etc). gitk could use
that file now. git could implement conversions a bit later. Maybe git could
warn about mismatching encoding as the first step.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [RFC/PATCH 3/3] Check repository format version.
From: Junio C Hamano @ 2005-11-24 3:36 UTC (permalink / raw)
To: git; +Cc: Martin Atukunda
Add check_repository_format() that is to be called when we know
where the configuration file is and die if the format version
is too new to be understood by us.
Use it in enter_repo(), setup_git_directory(), and git-find-git
to prevent the commands that use them to corrupt future git
repositories. What this patch does not cover are commands that
implicitly assumes it is always run from the toplevel, or the
user tells us where the git directory is with the GIT_DIR
environment variable.
setup_git_directory() users that could corrupt future repository
without this change are:
config-set symbolic-ref update-index update-ref
and that could yield incorrect results are:
cat-file diff-files diff-index diff-stages diff-tree
ls-files name-rev rev-list rev-parse show-branch
enter_repo() users are:
daemon receive-pack upload-pack
git-find-git is used by git-sh-setup, which means most of the
barebone Porcelain scripts are covered with this change upfront.
This might be enough for everyday use to futureproof us.
The repository format check code was originally done by Martin
Atukunda.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* The checks in this version is less intrusive compared to
Martin's version, and tries to check only once when we know
where the configuration file should be.
cache.h | 2 +-
find-git.c | 5 +++--
git-sh-setup.sh | 2 +-
path.c | 1 +
setup.c | 24 ++++++++++++++++++++++--
5 files changed, 28 insertions(+), 6 deletions(-)
applies-to: cfcbe85286bb9bfb4f04169269c543640626218d
08279559b1d63107c4e25abb4c882ad21e1ad43b
diff --git a/cache.h b/cache.h
index 7cde341..c3e46f3 100644
--- a/cache.h
+++ b/cache.h
@@ -185,7 +185,7 @@ extern int diff_rename_limit_default;
#define GIT_REPO_VERSION 0
extern int repository_format_version;
-extern int check_repo_format(void);
+extern int check_repository_format(void);
#define MTIME_CHANGED 0x0001
#define CTIME_CHANGED 0x0002
diff --git a/find-git.c b/find-git.c
index e063425..430ba7c 100644
--- a/find-git.c
+++ b/find-git.c
@@ -14,9 +14,10 @@ int main(int ac, char **av)
*/
git_config(git_default_config);
- /* Later we check repository version and exit with non-zero
- * status after issuing an error message here.
+ /* This would die after issuing an error message if we
+ * do not understand the repository format.
*/
+ check_repository_format();
if (!prefix)
/* we are at the project toplevel or GIT_DIR is set.
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 8e30bf6..2485bb9 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -37,6 +37,6 @@ case "$?" in
# (128) git-find-git died -- malformed configuration and that
# is really fatal. We have already given the error message.
-
+ exit $?
;;
esac
diff --git a/path.c b/path.c
index 4d88947..2c077c0 100644
--- a/path.c
+++ b/path.c
@@ -199,6 +199,7 @@ char *enter_repo(char *path, int strict)
if(access("objects", X_OK) == 0 && access("refs", X_OK) == 0 &&
validate_symref("HEAD") == 0) {
putenv("GIT_DIR=.");
+ check_repository_format();
return current_dir();
}
diff --git a/setup.c b/setup.c
index f64ca23..48be931 100644
--- a/setup.c
+++ b/setup.c
@@ -73,7 +73,7 @@ const char **get_pathspec(const char *pr
}
/*
- * Test it it looks like we're at the top
+ * Test if it looks like we're at the top
* level git directory. We want to see a
*
* - either a .git/objects/ directory _or_ the proper
@@ -135,5 +135,25 @@ const char *setup_git_directory_gently(i
const char *setup_git_directory(void)
{
- return setup_git_directory_gently(NULL);
+ const char *retval = setup_git_directory_gently(NULL);
+ check_repository_format();
+ return retval;
+}
+
+static int check_repository_format_version(const char *var, const char *value)
+{
+ if (strcmp(var, "core.repositoryformatversion") == 0) {
+ repository_format_version = git_config_int(var, value);
+ }
+ return 0;
+}
+
+int check_repository_format(void)
+{
+ if (git_config(check_repository_format_version) == -1)
+ return -1;
+ if (GIT_REPO_VERSION < repository_format_version)
+ die("Expected git repo version <= %d, found %d",
+ GIT_REPO_VERSION, repository_format_version);
+ return 0;
}
---
0.99.9.GIT
^ permalink raw reply related
* [RFC/PATCH 2/3] Add GIT_REPO_VERSION, and repository_format_version
From: Junio C Hamano @ 2005-11-24 3:36 UTC (permalink / raw)
To: git
From: Martin Atukunda <matlads@dsmagic.com>
Date: 1132619292 +0300
This variable will enable git to track the repository version. It's
currently set to 0. (in true C style :)
Signed-off-by: Martin Atukunda <matlads@dsmagic.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is verbatim as I received from Martin.
cache.h | 4 ++++
environment.c | 1 +
2 files changed, 5 insertions(+), 0 deletions(-)
applies-to: 787c201a1691219d30c1a3fd849dc5ee9b35e2ce
abb173e753857d7360ae7ff1869be8d96e353ba7
diff --git a/cache.h b/cache.h
index 3104c59..7cde341 100644
--- a/cache.h
+++ b/cache.h
@@ -183,6 +183,10 @@ extern int trust_executable_bit;
extern int only_use_symrefs;
extern int diff_rename_limit_default;
+#define GIT_REPO_VERSION 0
+extern int repository_format_version;
+extern int check_repo_format(void);
+
#define MTIME_CHANGED 0x0001
#define CTIME_CHANGED 0x0002
#define OWNER_CHANGED 0x0004
diff --git a/environment.c b/environment.c
index b5026f1..3f19473 100644
--- a/environment.c
+++ b/environment.c
@@ -13,6 +13,7 @@ char git_default_email[MAX_GITNAME];
char git_default_name[MAX_GITNAME];
int trust_executable_bit = 1;
int only_use_symrefs = 0;
+int repository_format_version = 0;
static char *git_dir, *git_object_dir, *git_index_file, *git_refs_dir,
*git_graft_file;
---
0.99.9.GIT
^ permalink raw reply related
* [RFC/PATCH 1/3] git-find-git: a new helper.
From: Junio C Hamano @ 2005-11-24 3:36 UTC (permalink / raw)
To: git; +Cc: Martin Atukunda
This is part of rev-format check work, which is currently my top
priority that is holding up any new 1.0rc updates to maint
branch. It adds a new helper, git-find-git command, to the
suite, and rewrites git-sh-setup to use it.
It adds setup_git_directory_gently(), which is a variant of
existing setup_git_directory() but does not die() if we are not
in a git managed repository. git-find-git uses it to find the
top-level, and if it was run from a subdirectory, outputs shell
script fragments that can be evaled to define the two variables:
GIT_DIR_PREFIX is a string to be prepended to cwd relative
paths to make them repository relative.
GIT_DIR_UPLEVEL is a string (e.g. "../") for the command to
use to cd to the top-level of repository.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 2 +-
cache.h | 1 +
find-git.c | 41 +++++++++++++++++++++++++++++++++++++++++
git-sh-setup.sh | 39 ++++++++++++++++++++++++++++-----------
setup.c | 14 ++++++++++++--
5 files changed, 83 insertions(+), 14 deletions(-)
create mode 100644 find-git.c
applies-to: 10227b43e837a38d95d472a0b7c400749fbd46e9
15d4e27b74f4ff0c9faa5bbbfe8e915398f3be97
diff --git a/Makefile b/Makefile
index a97a5d9..dda363a 100644
--- a/Makefile
+++ b/Makefile
@@ -110,7 +110,7 @@ SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)
# The ones that do not have to link with lcrypto nor lz.
SIMPLE_PROGRAMS = \
git-get-tar-commit-id$X git-mailinfo$X git-mailsplit$X \
- git-stripspace$X git-daemon$X
+ git-stripspace$X git-daemon$X git-find-git$X
# ... and all the rest
PROGRAMS = \
diff --git a/cache.h b/cache.h
index 6ac94c5..3104c59 100644
--- a/cache.h
+++ b/cache.h
@@ -148,6 +148,7 @@ extern char *get_graft_file(void);
extern const char **get_pathspec(const char *prefix, const char **pathspec);
extern const char *setup_git_directory(void);
+extern const char *setup_git_directory_gently(int *);
extern const char *prefix_path(const char *prefix, int len, const char *path);
#define alloc_nr(x) (((x)+16)*3/2)
diff --git a/find-git.c b/find-git.c
new file mode 100644
index 0000000..e063425
--- /dev/null
+++ b/find-git.c
@@ -0,0 +1,41 @@
+#include "cache.h"
+#include "quote.h"
+
+int main(int ac, char **av)
+{
+ int not_a_git = 0;
+ const char *prefix = setup_git_directory_gently(¬_a_git);
+
+ if (!prefix && not_a_git)
+ exit(1);
+
+ /* This can die with malformed configuration file --
+ * exit code from die() is 128.
+ */
+ git_config(git_default_config);
+
+ /* Later we check repository version and exit with non-zero
+ * status after issuing an error message here.
+ */
+
+ if (!prefix)
+ /* we are at the project toplevel or GIT_DIR is set.
+ * either case we do not have to muck with the
+ * environment further.
+ */
+ exit(0);
+
+ /* this leaks but we do not care ;-) */
+ printf("GIT_DIR_PREFIX=%s\n", sq_quote(prefix));
+ printf("GIT_DIR_UPLEVEL='");
+ while (prefix) {
+ prefix = strchr(prefix, '/');
+ if (prefix) {
+ prefix++;
+ printf("../");
+ }
+ }
+ printf("'\n");
+ printf("export GIT_DIR_PREFIX GIT_DIR_UPLEVEL\n");
+ exit(0);
+}
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index dbb9884..8e30bf6 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -3,13 +3,11 @@
# Set up GIT_DIR and GIT_OBJECT_DIRECTORY
# and return true if everything looks ok
#
-: ${GIT_DIR=.git}
-: ${GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"}
# Having this variable in your environment would break scripts because
-# you would cause "cd" to be be taken to unexpected places. If you
-# like CDPATH, define it for your interactive shell sessions without
-# exporting it.
+# you would cause "cd" to be taken to unexpected places. If you line
+# CDPATH, define it for your interactive shell sessions without exporting
+# it.
unset CDPATH
die() {
@@ -17,9 +15,28 @@ die() {
exit 1
}
-case "$(GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD 2>/dev/null)" in
-refs/*) : ;;
-*) false ;;
-esac &&
-[ -d "$GIT_DIR/refs" ] &&
-[ -d "$GIT_OBJECT_DIRECTORY/" ]
+eval "`git-find-git`"
+case "$?" in
+0)
+ : ${GIT_DIR=.git}
+ : ${GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"}
+
+ case "$(GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD 2>/dev/null)" in
+ refs/*) : ;;
+ *) false ;;
+ esac &&
+ [ -d "$GIT_DIR/refs" ] &&
+ [ -d "$GIT_OBJECT_DIRECTORY/" ]
+ ;;
+*)
+ # (1) we did not find a git directory. This is sometimes OK.
+ # ls-remote (and parse-remote called from it) uses sh-set to
+ # pick up remotes shortcut if available, but outside git the
+ # user would want to use the command with explicitly spelled
+ # out URL.
+
+ # (128) git-find-git died -- malformed configuration and that
+ # is really fatal. We have already given the error message.
+
+ ;;
+esac
diff --git a/setup.c b/setup.c
index c487d7e..f64ca23 100644
--- a/setup.c
+++ b/setup.c
@@ -92,7 +92,7 @@ static int is_toplevel_directory(void)
return 1;
}
-const char *setup_git_directory(void)
+const char *setup_git_directory_gently(int *just_fail_on_ungit)
{
static char cwd[PATH_MAX+1];
int len, offset;
@@ -113,8 +113,13 @@ const char *setup_git_directory(void)
break;
chdir("..");
do {
- if (!offset)
+ if (!offset) {
+ if (just_fail_on_ungit) {
+ *just_fail_on_ungit = 1;
+ return NULL;
+ }
die("Not a git repository");
+ }
} while (cwd[--offset] != '/');
}
@@ -127,3 +132,8 @@ const char *setup_git_directory(void)
cwd[len] = 0;
return cwd + offset;
}
+
+const char *setup_git_directory(void)
+{
+ return setup_git_directory_gently(NULL);
+}
---
0.99.9.GIT
^ permalink raw reply related
* Re: gitweb on kernel.org and UTF-8
From: Junio C Hamano @ 2005-11-24 3:24 UTC (permalink / raw)
To: Kay Sievers, Paul Mackerras; +Cc: git
In-Reply-To: <20051123033526.GA24098@vrfy.org>
Kay Sievers <kay.sievers@vrfy.org> writes:
> Should be fine now. The escapeHTML() garbled the utf8 "ö", and the
> decode() failed that.
Looking better. Thanks.
This begs for addressing another issue, although I am hesitant
to open this can of worms at this moment.
It might be a good idea to have configuration items gitk and
gitweb can use to get a hint to decide what the commit log
message and the blob data encodings might be. gitweb already
adds its own information to the git repository format
(.git/description), so this _could_ be stored outside just like
that (e.g. .git/commit_log_encoding), but using .git/config is
probably better.
How about doing something like this?
[i18n]
commitEncoding = utf8
blobEncoding = utf8
to mean:
If you _have_ to make an assumption on an encoding
commit and blob objects are in, utf8 is your best bet
(but mistakes can happen, and some blobs can be binary).
Then gitweb and gitk can look at commitEncoding and blobEncoding
as a hint to base its display defaults on. Sending everything
out in utf8 would be sane and safe choice these days for gitweb,
so if commitEncoding is latin-1 it may need to iconv latin-1 to
utf8 while reading commits. For blobs, it might be better off
asking file(1) or File::MMagic (since you are using Perl in
gitweb --- sorry I do not know tcl equivalent of that) what they
are; eventually you would want to be able to show repositories
full of jpeg pictures anyway ;-).
On the commit-producing side, I could have:
[i18n]
editorEncoding = latin-1
and if editorEncoding is different from commitEncoding,
"git-commit -c $commit" would first iconv from utf8 to latin-1
before populating the user's editor, and iconv back from latin-1
to utf8 before feeding what the user edited to commit-tree.
Pathname encoding is the reason why I was hesitant about bring
this up. Although it is too late for 1.0 now, we _could_ have
declared that the paths recorded in git tree objects and index
files are internally utf8, and working tree paths can be in
different encoding. As a local repository configuration not
project wide configuration, we could have something like:
[i18n]
pathnameEncoding = latin-1
to mean that the filesystem paths returned by readdir(3) and
accepted by open(2) and friends are in latin-1. Comparison and
movement between working tree files, the index file, and tree
objects have to involve iconv and do the right thing. So if you
fetch from such a repository into a filesystem that stores
pathnames in utf8, the right thing should happen.
I personally feel any sane project should restrict its pathname
to ASCII only, so this issue might be moot (or is the right word
"mute"?), but something like this _might_ be useful in later
versions of git.
But not in 1.0.
^ permalink raw reply
* Re: [PATCH] gitk: UTF-8 support
From: Paul Mackerras @ 2005-11-24 1:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git
In-Reply-To: <7v64qi50sw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> Pavel Roskin <proski@gnu.org> writes:
>
> > Add gitencoding variable and set it to "utf-8". Use it for converting
> > git-rev-list output.
>
> Sounds good, but is it necessary? Unless I am grossly mistaken,
> I am opposed to this patch.
I already put this into my gitk.git repository, so you might want to
hold off pulling that into git.git until we work this out.
Being clueless about i18n and locales, I tend to just take whatever
people tell me is needed in that area. :)
Regards,
Paul.
^ permalink raw reply
* Re: Why not clone to a remote directory over SSH
From: Nick Hengeveld @ 2005-11-24 1:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Ericsson, git
In-Reply-To: <Pine.LNX.4.63.0511240043300.11106@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, Nov 24, 2005 at 12:45:18AM +0100, Johannes Schindelin wrote:
> BTW, is it possible to convince git-http-push to store packs on the
> server?
Certainly, I'm not sure what conditions make sense for using packs
though.
When pushing changes to the server, there's an advantage to using loose
objects in that there is no way to resume a failed transfer. So if the
network barfs 99% of the way through, you'll be much less annoyed if
you need to retransmit the one object rather than a whole pack.
The same problem exists if you decide to pack loose objects on the
server since the pack would have to be generated locally and then sent
to the server. At least in this case, other remote clients would still
be able to fetch loose objects while packs were in transit.
> For that matter, is it possible to generate the file(s) needed for a dumb
> server on the client side?
Which files are those? I've been working on a way to update info/refs
and eventually objects/info/packs.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: Why not clone to a remote directory over SSH
From: Linus Torvalds @ 2005-11-24 0:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Carl Baldwin, git
In-Reply-To: <Pine.LNX.4.63.0511240038001.11106@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, 24 Nov 2005, Johannes Schindelin wrote:
>
> On Wed, 23 Nov 2005, Junio C Hamano wrote:
>
> > $ ssh machine 'git clone '`hostname`:`pwd`' /path/to/new/repository'
>
> Obviously, this only works if the other side can connect to this side via
> ssh. Hmm. Firewalls? Disabled sshd? `hostname` not reliably returning a
> valid address for the remote side?
Well, you could also just script it and just do
ssh machine 'mkdir -p /path/to/new/repository ;
cd /path/to/new/repo;
git-init-db'
git push --all machine:/path/to/new/repository
ssh machine 'cd /path/to/new/repo ; git checkout'
(and yes, we could obviously make this a "git-create-repo" command, and
then you could do
git-send-pack --exec=git-create-repo \
machine:/path/to/new/repository
$(git-rev-parse --all)
or something like that).
Linus
^ permalink raw reply
* Re: [PATCH] gitk: UTF-8 support
From: Junio C Hamano @ 2005-11-24 0:47 UTC (permalink / raw)
To: Pavel Roskin, Paul Mackerras; +Cc: git
In-Reply-To: <1132719301.12227.5.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> Add gitencoding variable and set it to "utf-8". Use it for converting
> git-rev-list output.
Sounds good, but is it necessary? Unless I am grossly mistaken,
I am opposed to this patch.
When I run gitk with LANG and/or LC_CTYPE set to ja_JP.utf8 (I
suspect *whatever*.utf8 would work the same way) on git.git
repository, I see Lukas's name (originally in iso8859-1 but my
commit objects have it in utf8) and Yoshifuji-san's name
(iso2022 converted to utf8) just fine.
And when I run gitk with LANG and/or LC_CTYPE set to ja_JP.ujis
(that is another name for EUC-JP) on a toy repository I have
commit log messages in EUC-JP (I am not recommending that, just
pointing out a possibility), I can see them just fine. In that
test repository, setting locale to *.utf8 would not work.
So I suspect your change breaks projects that use local
encodings, without fixing or adding anything new.
^ permalink raw reply
* Re: Why not clone to a remote directory over SSH
From: Nick Hengeveld @ 2005-11-24 0:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Carl Baldwin, git
In-Reply-To: <Pine.LNX.4.63.0511240038001.11106@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, Nov 24, 2005 at 12:41:56AM +0100, Johannes Schindelin wrote:
> Obviously, this only works if the other side can connect to this side via
> ssh. Hmm. Firewalls? Disabled sshd? `hostname` not reliably returning a
> valid address for the remote side?
If sshd is running locally, you can forward a port back to yourself and
have the remote clone localhost:`pwd`. Assuming there's a way to clone
using a nonstandard port.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: Why not clone to a remote directory over SSH
From: Johannes Schindelin @ 2005-11-23 23:45 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Andreas Ericsson, git
In-Reply-To: <20051123232829.GO3968@reactrix.com>
Hi,
On Wed, 23 Nov 2005, Nick Hengeveld wrote:
> If the server is DAV-enabled, a local git-init-db could use HTTP to
> create an empty remote repository, and git-http-push can already send
> local changes including merges etc. to such a remote repository.
>
> Want to host your project using GIT? Just use your .Mac iDisk.
That would be cool! And git-clone could be patched to do just that.
BTW, is it possible to convince git-http-push to store packs on the
server?
For that matter, is it possible to generate the file(s) needed for a dumb
server on the client side?
Ciao,
Dscho
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: Johannes Schindelin @ 2005-11-23 23:42 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <4384FB61.40506@op5.se>
Hi,
On Thu, 24 Nov 2005, Andreas Ericsson wrote:
> git-repo-config is way friendlier for us poor lazy folks. That last 'y' in
> "repository" really breaks the flow.
How about "git-local-config"?
Ciao,
Dscho
^ permalink raw reply
* Re: Why not clone to a remote directory over SSH
From: Johannes Schindelin @ 2005-11-23 23:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Baldwin, git
In-Reply-To: <7vd5kr3pz1.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 23 Nov 2005, Junio C Hamano wrote:
> $ ssh machine 'git clone '`hostname`:`pwd`' /path/to/new/repository'
Obviously, this only works if the other side can connect to this side via
ssh. Hmm. Firewalls? Disabled sshd? `hostname` not reliably returning a
valid address for the remote side?
Hth,
Dscho
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: Andreas Ericsson @ 2005-11-23 23:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7viruj3q7z.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> I somehow get a very funny feeling to see "git-XXXX --get"
> command that reports different things in different repositories
> (for obvious reasons) called git-config, and not
> git-repository-config. But it probably is just me.
>
git-repo-config is way friendlier for us poor lazy folks. That last 'y'
in "repository" really breaks the flow.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Why not clone to a remote directory over SSH
From: Nick Hengeveld @ 2005-11-23 23:28 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4384F7F6.10404@op5.se>
On Thu, Nov 24, 2005 at 12:15:02AM +0100, Andreas Ericsson wrote:
> You'll still need to install at least git-init-db and git-receive-pack
> (and git-merge, and...), even if they're run through commands from the
> web. That's pretty special intelligence.
If the server is DAV-enabled, a local git-init-db could use HTTP to
create an empty remote repository, and git-http-push can already send
local changes including merges etc. to such a remote repository.
Want to host your project using GIT? Just use your .Mac iDisk.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: Why not clone to a remote directory over SSH
From: Junio C Hamano @ 2005-11-23 23:26 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20051123211601.GA2260@hpsvcnb.fc.hp.com>
Carl Baldwin <cnb@fc.hp.com> writes:
> It might be cool to enable cloning to a remote over ssh if the remote
> doesn't yet exist.
>
> % git clone . machine:/path/to/new/repository
I wonder if that is:
$ ssh machine 'git clone '`hostname`:`pwd`' /path/to/new/repository'
Obviously you need a working git setup on the other end and
probably need to be much more careful shell-quoting if your
hostname and pwd has metacharacters, but...
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: Junio C Hamano @ 2005-11-23 23:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511231553390.8191@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> So... "git-config-set" is used for both getting and setting? Why not just
>> "git-config --set" and "git-config --get" to make things a bit less confusing?
>
> I tried to do this more like a proof of a concept (Yeah, famous last
> words...) and tried to be not so intrusive. There is already a config.c,
> and to keep with the naming, this would have to move to config-lib.c to
> make space for config.c which really is the source for git-config$(X).
>
> Should we rename config.c to config-lib.c, and config-set.c to config.c?
> Personally, I think it too intrusive, but what the heck.
I do not think that change is intrusive. We've renamed source
files number of times ;-).
I somehow get a very funny feeling to see "git-XXXX --get"
command that reports different things in different repositories
(for obvious reasons) called git-config, and not
git-repository-config. But it probably is just me.
Anyway, the whole "remote specification in config file" is not a
very high priority for me right now.
^ permalink raw reply
* Re: Why not clone to a remote directory over SSH
From: Andreas Ericsson @ 2005-11-23 23:15 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20051123230838.GN3968@reactrix.com>
Nick Hengeveld wrote:
> On Wed, Nov 23, 2005 at 02:16:01PM -0700, Carl Baldwin wrote:
>
>
>>It might be cool to enable cloning to a remote over ssh if the remote
>>doesn't yet exist.
>
>
> I would like to see the same for http. There is limited support for
> managing a repository using http but without the ability to run tools
> like init-db/clone/update-server-info you still need shell access
> or some other workaround. I think it would be useful to allow someone
> to create, manage, and share a repository without any special
> intelligence on the server side.
>
You'll still need to install at least git-init-db and git-receive-pack
(and git-merge, and...), even if they're run through commands from the
web. That's pretty special intelligence.
You'd also have to add some logic to enter_repo() to make it find
repositories without a HEAD correctly.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Why not clone to a remote directory over SSH
From: Nick Hengeveld @ 2005-11-23 23:08 UTC (permalink / raw)
To: git
In-Reply-To: <20051123211601.GA2260@hpsvcnb.fc.hp.com>
On Wed, Nov 23, 2005 at 02:16:01PM -0700, Carl Baldwin wrote:
> It might be cool to enable cloning to a remote over ssh if the remote
> doesn't yet exist.
I would like to see the same for http. There is limited support for
managing a repository using http but without the ability to run tools
like init-db/clone/update-server-info you still need shell access
or some other workaround. I think it would be useful to allow someone
to create, manage, and share a repository without any special
intelligence on the server side.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* [PATCH] gitk: add Update menu item.
From: Sven Verdoolaege @ 2005-11-23 22:20 UTC (permalink / raw)
To: Paul Mackerras, Junio C Hamano; +Cc: git
Update will redraw the commits if any commits have been added to any
of the selected heads. The new commits appear on the top.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
Updated patch against recent gitk in case someone is interested.
Previous version has been working for without any glitches.
skimo
gitk | 176 +++++++++++++++++++++++++++++++++++++++++++++++++++++-------------
1 files changed, 142 insertions(+), 34 deletions(-)
applies-to: c183291c9f13912f9111ee0ab2e24ac47f3147ed
6a2a3df712ce55ecbae91367b285ce295f38a558
diff --git a/gitk b/gitk
index 3dd97e2..352a319 100755
--- a/gitk
+++ b/gitk
@@ -16,8 +16,24 @@ proc gitdir {} {
}
}
+proc parse_args {rargs} {
+ global parsed_args
+
+ if [catch {
+ set parse_args [concat --default HEAD $rargs]
+ set parsed_args [split [eval exec git-rev-parse $parse_args] "\n"]
+ }] {
+ # if git-rev-parse failed for some reason...
+ if {$rargs == {}} {
+ set rargs HEAD
+ }
+ set parsed_args $rargs
+ }
+ return $parsed_args
+}
+
proc getcommits {rargs} {
- global commits commfd phase canv mainfont env
+ global oldcommits commits commfd phase canv mainfont env
global startmsecs nextupdate ncmupdate
global ctext maincursor textcursor leftover
@@ -27,21 +43,13 @@ proc getcommits {rargs} {
error_popup "Cannot find the git directory \"$gitdir\"."
exit 1
}
+ set oldcommits {}
set commits {}
set phase getcommits
set startmsecs [clock clicks -milliseconds]
set nextupdate [expr $startmsecs + 100]
set ncmupdate 1
- if [catch {
- set parse_args [concat --default HEAD $rargs]
- set parsed_args [split [eval exec git-rev-parse $parse_args] "\n"]
- }] {
- # if git-rev-parse failed for some reason...
- if {$rargs == {}} {
- set rargs HEAD
- }
- set parsed_args $rargs
- }
+ set parsed_args [parse_args $rargs]
if [catch {
set commfd [open "|git-rev-list --header --topo-order --parents $parsed_args" r]
} err] {
@@ -59,9 +67,10 @@ proc getcommits {rargs} {
}
proc getcommitlines {commfd} {
- global commits parents cdate children
+ global oldcommits commits parents cdate children nchildren
global commitlisted phase nextupdate
global stopped redisplaying leftover
+ global canv
set stuff [read $commfd]
if {$stuff == {}} {
@@ -119,10 +128,18 @@ to allow selection of commits to be disp
set id [lindex $ids 0]
set olds [lrange $ids 1 end]
set cmit [string range $cmit [expr {$j + 1}] end]
+ if {$phase == "updatecommits"} {
+ $canv delete all
+ set oldcommits $commits
+ set commits {}
+ unset children
+ unset nchildren
+ set phase getcommits
+ }
lappend commits $id
set commitlisted($id) 1
parsecommit $id $cmit 1 [lrange $ids 1 end]
- drawcommit $id
+ drawcommit $id 1
if {[clock clicks -milliseconds] >= $nextupdate} {
doupdate 1
}
@@ -132,7 +149,7 @@ to allow selection of commits to be disp
set stopped 0
set phase "getcommits"
foreach id $commits {
- drawcommit $id
+ drawcommit $id 1
if {$stopped} break
if {[clock clicks -milliseconds] >= $nextupdate} {
doupdate 1
@@ -168,16 +185,9 @@ proc readcommit {id} {
parsecommit $id $contents 0 {}
}
-proc parsecommit {id contents listed olds} {
- global commitinfo children nchildren parents nparents cdate ncleft
+proc updatechildren {id olds} {
+ global children nchildren parents nparents ncleft
- set inhdr 1
- set comment {}
- set headline {}
- set auname {}
- set audate {}
- set comname {}
- set comdate {}
if {![info exists nchildren($id)]} {
set children($id) {}
set nchildren($id) 0
@@ -196,6 +206,19 @@ proc parsecommit {id contents listed old
incr ncleft($p)
}
}
+}
+
+proc parsecommit {id contents listed olds} {
+ global commitinfo cdate
+
+ set inhdr 1
+ set comment {}
+ set headline {}
+ set auname {}
+ set audate {}
+ set comname {}
+ set comdate {}
+ updatechildren $id $olds
set hdrend [string first "\n\n" $contents]
if {$hdrend < 0} {
# should never happen...
@@ -243,6 +266,9 @@ proc readrefs {} {
global tagids idtags headids idheads tagcontents
global otherrefids idotherrefs
+ foreach v {tagids idtags headids idheads otherrefids idotherrefs} {
+ catch {unset $v}
+ }
set refd [open [list | git-ls-remote [gitdir]] r]
while {0 <= [set n [gets $refd line]]} {
if {![regexp {^([0-9a-f]{40}) refs/([^^]*)$} $line \
@@ -292,7 +318,7 @@ proc error_popup msg {
tkwait window $w
}
-proc makewindow {} {
+proc makewindow {rargs} {
global canv canv2 canv3 linespc charspc ctext cflist textfont
global findtype findtypemenu findloc findstring fstring geometry
global entries sha1entry sha1string sha1but
@@ -302,6 +328,7 @@ proc makewindow {} {
menu .bar
.bar add cascade -label "File" -menu .bar.file
menu .bar.file
+ .bar.file add command -label "Update" -command [list updatecommits $rargs]
.bar.file add command -label "Reread references" -command rereadrefs
.bar.file add command -label "Quit" -command doquit
menu .bar.help
@@ -1416,8 +1443,9 @@ proc decidenext {{noread 0}} {
return $level
}
-proc drawcommit {id} {
+proc drawcommit {id reading} {
global phase todo nchildren datemode nextupdate revlistorder
+ global numcommits ncmupdate displayorder todo onscreen
global numcommits ncmupdate displayorder todo onscreen parents
if {$phase != "incrdraw"} {
@@ -1455,20 +1483,29 @@ proc drawcommit {id} {
}
}
}
- drawmore 1
+ drawmore $reading
}
proc finishcommits {} {
- global phase
+ global phase oldcommits commits
global canv mainfont ctext maincursor textcursor
+ global parents
- if {$phase != "incrdraw"} {
+ if {$phase == "incrdraw" || $phase == "removecommits"} {
+ foreach id $oldcommits {
+ lappend commits $id
+ updatechildren $id $parents($id)
+ drawcommit $id 0
+ }
+ set oldcommits {}
+ drawrest
+ } elseif {$phase == "updatecommits"} {
+ set phase {}
+ } else {
$canv delete all
$canv create text 3 3 -anchor nw -text "No commits selected" \
-font $mainfont -tags textitems
set phase {}
- } else {
- drawrest
}
. config -cursor $maincursor
settextcursor $textcursor
@@ -3596,9 +3633,6 @@ proc rereadrefs {} {
set ref($id) [listrefs $id]
}
}
- foreach v {tagids idtags headids idheads otherrefids idotherrefs} {
- catch {unset $v}
- }
readrefs
set refids [lsort -unique [concat $refids [array names idtags] \
[array names idheads] [array names idotherrefs]]]
@@ -3610,6 +3644,80 @@ proc rereadrefs {} {
}
}
+proc updatecommits {rargs} {
+ global commitlisted commfd phase
+ global startmsecs nextupdate ncmupdate
+ global idtags idheads idotherrefs
+ global leftover
+ global parsed_args
+ global canv
+ global oldcommits commits
+ global parents nchildren children ncleft
+
+ set old_args $parsed_args
+ parse_args $rargs
+
+ foreach id $old_args {
+ if {![regexp {^[0-9a-f]{40}$} $id]} continue
+ if {[info exists oldref($id)]} continue
+ set oldref($id) $id
+ lappend ignoreold "^$id"
+ }
+ foreach id $parsed_args {
+ if {![regexp {^[0-9a-f]{40}$} $id]} continue
+ if {[info exists ref($id)]} continue
+ set ref($id) $id
+ lappend ignorenew "^$id"
+ }
+
+ foreach a $old_args {
+ if {![info exists ref($a)]} {
+ lappend ignorenew $a
+ }
+ }
+
+ set phase updatecommits
+ set removed_commits [split [eval exec git-rev-list $ignorenew] "\n" ]
+ if {[llength $removed_commits] > 0} {
+ $canv delete all
+ set oldcommits {}
+ foreach c $commits {
+ if {[lsearch $c $removed_commits] < 0} {
+ lappend oldcommits $c
+ } else {
+ unset commitlisted($c)
+ }
+ }
+ set commits {}
+ unset children
+ unset nchildren
+ set phase removecommits
+ }
+
+ set args {}
+ foreach a $parsed_args {
+ if {![info exists oldref($a)]} {
+ lappend args $a
+ }
+ }
+
+ readrefs
+ if [catch {
+ set commfd [open "|git-rev-list --header --topo-order --parents $args $ignoreold" r]
+ } err] {
+ puts stderr "Error executing git-rev-list: $err"
+ exit 1
+ }
+ set startmsecs [clock clicks -milliseconds]
+ set nextupdate [expr $startmsecs + 100]
+ set ncmupdate 1
+ set leftover {}
+ fconfigure $commfd -blocking 0 -translation lf
+ fileevent $commfd readable [list getcommitlines $commfd]
+ . config -cursor watch
+ settextcursor watch
+}
+
proc showtag {tag isnew} {
global ctext cflist tagcontents tagids linknum
@@ -3697,6 +3805,6 @@ set redisplaying 0
set stuffsaved 0
set patchnum 0
setcoords
-makewindow
+makewindow $revtreeargs
readrefs
getcommits $revtreeargs
---
0.99.9.GIT
^ permalink raw reply related
* Re: Perl version support (was Re: [PATCH] git-mv is not able to handle big directories)
From: Morten Welinder @ 2005-11-23 22:02 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Randal L. Schwartz, Ryan Anderson, Junio C Hamano, git
In-Reply-To: <4384E574.8060801@zytor.com>
> I'm very surprised you say that 5.6 is more prevalent than 5.8.
You are overestimating the update-eagerness of the world.
SunOS 5.8 seems to come with 5.005_03
SunOS 5.9 seems to come with v5.6.1.
("Seems" because I am only 99% sure no-one around here has mucked with
the perl in /usr/bin/.)
M.
^ permalink raw reply
* Re: Perl version support (was Re: [PATCH] git-mv is not able to handle big directories)
From: Randal L. Schwartz @ 2005-11-23 22:01 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Ryan Anderson, Junio C Hamano, git
In-Reply-To: <4384E574.8060801@zytor.com>
>>>>> "H" == H Peter Anvin <hpa@zytor.com> writes:
H> There are a lot of Perl modules we use, so limiting it to 5.5 is
H> probably a showstopper.
Hmm. I should look at that then. Most Perl Modules are 5.5
compatible, unless they've been written by naive people recently. :)
H> I'm very surprised you say that 5.6 is more prevalent than 5.8.
For individual early adopters, 5.8 is nearly universal. But a lot of
my corporate clients upgrade *very* slowly, and are on 5.6 for now.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: Perl version support (was Re: [PATCH] git-mv is not able to handle big directories)
From: H. Peter Anvin @ 2005-11-23 21:56 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Ryan Anderson, Junio C Hamano, git
In-Reply-To: <86mzjvphhj.fsf_-_@blue.stonehenge.com>
Randal L. Schwartz wrote:
>
> I'd say that 50% of the Perl-using population is at 5.6, with 25% each
> at 5.5 and 5.8. Those on 5.5 are generally unable to upgrade Perl
> for corporate reasons.
>
> Targetting Perl 5.6 would assist broad acceptance of git for the
> typical commercial end user. Targetting 5.5 where possible would
> ensure practical success for everyone.
>
> However, I have not seen the "target market" of git discussed yet
> (I came late to the party), so if support for 5.6 (or 5.5) is not chosen,
> it merely limits the market.
>
There are a lot of Perl modules we use, so limiting it to 5.5 is
probably a showstopper.
I'm very surprised you say that 5.6 is more prevalent than 5.8.
-hpa
^ permalink raw reply
* Why not clone to a remote directory over SSH
From: Carl Baldwin @ 2005-11-23 21:16 UTC (permalink / raw)
To: git
It might be cool to enable cloning to a remote over ssh if the remote
doesn't yet exist.
% git clone . machine:/path/to/new/repository
If you try this now it will clone the current working repository to a
new directory called 'machine:'.
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: [PATCH] Support username and password inside URL
From: Kalle Valo @ 2005-11-23 20:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtj3xe72.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Kalle Valo <Kalle.Valo@iki.fi> writes:
>
>> Currently usage of curl was so that netrc was mandatory and passwords in URL
>> weren't allowed. Change netrc to optional to make HTTP basic authentication
>> with username and password in URL also work.
>
> HTTP "basic"? Let's at least say "digest" for starters ;-).
Sorry, I didn't understand this. But anyway, I have always used the
basic authentication because it has been sufficient for my needs.
> I am modestly against letting users use auth-embedding URLs, and
> fairly strongly against encouraging users to do so.
I didn't even think about security implications when I sent the patch,
sorry about that. Now that I think of it, I even remember that some
browser removed this feature altogether. Yeah, it was IE:
http://support.microsoft.com/kb/834489
And Firefox seems to show a dialog confirmation dialog if I open an
URL with username and password. So I have to agree with you, it isn't
a good idea to embed the credentials to the URL.
> If you are using the password protected URL yourself, I'd
> imagine having them in your netrc would not be such a big deal,
Yes, I can manage with netrc for now. The only problem is that you
can't specify multiple usernames and passwords per host. (Or at least
that's how I understood the netrc man page.) If there's a way to do
that in git, I would really like to know about that.
> so I suspect your expected usage is not for yourself, but more
> like giving a temporary, even one-shot, access to others like
> the above example, and making it more convenient for them (even
> in that case, if it is not one-shot but for repeated use, I'd
> imagine it would not be such a big deal to ask them to do
> appropriate netrc).
Actually I'm going to be only user of the private git repository and
it's going to be permanent. I have multiple computers in different
locations (servers, workstations, laptops) and I would like to
distribute my private files (configuration files, scripts etc.) to all
of them using git. The files are not really that secret, but I just
don't want to share them with the whole world. That's why I'm using
just HTTP authentication and nothing secure.
> If that is what is going on here, then IMNSHO it would be better to
> make it clear that you are doing security-by-obscurity by not using
> username password pair, which makes you pretend that you are doing
> _some_ security.
I agree with you. I don't consider HTTP authentication secure at all.
It can just block search engines and casual readers from accessing the
page, nothing more. The problem with randomized URL (like you
suggested) is that if some person or a search engine finds the URL
somehow, then there's nothing stopping the information leak. HTTP
authentication at least stops search engines accessing the page.
--
Kalle Valo
^ 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