* Re: git /objects directory created 755 by default?
From: Johannes Schindelin @ 2005-12-22 11:35 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Martin Langhoff, git
In-Reply-To: <81b0412b0512220211o74f7f533j11b8e48311b61ec2@mail.gmail.com>
Hi,
On Thu, 22 Dec 2005, Alex Riesen wrote:
> On 12/21/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > >
> > > > [core]
> > > > umask = 0002
> > So, I tend to say: use core.umask only in shared setups (in which you
> > should not checkout files unless you know exactly what you are doing).
>
> May be "shell.umask" or "shared.umask" ?
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 out HEAD where you can't write to the working
directory (or at least modify the checked out files).
The sanest way I can think of is either to disallow checkout, or to make
the files writable to the group. Both methods do fine with core.umask.
Now that I think of it: A third possibility is to disallow pushing to the
checked out HEAD. Is this desirable? I think not. The user who works in
the working directory exclusively would have to keep track of the
pushed ref herself, instead of the user who pushed the ref. Sounds silly
to me.
Hth,
Dscho
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Andreas Ericsson @ 2005-12-22 12:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512221220220.7112@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 22 Dec 2005, Andreas Ericsson wrote:
>
>
>>Johannes Schindelin wrote:
>>
>>>Hi,
>>>
>>>On Wed, 21 Dec 2005, Junio C Hamano wrote:
>>>
>>>
>>>
>>>>Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>>
>>>>
>>>>
>>>>>If you don't use git-shell, because the same machine is used for other
>>>>>purposes, it makes sense to introduce
>>>>>
>>>>> [core]
>>>>> umask = 0002
>>>>
>>>>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 files.
>>>
>>>
>>>As we worked out in another thread, you should not have a working directory
>>>when you write-share the repository.
>>>
>>
>>Which thread was that? I see no particular problem with having a working
>>directory in a write-shared repo. The same care has to be taken there as
>>everywhere (pull before push), but that's nothing new.
>
>
> It was the thread "How to set up a shared repository".
>
> Okay, so there you are. You have a write-shared repository with the HEAD
> checked out. Somebody wants to push to that with different credentials
> than the user who checked out the files. Do you plainly deny updating the
> current HEAD?
>
> If you do, then you better give the pushing user (pun intended) a way to
> update the checked out files. You can do this by (tadaah) setting the
> umask to 0002 also for working files.
>
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 do
git checkout -f HEAD
whenever they want to dig around.
> Yes, we could find out exactly where writes happen inside GIT_DIR and plug
> in shared.umask which is only applied in these cases, but I am totally
> unconvinced that this is worth the hassle. In my cases, I am perfectly
> helped by a umask which is respected throughout git, and the patch is
> simple enough to be reviewed in 5 minutes.
>
But adding
umask 002
to /etc/bashrc would do exactly the same thing, so why have it a setting
for the repository only? In my experience, most servers used for hosting
git repos host *lots* of them (look at master.kernel.org), so a
server-wide setting really makes much more sense. If the server admin
can't be bothered you can always change $HOME/.bashrc.
So long as people remember that .bash_profile isn't read for
non-interactive shells this should do nicely. If they can't remember
that they won't remember adding the setting to the repository either.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] off-by-one bugs found by valgrind
From: Horst von Brand @ 2005-12-22 0:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git
In-Reply-To: <7vr7865fq5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Pavel Roskin <proski@gnu.org> writes:
[...]
> > quote_c_style_counted() in quote.c uses a dangerous construct, when a
> > variable is incremented once and used twice in the same expression.
>
> Sorry, I do not follow you. Isn't && a sequence point?
>
> > - for (sp = name; (ch = *sp++) && (sp - name) <= namelen; ) {
> > -
> > + for (sp = name; sp < name + namelen; sp++) {
Yes, it is, so it doesn't fix any bugs; but Pavel's version is definitely
more readable.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Johannes Schindelin @ 2005-12-22 14:37 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43AA9BE6.7000601@op5.se>
Hi,
On Thu, 22 Dec 2005, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
> >
> > Okay, so there you are. You have a write-shared repository with the HEAD
> > checked out. Somebody wants to push to that with different credentials than
> > the user who checked out the files. Do you plainly deny updating the current
> > HEAD?
> >
> > If you do, then you better give the pushing user (pun intended) a way to
> > update the checked out files. You can do this by (tadaah) setting the umask
> > to 0002 also for working files.
> >
>
> 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 do
> git checkout -f HEAD
>
> whenever they want to dig around.
Better to do this with a post-update hook, right? You can't forget to
checkout this way. *Plus* you can make sure the umask is correct in the
hook.
> > Yes, we could find out exactly where writes happen inside GIT_DIR and plug
> > in shared.umask which is only applied in these cases, but I am totally
> > unconvinced that this is worth the hassle. In my cases, I am perfectly
> > helped by a umask which is respected throughout git, and the patch is simple
> > enough to be reviewed in 5 minutes.
> >
>
> But adding
>
> umask 002
>
> to /etc/bashrc would do exactly the same thing, so why have it a setting for
> the repository only? In my experience, most servers used for hosting git repos
> host *lots* of them (look at master.kernel.org), so a server-wide setting
> really makes much more sense. If the server admin can't be bothered you can
> always change $HOME/.bashrc.
In my very special setup, it is a server on which you have your personal
files, too. So, setting umask = 0002 globally is not an option.
Furthermore, it just feels wrong to set an option outside of git which is
meant *only* for git usage.
> So long as people remember that .bash_profile isn't read for non-interactive
> shells this should do nicely. If they can't remember that they won't remember
> adding the setting to the repository either.
Problem is, what if one of your users is a tcsh zealot? Or simply forgot
to set it. Trouble in China. Also, I simply can not memorize what startup
script gets called when.
Ciao,
Dscho
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Alex Riesen @ 2005-12-22 14:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.63.0512221227190.7112@wbgn013.biozentrum.uni-wuerzburg.de>
On 12/22/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > >
> > > > > [core]
> > > > > umask = 0002
> > > So, I tend to say: use core.umask only in shared setups (in which you
> > > should not checkout files unless you know exactly what you are doing).
> >
> > May be "shell.umask" or "shared.umask" ?
>
> 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.
I mean it to be set only when git-shell called, but with explicit semantics
("for git-shell only").
> 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.
shared.mask = shell.mask. Just a name to express what it is for
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Johannes Schindelin @ 2005-12-22 15:09 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Martin Langhoff, git
In-Reply-To: <81b0412b0512220638j382252b5l24e1c6b261165bd6@mail.gmail.com>
Hi,
On Thu, 22 Dec 2005, Alex Riesen wrote:
> On 12/22/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > 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.
>
> I mean it to be set only when git-shell called, but with explicit semantics
> ("for git-shell only").
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
repository.
> > 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.
>
> shared.mask = shell.mask. Just a name to express what it is for
You do mean different umasks for different access methods, don't you? See
above why I don't think that makes sense.
Ciao,
Dscho
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Alex Riesen @ 2005-12-22 15:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.63.0512221603490.18668@wbgn013.biozentrum.uni-wuerzburg.de>
On 12/22/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > 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.
> >
> > I mean it to be set only when git-shell called, but with explicit semantics
> > ("for git-shell only").
>
> 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
> repository.
Does it make sense to allow different access methods to a shared repository?
> > > 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.
> >
> > shared.mask = shell.mask. Just a name to express what it is for
>
> You do mean different umasks for different access methods, don't you? See
> above why I don't think that makes sense.
No, just different names for the same access method.
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Johannes Schindelin @ 2005-12-22 15:52 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Martin Langhoff, git
In-Reply-To: <81b0412b0512220714w7fb1d9c2j95bbe620fd88cf95@mail.gmail.com>
Hi,
On Thu, 22 Dec 2005, Alex Riesen wrote:
> Does it make sense to allow different access methods to a shared repository?
My point is: regardless if you allow different access methods or not, you
only need one method to set a repository-wide umask.
Ciao,
Dscho
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Andreas Ericsson @ 2005-12-22 15:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512221530570.18551@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 22 Dec 2005, Andreas Ericsson wrote:
>
>
>>Johannes Schindelin wrote:
>>
>>>Okay, so there you are. You have a write-shared repository with the HEAD
>>>checked out. Somebody wants to push to that with different credentials than
>>>the user who checked out the files. Do you plainly deny updating the current
>>>HEAD?
>>>
>>>If you do, then you better give the pushing user (pun intended) a way to
>>>update the checked out files. You can do this by (tadaah) setting the umask
>>>to 0002 also for working files.
>>>
>>
>>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 do
>> git checkout -f HEAD
>>
>>whenever they want to dig around.
>
>
> Better to do this with a post-update hook, right? You can't forget to
> checkout this way. *Plus* you can make sure the umask is correct in the
> hook.
>
What prevents you from setting umask 002 in the hook? If the files are
already checked out with some other (write-denying) umask by some other
user it will fail regardless of where the umask comes from.
>
>>>Yes, we could find out exactly where writes happen inside GIT_DIR and plug
>>>in shared.umask which is only applied in these cases, but I am totally
>>>unconvinced that this is worth the hassle. In my cases, I am perfectly
>>>helped by a umask which is respected throughout git, and the patch is simple
>>>enough to be reviewed in 5 minutes.
>>>
>>
>>But adding
>>
>> umask 002
>>
>>to /etc/bashrc would do exactly the same thing, so why have it a setting for
>>the repository only? In my experience, most servers used for hosting git repos
>>host *lots* of them (look at master.kernel.org), so a server-wide setting
>>really makes much more sense. If the server admin can't be bothered you can
>>always change $HOME/.bashrc.
>
>
> In my very special setup, it is a server on which you have your personal
> files, too. So, setting umask = 0002 globally is not an option.
>
scp -p preserves the umask you have on your desktop/laptop, so unless
you frequently do
ssh somewhere "echo 'Gawds, this is an awkward way of editing files' >>
somefile"
you should be good with the bashrc setting. You can override it from
bash_profile to make sure you get a safely sane umask when logging in
interactively.
>
>>So long as people remember that .bash_profile isn't read for non-interactive
>>shells this should do nicely. If they can't remember that they won't remember
>>adding the setting to the repository either.
>
>
> Problem is, what if one of your users is a tcsh zealot? Or simply forgot
> to set it. Trouble in China. Also, I simply can not memorize what startup
> script gets called when.
>
tcsh zealot? Not familiar with that one. If you're trying to cover every
angle I think you'll be in for a disappointment though. Users are
usually fairly ingenious when it comes to finding ways of causing trouble.
As for forgetting to set it, I was talking about the /etc/bashrc file
here. There is a /etc/cshrc as well, although this tcsh zealot shell
might ignore it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Johannes Schindelin @ 2005-12-22 16:03 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43AACBE9.7060201@op5.se>
Hi,
this is getting silly. The problem is: how to setup a shared repository,
i.e. a repository into which different users can push their updates.
Yes, I can work around the fact that git (in its current official version)
does not have an option to make that happen.
It is just awfully cumbersome. And that is what good software should
prevent. Especially if it is *that* easy.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] GIT: Support [address] in URLs
From: Daniel Barkalow @ 2005-12-22 16:48 UTC (permalink / raw)
To: David S. Miller; +Cc: yoshfuji, junkio, git
In-Reply-To: <20051221.152648.122640664.davem@davemloft.net>
On Wed, 21 Dec 2005, David S. Miller wrote:
> This is a pain, but no better solutions have been suggested. Before
> anyone responds: 1) making the lists subscriber-only is not an option
> 2) Bayesian filters are hard to integrate into our setup but we are
> exploring ways to make that a reality at some point nevertheless.
Would it work to strip out all of the characters which are only in the
disallowed character set, change the character set to ascii, and check the
message like that? (Of course, empty or substantially reduced messages
should be discarded instead) It looks like the non-spam in these character
sets only has a few non-ascii characters, and those are transliterated
into ascii nearby anyway, and I doubt that there's much spam in non-ascii
with only a few characters in some other character set that wouldn't be
obvious in some other way after those characters were removed.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Andreas Ericsson @ 2005-12-22 16:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512221700310.18982@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> this is getting silly. The problem is: how to setup a shared repository,
> i.e. a repository into which different users can push their updates.
>
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 files."
which I whole-heartedly agree with. I'd be completely furious if a tool
ignored the umask I use for checking out files of a local repository
just because I happen to do some work at the machine where the repo is
stored (I imagine this couldn't possibly affect repositories cloned
remotely, although that would surely have me going ballistic).
You answered that it would be good for hooks as well, although those can
set their own umask easily enough (if you forget it there, you'll be
hastily reminded the first time it breaks, so no real harm done).
The problem as I see it is to update only the $GIT_DIR files with the
proper umask (or rather, just the objects/ and refs/ directories, since
$GIT_DIR/. is never touched after being created and the other are for
repo maintainers only).
Enter the nifty git-receive-pack, which does all the writing when a repo
is being pushed to, unless bypassed from the /git/foo working tree for
the /git/foo/.git repository. The latter is already discouraged, so we
might as well ignore that. It's also nice because it will never mess
with files that are for the repo maintainer only, although hooks can
ofcourse do whatever they like to those files provided the repo
maintainer allows it.
Now it's time to go home, but I'll have a patch by tonight unless you
beat me to it. :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] Fix for http-fetch from file:// URLs
From: Nick Hengeveld @ 2005-12-22 17:09 UTC (permalink / raw)
To: git
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 insertions(+), 4 deletions(-)
applies-to: 3ca81810fe174dec38fa6ccec874559a39d8893f
92865a7cc1ea511f88d1ab8aa4c0faa50e05566b
diff --git a/http-fetch.c b/http-fetch.c
index 3cd6ef9..61b2188 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -267,7 +267,8 @@ static void process_object_response(void
obj_req->state = COMPLETE;
/* Use alternates if necessary */
- if (obj_req->http_code == 404) {
+ if (obj_req->http_code == 404 ||
+ obj_req->curl_result == CURLE_FILE_COULDNT_READ_FILE) {
fetch_alternates(alt->base);
if (obj_req->repo->next != NULL) {
obj_req->repo =
@@ -475,7 +476,8 @@ static void process_alternates_response(
}
}
} else if (slot->curl_result != CURLE_OK) {
- if (slot->http_code != 404) {
+ if (slot->http_code != 404 &&
+ slot->curl_result != CURLE_FILE_COULDNT_READ_FILE) {
got_alternates = -1;
return;
}
@@ -637,7 +639,8 @@ static int fetch_indices(struct alt_base
if (start_active_slot(slot)) {
run_active_slot(slot);
if (slot->curl_result != CURLE_OK) {
- if (slot->http_code == 404) {
+ if (slot->http_code == 404 ||
+ slot->curl_result == CURLE_FILE_COULDNT_READ_FILE) {
repo->got_indices = 1;
free(buffer.buffer);
return 0;
@@ -802,7 +805,8 @@ static int fetch_object(struct alt_base
ret = error("Request for %s aborted", hex);
} else if (obj_req->curl_result != CURLE_OK &&
obj_req->http_code != 416) {
- if (obj_req->http_code == 404)
+ if (obj_req->http_code == 404 ||
+ obj_req->curl_result == CURLE_FILE_COULDNT_READ_FILE)
ret = -1; /* Be silent, it is probably in a pack. */
else
ret = error("%s (curl_result = %d, http_code = %ld, sha1 = %s)",
---
0.99.9.GIT
^ permalink raw reply related
* Re: git /objects directory created 755 by default?
From: Johannes Schindelin @ 2005-12-22 17:31 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43AAD9D7.1070503@op5.se>
Hi,
On Thu, 22 Dec 2005, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
> > Hi,
> >
> > this is getting silly. The problem is: how to setup a shared repository,
> > i.e. a repository into which different users can push their updates.
> >
>
> 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?"
No, I am not. My question really was: how do I setup a shared repository?
Now, my intention was to make it as easy as possible.
> 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 files."
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
DENIED), else you get all kinds of problems.
> which I whole-heartedly agree with. I'd be completely furious if a tool
> ignored the umask I use for checking out files of a local repository just
> because I happen to do some work at the machine where the repo is stored (I
> imagine this couldn't possibly affect repositories cloned remotely, although
> that would surely have me going ballistic).
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 what you get: a
complete mess.
As for setting the umask only when writing into $GIT_DIR: unless somebody
convinces me that it solves a problem, this is unncessary work.
You are free to ignore my warnings and my patch, I got no problem with
that.
You are also free to wait for users to complain why this and that breaks,
or why setting up a shared repository has to be hard, and apply my patch
then.
Hth,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.0.0b quickfix
From: Linus Torvalds @ 2005-12-22 17:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: H. Peter Anvin, Junio C Hamano, git, linux-kernel
In-Reply-To: <1135244363.10035.185.camel@gaston>
On Thu, 22 Dec 2005, Benjamin Herrenschmidt wrote:
> >
> > Wouldn't it make more sense for the maintenance release to be 1.0.1?
>
> Seconded. letters in versions are bad. With my MacOS background, for me,
> "b" means "beta" :)
FWIW, thirded. The kernel used to use letters too, and it's cute, but just
using multiple levels of release numbers is much more common.
Linus
^ permalink raw reply
* [PATCH] sha1_to_hex: properly terminate the SHA1
From: Johannes Schindelin @ 2005-12-22 17:55 UTC (permalink / raw)
To: git, junkio
sha1_to_hex() returns a pointer to a static buffer. Some of its users
modify that buffer by appending a newline character. Other users rely
on the fact that you can call
printf("%s", sha1_to_hex(sha1));
Just to be on the safe side, terminate the SHA1 in sha1_to_hex().
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
sha1_file.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
3a743c154546e4937b4afdc7848d9943ec2f4148
diff --git a/sha1_file.c b/sha1_file.c
index 6011473..d451a94 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -81,6 +81,8 @@ char * sha1_to_hex(const unsigned char *
*buf++ = hex[val >> 4];
*buf++ = hex[val & 0xf];
}
+ *buf = '\0';
+
return buffer;
}
--
1.0.0
^ permalink raw reply related
* [PATCH] git-clone-pack: do not silently overwrite an existing branch 'origin'
From: Johannes Schindelin @ 2005-12-22 17:59 UTC (permalink / raw)
To: git, junkio
When cloning a repository which already contains a branch called 'origin',
do not silently overwrite it with the remote 'master' ref.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This happened to me with a project I track via git-cvsimport.
The clone strangely suffered a time warp ;-)
git-clone.sh | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
f0d4ef72573488410a1e8eb0198e347630d6e2c9
diff --git a/git-clone.sh b/git-clone.sh
index 280cc2e..e988964 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -204,6 +204,10 @@ then
head_points_at=`git-symbolic-ref HEAD`
case "$head_points_at" in
refs/heads/*)
+ if test -e .git/refs/heads/origin; then
+ chmod a-w .git/refs/heads/origin
+ echo "Warning: branch 'origin' exists already"
+ fi
head_points_at=`expr "$head_points_at" : 'refs/heads/\(.*\)'`
mkdir -p .git/remotes &&
echo >.git/remotes/origin \
--
1.0.0
^ permalink raw reply related
* Re: git /objects directory created 755 by default?
From: Junio C Hamano @ 2005-12-22 19:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Andreas Ericsson
In-Reply-To: <43AAD9D7.1070503@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> 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 files."
I think this needs qualifying.
When we talk about "CVS-style shared repository", we know what
it is -- there is no such thing as "*the* working tree
associated with the repository" and there is no room for
disagreement.
The workflow your shared repository implies is that there is an
associated working tree with that repository, and the working
tree should allow updates by participants who are allowed to
create new things in .git/objects and update .git/refs/. If you
assume that is the only valid use case for non-naked shared
repository, then what I said above is not needed. It does not
make any sense to have anything stricter than 007 as umask in
such a case. But is it the only valid use case?
I could give each of the gitsters I trust an git-shell account
on my private machine and prepare refs/heads/rcpt/js branch for
you and refs/heads/rcpt/ae for Andreas to push into (I would use
Carl's per branch push policy to make sure those "receipt
branches" are the only ones you guys can push into if I did so).
Then instead of sending "I now have this public repository and
have goodies for git improvement; please pull" e-mail to me, you
could push into your branch. I will keep working on master (and
my own topic branches), with whatever branch checked out in the
working tree, and merge from those rcpt branches at my leisure.
You guys are not allowed to touch my working tree, though.
In such a scenario, there is no reason to forbid me from
applying umask 022 to my working tree files, even though making
sure that fan-out directories of .git/objects/ *I* lazily create
can be writable by you is essential.
I have a feeling that it might be good enough to modify
safe_create_leading_directories() to chmod(0777) after creating
a new directory under .git/ (or limit it to .git/objects/). The
repository administrator can restrict things further by chmod
0770 .git/ as needed.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.0.0b quickfix
From: Junio C Hamano @ 2005-12-22 19:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512220945450.4827@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 22 Dec 2005, Benjamin Herrenschmidt wrote:
>> >
>> > Wouldn't it make more sense for the maintenance release to be 1.0.1?
>>
>> Seconded. letters in versions are bad. With my MacOS background, for me,
>> "b" means "beta" :)
>
> FWIW, thirded. The kernel used to use letters too, and it's cute, but just
> using multiple levels of release numbers is much more common.
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 from now on. Similarly, the third maintenance
release that follows 1.0.0 will not be 1.0.0c as planned, but
will be called 1.0.3. The "maint" branch will merge in fixes
and immediately tagged, so there is no need for 1.0.2.GIT that
is in between 1.0.2 (aka 1.0.0b) and 1.0.3.
Signed-off-by: Junio C Hamano <junkio@cox.net>
^ permalink raw reply
* Re: [PATCH] Add suggestion to hard-to-understand error message
From: Junio C Hamano @ 2005-12-22 19:27 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43AA79EB.6040800@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
>> In a sense, both are "pull first?" situation, and it probably is
>> more confusing to give different messages to the user in these
>> two cases. From the end-user point of view they are the same
>> "remote is not strict subset.".
>
> 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).
Perhaps. I was suggesting to say that in *both* places, not
just one.
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Johannes Schindelin @ 2005-12-22 19:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andreas Ericsson
In-Reply-To: <7vwthxlzai.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 22 Dec 2005, Junio C Hamano wrote:
> When we talk about "CVS-style shared repository", we know what
> it is -- there is no such thing as "*the* working tree
> associated with the repository" and there is no room for
> disagreement.
This is what I mean by shared repository.
> I could give each of the gitsters I trust an git-shell account
> on my private machine and prepare refs/heads/rcpt/js branch for
> you and refs/heads/rcpt/ae for Andreas to push into (I would use
> Carl's per branch push policy to make sure those "receipt
> branches" are the only ones you guys can push into if I did so).
>
> Then instead of sending "I now have this public repository and
> have goodies for git improvement; please pull" e-mail to me, you
> could push into your branch. I will keep working on master (and
> my own topic branches), with whatever branch checked out in the
> working tree, and merge from those rcpt branches at my leisure.
> You guys are not allowed to touch my working tree, though.
This has some merit, for example, when some of the contributors have no
public repository.
> In such a scenario, there is no reason to forbid me from
> applying umask 022 to my working tree files, even though making
> sure that fan-out directories of .git/objects/ *I* lazily create
> can be writable by you is essential.
>
> I have a feeling that it might be good enough to modify
> safe_create_leading_directories() to chmod(0777) after creating
> a new directory under .git/ (or limit it to .git/objects/). The
> repository administrator can restrict things further by chmod
> 0770 .git/ as needed.
And then somebody comes along and allows world access by chmod(0775) and
does not realize that *everybody* can delete packs, objects and what-nots
in GIT_DIR.
Given the complexity we are talking about, and the needs which are not at
all that complicated, why not just go with core.umask until somebody
*needs* core.repositoryumask?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-format-patch should show the correct version
From: Johannes Schindelin @ 2005-12-22 19:38 UTC (permalink / raw)
To: git, junkio
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 %.py,%,$(SCRIPT_PYTHON)) : %
git-cherry-pick: git-revert
cp $< $@
+# format-patch records GIT_VERSION
+git-format-patch: Makefile
+
%.o: %.c
$(CC) -o $*.o -c $(ALL_CFLAGS) $<
%.o: %.S
--
1.0.GIT
^ permalink raw reply related
* Re: git /objects directory created 755 by default?
From: Junio C Hamano @ 2005-12-22 20:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512222022510.31591@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> And then somebody comes along and allows world access by chmod(0775) and
> does not realize that *everybody* can delete packs, objects and what-nots
> in GIT_DIR.
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
not a group member.
> Given the complexity we are talking about, and the needs which are not at
> all that complicated, why not just go with core.umask until somebody
> *needs* core.repositoryumask?
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 with
you that it would be nicer if we did not require people set
umask to sane values suitable for group work themselves, but
somehow we did that automatically for them. The longer I think
about it, however, the more I feel this is a lost cause.
Earlier, I suggested git-shell one-liner, only because I thought
git-shell users (or administrators that support git-shell users)
may not have any way to set the umask to sane values themselves,
but I think that should also be doable by telling sshd what the
initial umask of the users should be. And that was where this
umask discussion was started, but I think not touching umask at
all is the right direction.
Your core.umask would make sure the .git/objects/ directory
would be suitable for other members, but git is not the only
tool the people would use in the working tree. To work well
with an editor that does not overwrite an existing file but does
creat/rename upon saving would require you to have a sane umask
if the user adopts your "shared working tree writable by all
members" workflow. Running "make" in the working tree would
leave object files, worse yet in a temporary build directory
make created, with permission bits masked with your umask,
making it imposible to run "make clean" for other members.
Regardless of where and how people come from to work in the
working tree, they need to set umask appropriately anyway.
The only possible issue is one umask might not be sufficient,
but unfortunately you can have only one umask at a time. The
example of "receiption branches" is not a shared repository for
me in the strict sense, but allows for you to push into. I
cannot work with umask 022 in such a repository even if I wanted
to have files in the working tree honor tighter umask. To deal
also with such cases, not mucking with umask but solving the
problem in a more direct way may make more sense -- namely we
should be able to say "such and such things under .git/ in this
repository must be ug+rw regardless of user's umask".
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Johannes Schindelin @ 2005-12-22 20:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bkkkhwb.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 22 Dec 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > And then somebody comes along and allows world access by chmod(0775) and
> > does not realize that *everybody* can delete packs, objects and what-nots
> > in GIT_DIR.
>
> 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
> not a group member.
I was talking about somebody who has only one server for everything: mail,
web and git. So this somebody would be the owner of .git.
> > Given the complexity we are talking about, and the needs which are not at
> > all that complicated, why not just go with core.umask until somebody
> > *needs* core.repositoryumask?
>
> I am afraid that is going backwards. Nobody *needs* core.umask
> either, but we are still talking about this.
Well, I do.
> Your core.umask would make sure the .git/objects/ directory
> would be suitable for other members, but git is not the only
> tool the people would use in the working tree. To work well
> with an editor that does not overwrite an existing file but does
> creat/rename upon saving would require you to have a sane umask
> if the user adopts your "shared working tree writable by all
> members" workflow. Running "make" in the working tree would
> leave object files, worse yet in a temporary build directory
> make created, with permission bits masked with your umask,
> making it imposible to run "make clean" for other members.
Hmm. That is convincing.
> we should be able to say "such and such things under .git/ in this
> repository must be ug+rw regardless of user's umask".
Yes, I tried to avoid that.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] send-pack: reword non-fast-forward error message.
From: Junio C Hamano @ 2005-12-22 20:41 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Johannes Schindelin
In-Reply-To: <7vek45lyor.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Andreas Ericsson <ae@op5.se> writes:
>
>> Junio C Hamano wrote:
>>> In a sense, both are "pull first?" situation, and it probably is
>>> more confusing to give different messages to the user in these
>>> two cases. From the end-user point of view they are the same
>>> "remote is not strict subset.".
>>
>> 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).
That is reasonable. How about this?
-- >8 --
Wnen refusing to push a head, we said cryptic "remote 'branch'
object X does not exist on local" or "remote ref 'branch' is not
a strict subset of local ref 'branch'". That was gittish.
Since the most likely reason this happens is because the pushed
head was not up-to-date, clarify the error message to say that
straight, and suggest pulling first.
First noticed by Johannes and seconded by Andreas.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
send-pack.c | 30 ++++++++++++++----------------
1 files changed, 14 insertions(+), 16 deletions(-)
69310a34cb6dcca32b08cf3ea9e91ab19354a874
diff --git a/send-pack.c b/send-pack.c
index 5bc2f01..0d41f9a 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -231,23 +231,21 @@ static int send_pack(int in, int out, in
if (!force_update &&
!is_zero_sha1(ref->old_sha1) &&
!ref->force) {
- if (!has_sha1_file(ref->old_sha1)) {
- error("remote '%s' object %s does not "
- "exist on local",
- ref->name, sha1_to_hex(ref->old_sha1));
- ret = -2;
- continue;
- }
-
- /* We assume that local is fsck-clean. Otherwise
- * you _could_ have an old tag which points at
- * something you do not have, which may or may not
- * be a commit.
- */
- if (!ref_newer(ref->peer_ref->new_sha1,
+ if (!has_sha1_file(ref->old_sha1) ||
+ !ref_newer(ref->peer_ref->new_sha1,
ref->old_sha1)) {
- error("remote ref '%s' is not a strict "
- "subset of local ref '%s'.", ref->name,
+ /* We do not have the remote ref, or
+ * we know that the remote ref is not
+ * an ancestor of what we are trying to
+ * push. Either way this can be losing
+ * commits at the remote end and likely
+ * we were not up to date to begin with.
+ */
+ error("remote '%s' is not a strict "
+ "subset of local ref '%s'. "
+ "maybe you are not up-to-date and "
+ "need to pull first?",
+ ref->name,
ref->peer_ref->name);
ret = -2;
continue;
--
1.0.GIT
^ permalink raw reply related
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