* 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: [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: 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: 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: Johannes Schindelin @ 2005-12-22 11:27 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43AA75D1.7040009@op5.se>
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.
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.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] whatchanged: customize diff-tree output
From: Johannes Schindelin @ 2005-12-22 11:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0512212245440.4827@g5.osdl.org>
Hi,
On Wed, 21 Dec 2005, Linus Torvalds wrote:
> On Wed, 21 Dec 2005, Junio C Hamano wrote:
> >
> > How about doing something like this patch first, and then decide
> > what the default should be?
I see you already applied it, with a sane default. That's great!
> I'm certainly ok with the short format by default. And making it
> configurable per repo sounds fine, although at the same time I wonder if
> that perhaps confuses people more (something that works in one project one
> way works subtly differently in another project..)
I cannot think of a saner way to have an overridable policy. Just provide
a template config, and you're done. Everyone gets those flags per default,
and if someone does not like it: go ahead, change it yourself!
Besides, you are usually calling git-whatchanged in your private working
tree, where not many people can change the config.
Ciao,
Dscho
^ permalink raw reply
* Re: problems when pushing to a master repository
From: Mauro Carvalho Chehab @ 2005-12-22 10:56 UTC (permalink / raw)
To: git
In-Reply-To: <1135246723.17758.14.camel@localhost>
Em Qui, 2005-12-22 às 08:18 -0200, Mauro Carvalho Chehab escreveu:
> 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?
I found the problem. git created a refs/bases dir, with old references
with the same names. Removing it fixed the problem.
Cheers,
Mauro.
^ permalink raw reply
* problems when pushing to a master repository
From: Mauro Carvalho Chehab @ 2005-12-22 10:18 UTC (permalink / raw)
To: git
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.
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Alex Riesen @ 2005-12-22 10:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.63.0512212317400.18684@wbgn013.biozentrum.uni-wuerzburg.de>
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" ?
^ permalink raw reply
* Re: [PATCH] Add suggestion to hard-to-understand error message
From: Andreas Ericsson @ 2005-12-22 10:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vd5jqvsn1.fsf@assigned-by-dhcp.cox.net>
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).
--
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: Andreas Ericsson @ 2005-12-22 9:45 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0512212317400.18684@wbgn013.biozentrum.uni-wuerzburg.de>
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.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.0.0b quickfix
From: Benjamin Herrenschmidt @ 2005-12-22 9:39 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <43A9E15F.1060808@zytor.com>
On Wed, 2005-12-21 at 15:12 -0800, H. Peter Anvin wrote:
> Junio C Hamano wrote:
> > I've pushed out a v1.0.0b maint release to fix a bug in HTTP
> > fetch that was discovered today X-<.
> >
>
> 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" :)
Ben.
^ permalink raw reply
* Re: [PATCH] sanity check in add_packed_git()
From: Junio C Hamano @ 2005-12-22 9:39 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512212046340.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> I'd like to require it to be a hash, just because that makes it
> prohibitively difficult to make something people will accept as
> pack-05f611b3b8198b262acdf678584d365f8e879aec.pack other than the one from
> the git repository.
How about doing something like this, then?
I haven't tried this with http-fetch but with this I think we
can unconditionally assign p->sha1 in add_packed_git().
-- >8 --
Subject: [PATCH] Require packfiles to follow the naming convention.
With this, pack files must be named "pack-[0-9a-f]{40}.pack",
with corresponding .idx file, and the hexadecimal part must
match the SHA1 checksum git-pack-objects computed when the pack
was created originally (i.e. sum over sorted object names of all
the contained objects). The core would ignore a valid packfile
in $GIT_OBJECT_DIRECTORY/packs that "git-unpack-objects" would
expand properly if it does not follow the naming convention.
[jc: this breaks existing test t5300.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
sha1_file.c | 38 +++++++++++++++++++++++++++++++++++++-
1 files changed, 37 insertions(+), 1 deletions(-)
4ff64a29401b28cfbd925cf86eed8b8e734ed24b
diff --git a/sha1_file.c b/sha1_file.c
index 6011473..01ac925 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -319,18 +319,33 @@ struct packed_git *packed_git;
static int check_packed_git_idx(const char *path, unsigned long *idx_size_,
void **idx_map_)
{
+ SHA_CTX ctx;
+ unsigned char sha1[20];
+ unsigned char packname[20];
void *idx_map;
unsigned int *index;
unsigned long idx_size;
int nr, i;
- int fd = open(path, O_RDONLY);
+ int fd;
struct stat st;
+
+ fd = open(path, O_RDONLY);
if (fd < 0)
return -1;
if (fstat(fd, &st)) {
close(fd);
return -1;
}
+
+ /* We require "...../pack-XXXX{40}XXXX.idx" now.
+ * 5-byte "pack-", 40-byte hex and 4-byte .idx.
+ */
+ i = strlen(path);
+ if (i < 49 || strcmp(path + i - 4, ".idx") ||
+ strncmp(path + i - 49, "pack-", 5) ||
+ get_sha1_hex(path + i - 44, packname))
+ return error("non index file %s ignored", path);
+
idx_size = st.st_size;
idx_map = mmap(NULL, idx_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
@@ -362,6 +377,27 @@ static int check_packed_git_idx(const ch
if (idx_size != 4*256 + nr * 24 + 20 + 20)
return error("wrong index file size");
+ /*
+ * File checksum and index name.
+ */
+ SHA1_Init(&ctx);
+ SHA1_Update(&ctx, idx_map, idx_size-20);
+ SHA1_Final(sha1, &ctx);
+
+ if (memcmp(sha1, idx_map + idx_size - 20, 20))
+ return error("index checksum mismatch");
+
+ SHA1_Init(&ctx);
+ for (i = 0; i < nr; i++) {
+ unsigned char *ent = (idx_map + 4*256) + i * 24 + 4;
+ SHA1_Update(&ctx, ent, 20);
+ }
+ SHA1_Final(sha1, &ctx);
+
+ if (memcmp(sha1, packname, 20))
+ return error("pack index name %s does not match contents %s",
+ path, sha1_to_hex(sha1));
+
return 0;
}
--
1.0.GIT
^ permalink raw reply related
* Re: [PATCH] whatchanged: customize diff-tree output
From: Linus Torvalds @ 2005-12-22 6:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vvexhr6rc.fsf@assigned-by-dhcp.cox.net>
On Wed, 21 Dec 2005, Junio C Hamano wrote:
>
> 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.
I'm certainly ok with the short format by default. And making it
configurable per repo sounds fine, although at the same time I wonder if
that perhaps confuses people more (something that works in one project one
way works subtly differently in another project..)
Linus
^ permalink raw reply
* [PATCH] whatchanged: customize diff-tree output
From: Junio C Hamano @ 2005-12-22 6:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512212336230.18908@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> The output is much nicer on standard 80 columns. If you want the old
> behaviour, you can still do
>
> git-whatchanged --abbrev=40
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
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 configuration item whatchanged.difftree to
control the output from git-whatchanged command. For example:
[whatchanged]
difftree = --pretty=fuller --name-status -M
does rename detection, shows the commit header in "fuller"
format and lists modified pathnames with the kind of change
instead of the default hash pairs.
Not having the configuration item is the same as the original
output format (--pretty -r).
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-whatchanged.sh b/git-whatchanged.sh
index b170f74..b651b3f 100755
--- a/git-whatchanged.sh
+++ b/git-whatchanged.sh
@@ -4,9 +4,15 @@ USAGE='[-p] [--max-count=<n>] [<since>..
SUBDIRECTORY_OK='Yes'
. git-sh-setup
+diff_tree_flags=$(git-rev-parse --sq --no-revs --flags "$@")
+test -z "$diff_tree_flags" &&
+ diff_tree_flags=$(git-repo-config --get whatchanged.difftree)
+test -z "$diff_tree_flags" &&
+ diff_tree_flags='' # NEW DEFAULT HERE
+
rev_list_args=$(git-rev-parse --sq --default HEAD --revs-only "$@") &&
-diff_tree_args=$(git-rev-parse --sq --no-revs "$@") &&
+diff_tree_args=$(git-rev-parse --sq --no-revs --no-flags "$@") &&
eval "git-rev-list $rev_list_args" |
-eval "git-diff-tree --stdin --pretty -r $diff_tree_args" |
+eval "git-diff-tree --stdin --pretty -r $diff_tree_flags $diff_tree_args" |
LESS="$LESS -S" ${PAGER:-less}
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.0.0b quickfix
From: H. Peter Anvin @ 2005-12-22 4:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0d1u7ct.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> We could do 1.0.0 (base 1.0 release), 1.0.1 (instead of 1.0.0a),
> 1.0.2 (instead of 1.0.0b) on the "maint" branch and 1.1.0 to be
> next minor feature release. Do you like it better?
>
I think that would make sense.
-hpa
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.0.0b quickfix
From: Junio C Hamano @ 2005-12-22 3:40 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <43AA0C68.4030802@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
>>>Wouldn't it make more sense for the maintenance release to be 1.0.1?
>> Maybe. Nobody mentioned this about 0.99.9a, 0.99.9b... though.
>
> Yeah, well, the 0.99 bit in front kind of had made that hard to do.
Well, I could have done 0.99.9.1 instead of 0.99.9a.
>> The series 1.0.0[a-z] is meant to parallel 2.6.14.[123...]
>> "fixes only"; OTOH I'd like to allow 1.0.[123...] to contain
>> enhancements.
>
> Well, the Linux numbering scheme has gotten ridiculous, with the 2. in
> front having no meaning.
True.
We could do 1.0.0 (base 1.0 release), 1.0.1 (instead of 1.0.0a),
1.0.2 (instead of 1.0.0b) on the "maint" branch and 1.1.0 to be
next minor feature release. Do you like it better?
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.0.0b quickfix
From: H. Peter Anvin @ 2005-12-22 2:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsnqyqji.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>
>>Junio C Hamano wrote:
>>
>>>I've pushed out a v1.0.0b maint release to fix a bug in HTTP
>>>fetch that was discovered today X-<.
>>>
>>
>>Wouldn't it make more sense for the maintenance release to be 1.0.1?
>
>
> Maybe. Nobody mentioned this about 0.99.9a, 0.99.9b... though.
Yeah, well, the 0.99 bit in front kind of had made that hard to do.
> The series 1.0.0[a-z] is meant to parallel 2.6.14.[123...]
> "fixes only"; OTOH I'd like to allow 1.0.[123...] to contain
> enhancements.
Well, the Linux numbering scheme has gotten ridiculous, with the 2. in
front having no meaning.
-hpa
^ permalink raw reply
* Re: [PATCH] sanity check in add_packed_git()
From: Daniel Barkalow @ 2005-12-22 1:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git
In-Reply-To: <7v7j9xvrf3.fsf@assigned-by-dhcp.cox.net>
On Wed, 21 Dec 2005, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
>
> > add_packed_git() tries to get the pack SHA1 by parsing its name. It may
> > access uninitialized memory for packs with short names.
>
> Thanks.
>
> This fixes when there is ".git/objects/packs/junk-X.pack", so in
> that sense it is a real fix and I'll take it.
>
> However, I feel a bit uneasy about this whole thing. The core
> does not care how you name your packs, as long as .pack and .idx
> files have the same prefix, but we started relying on the prefix
> being "pack-" followed by 40 hexadecimal digits since we started
> packed repository support in http-fetch, and we also allowed
> sha1_pack_name() function that shares the assumption to sneak
> into the real core part of the system around the same time (end
> of July 2005). git-repack and git-verify-pack stay ignorant
> about this prefix convention and I think that is a good
> property. However, we might be better off if we declare that
> the pack files *must* be named following that convention
> (currently nobody enforces it, but as long as the user uses "git
> repack" to create packs, the packs automatically follow that
> convention), and make check_packed_git_idx() reject a packfile
> whose name does not begin with "pack-" or the 40 hexdigits that
> follow does not match the hash of the object names the index
> records. If we go that route, then this patch becomes unneeded;
> more extensive check needs to be done in check_packed_git_idx().
>
> Thoughts?
I'd like to require it to be a hash, just because that makes it
prohibitively difficult to make something people will accept as
pack-05f611b3b8198b262acdf678584d365f8e879aec.pack other than the one from
the git repository. Sure, it would only be a minor DoS and a bit of
confusion, because it still couldn't do any worse than contain some
different objects, but it would block people from getting the pack with
the objects they want. Since nobody seems interested in naming their
packs, so far as I know, it seems best to force the names to be
universally unique, modulo an incredible coincidence.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] sanity check in add_packed_git()
From: Junio C Hamano @ 2005-12-22 1:42 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, Daniel Barkalow
In-Reply-To: <1135208829.15567.18.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> add_packed_git() tries to get the pack SHA1 by parsing its name. It may
> access uninitialized memory for packs with short names.
Thanks.
This fixes when there is ".git/objects/packs/junk-X.pack", so in
that sense it is a real fix and I'll take it.
However, I feel a bit uneasy about this whole thing. The core
does not care how you name your packs, as long as .pack and .idx
files have the same prefix, but we started relying on the prefix
being "pack-" followed by 40 hexadecimal digits since we started
packed repository support in http-fetch, and we also allowed
sha1_pack_name() function that shares the assumption to sneak
into the real core part of the system around the same time (end
of July 2005). git-repack and git-verify-pack stay ignorant
about this prefix convention and I think that is a good
property. However, we might be better off if we declare that
the pack files *must* be named following that convention
(currently nobody enforces it, but as long as the user uses "git
repack" to create packs, the packs automatically follow that
convention), and make check_packed_git_idx() reject a packfile
whose name does not begin with "pack-" or the 40 hexdigits that
follow does not match the hash of the object names the index
records. If we go that route, then this patch becomes unneeded;
more extensive check needs to be done in check_packed_git_idx().
Thoughts?
^ permalink raw reply
* [PATCH] qgit: patchesStillToFind not initialized
From: Pavel Roskin @ 2005-12-22 1:19 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
Git::patchesStillToFind is not initialized on non-StGit repositories.
Found by Valgrind.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/src/git_startup.cpp b/src/git_startup.cpp
index 35dcaf7..307517f 100644
--- a/src/git_startup.cpp
+++ b/src/git_startup.cpp
@@ -473,6 +473,7 @@ bool Git::init(QString* repoDir, bool as
if (!startGetFileProc())
qDebug("ERROR: unable to start background git-diff-tree");
+ patchesStillToFind = 0;
if (isStGIT && !filteredLoading) { // updated by getRefs()
POST_MSG(msg1 + "StGIT patches...");
if (getStGITPatches()) {
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: [PATCH] Add suggestion to hard-to-understand error message
From: Junio C Hamano @ 2005-12-22 1:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512220048360.13453@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Dummies like me do not understand readily that "remote object abcdef...
> does not exist on local" means: "Hey, you did not pull this, did you?".
> So, add "(pull first?)" to that message.
I am ambivalent about this one. It is a special case of "remote
is not a strict subset of local" situation, so we might be
better if we just said the same as the other error message and
be done with it. On the other hand, the code does know the
difference of the two situations at this point, and it could be
argued that giving the same error is losing information.
Earlier I once rewound the "master" branch head by one commit
too much by mistake. The next push to the public server would
have given me a different error message, depending on whether I
pruned my private repository or not in between. For example,
after this sequence:
$ git commit -m 'initial'
$ git commit -m 'next'
$ git push remote master
$ git reset --hard HEAD^
$ git commit -m 'third but second'
If you do not prune at this point, then the remote commit "next"
still exists in the local repository (but not reachable). Then
$ git push remote master
would not say "pull first?". But if you prune local repository
before pushing, it would now say "pull first?".
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.".
^ permalink raw reply
* Re: [RFC] Add "write-index" hook
From: Johannes Schindelin @ 2005-12-22 0:35 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0512220055050.13515@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
there is an obvious bug in this patch: both calls to run_hook() have to
have a final NULL argument.
Ciao,
Dscho
P.S.: The reason I did not find this earlier was that I had hooks
installed, but they were not executable, and thus did not get executed.
D'oh!
^ permalink raw reply
* Re: [PATCH] cg-completion: improve options and command listing
From: Ben Clifford @ 2005-12-20 2:13 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Git List
In-Reply-To: <20051218143439.GA7064@diku.dk>
On 19 Dec 2005, at 00:04, Jonas Fonseca wrote:
>>
>> I'm interested by what you mean by 'all sorts of garbage' - it seems
>> ok on my machine.
>
> ~/src/cogito/cogito > __cg_cmdlist | head
> cg-add Add files to the GIT repository.
> cg-clean Clean unknown files from the working tree.
> cg-clone Clone a remote GIT repository.
I definitely don't get that here. Bleugh!
> Else I was thinking of maybe adding --list parameter to cg-help to
> have
> it list all known commands.
One thing that seemed kinda neat that I saw somewhere (perhaps in
darcs?) is that it will tab complete only commands that would make
sense in the present location (so cg <tab> would perhaps only bring
up 'init' and 'help' in a non-git directory) - that would be rather
more invasive to implement, I expect.
Another thing that has been mooted is autogenerating the completion
code based on USAGE info - I've had a hack about in the past with
that (its in the autogen branch in the gitcompletion repo on
hawaga.org.uk) but then I reached the point where it seemed too icky
for my tastes...
--
Ben • ベン • Бэн • 벤 • 班明
http://www.hawaga.org.uk/ben/
My email is high latency but best way to contact me. Alternatively,
SMS number(s) at above URL.
^ permalink raw reply
* Re: [PATCH] GIT: Support [address] in URLs
From: David S. Miller @ 2005-12-22 0:08 UTC (permalink / raw)
To: yoshfuji; +Cc: junkio, git, matti.aarnio
In-Reply-To: <20051222.085917.60400643.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Thu, 22 Dec 2005 08:59:17 +0900 (JST)
> Can I help you somehow?
> E.g. if you give me an account on vger, I happily try to find the way to
> setup bayesian filter(s) on them.
You are expert with Zmailer+Majordomo? :-)
Sure, it is no problem to setup Bayesian filter with sendmail, qmail,
Exim et al. with standard mailing list software. But doing it with
the Zmailer and Majordomo setup we have is non-trivial.
Matti, non-ascii filtering really becomes big enough pain enough to
fix. I can do the leg work if you can provide some pointers and
what you know so far.
Thanks.
^ 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