* 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
* Re: [PATCH] GIT: Support [address] in URLs
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-12-21 23:59 UTC (permalink / raw)
To: davem; +Cc: junkio, git, yoshfuji
In-Reply-To: <20051221.152648.122640664.davem@davemloft.net>
In article <20051221.152648.122640664.davem@davemloft.net> (at Wed, 21 Dec 2005 15:26:48 -0800 (PST)), "David S. Miller" <davem@davemloft.net> says:
> The vger.kernel.org spam filter filters out all non-ascii character
> sets. We have to do this because Matti and myself do all of the
> filtering by hand, and we do not understand so many languages as to be
> able to make sensible filters for spam in languages such as Japanese,
> Korean, Chinese, Russian, etc. so we just filter them all.
Too bad...
Well, I know some Japanese people kill all messages with non-Japanese
(usually English) subject... It is too bad, too...
> 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.
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.
Regards,
--yoshfuji
^ permalink raw reply
* [RFC] Add "write-index" hook
From: Johannes Schindelin @ 2005-12-21 23:56 UTC (permalink / raw)
To: git
This is a less hacky way to prevent index access than what I suggested
earlier. It has the additional benefit that you can control access to
the index writing now.
Oh, and the code to run hooks (which die() on errors) has been refactored.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
While the use of this hook is questionable, I actually like the
refactoring of the hooks, since it makes it so much easier
to add new ones.
index.c | 7 ++++++
receive-pack.c | 61 ++------------------------------------------------------
run-command.c | 49 +++++++++++++++++++++++++++++++++++++++++++++
run-command.h | 2 ++
4 files changed, 60 insertions(+), 59 deletions(-)
d567efd0ccfb60ae03a81f02f819283767d69011
diff --git a/index.c b/index.c
index ad0eafe..3f6ca1e 100644
--- a/index.c
+++ b/index.c
@@ -3,6 +3,7 @@
*/
#include <signal.h>
#include "cache.h"
+#include "run-command.h"
static struct cache_file *cache_file_list;
@@ -20,9 +21,15 @@ static void remove_lock_file_on_signal(i
remove_lock_file();
}
+static char write_index_hook[] = "hooks/write-index";
+
int hold_index_file_for_update(struct cache_file *cf, const char *path)
{
int fd;
+
+ if (run_hook(write_index_hook))
+ return error("hook declined to write index\n");
+
sprintf(cf->lockfile, "%s.lock", path);
fd = open(cf->lockfile, O_RDWR | O_CREAT | O_EXCL, 0666);
if (fd >=0 && !cf->next) {
diff --git a/receive-pack.c b/receive-pack.c
index cbe37e7..d52d793 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -59,36 +59,6 @@ static int verify_old_ref(const char *na
static char update_hook[] = "hooks/update";
-static int run_update_hook(const char *refname,
- char *old_hex, char *new_hex)
-{
- int code;
-
- if (access(update_hook, X_OK) < 0)
- return 0;
- code = run_command(update_hook, refname, old_hex, new_hex, NULL);
- switch (code) {
- case 0:
- return 0;
- case -ERR_RUN_COMMAND_FORK:
- die("hook fork failed");
- case -ERR_RUN_COMMAND_EXEC:
- die("hook execute failed");
- case -ERR_RUN_COMMAND_WAITPID:
- die("waitpid failed");
- case -ERR_RUN_COMMAND_WAITPID_WRONG_PID:
- die("waitpid is confused");
- case -ERR_RUN_COMMAND_WAITPID_SIGNAL:
- fprintf(stderr, "%s died of signal", update_hook);
- return -1;
- case -ERR_RUN_COMMAND_WAITPID_NOEXIT:
- die("%s died strangely", update_hook);
- default:
- error("%s exited with error code %d", update_hook, -code);
- return -code;
- }
-}
-
static int update(const char *name,
unsigned char *old_sha1, unsigned char *new_sha1)
{
@@ -133,7 +103,7 @@ static int update(const char *name,
unlink(lock_name);
return error("%s changed during push", name);
}
- if (run_update_hook(name, old_hex, new_hex)) {
+ if (run_hook(update_hook, name, old_hex, new_hex)) {
unlink(lock_name);
return error("hook declined to update %s\n", name);
}
@@ -149,33 +119,6 @@ static int update(const char *name,
static char update_post_hook[] = "hooks/post-update";
-static void run_update_post_hook(struct command *cmd)
-{
- struct command *cmd_p;
- int argc;
- char **argv;
-
- if (access(update_post_hook, X_OK) < 0)
- return;
- for (argc = 1, cmd_p = cmd; cmd_p; cmd_p = cmd_p->next) {
- if (!cmd_p->updated)
- continue;
- argc++;
- }
- argv = xmalloc(sizeof(*argv) * (1 + argc));
- argv[0] = update_post_hook;
-
- for (argc = 1, cmd_p = cmd; cmd_p; cmd_p = cmd_p->next) {
- if (!cmd_p->updated)
- continue;
- argv[argc] = xmalloc(strlen(cmd_p->ref_name) + 1);
- strcpy(argv[argc], cmd_p->ref_name);
- argc++;
- }
- argv[argc] = NULL;
- run_command_v_opt(argc, argv, RUN_COMMAND_NO_STDIO);
-}
-
/*
* This gets called after(if) we've successfully
* unpacked the data payload.
@@ -189,7 +132,7 @@ static void execute_commands(void)
cmd->old_sha1, cmd->new_sha1);
cmd = cmd->next;
}
- run_update_post_hook(commands);
+ run_hook(update_post_hook, commands);
}
static void read_head_info(void)
diff --git a/run-command.c b/run-command.c
index 8bf5922..95455ef 100644
--- a/run-command.c
+++ b/run-command.c
@@ -67,3 +67,52 @@ int run_command(const char *cmd, ...)
return error("too many args to run %s", cmd);
return run_command_v_opt(argc, argv, 0);
}
+
+int run_hook(const char* hook, ...)
+{
+ int argc;
+ char *argv[MAX_RUN_COMMAND_ARGS];
+ const char *arg;
+ va_list param;
+ int code;
+
+ if (access(hook, X_OK) < 0)
+ return 0;
+
+ va_start(param, hook);
+ argv[0] = (char*) hook;
+ argc = 1;
+ while (argc < MAX_RUN_COMMAND_ARGS) {
+ arg = argv[argc++] = va_arg(param, char *);
+ if (!arg)
+ break;
+ }
+ va_end(param);
+ if (MAX_RUN_COMMAND_ARGS <= argc)
+ return error("too many args to run %s", hook);
+
+ code = run_command_v_opt(argc, argv, 0);
+
+ switch (code) {
+ case 0:
+ return 0;
+ case -ERR_RUN_COMMAND_FORK:
+ die("hook fork failed");
+ case -ERR_RUN_COMMAND_EXEC:
+ die("hook execute failed");
+ case -ERR_RUN_COMMAND_WAITPID:
+ die("waitpid failed");
+ case -ERR_RUN_COMMAND_WAITPID_WRONG_PID:
+ die("waitpid is confused");
+ case -ERR_RUN_COMMAND_WAITPID_SIGNAL:
+ fprintf(stderr, "%s died of signal", hook);
+ return -1;
+ case -ERR_RUN_COMMAND_WAITPID_NOEXIT:
+ die("%s died strangely", hook);
+ default:
+ error("%s exited with error code %d", hook, -code);
+ return -code;
+ }
+}
+
+
diff --git a/run-command.h b/run-command.h
index 2469eea..604176f 100644
--- a/run-command.h
+++ b/run-command.h
@@ -16,5 +16,7 @@ enum {
int run_command_v_opt(int argc, char **argv, int opt);
int run_command_v(int argc, char **argv);
int run_command(const char *cmd, ...);
+/* unlike run_command(), run_hook die()s on errors */
+int run_hook(const char *hook, ...);
#endif
--
1.0.0
^ permalink raw reply related
* [PATCH] Add suggestion to hard-to-understand error message
From: Johannes Schindelin @ 2005-12-21 23:49 UTC (permalink / raw)
To: git, junkio
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.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Wow, my commit messages get longer, while the patches get shorter.
Odd.
send-pack.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
af2d86726fe961043d0c69c4fb727689a5903b63
diff --git a/send-pack.c b/send-pack.c
index 5bc2f01..643662a 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -233,7 +233,7 @@ static int send_pack(int in, int out, in
!ref->force) {
if (!has_sha1_file(ref->old_sha1)) {
error("remote '%s' object %s does not "
- "exist on local",
+ "exist on local (pull first?)",
ref->name, sha1_to_hex(ref->old_sha1));
ret = -2;
continue;
--
0.99.9.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