Is it safe to set SUBDIRECTORY_OK='Yes' in git-checkout.sh? What about the other *.sh that don't already set it? -- Jon Nelson <jnelson-git@jamponi.net> -

For scripted use you can give command line arguments yourself to whatchanged and you can bypass the repoconfig. I do not think whatchanged is meant for scripted use, though --- it is such a simple script, and if you want to build on it to do something more elaborate, I think you would be better off writing those rev-list and diff-tree in your script. -

Tommi Virtanen expressed a wish on #git to be able to use short and elegant git URLs by making git-daemon 'root' in a given directory. This patch implements this, causing git-daemon to interpret all paths relative to the given base path if any is given. Signed-off-by: Petr Baudis <pasky@suse.cz> --- Documentation/git-daemon.txt | 11 ++++++++++- daemon.c | 21 ++++++++++++++++++++- 2 files changed, 30 insertions(+), 2 deletions(-) diff --git ...

Wouldn't this safe_create_leading_directories("/pub/git.git/objects") try chmod "/pub" and fail? -

This is the second attempt, after Junio convinced me that my simple approach to set umask was misguided. If the config variable 'core.sharedrepository' is set, the directories $GIT_DIR/objects/ $GIT_DIR/objects/?? $GIT_DIR/objects/pack $GIT_DIR/refs $GIT_DIR/refs/heads $GIT_DIR/refs/heads/tags are set group writable (and g+s, since the git group may be not the primary group of all users). Since all files are written as lock files first, and then moved to their destination, ...

We want to record the version of the tools the patch was generated with. While these tools could be rebuilt, git-format-patch stayed the same and report the wrong version. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> --- Makefile | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) ca85baee8d11e5c4c6de4678fecf311a029c1d7c diff --git a/Makefile b/Makefile index d35637c..5dec33a 100644 --- a/Makefile +++ b/Makefile @@ -406,6 +406,9 @@ $(patsubst ...

Hi, I like it. Ciao, Dscho -

FWIW, fourthed ;-) commit c894168631e4b7da66ed3993a4c92380d38599a8 Author: Junio C Hamano <junkio@cox.net> Date: Wed Dec 21 22:33:37 2005 -0800 Versioning scheme changes. HPA suggests it is simply silly to imitate Linux versioning scheme where the leading "2" does not mean anything anymore, and I tend to agree. The first feature release after 1.0.0 will be 1.1.0, and the development path leading to 1.1.0 will carry 1.0.GIT as the version number ...

If we consider the "origin is special and is used to track upstream" convention pretty much ingrained, then unconditionally overwriting origin without saying anything is the right approach. After all, you do not care what upstream your upstream is keeping track of, and you would want to use 'origin' for the usual purpose of keeping track of upstream. Otherwise, if we do not treat "origin" specially, we could do something like this. If "origin" exists, then we do not overwrite upon clone, ...

Good catch, thanks. The worst one is: diff.c:727: memcpy(one_sha1, sha1_to_hex(one->sha1), 41); -

Recognize missing files when using http-fetch with file:// URLs Signed-off-by: Nick Hengeveld <nickh@reactrix.com> --- By way of explanation, our content distribution clients use a self-referential file:// URL when fetching updates, and all actual content servers are listed in http-alternates. This removes the dependency on a single external primary server so updates will continue to work as long as any one server is available. http-fetch.c | 12 ++++++++---- 1 files changed, 8 ...

I've started working recently with git, and I'm suffering problems to update a master repository. Sometimes, git refuses to update a master repository: git push ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git master error: src refspec master matches more than one. fatal: unexpected EOF Even removing the branch, git-prune and reimporting doesn't work. I have to reimport the tree from master repository. Any sugestions? Cheers, Mauro. -

In non-git'ish, does this mean "you're not up to date, so pull before pushing" ? If so, why not say so? I'm sure it could prevent a fair few problems for users (not least those new to scm's). -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -

Hi, And that makes the script not stop how? Ciao, Dscho -

You already know I am in favor of this; it was the motivation behind --abbrev. With an 80-column terminal, especially with the hardcoded LESS=-S switch, the default diff-raw output was unusable. How about doing something like this patch first, and then decide what the default should be? I would recommend "--pretty -r --name-status -M" as the default. But I am not particularly interested in imposing my preference over that of Linus to the end users. -- >8 -- This allows the ...

That's the point, isn't it? A script from ~user1/bin, which calls git-whatchanged suddenly stops working in ~user2/repo. Besides, how can user1 know what he has to specify to git-whatchanged (I assume the command line overrides .git/config) so that his script works everywhere? Maybe such configuration better left to environment variables? -

Seconded. letters in versions are bad. With my MacOS background, for me, "b" means "beta" :) Ben. -

I mean it to be set only when git-shell called, but with explicit semantics shared.mask = shell.mask. Just a name to express what it is for -

Hi, What would shell.umask do? Be set only when git-shell is called? Then you better have the policy to access that particular repository *only* via git-shell. Voila, it is the same effect as of core.umask. What would shared.umask do? Be set only when writing to GIT_DIR? This is a major task, since you have to find out which writes are to the working directory, which ones go to GIT_DIR. And you have to workout a policy (as I just answered in this thread) how to deal with a checked ...

May be "shell.umask" or "shared.umask" ? -

You're simplifying. Your question was "How can I set up a repository for multiple users to write to without setting a global umask for non-interactive shells?" Junio said: "I agree the setting should not be limited to git-shell, but I do not think setting "umask" from git configuration is the right way either. For files and directories under $GIT_DIR, maybe imposing the policy git configuration file has is OK, but I think honoring the user's umask is the right thing for working tree ...

Hi, No, I am not. My question really was: how do I setup a shared repository? IMHO Junio is wrong here. If the repository is write-shared, then the working directory should be write-shared as well (or checkout should be I do not understand what you mean by "repositories cloned remotely". And if you really are working in the working directory of the shared repository, and a user (I know I would do it just to annoy you) pushes a new HEAD while you have modified files, you deserve ...

Ahh. Sorry. We use this method a lot, really, but always only for running gitk and archaeology tools to check newly pushed changes, so the write-shared repo is only write-shared for remote users, and the local one never does a commit. It's perhaps a bit of a weird setup, but it lets you get an overview faster than gitweb and works well enough with samba. Noted should be that having the repo checked out is merely a convenience thing to let one browse the files at leisure. People know to ...

That somebody has to be somebody who owns .git directory not just a group member, so that is not a serious objection either, but you need to realize I was joking with 0777 -- a saner default would obviously be 0775. Otherwise you would not be able to server it from gitweb safely -- http server is typically I am afraid that is going backwards. Nobody *needs* core.umask either, but we are still talking about this. That is because you wanted to make things easier for people, and I agree ...

Hi, But if somebody writes to the same repository with another umask, say 0022, you have problems. Example: - I push -- via ssh/bash -- to the repository. The ref refs/heads/bruchpilot is updated (mode: 0644). - My colleague pushes -- via ssh/git-shell -- to the repository. When she tries to write refs/heads/bruchpilot, it fails, even if she set the correct umask. See what I mean? It makes no sense to allow different umasks on the You do mean different umasks for different ...

Hi, I was talking about somebody who has only one server for everything: mail, Yes, I tried to avoid that. Ciao, Dscho -