* Re: [PATCH] [COGITO] make cg-tag use git-check-ref-format
From: Junio C Hamano @ 2005-12-16 2:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: Alex Riesen, git
In-Reply-To: <7vacf2lyn4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> The wildcard letters like ? and * I understand and sympathetic
> about somewhat. Something like this:
>
> name="*.sh" ;# this also comes from the end user
> echo $name
>
> ends up showing every shell script in the current directory,
> and not literal '*.sh'.
So why don't we do this?
-- >8 --
Subject: [PATCH] Forbid pattern maching characters in refnames.
by marking '?', '*', and '[' as bad_ref_char().
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-check-ref-format.txt | 8 +++++---
refs.c | 4 +++-
2 files changed, 8 insertions(+), 4 deletions(-)
d04ec25a77249095b6d2af5a08fe131351f2d86d
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index 636e951..f7f84c6 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -26,13 +26,15 @@ imposes the following rules on how refs
. It cannot have ASCII control character (i.e. bytes whose
values are lower than \040, or \177 `DEL`), space, tilde `~`,
- caret `{caret}`, or colon `:` anywhere;
+ caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`,
+ or open bracket `[` anywhere;
. It cannot end with a slash `/`.
These rules makes it easy for shell script based tools to parse
-refnames, and also avoids ambiguities in certain refname
-expressions (see gitlink:git-rev-parse[1]). Namely:
+refnames, pathname expansion by the shell when a refname is used
+unquoted (by mistake), and also avoids ambiguities in certain
+refname expressions (see gitlink:git-rev-parse[1]). Namely:
. double-dot `..` are often used as in `ref1..ref2`, and in some
context this notation means `{caret}ref1 ref2` (i.e. not in
diff --git a/refs.c b/refs.c
index b8fcb98..0d63c1f 100644
--- a/refs.c
+++ b/refs.c
@@ -313,7 +313,9 @@ int write_ref_sha1(const char *ref, int
static inline int bad_ref_char(int ch)
{
return (((unsigned) ch) <= ' ' ||
- ch == '~' || ch == '^' || ch == ':');
+ ch == '~' || ch == '^' || ch == ':' ||
+ /* 2.13 Pattern Matching Notation */
+ ch == '?' || ch == '*' || ch == '[');
}
int check_ref_format(const char *ref)
--
0.99.9.GIT
^ permalink raw reply related
* Re: [RFC] faking cvs annotate
From: Junio C Hamano @ 2005-12-16 1:42 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90512151713i118e58acia466d0f65ff91383@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> Suggestions of GIT machinery that would shortcut the trip from
>
> git-rev-list HEAD $path
>
> to a annotate-ish output. Did I dream it or is qgit showing something
> annotate-ish in its screenshots?
I haven't actively done anything but one of the good things that
could happen is to split out the access routines for annotate
database qgit build when run the first time in the repository,
and make them available to other Porcelains. There is no need
to reinvent the wheel.
^ permalink raw reply
* Re: [PATCH] We do not like "HEAD" as a new branch name
From: Johannes Schindelin @ 2005-12-16 1:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q5alyms.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 15 Dec 2005, Junio C Hamano wrote:
> Just to futureproof ourselves, how about this?
>
> /^(?:.*/)?(?:[A-Z0-9]+_)?HEAD$/
>
> The last path component being "HEAD" or capital-or-digit
> followed by underscore followed by "HEAD".
Okay. Why not go the full nine yards, and not be difficult about it:
diff --git a/refs.c b/refs.c
--- a/refs.c
+++ b/refs.c
@@ -345,6 +345,11 @@ int check_ref_format(const char *ref)
if (!ch) {
if (level < 2)
return -1; /* at least of form "heads/blah" */
+
+ /* do not allow ref name to end in "HEAD" */
+ if (cp - ref > 4 && !strcmp(cp - 4, "HEAD"))
+ return -1;
+
return 0;
}
}
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] faking cvs annotate
From: Johannes Schindelin @ 2005-12-16 1:31 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90512151713i118e58acia466d0f65ff91383@mail.gmail.com>
Hi,
On Fri, 16 Dec 2005, Martin Langhoff wrote:
> I know, I know, use pickaxe :-)
>
> Any suggestions as to how to implement a not-too-slow annotate that
> looks reasonable enough so as to fool real cvs clients?
For starters, you could use my attempt:
http://www.gelato.unsw.edu.au/archives/git/0508/7171.html
It does not fool any CVS user, because it does not fake version numbers.
Instead, you can display SHA1s, short SHA1s, author names, or mixtures
thereof.
However, I learnt to use git-whatchanged in the meantime, and I'll
probably never go back.
Hth,
Dscho
^ permalink raw reply
* [RFC] faking cvs annotate
From: Martin Langhoff @ 2005-12-16 1:13 UTC (permalink / raw)
To: Git Mailing List
I know, I know, use pickaxe :-)
Any suggestions as to how to implement a not-too-slow annotate that
looks reasonable enough so as to fool real cvs clients? Let's assume
I'll have the "per-file-version numbers" to translate commit SHA1s
into cvs-ish version numbers in a magic hat, right next to the fluffy
bunnies.
Suggestions of GIT machinery that would shortcut the trip from
git-rev-list HEAD $path
to a annotate-ish output. Did I dream it or is qgit showing something
annotate-ish in its screenshots?
Note! Just told a white lie: I won't be actually using git-rev-list.
Instead, I'll have a rev list that will gloss over branched
development, picking only one "path" of the history every time
(initially using the algorithm formerly known as rand() ) , and
showing merge commits as one.
cheers,
martin
^ permalink raw reply
* Re: qgit reports errors in the git repository
From: Pavel Roskin @ 2005-12-16 0:35 UTC (permalink / raw)
To: Marco Costalba; +Cc: Linus Torvalds, git, Marco Costalba
In-Reply-To: <e5bfff550512151100k33a66db5tdb2eb1ff2da10a59@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3775 bytes --]
On Thu, 2005-12-15 at 20:00 +0100, Marco Costalba wrote:
> Yes! this is a bug.
> Thanks for the patch, applied.
Actually, the qgit git repository appear to be broken right now. First
of all, requests to missing files return code 200 rather that 404.
git-http-fetch crashes trying to parse the returned page as alternates.
I've fixed it.
It's a hack, not a signed patch, please be cautious:
diff --git a/http-fetch.c b/http-fetch.c
index ad59f1c..2767676 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -520,6 +520,8 @@ static void process_alternates_response(
}
}
// skip 'objects' at end
+ okay &= (posn - i > 8);
+ okay &= (strncmp(data + posn - 8, "/objects", 8) == 0);
if (okay) {
target = xmalloc(serverlen + posn - i - 6);
strncpy(target, base, serverlen);
@@ -601,7 +603,7 @@ static void fetch_alternates(char *base)
else
got_alternates = -1;
- free(data);
+// free(data);
free(url);
}
The free() was commented out because glibc detects double free and
prints backtrace. It's Fedora Core 4 on x86_64, all up-to-date. I
don't see where "data" is freed, maybe it's a bug in glibc.
Even clean fetch of qgit doesn't work:
$ cg-clone http://digilander.libero.it/mcostalba/qgit.git
defaulting to local storage area
Fetching head...
Fetching objects...
progress: 8 objects, 12858 bytes
error: File 8fef66ee82bcbbc26426d21e537478867f648e12 (http://digilander.libero.it/mcostalba/qgit.git/objects/fc/0712e55de18eda32aee44bd7863fee37fc83aa) corrupt
Getting pack list for http://digilander.libero.it/mcostalba/qgit.git/
progress: 11 objects, 76091 bytes
Getting alternates list for http://digilander.libero.it/mcostalba/qgit.git/
error: Unable to find fc0712e55de18eda32aee44bd7863fee37fc83aa under http://digilander.libero.it/mcostalba/qgit.git/
Cannot obtain needed commit fc0712e55de18eda32aee44bd7863fee37fc83aa
while processing commit 5013d718eea0b19a28faebf93eade68127f4b2b4.
Waiting for http://digilander.libero.it/mcostalba/qgit.git/objects/20/35781249a0d6c788e4aef07432c335d9694b9b
progress: 12 objects, 80655 bytes
cg-fetch: objects fetch failed
cg-clone: fetch failed
Anyway, I'm using the latest revision I could get,
9e5ccecbef2a9cb4b75887791b410c0e07d630cc.
> Unfortunatly, regarding the main question on git-cat-file I cannot
> reproduce the bug.
I've made a clean checkout of git using git-fetch:
git-clone git://www.kernel.org/pub/scm/git/git.git
Now qgit complains about 1ed91937e5cd59fdbdfa5f15f6fac132d2b21ce0.
> The problem is that on my box the object
> 23ea3e201cea0deea909569e08e950a9ec2345f7 is
> _never_ fed to git-cat-file because is filtered out ending with "^{}"
> git-ls-remote ./.git |grep 23ea3e201cea0deea909569e08e950a9ec2345f7
> 23ea3e201cea0deea909569e08e950a9ec2345f7 refs/tags/v0.99.9g^{}
Same for me.
> The corresponding tag feeded to git-cat-file is
> bd67d7d845eb5ae929306dadd3dff41cf04ce004
>
> I have just made a
> git pull
> git fetch --tags
>
> from git repository.
OK, "git fetch --tags" made the difference for the old repository! Now
it also complains about 1ed91937e5cd59fdbdfa5f15f6fac132d2b21ce0.
I was using cogito only on the old repository. I think cogito doesn't
run "git fetch --tags" or anything equivalent.
> So, please, test with this:
>
> --- a/src/git_startup.cpp
> +++ b/src/git_startup.cpp
> @@ -111,6 +111,7 @@ bool Git::getRefs() {
>
> if (itNext != rLst.constEnd() && (*itNext).right(3) == "^{}")
> {
> signedTag = true;
> + dbg(refSha);
> if (run("git-cat-file tag " + refSha, &runOutput)) {
> QString msg(runOutput.section("\n\n", 1));
> if (!msg.isEmpty())
>
> and send me the output. Mine is
[skip]
Both are attached.
--
Regards,
Pavel Roskin
[-- Attachment #2: log.new --]
[-- Type: text/plain, Size: 2268 bytes --]
refSha is <a0e7d36193b96f552073558acf5fcc1f10528917>
refSha is <f25a265a342aed6041ab0cc484224d9ca54b6f41>
refSha is <c5db5456ae3b0873fc659c19fafdde22313cc441>
refSha is <7ceca275d047c90c0c7d5afb13ab97efdf51bd6e>
refSha is <b3e9704ecdf48869f635f0aa99ddfb513f885aff>
refSha is <07e38db6a5a03690034d27104401f6c8ea40f1fc>
refSha is <f12e22d4c12c3d0263fa681f25c06569f643da0f>
refSha is <f8696fcd2abc446a5ccda3e414b731eff2a7e981>
refSha is <1094cf40f7029f803421c1dcc971238507c830c5>
refSha is <da30c6c39cd3b048952a15929c5440acfd71b912>
refSha is <9165ec17fde255a1770886189359897dbb541012>
refSha is <02b2acff8bafb6d73c6513469cdda0c6c18c4138>
refSha is <b041895af323bdef10cc9a718bda468ba3622bc0>
refSha is <cfc2ea6116410a545573d5fa5311d3c3b2df69d1>
refSha is <0b122201af0afb6a6a8059ff446a1e26b1d0c823>
refSha is <d186f3d21148f373a5ea5e43804f5f6707670a87>
refSha is <48055bb38d650ab39957ed07d640469176c12419>
refSha is <b79a5a49c9e412e27a336e705fb7b462367f4c16>
refSha is <ebd5d002da3f6cfbd0aa3ff5b5c4a9d9eeee630d>
refSha is <08f9f32076455ff75b59b41d7003927869082a3f>
refSha is <67b4b78858d9d9dd044f758a90a4270e48543cf1>
refSha is <c512b0344196931ad3a9a049eb3f5d3f05b09328>
refSha is <3d65a838c77f816527acf84c899419eb6825dcee>
refSha is <3521017556c5de4159da4615a39fa4d5d2c279b5>
refSha is <107e3d2b4d5b9ecd9a15a23ad1c64652b8b67ba9>
refSha is <10e5ae69eb6cdcdd149bb23e1e73131adf4ab3b7>
refSha is <b685b14cd9385e8b0f5742ebcd35ef8c8c12ec4d>
refSha is <bd67d7d845eb5ae929306dadd3dff41cf04ce004>
refSha is <5c857638d55bdd575d3f38bf3b99f1a2f99d3e46>
refSha is <4a6a394c62f33a3bf94badd6b14bc1f48647905f>
refSha is <c0f7d44ecba75d54a73ba542adde0ff80d2da03a>
refSha is <0c675e9d0b5f5d1fbb7b0169d71769993b225701>
refSha is <ca6cec9c5843d85d23b1184d584a11699d92e927>
refSha is <93ea4a9599564101be20507a3a756d38427a70ac>
refSha is <71c1a700da60da8cf99d586cc618c46fef201ed1>
refSha is <1ed91937e5cd59fdbdfa5f15f6fac132d2b21ce0>
refSha is <5f4cd4ca015dc795b9f7f4fed11b3f80a60ac175>
refSha is <112c4fd6b3fe400a075d575c0fe1a583aafe8f2c>
refSha is <dcd118f6b933d7a81739c3c4269e2bf4654e4a99>
refSha is <055e4ae3ae6eb344cbabf2a5256a49ea66040131>
refSha is <2d2846cd06fce719c35b58a8b81f7ae42f1986ca>
refSha is <781aab17fe544cbfcaba0f0ea5cacf7672717236>
[-- Attachment #3: log.old --]
[-- Type: application/x-trash, Size: 1590 bytes --]
^ permalink raw reply related
* Re: bad git pull
From: Junio C Hamano @ 2005-12-15 23:53 UTC (permalink / raw)
To: Don Zickus; +Cc: git
In-Reply-To: <7vzmn2kjw1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Don Zickus <dzickus@gmail.com> writes:
>
>> I notice if I create a branch (and switch to it) in the linux kernel
>> off of say version 2.6.14, then later do a git pull, things get ugly.
>> It seems like all the upstream changes are being merged into the
>> 2.6.14 branch (instead of the latest kernel tag).
>>
>> Is this a user error because the tool is still fragile?
>
> I do not understand the question.
>
> The user wanted all the good developments from the mainline into
> the fork he created starting at 2.6.14, and the tool did what
> was asked. Why would you want to forbid that from happening,
> and what did you want to happen instead?
Actually I think I do understand the question. You have a clone
of linux-2.6 repository, and your "origin" branch tracks the
bleeding edge from Linus. You also have "myhack" branch that
was forked off from 2.6.14, and wanted to see what new things
Linus has by updating "origin", and perhaps merge those changes
into your "master" which keeps track of your hacks based on
Linus tip, but unfortunately you were on "myhack" branch.
Ouch.
So what you wanted to do was probably:
$ git fetch ;# this updates "origin" to Linus tip
instead of
$ git pull ;# this updates "origin" to Linus tip *and*
# merges that into the current branch
As you may probably know, you can recover by
$ git reset --hard
While I am sympathetic, this "Oops, I said pull when I meant
fetch" sounds remotely similar to "oops, I said 'rm -r' when I
meant to say 'ls -r'". Is it that the tool is too fragile?
^ permalink raw reply
* Re: bad git pull
From: Junio C Hamano @ 2005-12-15 23:42 UTC (permalink / raw)
To: Don Zickus; +Cc: git
In-Reply-To: <68948ca0512151537v2d8f22c8x962c55bd507af8cf@mail.gmail.com>
Don Zickus <dzickus@gmail.com> writes:
> I notice if I create a branch (and switch to it) in the linux kernel
> off of say version 2.6.14, then later do a git pull, things get ugly.
> It seems like all the upstream changes are being merged into the
> 2.6.14 branch (instead of the latest kernel tag).
>
> Is this a user error because the tool is still fragile?
I do not understand the question.
The user wanted all the good developments from the mainline into
the fork he created starting at 2.6.14, and the tool did what
was asked. Why would you want to forbid that from happening,
and what did you want to happen instead?
^ permalink raw reply
* Re: [PATCH] We do not like "HEAD" as a new branch name
From: Junio C Hamano @ 2005-12-15 23:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512152339530.4962@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Okay, I think this is what *I* would want to be illegal:
>
> HEAD,
> ORIG_HEAD,
> FETCH_HEAD
> MERGE_HEAD
>
> Others? Or should I really test for just *anything* ending in _HEAD
> besides HEAD itself?
Just to futureproof ourselves, how about this?
/^(?:.*/)?(?:[A-Z0-9]+_)?HEAD$/
The last path component being "HEAD" or capital-or-digit
followed by underscore followed by "HEAD".
^ permalink raw reply
* Re: [PATCH] [COGITO] make cg-tag use git-check-ref-format
From: Junio C Hamano @ 2005-12-15 23:38 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20051215222424.GA3094@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Junio C Hamano, Tue, Dec 13, 2005 19:41:27 +0100:
>>
>> > Thank you both for the patch, but I'd be much more comfortable if at
>> > least quotes (both ' and "), backslashes, ? and * would be prohibited in
>> > the names as well.
>>
>> I second that, and thanks for pointing it out. Any objections?
>
> Just as a warning, perhaps? It's not like git is anywhere limited in
> this respect...
Yeah, after thinking about it a bit more, I changed my mind.
The wildcard letters like ? and * I understand and sympathetic
about somewhat. Something like this:
name="*.sh" ;# this also comes from the end user
echo $name
ends up showing every shell script in the current directory,
and not literal '*.sh'.
However, I do not think covering five characters '"\?* gives us
anything, and sends a strong message that we do not know our
shell programming to whoever is reading our code. For one
thing, the user can still say "foo[a-z]bar" to confuse you, so
you also need to forbid [].
The thing is, if you start to care about single and double
quotes, then what you are doing carelessly is not something
simple like this:
name='frotz'\''nitfol"filfre\xyzzy' ;# this comes from the end user.
echo $name ;# and this prints just fine.
For quotes to matter, you must be doing an "eval" carelessly,
and "eval" and careless should never go together.
# do not try this in your repository without echo
name="foo; echo rm -fr ."
eval "git-rev-parse $name"
You end up needing to forbid a lot more than the quoting and
wildcard, if you want to keep your shell scripts loose and lazy;
which may be a worthy goal in itself but pretty much defeats the
initial discussion of "why do we allow only these characters in
tags".
So in short, I am somewhat negative about the idea of adding
more "forbidden letters". Let's make sure our scripts are
careful where safety matters.
Note that this does not forbid Porcelains to enforce additional
restrictions on their own.
^ permalink raw reply
* bad git pull
From: Don Zickus @ 2005-12-15 23:37 UTC (permalink / raw)
Cc: git, junkio
Hello,
I notice if I create a branch (and switch to it) in the linux kernel
off of say version 2.6.14, then later do a git pull, things get ugly.
It seems like all the upstream changes are being merged into the
2.6.14 branch (instead of the latest kernel tag).
Is this a user error because the tool is still fragile?
Thanks,
Don
^ permalink raw reply
* [PATCH 3/3] git-whatchanged: Add usage string
From: Fredrik Kuivinen @ 2005-12-15 22:48 UTC (permalink / raw)
To: git; +Cc: junkio
In-Reply-To: <20051215224350.GB14388@c165.ib.student.liu.se>
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-whatchanged.sh | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
1d3bc689dd66918b27432ad868592c9cc557f926
diff --git a/git-whatchanged.sh b/git-whatchanged.sh
index 85a49fc..b170f74 100755
--- a/git-whatchanged.sh
+++ b/git-whatchanged.sh
@@ -1,4 +1,9 @@
#!/bin/sh
+
+USAGE='[-p] [--max-count=<n>] [<since>..<limit>] [--pretty=<format>] [-m] [git-diff-tree options] [git-rev-list options]'
+SUBDIRECTORY_OK='Yes'
+. git-sh-setup
+
rev_list_args=$(git-rev-parse --sq --default HEAD --revs-only "$@") &&
diff_tree_args=$(git-rev-parse --sq --no-revs "$@") &&
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 2/3] git-log: Add usage string
From: Fredrik Kuivinen @ 2005-12-15 22:48 UTC (permalink / raw)
To: git; +Cc: junkio
In-Reply-To: <20051215224350.GB14388@c165.ib.student.liu.se>
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-log.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
381a6c62ad8e735de6122127c7684e8a14f41676
diff --git a/git-log.sh b/git-log.sh
index b36c4e9..c2ea71c 100755
--- a/git-log.sh
+++ b/git-log.sh
@@ -3,13 +3,13 @@
# Copyright (c) 2005 Linus Torvalds
#
-# This one uses only subdirectory-aware commands, so no need to
-# include sh-setup-script.
+USAGE='[--max-count=<n>] [<since>..<limit>] [--pretty=<format>] [git-rev-list options]'
+SUBDIRECTORY_OK='Yes'
+. git-sh-setup
revs=$(git-rev-parse --revs-only --no-flags --default HEAD "$@") || exit
[ "$revs" ] || {
- echo >&2 "No HEAD ref"
- exit 1
+ die "No HEAD ref"
}
git-rev-list --pretty $(git-rev-parse --default HEAD "$@") |
LESS=-S ${PAGER:-less}
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 1/3] git-diff: Usage string clean-up
From: Fredrik Kuivinen @ 2005-12-15 22:47 UTC (permalink / raw)
To: git; +Cc: junkio
In-Reply-To: <20051215224350.GB14388@c165.ib.student.liu.se>
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-diff.sh | 14 ++++++--------
1 files changed, 6 insertions(+), 8 deletions(-)
ca73d87d08c8c3702495694cc1080112c4c34ba1
diff --git a/git-diff.sh b/git-diff.sh
index b62e583..4812ae4 100755
--- a/git-diff.sh
+++ b/git-diff.sh
@@ -3,15 +3,14 @@
# Copyright (c) 2005 Linus Torvalds
# Copyright (c) 2005 Junio C Hamano
+USAGE='[ --diff-options ] <ent>{0,2} [<path>...]'
+SUBDIRECTORY_OK='Yes'
+. git-sh-setup
+
rev=$(git-rev-parse --revs-only --no-flags --sq "$@") || exit
flags=$(git-rev-parse --no-revs --flags --sq "$@")
files=$(git-rev-parse --no-revs --no-flags --sq "$@")
-die () {
- echo >&2 "$*"
- exit 1
-}
-
# I often say 'git diff --cached -p' and get scolded by git-diff-files, but
# obviously I mean 'git diff --cached -p HEAD' in that case.
case "$rev" in
@@ -40,8 +39,7 @@ esac
case "$rev" in
?*' '?*' '?*)
- echo >&2 "I don't understand"
- exit 1
+ usage
;;
?*' '^?*)
begin=$(expr "$rev" : '.*^.\([0-9a-f]*\).*') &&
@@ -58,7 +56,7 @@ case "$rev" in
cmd="git-diff-files $flags -- $files"
;;
*)
- die "I don't understand $*"
+ usage
;;
esac
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 0/3] Usage string clean-up (diff, log and whatchanged)
From: Fredrik Kuivinen @ 2005-12-15 22:43 UTC (permalink / raw)
To: git; +Cc: junkio
Hi,
Apparently I forgot those commands in the previous patch series.
git-diff.sh | 14 ++++++--------
git-log.sh | 8 ++++----
git-whatchanged.sh | 5 +++++
3 files changed, 15 insertions(+), 12 deletions(-)
- Fredrik
^ permalink raw reply
* Re: [PATCH] We do not like "HEAD" as a new branch name
From: Johannes Schindelin @ 2005-12-15 22:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacf2p320.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 15 Dec 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > + /* do not allow "HEAD" as ref name */
> > + if (ch == 'H' && (!strcmp(cp, "EAD") ||
> > + !strncmp(cp, "EAD/", 4)))
>
> Why forbid HEAD in the middle, like "refs/heads/HEAD/frotz"?
> Confusion avoidance?
Exactly.
> We might want to forbid anything that matches /^.*_?HEAD$/ to catch
> ORIG_HEAD for example, though.
Okay, I think this is what *I* would want to be illegal:
HEAD,
ORIG_HEAD,
FETCH_HEAD
MERGE_HEAD
Others? Or should I really test for just *anything* ending in _HEAD
besides HEAD itself?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] [COGITO] make cg-tag use git-check-ref-format
From: Alex Riesen @ 2005-12-15 22:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vu0dcalgo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Tue, Dec 13, 2005 19:41:27 +0100:
>
> > Thank you both for the patch, but I'd be much more comfortable if at
> > least quotes (both ' and "), backslashes, ? and * would be prohibited in
> > the names as well.
>
> I second that, and thanks for pointing it out. Any objections?
Just as a warning, perhaps? It's not like git is anywhere limited in
this respect...
^ permalink raw reply
* Re: [PATCH 5/11] git-applypatch: Usage string clean-up, emit usage string at incorrect invocation
From: Junio C Hamano @ 2005-12-15 20:42 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <43A1D24B.5070603@gmail.com>
Marco Costalba <mcostalba@gmail.com> writes:
> This patch seems not working for me:
>
> -[[ "$#" = "3" || "$#" = "4" ]] || usage
> +case "$#" in 3|4) usage ;; esac
I am an idiot. Thanks. That should have read "3|4) ;; *)
usage", obviously.
^ permalink raw reply
* Re: [PATCH 5/11] git-applypatch: Usage string clean-up, emit usage string at incorrect invocation
From: Marco Costalba @ 2005-12-15 20:30 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Timo Hirvonen, Junio C Hamano, git
In-Reply-To: <20051215195528.GA14388@c165.ib.student.liu.se>
Fredrik Kuivinen wrote:
> On Wed, Dec 14, 2005 at 02:45:42PM +0200, Timo Hirvonen wrote:
>
>>On Tue, 13 Dec 2005 21:20:57 -0800
>>Junio C Hamano <junkio@cox.net> wrote:
>>
>>
>>>freku045@student.liu.se writes:
>>>
>>>
>>>> . git-sh-setup
>>>>
>>>>+[[ "$#" = "3" || "$#" = "4" ]] || usage
>>>>+
>>>
>>>I do not see much advantage to use [[...]] construct here.
>>
>>[[ ]] is bashishm. Does not work with ash.
>>
>>
>>test $# -ge 3 && test $# -le 4 || usage
>>
>>You don't need to quote $# because it is always defined (and always
>>non-negative integer). You can't unset or set it.
>
>
This patch seems not working for me:
$ git-applymbox -k 0001-JUST-A-TEST.txt
1 patch(es) to process.
Usage: /home/marco/bin/git-applypatch <msg> <patch> <info> [<signoff>]
where
$ cat 0001-JUST-A-TEST.txt
From nobody Mon Sep 17 00:00:00 2001
Subject: [PATCH] JUST A TEST
From: Marco Costalba <mcostalba@gmail.com>
Date: 1134677832 +0100
---
git-applypatch.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
ee8ea125fd2b0598e26e1556210abb9d0edc459a
diff --git a/git-applypatch.sh b/git-applypatch.sh
index e8ba34a..26b4cba 100755
--- a/git-applypatch.sh
+++ b/git-applypatch.sh
@@ -10,7 +10,7 @@
## $3 - "info" file with Author, email and subject
## $4 - optional file containing signoff to add
##
-
+## JUST A TEST
USAGE='<msg> <patch> <info> [<signoff>]'
. git-sh-setup
--
0.99.9.GIT
The offending patch is
Author: Junio C Hamano <junkio@cox.net>
Date: 14/12/2005 03:19:12
Parent: git-repack: Usage string clean-up, emit usage at incorrec...
applypatch: no need to do non-portable [[ ... ]]
... when old, proven, case would do.
Signed-off-by: Junio C Hamano <junkio@cox.net>
--- a/git-applypatch.sh
+++ b/git-applypatch.sh
@@ -14,7 +14,7 @@
USAGE='<msg> <patch> <info> [<signoff>]'
. git-sh-setup
-[[ "$#" = "3" || "$#" = "4" ]] || usage
+case "$#" in 3|4) usage ;; esac
final=.dotest/final-commit
##
reverting the patch everything works fine.
Marco
^ permalink raw reply related
* Re: [PATCH 5/11] git-applypatch: Usage string clean-up, emit usage string at incorrect invocation
From: Fredrik Kuivinen @ 2005-12-15 19:55 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: Junio C Hamano, freku045, git
In-Reply-To: <20051214144542.0a509e3e.tihirvon@gmail.com>
On Wed, Dec 14, 2005 at 02:45:42PM +0200, Timo Hirvonen wrote:
> On Tue, 13 Dec 2005 21:20:57 -0800
> Junio C Hamano <junkio@cox.net> wrote:
>
> > freku045@student.liu.se writes:
> >
> > > . git-sh-setup
> > >
> > > +[[ "$#" = "3" || "$#" = "4" ]] || usage
> > > +
> >
> > I do not see much advantage to use [[...]] construct here.
>
> [[ ]] is bashishm. Does not work with ash.
>
>
> test $# -ge 3 && test $# -le 4 || usage
>
> You don't need to quote $# because it is always defined (and always
> non-negative integer). You can't unset or set it.
Thanks. I guess this is what happens when you try to learn sh
programming from the bash manpage. :)
- Fredrik
^ permalink raw reply
* Re: [PATCH] We do not like "HEAD" as a new branch name
From: Junio C Hamano @ 2005-12-15 19:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512151244230.22400@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> + /* do not allow "HEAD" as ref name */
> + if (ch == 'H' && (!strcmp(cp, "EAD") ||
> + !strncmp(cp, "EAD/", 4)))
Why forbid HEAD in the middle, like "refs/heads/HEAD/frotz"?
Confusion avoidance?
We might want to forbid anything that matches /^.*_?HEAD$/ to catch
ORIG_HEAD for example, though.
^ permalink raw reply
* [Fwd: Re: qgit reports errors in the git repository]
From: Marco Costalba @ 2005-12-15 19:16 UTC (permalink / raw)
To: git
On 12/15/05, Pavel Roskin <proski@gnu.org> wrote:
>
> Hello, Marco.
> qgit doesn't print its command line at all when running commands
> synchronously.
Hi Pavel,
Yes! this is a bug.
Thanks for the patch, applied.
Unfortunatly, regarding the main question on git-cat-file I cannot reproduce
the bug.
The problem is that on my box the object
23ea3e201cea0deea909569e08e950a9ec2345f7 is
_never_ fed to git-cat-file because is filtered out ending with "^{}"
git-ls-remote ./.git |grep 23ea3e201cea0deea909569e08e950a9ec2345f7
23ea3e201cea0deea909569e08e950a9ec2345f7 refs/tags/v0.99.9g^{}
The corresponding tag feeded to git-cat-file is
bd67d7d845eb5ae929306dadd3dff41cf04ce004
I have just made a
git pull
git fetch --tags
from git repository.
So, please, test with this:
--- a/src/git_startup.cpp
+++ b/src/git_startup.cpp
@@ -111,6 +111,7 @@ bool Git::getRefs() {
if (itNext != rLst.constEnd() && (*itNext).right(3) == "^{}") {
signedTag = true;
+ dbg(refSha);
if (run("git-cat-file tag " + refSha, &runOutput)) {
QString msg(runOutput.section("\n\n", 1));
if (!msg.isEmpty())
and send me the output. Mine is
refSha is <a0e7d36193b96f552073558acf5fcc1f10528917>
refSha is <24d9d195a206825bc1f03e7e7110fe05a827d1e3>
refSha is <d6602ec5194c87b0fc87103ca4d67251c76f233a>
refSha is <f25a265a342aed6041ab0cc484224d9ca54b6f41>
refSha is <c5db5456ae3b0873fc659c19fafdde22313cc441>
refSha is <7ceca275d047c90c0c7d5afb13ab97efdf51bd6e>
refSha is <b3e9704ecdf48869f635f0aa99ddfb513f885aff>
refSha is <07e38db6a5a03690034d27104401f6c8ea40f1fc>
refSha is <f12e22d4c12c3d0263fa681f25c06569f643da0f>
refSha is <f8696fcd2abc446a5ccda3e414b731eff2a7e981>
refSha is <1094cf40f7029f803421c1dcc971238507c830c5>
refSha is <da30c6c39cd3b048952a15929c5440acfd71b912>
refSha is <9165ec17fde255a1770886189359897dbb541012>
refSha is <02b2acff8bafb6d73c6513469cdda0c6c18c4138>
refSha is <b041895af323bdef10cc9a718bda468ba3622bc0>
refSha is <cfc2ea6116410a545573d5fa5311d3c3b2df69d1>
refSha is <0b122201af0afb6a6a8059ff446a1e26b1d0c823>
refSha is <d186f3d21148f373a5ea5e43804f5f6707670a87>
refSha is <48055bb38d650ab39957ed07d640469176c12419>
refSha is <b79a5a49c9e412e27a336e705fb7b462367f4c16>
refSha is <ebd5d002da3f6cfbd0aa3ff5b5c4a9d9eeee630d>
refSha is <08f9f32076455ff75b59b41d7003927869082a3f>
refSha is <67b4b78858d9d9dd044f758a90a4270e48543cf1>
refSha is <c512b0344196931ad3a9a049eb3f5d3f05b09328>
refSha is <3d65a838c77f816527acf84c899419eb6825dcee>
refSha is <3521017556c5de4159da4615a39fa4d5d2c279b5>
refSha is <107e3d2b4d5b9ecd9a15a23ad1c64652b8b67ba9>
refSha is <10e5ae69eb6cdcdd149bb23e1e73131adf4ab3b7>
refSha is <b685b14cd9385e8b0f5742ebcd35ef8c8c12ec4d>
refSha is <bd67d7d845eb5ae929306dadd3dff41cf04ce004>
refSha is <5c857638d55bdd575d3f38bf3b99f1a2f99d3e46>
refSha is <4a6a394c62f33a3bf94badd6b14bc1f48647905f>
refSha is <c0f7d44ecba75d54a73ba542adde0ff80d2da03a>
refSha is <0c675e9d0b5f5d1fbb7b0169d71769993b225701>
refSha is <ca6cec9c5843d85d23b1184d584a11699d92e927>
refSha is <93ea4a9599564101be20507a3a756d38427a70ac>
refSha is <71c1a700da60da8cf99d586cc618c46fef201ed1>
refSha is <5f4cd4ca015dc795b9f7f4fed11b3f80a60ac175>
refSha is <112c4fd6b3fe400a075d575c0fe1a583aafe8f2c>
refSha is <dcd118f6b933d7a81739c3c4269e2bf4654e4a99>
refSha is <055e4ae3ae6eb344cbabf2a5256a49ea66040131>
refSha is <2d2846cd06fce719c35b58a8b81f7ae42f1986ca>
refSha is <781aab17fe544cbfcaba0f0ea5cacf7672717236>
and the offending object is not displayed.
Thanks
Marco
^ permalink raw reply
* Re: [PATCH] We do not like "HEAD" as a new branch name
From: Alex Riesen @ 2005-12-15 17:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: H. Peter Anvin, git, junkio
In-Reply-To: <Pine.LNX.4.63.0512151737240.3542@wbgn013.biozentrum.uni-wuerzburg.de>
On 12/15/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > If you're have to open-code it, you might want to just do it all the way:
> >
> I don't really care. I could have used !strcmp(cp - 1, "HEAD"), just as
> well...
>
...which would be more readable and greppable.
^ permalink raw reply
* Re: qgit reports errors in the git repository
From: Pavel Roskin @ 2005-12-15 16:44 UTC (permalink / raw)
To: Marco Costalba; +Cc: Linus Torvalds, git, Marco Costalba
In-Reply-To: <e5bfff550512150501v48bb65abwf44b3fc21f33bdf6@mail.gmail.com>
Hello, Marco.
On Thu, 2005-12-15 at 14:01 +0100, Marco Costalba wrote:
> Just one quickly note. The error report says:
> git-cat-file 23ea3e201cea0deea909569e08e950a9ec2345f7
It's stderr from git-cat-file. I guess git-cat-file could be improved.
> the error message should be:
> git-cat-file tag 23ea3e201cea0deea909569e08e950a9ec2345f7
>
> because it is just the print out of the command line. Or we have 2 bugs ;-)
qgit doesn't print its command line at all when running commands
synchronously.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/src/myprocess.cpp b/src/myprocess.cpp
index 5eee6e1..baae026 100644
--- a/src/myprocess.cpp
+++ b/src/myprocess.cpp
@@ -49,6 +49,7 @@ int MyProcess::runAsync(SCRef rc, QObjec
bool MyProcess::runSync(SCRef runCmd, QString* ro) {
+ this->runCmd = runCmd;
runOutput = ro;
if (runOutput != NULL)
*runOutput = "";
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: [PATCH] We do not like "HEAD" as a new branch name
From: Johannes Schindelin @ 2005-12-15 16:40 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git, junkio
In-Reply-To: <43A19962.2000202@zytor.com>
Hi,
On Thu, 15 Dec 2005, H. Peter Anvin wrote:
> Johannes Schindelin wrote:
> > This makes git-check-ref-format fail for "HEAD". Since the check is only
> > executed when creating refs, the existing symbolic ref is safe.
>
> > diff --git a/refs.c b/refs.c
> > index bda45f7..293bfe7 100644
> > --- a/refs.c
> > +++ b/refs.c
> > @@ -332,6 +332,11 @@ int check_ref_format(const char *ref)
> > if (ch == '.' || bad_ref_char(ch))
> > return -1;
> > + /* do not allow "HEAD" as ref name */
> > + if (ch == 'H' && (!strcmp(cp, "EAD") ||
> > + !strncmp(cp, "EAD/", 4)))
> > + return -1;
> > +
> > /* scan the rest of the path component */
> > while ((ch = *cp++) != 0) {
>
> If you're have to open-code it, you might want to just do it all the way:
>
> if (ch == 'H' && cp[0] == 'E' && cp[1] == 'A' && cp[2] == 'D' &&
> (cp[3] == '\0' || cp[3] == '/'))
;-)
I don't really care. I could have used !strcmp(cp - 1, "HEAD"), just as
well...
Ciao,
Dscho
^ 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