* Re: Corruption: empty refs/heads in otherwise filled repo: cannot clone?
From: Jakub Narebski @ 2008-06-30 12:03 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: git
In-Reply-To: <200806301344.09938.J.Wielemaker@uva.nl>
Jan Wielemaker wrote:
> Summarising, I think the conclusion is that git pack-refs has somehow
> been run on this repository, and being a bare one this is not a
> particulary good idea right now. I have the impression I should `unpack'
> them by putting the appriate files in heads (done) and tags (now still)
> and (re)move packed-refs.
If you use new enough git both on server and on clients it should
not have problems with packed-refs. I would rather check permissions
of $GIT_DIR and $GIT_DIR/packed-refs.
If "git show-ref" and "git for-each-ref" works, then
"git ls-remote <repo>" should work, and git-fetch/git-clone
shoulw work too...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Corruption: empty refs/heads in otherwise filled repo: cannot clone?
From: Jan Wielemaker @ 2008-06-30 12:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200806301403.57900.jnareb@gmail.com>
On Monday 30 June 2008 14:03, Jakub Narebski wrote:
> Jan Wielemaker wrote:
> > Summarising, I think the conclusion is that git pack-refs has somehow
> > been run on this repository, and being a bare one this is not a
> > particulary good idea right now. I have the impression I should `unpack'
> > them by putting the appriate files in heads (done) and tags (now still)
> > and (re)move packed-refs.
>
> If you use new enough git both on server and on clients it should
> not have problems with packed-refs. I would rather check permissions
> of $GIT_DIR and $GIT_DIR/packed-refs.
There is no permission problem, as a I proved by doing a recursive copy
of the whole repo (cp -a, no errors) and the problem prevails on the
copy. A serious scan for permission errors was my first step. Almost
looks like something in the environment, but I can't find anything weird
there either.
> If "git show-ref" and "git for-each-ref" works, then
> "git ls-remote <repo>" should work, and git-fetch/git-clone
> shoulw work too...
Thanks for the pointers. I'll leave it for now (busy ...). I now
understand how it is supposed to work. If I can find time at some point
I'll run strace in different setups to see whether I can spot the
difference.
Anyway, thanks to your help I am fairly confident my repo is in good
shape again.
Cheers --- Jan
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Kristian Høgsberg @ 2008-06-30 14:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3amv1e8n.fsf@gitster.siamese.dyndns.org>
On Mon, 2008-06-30 at 02:08 -0700, Junio C Hamano wrote:
> Here are the topics that have been cooking. Commits prefixed
> with '-' are only in 'pu' while commits prefixed with '+' are
> in 'next'.
>
> The topics list the commits in reverse chronological order. The topics
> meant to be applied to the maintenance series have "maint-" in their
> names.
>
> It already is beginning to become clear what 1.6.0 will look like. What's
> already in 'next' all are well intentioned (I do not guarantee they are
> already bug-free --- that is what cooking them in 'next' is for) and are
> good set of feature enhancements. Bigger changes will be:
>
> * MinGW will be in.
>
> * With the default Makefile settings, most of the programs will be
> installed outside your $PATH, except for "git", "gitk", "git-gui" and
> some server side programs that need to be accessible for technical
> reasons. Invoking a git subcommand as "git-xyzzy" from the command
> line has been deprecated since early 2006 (and officially announced in
> 1.5.4 release notes); use of them from your scripts after adding
> output from "git --exec-path" to the $PATH will still be supported in
> 1.6.0, but users are again strongly encouraged to adjust their
> scripts to use "git xyzzy" form, as we will stop installing
> "git-xyzzy" hardlinks for built-in commands in later releases.
>
> * git-merge will be rewritten in C.
>
> * default pack and idx versions will be updated as scheduled for some
> time ago.
A small detail I've suggested scheduling for 1.6 before is removing (or
rather, stop creating) the empty .git/branches directory. How does that
sound?
cheers,
Kristian
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Brandon Casey @ 2008-06-30 14:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vod5kd3im.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> * jc/reflog-expire (Sat Jun 28 22:24:49 2008 -0700) 2 commits
> - Make default expiration period of reflog used for stash infinite
> - Per-ref reflog expiry configuration
Thanks.
-brandon
^ permalink raw reply
* [RFC] Single system account for multiple git users
From: Dmitry Potapov @ 2008-06-30 15:11 UTC (permalink / raw)
To: Git Mailing List
Hi,
Using SSH access with restricted git-shell as login shell and using
the script from the update-hook-example.txt works fine, but it requres
that every Git user has a separate system account on the server, which
is often frowned upon by system administrators, who would prefer to have
a single system account for access to Git repo.
I have looked on gitosis, but it requires normal shell account for
the git user, which was vetoed by sysadmin. Also, I found its
configuration more complex than necessary and not flexible enough
to differentiate what branches can have non-fast-forward pushes on
it and what cannot.
In fact, the simple solution for me would be to have authorized_key
for the git user being like this:
environment="GIT_USER=user1" ssh-rsa USER1-SSH-PUBLIC-KEY
environment="GIT_USER=user2" ssh-rsa USER2-SSH-PUBLIC-KEY
...
In this case, with one line change to update-hook-example from
username=$(id -u -n)
to
username="$GIT_USER"
I would get exactly what I want.
However, the environment option in authorized_key works only if
PermitUserEnvironment is set in sshd configuration, and this option
will allow _all_ users to overwrite their environment, which may be
not desirable in some settings for security reasons.
So, instead, I have to write a simple program, which is placed as
the login shell and interprets the given command as user name, sets
GIT_USER to it, and invokes git-shell with SSH_ORIGINAL_COMMAND.
Thus authorized_key looks like that:
command="git-su user1" ssh-rsa USER1-SSH-PUBLIC-KEY
command="git-su user2" ssh-rsa USER2-SSH-PUBLIC-KEY
...
But then I realized that it is simpler and more efficient to add
some built-in command to git-shell to do that.
You can see my patch below. I hope it will be useful for people
who wants to user git on server with a single system account for
all git users.
Dmitry
-- 8< --
From: Dmitry Potapov <dpotapov@gmail.com>
Date: Wed, 25 Jun 2008 08:14:22 +0400
Subject: [PATCH] git-shell: add git-su command
git-su interprets the given command as a user name that must be set to the
GIT_USER environment variable and then executing SSH_ORIGINAL_COMMAND as
it were the command given to git-shell. This allows to have different
values for GIT_USER variable for different ssh public keys, which is
necessary to have a single system for many Git users. With this command
the typical authorized_key will for git user will be look like this:
command="git-su user1" ssh-rsa USER1-SSH-PUBLIC-KEY
command="git-su user2" ssh-rsa USER2-SSH-PUBLIC-KEY
...
The alternative of using the "environment" option in authorized_key may be
problematic as it requires that the PermitUserEnvironment option was set
in sshd_config and by default this option is not enabled, because it may
allow some users to bypass access restrictions.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
I moved command parsing logic from main() to a separate function,
(which makes the patch a bit bigger than it actually is) and then
added do_su_cmd(), which reuses this functionality.
shell.c | 51 ++++++++++++++++++++++++++++++++++-----------------
1 files changed, 34 insertions(+), 17 deletions(-)
diff --git a/shell.c b/shell.c
index 91ca7de..05bd3cc 100644
--- a/shell.c
+++ b/shell.c
@@ -41,6 +41,19 @@ static int do_cvs_cmd(const char *me, char *arg)
return execv_git_cmd(cvsserver_argv);
}
+static int exec_cmd(char *prog);
+
+static int do_su_cmd(const char *me, char *arg)
+{
+ char *cmd = getenv("SSH_ORIGINAL_COMMAND");
+ if (!cmd)
+ die("SSH_ORIGINAL_COMMAND is not set");
+ if (setenv("GIT_USER", arg, 1))
+ die ("setenv failed: %s", strerror(errno));
+ if (unsetenv("SSH_ORIGINAL_COMMAND"))
+ die ("unsetenv failed: %s", strerror(errno));
+ return exec_cmd(cmd);
+}
static struct commands {
const char *name;
@@ -49,28 +62,14 @@ static struct commands {
{ "git-receive-pack", do_generic_cmd },
{ "git-upload-pack", do_generic_cmd },
{ "cvs", do_cvs_cmd },
+ { "git-su", do_su_cmd },
{ NULL },
};
-int main(int argc, char **argv)
+static int exec_cmd(char *prog)
{
- char *prog;
struct commands *cmd;
- /*
- * Special hack to pretend to be a CVS server
- */
- if (argc == 2 && !strcmp(argv[1], "cvs server"))
- argv--;
-
- /*
- * We do not accept anything but "-c" followed by "cmd arg",
- * where "cmd" is a very limited subset of git commands.
- */
- else if (argc != 3 || strcmp(argv[1], "-c"))
- die("What do you think I am? A shell?");
-
- prog = argv[2];
if (!strncmp(prog, "git", 3) && isspace(prog[3]))
/* Accept "git foo" as if the caller said "git-foo". */
prog[3] = '-';
@@ -91,7 +90,25 @@ int main(int argc, char **argv)
default:
continue;
}
- exit(cmd->exec(cmd->name, arg));
+ return cmd->exec(cmd->name, arg);
}
die("unrecognized command '%s'", prog);
}
+
+int main(int argc, char **argv)
+{
+ /*
+ * Special hack to pretend to be a CVS server
+ */
+ if (argc == 2 && !strcmp(argv[1], "cvs server"))
+ argv--;
+
+ /*
+ * We do not accept anything but "-c" followed by "cmd arg",
+ * where "cmd" is a very limited subset of git commands.
+ */
+ else if (argc != 3 || strcmp(argv[1], "-c"))
+ die("What do you think I am? A shell?");
+
+ return exec_cmd(argv[2]);
+}
--
1.5.6.1
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Jakub Narebski @ 2008-06-30 15:58 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: Junio C Hamano, git
In-Reply-To: <1214834970.3382.4.camel@gaara.bos.redhat.com>
Kristian Høgsberg <krh@redhat.com> writes:
>
> A small detail I've suggested scheduling for 1.6 before is removing (or
> rather, stop creating) the empty .git/branches directory. How does that
> sound?
Perhaps also stop creating .git/description (remove
'templates/this--description' file), now that it is mentioned in
gitweb/README and/or gitweb/INSTALL?
(Do you want a patch?)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Single system account for multiple git users
From: Asheesh Laroia @ 2008-06-30 15:59 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Git Mailing List
In-Reply-To: <20080630151113.GO5737@dpotapov.dyndns.org>
On Mon, 30 Jun 2008, Dmitry Potapov wrote:
> Hi,
>
> Using SSH access with restricted git-shell as login shell and using the
> script from the update-hook-example.txt works fine, but it requres that
> every Git user has a separate system account on the server, which is
> often frowned upon by system administrators, who would prefer to have a
> single system account for access to Git repo.
>
> I have looked on gitosis, but it requires normal shell account for the
> git user, which was vetoed by sysadmin. Also, I found its configuration
> more complex than necessary and not flexible enough to differentiate
> what branches can have non-fast-forward pushes on it and what cannot.
I seem to recall that gitosis works with git-shell. Maybe I'm
mis-remembering, though.
-- Asheesh.
--
QOTD:
Some people have one of those days. I've had one of those lives.
^ permalink raw reply
* Re: [RFC] Single system account for multiple git users
From: Jakub Narebski @ 2008-06-30 16:04 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Git Mailing List
In-Reply-To: <20080630151113.GO5737@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov@gmail.com> writes:
> Using SSH access with restricted git-shell as login shell and using
> the script from the update-hook-example.txt works fine, but it requres
> that every Git user has a separate system account on the server, which
> is often frowned upon by system administrators, who would prefer to have
> a single system account for access to Git repo.
>
> I have looked on gitosis, but it requires normal shell account for
> the git user, which was vetoed by sysadmin. [...]
Have you took a look at ssh_acl from InterfacesFrontendsAndTools
from Git Wiki?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: EasyGit [Was: Re: my git problem]
From: Sean Kelley @ 2008-06-30 16:23 UTC (permalink / raw)
To: Elijah Newren
Cc: Carl Worth, Linus Torvalds, Andrew Morton, git, Havoc Pennington
In-Reply-To: <51419b2c0805020441l7a52f9d2q6bfc8eb4e18e4e7e@mail.gmail.com>
On Fri, May 2, 2008 at 6:41 AM, Elijah Newren <newren@gmail.com> wrote:
> On Thu, May 1, 2008 at 12:01 AM, Carl Worth <cworth@cworth.org> wrote:
>> Or maybe go Elijah's route and invent a new top-level command name in
>> which issues like this can get fixed. (I've been lukewarm on the idea
>> after watching the cogito attempt eventually be abandoned. I'd really
>> much rather see Elijah's ideas get pushed down into git itself for the
>> most part. But it's tough when backwards-compatibility prevents fixing
>> some things that are obviously confusing people.)
>
> Except my route really doesn't fix things like this since I also
> pushed for backwards compatibility. You'll note that Havoc used
> EasyGit and Git interchangably (both in his description and probably
> on his projects), since all I've really done so far in EasyGit is
> * provide built-in tutorial-oriented documentation
> * check for common user mistakes and warn about them
> * add subcommand options in a way that breaks up the near cylic
> knowledge dependence of git subcommands so that they can be learned in
> a layered/hierarchical fashion
> * add some gratuitous svn-compatibility commands to ease the
> transition for svn users
>
> I agree that it would be nice to get this stuff (other than the last
> point that likely doesn't make sense for git-core) into git
> itself...if the community wants it.
I agree with Carl in that my fear is that this will go the same route
as cogito if it doesn't get into git itself. We use mercurial rather
extensively at garmin on my teams. There are a number of items I
really miss from git. For the most part I believe Carl has enumerated
in other threads the sort of items that cause the greatest issues with
usability.
I think you addressed the first steps rather well with eg.
Sean
^ permalink raw reply
* Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
From: Daniel Barkalow @ 2008-06-30 16:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Pieter de Bie, Git Mailinglist
In-Reply-To: <alpine.DEB.1.00.0806301233560.9925@racer>
On Mon, 30 Jun 2008, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 29 Jun 2008, Daniel Barkalow wrote:
>
> > Now, clone writes to the config file before reading any configuration, so,
> > if it's going to write to ".git/config" instead of $GIT_CONFIG, it can't
> > read from $GIT_CONFIG either. So there's no way (outside of redesigning
> > config.c) to make GIT_CONFIG useful for "clone" in particular.
>
> Except you could read the config _before_ writing.
>
> Or you could enhance (not redesign, as you suggest) config.c thusly:
>
> -- snip --
> diff --git a/cache.h b/cache.h
> index 871f6c1..f3ea997 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -742,6 +742,7 @@ extern int git_config_bool(const char *, const char *);
> extern int git_config_string(const char **, const char *, const char *);
> extern int git_config_set(const char *, const char *);
> extern int git_config_set_multivar(const char *, const char *, const char *, int);
> +extern int git_config_set_multivar_in_file(const char *, const char *, const char *, int, const char *);
> extern int git_config_rename_section(const char *, const char *);
> extern const char *git_etc_gitconfig(void);
> extern int check_repository_format_version(const char *var, const char *value, void *cb);
> diff --git a/config.c b/config.c
> index 58749bf..41a35eb 100644
> --- a/config.c
> +++ b/config.c
> @@ -863,23 +863,31 @@ int git_config_set(const char* key, const char* value)
> * - the config file is removed and the lock file rename()d to it.
> *
> */
> -int git_config_set_multivar(const char* key, const char* value,
> - const char* value_regex, int multi_replace)
> +int git_config_set_multivar(const char *key, const char *value,
> + const char *value_regex, int multi_replace)
> +{
> + return git_config_set_multivar_in_file(key, value, value_regex,
> + multi_replace, NULL);
> +}
> +
> +int git_config_set_multivar_in_file(const char *key, const char *value,
> + const char *value_regex, int multi_replace, const char *config_filename)
> {
> int i, dot;
> int fd = -1, in_fd;
> int ret;
> - char* config_filename;
> + char *filename;
> struct lock_file *lock = NULL;
> const char* last_dot = strrchr(key, '.');
>
> - config_filename = getenv(CONFIG_ENVIRONMENT);
> + if (!config_filename)
> + config_filename = getenv(CONFIG_ENVIRONMENT);
> if (!config_filename) {
> config_filename = getenv(CONFIG_LOCAL_ENVIRONMENT);
> if (!config_filename)
> - config_filename = git_path("config");
> + config_filename =
> + filename = xstrdup(git_path("config"));
> }
> - config_filename = xstrdup(config_filename);
>
> /*
> * Since "key" actually contains the section name and the real
> @@ -1091,7 +1099,8 @@ int git_config_set_multivar(const char* key, const char* value,
> out_free:
> if (lock)
> rollback_lock_file(lock);
> - free(config_filename);
> + if (filename)
> + free(filename);
> return ret;
>
> write_err_out:
> -- snap --
>
> ... and then have something like
>
> config_filename = xstrdup(mkpath("%s/config", git_dir));
>
> if (safe_create_leading_directories_const(git_dir) < 0)
> die("could not create leading directories of '%s'", git_dir);
> set_git_dir(make_absolute_path(git_dir));
>
> [...]
>
> if (option_bare) {
> strcpy(branch_top, "refs/heads/");
>
> git_config_set_multivar_in_file("core.bare", "true",
> NULL, 0, config_filename);
>
> [...]
>
> Of course, you would also have to teach init_db() to use this filename.
>
> But frankly, I do not see the use of your "narrow" special case. And as I
> stated in another thread, I am pretty opposed to crossing bridges that are
> miles (or an eternity) away.
>
> So unless you present me with a sensible scenario where your "respect
> GIT_CONFIG for _reading_ in GIT_CONFIG=... git clone" makes sense, there
> is nothing to see here, please move along.
I haven't been able to find a sensible scenario for paying attention to
GIT_CONFIG at all, except for backwards compatibility in builtin-config.c;
I'd been going on the assumption that there was a sensible scenario for
having it in the first place, and that "git clone" wouldn't be any
different from "git init", "git remote", or "git fetch".
But nobody seems to have any reason for GIT_CONFIG to exist outside of the
"git config" command-line and environment parsing, so I posted a patch to
rip it out of the general code, so "git clone" doesn't have to deal with
it at all.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] Single system account for multiple git users
From: Dmitry Potapov @ 2008-06-30 16:51 UTC (permalink / raw)
To: Asheesh Laroia; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.10.0806300858380.25384@alchemy.localdomain>
On Mon, Jun 30, 2008 at 7:59 PM, Asheesh Laroia <asheesh@asheesh.org> wrote:
>
> I seem to recall that gitosis works with git-shell. Maybe I'm
> mis-remembering, though.
I don't see how it is possible for gitosis to work with git-shell.
Besides, in the article (which also is mentioned in Gitosis FAQ in the
section: Creating new repositories and adding users") clearly state:
"The next thing to do is to create a user that will own the repositories
you want to manage. This user is usually called git, but any name will
work, and you can have more than one per system if you really want to.
The user does not need a password, but does need a valid shell
(otherwise, SSH will refuse to work)."
Source: http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
So, I think you misread something.
Dmitry
^ permalink raw reply
* Re: [RFC] Single system account for multiple git users
From: Jon Loeliger @ 2008-06-30 16:56 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Asheesh Laroia, Git Mailing List
In-Reply-To: <37fcd2780806300951sd164870ib09bfc5e47dcaa57@mail.gmail.com>
Dmitry Potapov wrote:
> "The next thing to do is to create a user that will own the repositories
> you want to manage. This user is usually called git, but any name will
> work, and you can have more than one per system if you really want to.
> The user does not need a password, but does need a valid shell
> (otherwise, SSH will refuse to work)."
Does that just mean that the git-shell program
has to be listed in /etc/shells?
jdl
^ permalink raw reply
* Re: [RFC] Single system account for multiple git users
From: Dmitry Potapov @ 2008-06-30 17:05 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git Mailing List
In-Reply-To: <m3iqvqhptu.fsf@localhost.localdomain>
On Mon, Jun 30, 2008 at 8:04 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>
> Have you took a look at ssh_acl from InterfacesFrontendsAndTools
> from Git Wiki?
I have looked at it and if I am not mistaken it requires the normal
shell as login shell.
BTW, the link to GitWiki is outdated, the new link is
http://www.inf.ufpr.br/ribas/ssh_acl.html
but it practically lacks of all documentation, and at the top
of that page, you can see:
===================
WARNING
These explanation are outdated!
I already wrote a new version and I'm using
Soon I will update here
===================
My goal was to have something small and simple. I really like git-shell
plus the update hook from the documentation, but that does not allow
to have multiple Git users with a single system account.
Dmitry
^ permalink raw reply
* Re: [RFC] Single system account for multiple git users
From: Dmitry Potapov @ 2008-06-30 17:07 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Asheesh Laroia, Git Mailing List
In-Reply-To: <48691059.4060604@freescale.com>
On Mon, Jun 30, 2008 at 8:56 PM, Jon Loeliger <jdl@freescale.com> wrote:
>
> Does that just mean that the git-shell program
> has to be listed in /etc/shells?
Whether git-shell should be listed in etc/shells depends on your
distributive, but it is irrelevant in this case. git-shell will not interpret
the given command. So, it won't work.
Dmitry
^ permalink raw reply
* Re: [PATCH] Only use GIT_CONFIG in "git config", not other programs
From: Daniel Barkalow @ 2008-06-30 17:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vskuv1hj1.fsf@gitster.siamese.dyndns.org>
On Mon, 30 Jun 2008, Junio C Hamano wrote:
> Hmm, I actually think this is a good thing to do in the sense that it
> vastly simplifies the user experience ;-). Two less things to explain.
>
> Care to write up a snippet for 1.6.0 release notes, as this is quite a
> large user visible backward incompatible change, even though it would be
> an improvement?
Sure:
* GIT_CONFIG, which was only documented as affecting "git config", but
actually affected all git commands, now only affects "git config".
GIT_LOCAL_CONFIG, also only documented as affecting "git config" and not
different from GIT_CONFIG in a useful way, is removed.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 13/13] Build in merge
From: Alex Riesen @ 2008-06-30 17:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git, Johannes Schindelin, Olivier Marin
In-Reply-To: <7vd4lz4gtw.fsf@gitster.siamese.dyndns.org>
2008/6/30 Junio C Hamano <gitster@pobox.com>:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>> + /* See if remote matches <name>~<number>, or <name>^ */
>> + ptr = strrchr(remote, '^');
>> + if (ptr && ptr[1] == '\0') {
>> + len = strlen(remote);
>> + while ((ptr = (char *)memrchr(remote, '^', len)))
>> + if (ptr && ptr[1] == '\0')
>> + len = ptr - remote - 1;
>> + else
>> + break;
>
> That's a funny way to say:
>
> for (len = 0, ptr = remote + strlen(remote);
> remote < ptr && ptr[-1] == '^';
> ptr--)
> len++;
>
Besides, Cygwin has no memrchr
^ permalink raw reply
* Git clone fatal when using git-shell account
From: Denis Bueno @ 2008-06-30 18:05 UTC (permalink / raw)
To: Git Mailing List
I have a machine containing a "central" git repo, which I access via
SSH using an account that uses /bin/bash. From my laptop, doing a
clone works. But when I change the shell on the central machine to
git-shell (which is listed in /etc/shells), the clone fails.
Clone using /bin/bash:
tmp[82] > git clone ssh://cameron@churn/Users/Shared/src/jmatch.git
Initialize jmatch/.git
Initialized empty Git repository in /private/tmp/jmatch/.git/
Password:
remote: Counting objects: 1690, done.
remote: Compressing objremote: ects: 100% (1239/1239), done.
remote: Total 1690 (delta 424), reused 1683 (delta 422)
Receiving objects: 100% (1690/1690), 3.62 MiB | 2332 KiB/s, done.
Resolving deltas: 100% (424/424), done.
Clone using /opt/local/bin/git-shell:
tmp[81] > git clone ssh://cameron@churn/Users/Shared/src/jmatch.git
Initialize jmatch/.git
Initialized empty Git repository in /private/tmp/jmatch/.git/
Password:
fatal: The remote end hung up unexpectedly
Laptop (Tiger OS X 10.4.11):
git version 1.5.6.1
Central (Leopard OS X 10.5):
git version 1.5.6.1
Configuration of repository:
[core]
repositoryformatversion = 0
filemode = true
bare = true
ignorecase = true
sharedrepository = 1
[receive]
denyNonFastforwards = true
I couldn't find this issue discussed anywhere, so, I post in hope that
someone has run into it before.
--
Denis
^ permalink raw reply
* Re: [msysGit] How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics))
From: Johannes Sixt @ 2008-06-30 18:47 UTC (permalink / raw)
To: prohaska; +Cc: msysGit, Junio C Hamano, Git Mailing List
In-Reply-To: <4CE52307-A2DE-488B-998B-76D60B66E804@zib.de>
On Montag, 30. Juni 2008, Steffen Prohaska wrote:
> On Jun 30, 2008, at 11:08 AM, Junio C Hamano wrote:
> > * MinGW will be in.
>
> If this is done, we should be able to create the msysgit release
> directly
> from Junio's master. Hannes changes alone, however, are not sufficient,
> because some commits have been parked in 4msysgit. Now that MinGW is
> on Junio's next and Junio's next is also on 4msysgit's next, it it easy
> to see how much is left to do by running:
>
> git diff --stat junio/next..4msysgit/next
>
> junio is a remote pointing to git://git.kernel.org/pub/scm/git/git.git.
> 4msysgit is a remote pointing to git://repo.or.cz/git/mingw/
> 4msysgit.git.
> I attached the output below.
>
> How should we proceed to get rid of the differences?
>
> Should we prepare and send patches directly to the official git list
> now?
> Should we wait until the first MinGW branch is on master?
> Should we prepare a whole patch series? Maybe Hannes would maintain
> this
> patch series.
Until 1.6.0 is released, a number of _required_ patches will have to be
included. There are two sorts of them:
* Patches that touch generic code, like replacing c == '/' by is_dir_sep(c).
* Patches that are purly Windows specific.
The former I intend to submit to the mailing list directly and as soon as
possible (but if I can intervene on newly submitted patches early so that a
fixup is not even necessary, then even better). The latter I intend to
collect in a branch and submit as a batch. Let's see how this works out.
Then there are the extra patches in 4msysgit. From my POV, they are not
_required_ because I can appearently work with git on Windows without them. I
think some of them are not necessary. Can we go through them again?
And then there are the patches to the t/ directory. I do not target them for
1.6.0, but I do want to prepare another series with them.
-- Hannes
^ permalink raw reply
* [PATCH] Add another fast-import example, this time for .zip files
From: Johannes Schindelin @ 2008-06-30 18:50 UTC (permalink / raw)
To: spearce, git
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
I needed that today.
contrib/fast-import/import-zip.py | 66 +++++++++++++++++++++++++++++++++++++
1 files changed, 66 insertions(+), 0 deletions(-)
create mode 100755 contrib/fast-import/import-zip.py
diff --git a/contrib/fast-import/import-zip.py b/contrib/fast-import/import-zip.py
new file mode 100755
index 0000000..de677e4
--- /dev/null
+++ b/contrib/fast-import/import-zip.py
@@ -0,0 +1,66 @@
+#!/usr/bin/python
+
+## zip archive frontend for git-fast-import
+##
+## For example:
+##
+## mkdir project; cd project; git init
+## python import-zips.py *.zip
+## git log --stat import-zips
+
+from os import popen, path
+from sys import argv, exit
+from time import mktime
+from zipfile import ZipFile
+
+if len(argv) < 2:
+ print 'Usage:', argv[0], '<zipfile>...'
+ exit(1)
+
+branch_ref = 'refs/heads/import-zips'
+committer_name = 'Z Ip Creator'
+committer_email = 'zip@example.com'
+
+fast_import = popen('git fast-import --quiet', 'w')
+def printlines(list):
+ for str in list:
+ fast_import.write(str + "\n")
+
+for zipfile in argv[1:]:
+ commit_time = 0
+ next_mark = 1
+ common_prefix = None
+ mark = dict()
+
+ zip = ZipFile(zipfile, 'r')
+ for name in zip.namelist():
+ if name.endswith('/'):
+ continue
+ info = zip.getinfo(name)
+
+ if commit_time < info.date_time:
+ commit_time = info.date_time
+
+ mark[name] = ':' + str(next_mark)
+ next_mark += 1
+
+ printlines(('blob', 'mark ' + mark[name], \
+ 'data ' + str(info.file_size)))
+ fast_import.write(zip.read(name) + "\n")
+
+ committer = committer_name + ' <' + committer_email + '> %d +0000' % \
+ mktime(commit_time + (0, 0, 0))
+
+ printlines(('commit ' + branch_ref, 'committer ' + committer, \
+ 'data <<EOM', 'Imported from ' + zipfile + '.', 'EOM', \
+ '', 'deleteall'))
+
+ for name in mark.keys():
+ fast_import.write('M 100644 ' + mark[name] + ' ' + name + "\n")
+
+ printlines(('', 'tag ' + path.basename(zipfile), \
+ 'from ' + branch_ref, 'tagger ' + committer, \
+ 'data <<EOM', 'Package ' + zipfile, 'EOM', ''))
+
+if fast_import.close():
+ exit(1)
--
1.5.6.1.297.g148d9
^ permalink raw reply related
* Multiple remote.<...>.fetch and .push patterns
From: Adr3nal D0S @ 2008-06-30 18:58 UTC (permalink / raw)
To: git
How can I do something like what is shown in Everyday git using git-config?
$ cat .git/remotes/ko
URL: kernel.org:/pub/scm/git/git.git
Pull: master:refs/tags/ko-master
Pull: next:refs/tags/ko-next
Pull: maint:refs/tags/ko-maint
Push: master
Push: next
Push: +pu
Push: maint
I know I can do:
git config remote.ko.fetch refs/heads/*:refs/tags/ko-*
but that will get all KO heads. And I have no clue about the push version.
^ permalink raw reply
* Re: pread() over NFS (again) [1.5.5.4]
From: Nicolas Pitre @ 2008-06-30 19:09 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Trond Myklebust, J. Bruce Fields, Junio C Hamano, logank,
Christian Holtje, git, Trond Myklebust
In-Reply-To: <20080630003203.GJ11793@spearce.org>
On Sun, 29 Jun 2008, Shawn O. Pearce wrote:
> Trond Myklebust <Trond.Myklebust@netapp.com> wrote:
> > Is the file only being read, or could there be a simultaneous write to
> > the same file? I'm surmising this could be an effect resulting from
> > simultaneous cache invalidations: prior to Linux 2.6.20 or so, we
> > weren't rigorously following the VFS/VM rules for page locking, and so
> > page cache invalidation in particular could have some curious
> > side-effects.
>
> The file was created and opened O_CREAT|O_EXCL|O_RDWR, by this
> process, written linearly using write(2), without any lseeks.
> We kept the file descriptor open and starting issuing pread(2)
> calls for earlier offsets we had alread written. One of those
> kicks back EOF far too early (and results in this bug report).
>
> Note the only accesses we are using is write(2) and pread(2), and
> once we start reading we don't ever go back to writing.
That's not exact. With a thin pack, we continue appending data to the
file after a bunch of pread() have occurred. And only after those
pread()'s do we know that we actually have a thin pack.
> The pread(2)
> calls are typically issued in ascending offsets, and we read each
> position only once. This is to try and take advantage of any
> read-ahead the kernel may be able to do.
That's not exact. The pread() calls are done when resolving deltas,
hence a base object is read and every deltas based on it are recursively
resolved to find their SHA1 signature. Then another base is picked up
and the same process repeated. And in practice all those delta chains
are all interleaced in the pack file due to the fact that objects are
stored so to optimize access to recent commits. Therefore they're more
or less random.
Nicolas
^ permalink raw reply
* Re: Multiple remote.<...>.fetch and .push patterns
From: Jon Loeliger @ 2008-06-30 19:29 UTC (permalink / raw)
To: Adr3nal D0S; +Cc: git
In-Reply-To: <308083c30806301158i1100c84dqe7f50daad417934c@mail.gmail.com>
Adr3nal D0S wrote:
> How can I do something like what is shown in Everyday git using git-config?
>
> $ cat .git/remotes/ko
> URL: kernel.org:/pub/scm/git/git.git
> Pull: master:refs/tags/ko-master
> Pull: next:refs/tags/ko-next
> Pull: maint:refs/tags/ko-maint
> Push: master
> Push: next
> Push: +pu
> Push: maint
>
> I know I can do:
>
> git config remote.ko.fetch refs/heads/*:refs/tags/ko-*
>
> but that will get all KO heads. And I have no clue about the push version.
The file is editable!
You can have both Push: and Pull: lines for a remote there.
Or have I misunderstood your question here?
jdl
^ permalink raw reply
* Re: Corruption: empty refs/heads in otherwise filled repo: cannot clone?
From: Daniel Barkalow @ 2008-06-30 19:33 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: Jakub Narebski, git
In-Reply-To: <200806301420.12872.J.Wielemaker@uva.nl>
On Mon, 30 Jun 2008, Jan Wielemaker wrote:
> On Monday 30 June 2008 14:03, Jakub Narebski wrote:
> > Jan Wielemaker wrote:
> > > Summarising, I think the conclusion is that git pack-refs has somehow
> > > been run on this repository, and being a bare one this is not a
> > > particulary good idea right now. I have the impression I should `unpack'
> > > them by putting the appriate files in heads (done) and tags (now still)
> > > and (re)move packed-refs.
> >
> > If you use new enough git both on server and on clients it should
> > not have problems with packed-refs. I would rather check permissions
> > of $GIT_DIR and $GIT_DIR/packed-refs.
>
> There is no permission problem, as a I proved by doing a recursive copy
> of the whole repo (cp -a, no errors) and the problem prevails on the
> copy. A serious scan for permission errors was my first step. Almost
> looks like something in the environment, but I can't find anything weird
> there either.
That's a "cp -a" as somebody else, I assume? (If it were as you or root,
you'd generate a copy of the repository with any permission problem
unchanged, since -a includes -p.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Multiple remote.<...>.fetch and .push patterns
From: Adr3nal D0S @ 2008-06-30 19:52 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <48693434.4090402@freescale.com>
In reference to my question about .git/remotes/ko, Jon Loeliger
<jdl@freescale.com> wrote:
> You can have both Push: and Pull: lines for a remote there.
>
> Or have I misunderstood your question here?
I know that I can create files in .git/remotes that look like Linus'
ko sample. But I was wondering if this could be done with git-config.
I have some developers that are new to SCMs in general and git in
particular. They are a little nervous playing in the git directory.
Also, I was uncertain how settings in .git/remotes files interact with
git-config ...fetch and ...push settings, if at all.
^ permalink raw reply
* Re: Corruption: empty refs/heads in otherwise filled repo: cannot clone?
From: Jan Wielemaker @ 2008-06-30 19:46 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Jakub Narebski, git
In-Reply-To: <alpine.LNX.1.00.0806301528500.19665@iabervon.org>
On Monday 30 June 2008 21:33:50 Daniel Barkalow wrote:
> On Mon, 30 Jun 2008, Jan Wielemaker wrote:
> > On Monday 30 June 2008 14:03, Jakub Narebski wrote:
> > > Jan Wielemaker wrote:
> > > > Summarising, I think the conclusion is that git pack-refs has somehow
> > > > been run on this repository, and being a bare one this is not a
> > > > particulary good idea right now. I have the impression I should
> > > > `unpack' them by putting the appriate files in heads (done) and tags
> > > > (now still) and (re)move packed-refs.
> > >
> > > If you use new enough git both on server and on clients it should
> > > not have problems with packed-refs. I would rather check permissions
> > > of $GIT_DIR and $GIT_DIR/packed-refs.
> >
> > There is no permission problem, as a I proved by doing a recursive copy
> > of the whole repo (cp -a, no errors) and the problem prevails on the
> > copy. A serious scan for permission errors was my first step. Almost
> > looks like something in the environment, but I can't find anything weird
> > there either.
>
> That's a "cp -a" as somebody else, I assume? (If it were as you or root,
> you'd generate a copy of the repository with any permission problem
> unchanged, since -a includes -p.)
I'm an old time Unix guy :-). The failing user has a git-shell. I did
(reconstructing from memory):
% sudo -u failinguser /bin/bash
<passwd>
% Use whoami to validate I was this user
% git clone /home/git/pl.git
<failed (no remote branches)>
% cp -a /home/git/pl.git tmp.git
<ok, no errors>
% git clone tmp.git
<failed (no remote branches)>
Funny enough, as myself I can clone tmp.git!? I have only one git
installation
in /usr/local/bin.
Cheers --- Jan
^ 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