* Re: [PATCH] Include Makefile.localdef in Makefile, if it exists.
From: Johannes Schindelin @ 2005-12-03 10:45 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <3061.1133591717@lotus.CS.Berkeley.EDU>
Hi,
On Fri, 2 Dec 2005, Jason Riedy wrote:
> And Johannes Schindelin writes:
> - I wonder why you do not just override them in config.mak, which was
> - introduced just for that purpose...
>
> 'Cause I'm a git and didn't notice it, thanks.
Nopraw.
> The prefix stuff probably ought to be moved below the -include
> config.mak so someone need only change $(prefix) and not the rest. I
> might send along such a patch, along with a note about config.mak in
> INSTALL...
Actually, it is a feature that you can override prefix and template_dir
independently.
Hth,
Dscho
^ permalink raw reply
* Re: Is reserving the branch name "bisect" a good thing?
From: linux @ 2005-12-03 13:41 UTC (permalink / raw)
To: junkio; +Cc: git, linux
In-Reply-To: <20051202232555.13082.qmail@science.horizon.com>
>> Would it be better if "git bisect" followed that rule as well?
>> Otherwise, we really should document the reserved word.
> I wonder if you broke "git bisect visualize" with that patch.
I don't know, but I sure broke git-bisect.
The problem is that git-checkout won't switch branches if the
ref given is not in $GIT_DIR/refs/heads. (Try to include a "heads/"
prefix on a non-selected existing branch to see.)
Without changing this policy in git-checkout, or replicating most
of git-checkout's code in git-bisect, I can't get away from using
a head name in refs/heads/. :-(
Stepping back, the problem is that
- git has a policy against allowing checkins against a ref not in refs/heads/
- git-commit doesn't have a concept of an unwriteable HEAD, so
- git-checkout refuses to set HEAD to an unwriteable ref (not in refs/heads/)
But "git bisect" wants exactly this sort of historical snapshot.
Actually, this leads to a question... suppose I want to manually
check out some old revision (like "v.2.6.12") for some reason
(performance testing, say). How do I do that?
Do I have to create a branch just to do that?
It might be nicer to allow such a checkout and do the checking in
git-commit, telling you to "git-checkout -b <new_branch>" before
you check in your edits.
In git-bisect, I finally managed to do a bit of a hack, but it's
a bit annoying for doing the above from the command line.
(Error handling could also probably use improvement.)
See the "@@ -146,10 +160,12 @@ bisect_next() {" chunk, third
from the end, for the meat.
diff --git a/git-bisect.sh b/git-bisect.sh
index 68838f3..c8b9d7b 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -1,6 +1,9 @@
#!/bin/sh
. git-sh-setup
+# Put arguments in single quotes to they can be re-interpreted by the shell.
+# (To put a single quote in a single-quoted string, you need to write
+# 'wasn'\''t' = 'wasn' + \' + 't'.)
sq() {
perl -e '
for (@ARGV) {
@@ -42,6 +45,18 @@ bisect_autostart() {
}
}
+# Not generally needed, but provide a cleanup function
+bisect_stop() {
+ case "$(cat "$GIT_DIR/HEAD")" in
+ refs/bisect/*)
+ echo "Resetting HEAD to master"
+ git checkout master || exit
+ ;;
+ esac
+ rm -rf "$GIT_DIR/refs/bisect/"
+ rm -f "$GIT_DIR/BISECT_LOG" "$GIT_DIR/BISECT_NAMES"
+}
+
bisect_start() {
#
# Verify HEAD. If we were bisecting before this, reset to the
@@ -50,7 +65,7 @@ bisect_start() {
head=$(GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD) ||
die "Bad HEAD - I need a symbolic ref"
case "$head" in
- refs/heads/bisect*)
+ refs/bisect/*)
git checkout master || exit
;;
refs/heads/*)
@@ -63,7 +78,6 @@ bisect_start() {
#
# Get rid of any old bisect state
#
- rm -f "$GIT_DIR/refs/heads/bisect"
rm -rf "$GIT_DIR/refs/bisect/"
mkdir "$GIT_DIR/refs/bisect"
{
@@ -146,10 +160,12 @@ bisect_next() {
fi
nr=$(eval "git-rev-list $rev $good -- $(cat $GIT_DIR/BISECT_NAMES)" | wc -l) || exit
echo "Bisecting: $nr revisions left to test after this"
- echo "$rev" > "$GIT_DIR/refs/heads/new-bisect"
- git checkout new-bisect || exit
- mv "$GIT_DIR/refs/heads/new-bisect" "$GIT_DIR/refs/heads/bisect" &&
- GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD refs/heads/bisect
+ next="$(TMPDIR="$GIT_DIR/refs/heads" tempfile -p bisect)"
+ echo "$rev" > "$next"
+ # checkout refuses to deal with a head name not in refs/heads...
+ git checkout $(basename "$next")
+ mv "$next" "$GIT_DIR/refs/bisect/current" &&
+ GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD refs/bisect/current
git-show-branch "$rev"
}
@@ -172,7 +188,6 @@ bisect_reset() {
esac
git checkout "$branch" &&
rm -fr "$GIT_DIR/refs/bisect"
- rm -f "$GIT_DIR/refs/heads/bisect"
rm -f "$GIT_DIR/BISECT_LOG"
}
@@ -217,6 +232,8 @@ case "$#" in
case "$cmd" in
start)
bisect_start "$@" ;;
+ stop)
+ bisect_stop "$@" ;;
bad)
bisect_bad "$@" ;;
good)
^ permalink raw reply related
* gitk does not recognizes ISO-8859-15
From: Marco Costalba @ 2005-12-03 16:24 UTC (permalink / raw)
To: git; +Cc: junkio, paulus
Cannot use ISO-8859-15 according to IANA character-sets encoding file
(http://www.iana.org/assignments/character-sets):
[marco@costalba git]$ git-repo-config i18n.commitencoding ISO-8859-15
[marco@costalba git]$ gitk
Error in startup script: unknown encoding "ISO-8859-15"
while executing
"fconfigure $commfd -blocking 0 -translation lf -encoding $gitencoding"
(procedure "getcommits" line 34)
invoked from within
"getcommits $revtreeargs"
(file "/home/marco/bin/gitk" line 3743)
[marco@costalba git]$ git-repo-config i18n.commitencoding ISO_8859-15
[marco@costalba git]$ gitk
Error in startup script: unknown encoding "ISO_8859-15"
while executing
"fconfigure $commfd -blocking 0 -translation lf -encoding $gitencoding"
(procedure "getcommits" line 34)
invoked from within
"getcommits $revtreeargs"
(file "/home/marco/bin/gitk" line 3743)
Finally, after some trials, I found the Tcl/Tk recognized name is "iso8859-15".
This does not seems a standard name and worst ;-) it is different from the Qt
internal name "ISO8859-15".
I would like to use the qgit text codec selector to save the encoding in the
repository config file (using git-repo-config i18n.commitencoding). But to do
this I must do not break gitk.
Qt can reconize IANA names and also the following "internal" names (only the
first part, before " --") that user can choose with codec selector combobox:
Latin1
Big5 -- Chinese
Big5-HKSCS -- Chinese
eucJP -- Japanese
eucKR -- Korean
GB2312 -- Chinese
GBK -- Chinese
GB18030 -- Chinese
JIS7 -- Japanese
Shift-JIS -- Japanese
TSCII -- Tamil
utf8 -- Unicode, 8-bit
utf16 -- Unicode
KOI8-R -- Russian
KOI8-U -- Ukrainian
ISO8859-1 -- Western
ISO8859-2 -- Central European
ISO8859-3 -- Central European
ISO8859-4 -- Baltic
ISO8859-5 -- Cyrillic
ISO8859-6 -- Arabic
ISO8859-7 -- Greek
ISO8859-8 -- Hebrew, visually ordered
ISO8859-8-i -- Hebrew, logically ordered
ISO8859-9 -- Turkish
ISO8859-10
ISO8859-13
ISO8859-14
ISO8859-15 -- Western
IBM 850
IBM 866
CP874
CP1250 -- Central European
CP1251 -- Cyrillic
CP1252 -- Western
CP1253 -- Greek
CP1254 -- Turkish
CP1255 -- Hebrew
CP1256 -- Arabic
CP1257 -- Baltic
CP1258
Apple Roman
TIS-620 -- Thai
So here we arrive. I see two ways to deal with this:
1) *solution* make gitk use IANA names
2) *workaround* get from somewhere the list of Tcl/Tk recognized codec names and
teach qgit to do the map from IANA when setting a codec with "git-repo-config
i18n.commitencoding"
In both cases I need your help ;-)
Thanks
Marco
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* Re: gitk does not recognizes ISO-8859-15
From: Junio C Hamano @ 2005-12-03 19:08 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <4391C6B8.7010507@yahoo.it>
Marco Costalba <mcostalba@yahoo.it> writes:
> So here we arrive. I see two ways to deal with this:
>
> 1) *solution* make gitk use IANA names
>
> 2) *workaround* get from somewhere the list of Tcl/Tk recognized codec names and
> teach qgit to do the map from IANA when setting a codec with "git-repo-config
> i18n.commitencoding"
The intent of i18n.commitencoding is to have something that is
understood by iconv there, so if gitk does not work with these
things spelled like. ISO8859-1 or ISO-8859-15, and qgit is happy
with them, I would say that we should fix gitk, which means
*workaround* should be on the tcl/tk side.
Tcl/Tk expert may have more thoughts (and I suspect experiences)
on this, but I am not one of them.
^ permalink raw reply
* Re: How can I specify a non-standard TCP port for a git+ssh connection?
From: Junio C Hamano @ 2005-12-03 19:09 UTC (permalink / raw)
To: Andreas Jochens; +Cc: git
In-Reply-To: <20051203080620.GA22032@andaco.de>
Andreas Jochens <aj@andaco.de> writes:
> This is a nice feature, of course. But I still have to edit a separate
> config file. In some cases (e.g. scripts using ad hoc port forwarding) it
> would be much easier if the non-standard port and maybe some other
> options could be specified directly on the git command line or
Having something on the command line to make it easy to override
one-shot you might be able to talk me into, but not in a config
file for git; there is a standard place to hold ssh
configuration already.
^ permalink raw reply
* Re: [PATCH] Include Makefile.localdef in Makefile, if it exists.
From: Junio C Hamano @ 2005-12-03 19:14 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <3061.1133591717@lotus.CS.Berkeley.EDU>
Jason Riedy <ejr@EECS.Berkeley.EDU> writes:
> ... I might
> send along such a patch, along with a note about config.mak in
> INSTALL...
Please don't, unless you are confident your change can satisfy
_everybody_.
People with makefile needs that are more "advanced" (that is,
something a simple "-include config.mak" cannot easily satisfy)
can do any number of things without touching Makefile I ship.
Examples include:
- have own makefile, include Makefile.
- have onw Make script, run "make -f Makefile" with preset
"bindir=HERE NO_XXX=NoThanks" to reduce typing.
- have own makefile, whose build target depends on Make.file
and runs "make -f Make.file", with a build rule for Make.file
to munge Makefile using custom perl/sed into it.
^ permalink raw reply
* Re: Is reserving the branch name "bisect" a good thing?
From: Junio C Hamano @ 2005-12-03 19:15 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20051203134136.31524.qmail@science.horizon.com>
linux@horizon.com writes:
> Without changing this policy in git-checkout, or replicating most
> of git-checkout's code in git-bisect, I can't get away from using
> a head name in refs/heads/. :-(
I tend to think the above "restriction" a conscious design decision.
> Actually, this leads to a question... suppose I want to manually
> check out some old revision (like "v.2.6.12") for some reason
> (performance testing, say). How do I do that?
> Do I have to create a branch just to do that?
Absolutely, and that is deliberately so. You do not want to:
git checkout v2.6.12
work work work
git commit
and move tag v2.6.12 to something that is not v2.6.12. As you
outlined, that "not moving the tag" check can be done in git
commit and have the user do:
git checkout v2.6.12
work work work
git commit ;# fails
git checkout -b oops-i-needed-a-branch-after-all
git commit
but that feels ugly and wrong.
Branches are cheap (just a single file which is a pointer), so
if you prefer neatness:
git checkout -b test-build v2.6.12
work work work
git checkout master ;# when you are done
git branch -d test-build
Or if you are lazy like me, just keep a single throwaway branch
around, and whenever you feel like:
git branch -f ta v2.6.12
git checkout ta
work work work
git checkout master ;# when you are done
To test and possibly further develop the git-daemon update topic
branch, which is two revs before the tip of proposed updates
branch:
git branch -f daemon-updates pu~2
git checkout daemon-updates
make
work work work, find problems and do enhancements
git commit
then you can say "Hey, Junio I found problem in your daemon
updates topic branch, and if you want my fixes you can pull from
my daemon-updates branch".
> It might be nicer to allow such a checkout and do the checking in
> git-commit, telling you to "git-checkout -b <new_branch>" before
> you check in your edits.
That may be, but it is too confusing. Everybody needs to be
aware HEAD can point at random place, not necessarily on some
branch. You happen to have noticed git-commit wants HEAD to be
pointing at a branch and no other random place, but are you
absolutely sure no other tools care? I don't.
> +# Not generally needed, but provide a cleanup function
> +bisect_stop() {
Why isn't this part of bisect reset?
^ permalink raw reply
* Re: git pull aborts in 50% of cases
From: H. Peter Anvin @ 2005-12-03 19:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vpsoezf6y.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>
>>/pub is a symbolic link. We shouldn't rely on getcwd() for this kind of
>>stuff; it's bad for a whole bunch of reasons.
>
>
> Well, if I recall correctly it was done this way because
> DWIMmery needs to be done before the validation.
>
> Anyway, here is a rewrite of tonight (I resurrected your "belts
> and suspenders paranoia patch" for this). Would appreciate it
> if people can try this out (in the proposed updates branch).
>
> The rules (in 0.99.9k and "master" so far) have been that if you
> have symlinked public, whitelist should say what the canonical
> names of them are (and the way canonical names are obtained were
> getcwd()). The rule of this patch is different: whitelist says
> what the remote requestor can ask for. So if your /pub is a
> symlink to /mnt/mnt1/pub, you do not have to say /mnt/mnt1/pub
> to export it. Instead you whitelist /pub (or /pub/scm). Also
> if your ~bob is /home1/bob and ~alice is /home2/alice, you do
> not say "/home1 /home2" -- instead, you say "~alice ~bob".
>
Yup, this is the way to do it. Forcing people to use canonical names is
quite a nonstarter.
-hpa
^ permalink raw reply
* Re: gitk does not recognizes ISO-8859-15
From: H. Peter Anvin @ 2005-12-03 19:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Costalba, git
In-Reply-To: <7v4q5qyp5p.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Marco Costalba <mcostalba@yahoo.it> writes:
>
>
>>So here we arrive. I see two ways to deal with this:
>>
>>1) *solution* make gitk use IANA names
>>
>>2) *workaround* get from somewhere the list of Tcl/Tk recognized codec names and
>>teach qgit to do the map from IANA when setting a codec with "git-repo-config
>>i18n.commitencoding"
>
>
> The intent of i18n.commitencoding is to have something that is
> understood by iconv there, so if gitk does not work with these
> things spelled like. ISO8859-1 or ISO-8859-15, and qgit is happy
> with them, I would say that we should fix gitk, which means
> *workaround* should be on the tcl/tk side.
>
> Tcl/Tk expert may have more thoughts (and I suspect experiences)
> on this, but I am not one of them.
>
I would say that the only sustainable ruleset is to use IANA rules for
character name resolutions, if multiple tools are to be able to use them.
-hpa
^ permalink raw reply
* [RFC] daemon whitelist handling (Re: git pull aborts in 50% of cases)
From: Junio C Hamano @ 2005-12-03 19:30 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Johannes Schindelin, git
In-Reply-To: <7vpsoezf6y.fsf@assigned-by-dhcp.cox.net>
Having slept over the patch I am responding to, I tend to think
this is more trouble than its worth. Validating the
directory enter_repo() chdir()'ed into and validated to be a
good git repository should be done on its canonical name as
getcwd() returns, not with a userland aliasing avoidance.
As an administrator, being able to say /pub/scm on the
whitelist, knowing /pub to be a symbolic link points at
somewhere today but maybe at different place tomorrow, and not
having to adjust the whitelist whenever that happens, is indeed
nice. We do not allow the remote requestor to say /../ in the
path, so we trap him within the directories the whitelist
describes.
Not.
For example, I can by mistake create a symbolic link:
ln -s /home /pub/scm/git/git.git/oops
now accesses /pub/scm/git/oops/hpa/secret.git/ is not
restricted. We could hand-resolve the each level from the
request to see if no "funny" symbolic links are involved, but
what is the definition of "funny"? When we see /pub pointing at
somewhere in /mnt/disk47/slice31, we should not complain. When
we see "oops" under git in the above example, we would want to
complain. These things are hard to get right.
I tend to say that the 0.99.9k (and the current master) rule to
make validation always work on what getcwd() gives back is
easier to understand (which generally means safer). Can I talk
you into adjusting your whitelist on kernel.org machines?
^ permalink raw reply
* Re: [RFC] daemon whitelist handling (Re: git pull aborts in 50% of cases)
From: H. Peter Anvin @ 2005-12-03 19:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vzmnivuz8.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> For example, I can by mistake create a symbolic link:
>
> ln -s /home /pub/scm/git/git.git/oops
>
> now accesses /pub/scm/git/oops/hpa/secret.git/ is not
> restricted. We could hand-resolve the each level from the
> request to see if no "funny" symbolic links are involved, but
> what is the definition of "funny"? When we see /pub pointing at
> somewhere in /mnt/disk47/slice31, we should not complain. When
> we see "oops" under git in the above example, we would want to
> complain. These things are hard to get right.
>
Actually, it's a policy decision whether or not symlinks should be
allowed to exit space like that; in Apache, for example, it's a
configurable.
> I tend to say that the 0.99.9k (and the current master) rule to
> make validation always work on what getcwd() gives back is
> easier to understand (which generally means safer). Can I talk
> you into adjusting your whitelist on kernel.org machines?
I'm not happy about it, but it's not a huge deal on kernel.org.
However, I think it's the wrong thing, especially in the light of
allowing user-relative paths.
At the very least, if you insist on using getcwd() names, you should
pre-canonicalize the whitelist, too.
-hpa
^ permalink raw reply
* Re: [RFC] daemon whitelist handling (Re: git pull aborts in 50% of cases)
From: Linus Torvalds @ 2005-12-03 19:56 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <4391F4DD.2060002@zytor.com>
On Sat, 3 Dec 2005, H. Peter Anvin wrote:
>
> At the very least, if you insist on using getcwd() names, you should
> pre-canonicalize the whitelist, too.
That would probably solve the problem and sounds like the right
user-friendly solution.
Linus
^ permalink raw reply
* Re: [RFC] daemon whitelist handling (Re: git pull aborts in 50% of cases)
From: Junio C Hamano @ 2005-12-03 20:20 UTC (permalink / raw)
To: git
In-Reply-To: <4391F4DD.2060002@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> At the very least, if you insist on using getcwd() names, you should
> pre-canonicalize the whitelist, too.
With the current "prefix" rule (and not allowing /ho to match
/home) that sounds possible and sensivle, but that is not nice
in the long run. We may later want to say "/pub/git/**/*.git"
for example to mean "any subdirectory under /pub/git but the
base directory name must be something ending with '.git'".
Hmm...
^ permalink raw reply
* Re: [RFC] daemon whitelist handling (Re: git pull aborts in 50% of cases)
From: H. Peter Anvin @ 2005-12-03 20:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvey6vsop.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>>At the very least, if you insist on using getcwd() names, you should
>>pre-canonicalize the whitelist, too.
>
> With the current "prefix" rule (and not allowing /ho to match
> /home) that sounds possible and sensivle, but that is not nice
> in the long run. We may later want to say "/pub/git/**/*.git"
> for example to mean "any subdirectory under /pub/git but the
> base directory name must be something ending with '.git'".
>
> Hmm...
>
Yep, this stuff is hard. For example, on kernel.org I'm not concerned
about symbolic links; the likelihood of an accidental symbolic link that
would violate security is very small. Other applications might be
different.
Arguably, the correct interface is to modularize it, and have both the
user request, the post-DWIM output, and the
-hpa
^ permalink raw reply
* Re: [RFC] daemon whitelist handling (Re: git pull aborts in 50% of cases)
From: Junio C Hamano @ 2005-12-03 21:19 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0512031156070.3099@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sat, 3 Dec 2005, H. Peter Anvin wrote:
>>
>> At the very least, if you insist on using getcwd() names, you should
>> pre-canonicalize the whitelist, too.
>
> That would probably solve the problem and sounds like the right
> user-friendly solution.
I agree with you that limiting with names exposed to the
end-user is the right approach and we should avoid having
administrators to use getcwd() names. So in that sense, I think
the patch I sent earlier is going in the right direction.
To cope with the "oops" symlink problem, we could introduce
"--strict-symlink" flag to daemon that does these things:
- enter_repo() returns three things: "~alice/foo.git/.git",
"/home/alice/foo.git/.git", and "/home/alice"; the first is
what remote requested with DWIM, the second is where it
chdir()ed, and the third is what it expanded the
user-relative base to. None of them uses getcwd(). When
user-relative path is not involved, the first two are the
same, and the last one is undefined (and not used).
- daemon checks the whitelist with the first one, and if the
path is not allowed, the processing stops there with failure.
Without --strict-symlink, this is the only test done with
whitelist. This means the whitelist should have /pub/scm and
~alice, not /mnt/disk47/slice31/scm nor /home2/alice.
With --strict-symlink, it uses the latter two with the
whitelist entry it matched, to determine where to start
further "strict symlink check". The part that matched the
whitelist is OK and the rest is checked [*1*]:
- If "~alice" was whitelisted, it knows ~alice expanded to
/home/alice, and starts checking from /home/alice/foo.git
and then checks /home/alice/foo.git/.git.
- If "~alice/foo.git" was whitelisted, it knows it expands to
/home/alice/foo.git, and checks /home/alice/foo.git/.git.
- If a whitelist entry "/pub/scm" was matched against a
request "/pub/scm/git/git.git", it checks /pub/scm/git and
/pub/scm/git.git
The strict symlink check tries to readlink() each of what are
to be checked by the above logic, and rejects if it was found
to be a symlink that starts with a "/" (i.e. absolute
pathname) or anything that has undesiable aliasing effect;
"belts and suspender paranoia" in daemon.c::avoid_alias(),
which is stricter than needed but is safe is a good starting
point, but we may want to allow things that do not step
outside the prefix we matched.
However, I am not ready to do all of the above, not just yet.
Since I wanted to do another maintenance update this weekend,
I'd throw in the last-night's patch in the master so that at
least 0.99.9l works with /pub whitelist, knowing the "oops"
symlink issue is still to be solved. That way we can keep the
users' configuration the same when later we introduce all of the
above.
Thoughts?
[Footnote]
*1* If we later introduce "/pub/scm/**/*.git", we allow symlinks
in the first directories without glob patterns, i.e. "/pub/scm",
so this is somewhat future-proof.
^ permalink raw reply
* Re: [RFC] daemon whitelist handling (Re: git pull aborts in 50% of cases)
From: Junio C Hamano @ 2005-12-03 21:28 UTC (permalink / raw)
To: git
In-Reply-To: <7vslt9vpxo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
Trivial typo.
> - If a whitelist entry "/pub/scm" was matched against a
> request "/pub/scm/git/git.git", it checks /pub/scm/git and
> /pub/scm/git.git
Obviously "/pub/scm/git" and "/pub/scm/git/git.git" are the ones
that are checked here. Whitelist "/pub/scm" means "/pub/scm
and under, and the administrator knows /pub or /pub/scm may be
symlinks pointing at places he wants them to, so do not check
and complain where they point at".
^ permalink raw reply
* Re: How can I specify a non-standard TCP port for a git+ssh connection?
From: Andreas Jochens @ 2005-12-03 21:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtimxait.fsf@assigned-by-dhcp.cox.net>
On 05-Dec-03 11:09, Junio C Hamano wrote:
> Having something on the command line to make it easy to override
> one-shot you might be able to talk me into, but not in a config
> file for git; there is a standard place to hold ssh
> configuration already.
You are right, a duplication of ssh config file options in git
config files should not be necessary.
A way to specify a non-standard port for ssh on the command line
would be sufficient. It is possible to specify non-standard
ports for the git, http and rsync protocols on the command line.
Why not for ssh?
Regards
Andreas Jochens
^ permalink raw reply
* git-update-server-info crashes on hera.kernel.org:/pub/scm/libs/klibc/klibc.git
From: H. Peter Anvin @ 2005-12-03 22:35 UTC (permalink / raw)
To: Git Mailing List
git-core-0.99.9j-1, and the backtrace is as follows:
: hera 29 ; ls -l /usr/lib/debug/usr/bin/git-update-
git-update-index.debug* git-update-ref.debug*
git-update-server-info.debug*
: hera 29 ; gdb -s /usr/lib/debug/usr/bin/git-update-server-info.debug
/usr/bin/git-update-server-info
GNU gdb Red Hat Linux (6.3.0.0-1.63rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host
libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) run
Starting program: /usr/bin/git-update-server-info
Program received signal SIGSEGV, Segmentation fault.
0x0804c04c in nth_packed_object_sha1 (p=0x986a1f0, n=0, sha1=0xbfffc9f0
"") at sha1_file.c:1017
1017 memcpy(sha1, (index + 24 * n + 4), 20);
(gdb) where
#0 0x0804c04c in nth_packed_object_sha1 (p=0x986a1f0, n=0,
sha1=0xbfffc9f0 "") at sha1_file.c:1017
#1 0x08049a61 in update_server_info (force=0) at server-info.c:248
#2 0x08049466 in main (ac=1, av=0xbfffeed4) at update-server-info.c:22
#3 0x00ce1e23 in __libc_start_main () from /lib/tls/libc.so.6
#4 0x080493a1 in _start ()
-hpa
^ permalink raw reply
* [PATCH] A few more options for git-cat-file
From: H. Peter Anvin @ 2005-12-04 1:57 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 302 bytes --]
This adds the following options to git-cat-file:
-n, to get the canonical name of a resource. This is for one thing
useful in tagging scripts.
-e, to test for the existence of a file.
This also cleans up the option-parsing in git-cat-file slightly.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
[-- Attachment #2: git-cat-enhancements --]
[-- Type: text/plain, Size: 2664 bytes --]
diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
index ab4dcae..a59e513 100644
--- a/Documentation/git-cat-file.txt
+++ b/Documentation/git-cat-file.txt
@@ -8,7 +8,7 @@ git-cat-file - Provide content or type i
SYNOPSIS
--------
-'git-cat-file' (-t | -s | <type>) <object>
+'git-cat-file' (-t | -s | -n | -e | <type>) <object>
DESCRIPTION
-----------
@@ -29,6 +29,13 @@ OPTIONS
Instead of the content, show the object size identified by
<object>.
+-n::
+ Instead of the content, show the canoncical name of <object>.
+
+-e::
+ Suppress all output; instead exit with zero status if <object>
+ exists and is a valid object.
+
<type>::
Typically this matches the real type of <object> but asking
for a type that can trivially be dereferenced from the given
@@ -39,8 +46,14 @@ OPTIONS
OUTPUT
------
-If '-t' is specified, one of the <type>. If '-s' is specified,
-the size of the <object> in bytes.
+If '-t' is specified, one of the <type>.
+
+If '-s' is specified, the size of the <object> in bytes.
+
+If '-n' is specified, the canoncial name (40-character SHA1
+hexadecimal string) of the object.
+
+If '-e' is specified, no output.
Otherwise the raw (though uncompressed) contents of the <object> will
be returned.
diff --git a/cat-file.c b/cat-file.c
index d775a15..23fbd28 100644
--- a/cat-file.c
+++ b/cat-file.c
@@ -11,27 +11,48 @@ int main(int argc, char **argv)
char type[20];
void *buf;
unsigned long size;
+ int opt;
setup_git_directory();
if (argc != 3 || get_sha1(argv[2], sha1))
- usage("git-cat-file [-t | -s | <type>] <sha1>");
+ usage("git-cat-file [-t|-s|-n|-e|<type>] <sha1>");
- if (!strcmp("-t", argv[1]) || !strcmp("-s", argv[1])) {
- if (!sha1_object_info(sha1, type,
- argv[1][1] == 's' ? &size : NULL)) {
- switch (argv[1][1]) {
- case 't':
- printf("%s\n", type);
- break;
- case 's':
- printf("%lu\n", size);
- break;
- }
+ opt = 0;
+ if ( argv[1][0] == '-' ) {
+ opt = argv[1][1];
+ if ( !opt || argv[1][2] )
+ opt = -1; /* Not a single character option */
+ }
+
+ buf = NULL;
+ switch (opt) {
+ case 'n':
+ printf("%s\n", sha1_to_hex(sha1));
+ return 0;
+
+ case 't':
+ if (!sha1_object_info(sha1, type, NULL)) {
+ printf("%s\n", type);
return 0;
}
- buf = NULL;
- } else {
+ break;
+
+ case 's':
+ if (!sha1_object_info(sha1, type, &size)) {
+ printf("%lu\n", size);
+ return 0;
+ }
+ break;
+
+ case 'e':
+ return !has_sha1_file(sha1);
+
+ case 0:
buf = read_object_with_reference(sha1, argv[1], &size, NULL);
+ break;
+
+ default:
+ die("git-cat-file: unknown option: %s\n", argv[1]);
}
if (!buf)
^ permalink raw reply related
* gitk - ewww
From: Ben Clifford @ 2005-12-04 1:27 UTC (permalink / raw)
To: Git Mailing List
Here's a screen shot that surprised me with a really high 'ewwww'
factor when I fired up gitk this morning on my local git repo, given
that it looks pretty the rest of the time.
This repo tracking git master with just one extra commit that I've
added and rebase off origin repeatedly.
The area around where the 'master' green tag is displayed
(specifically the two lines below it) are surprisingly poor.
I'm not going to learn tcl/tk and how gitk works to investigate,
though, but maybe someone else cares enough and/or can see a trivial
fix...
Screen shot is at:
http://www/hawaga.org.uk/ben/tech/gitk-eww-1.png
If trying to recreate, e011472b550b27a4644403c6fa99543ee9004a63 is
only on my local machine, but I can supply a copy of my tree too.
$ cg status
Heads:
>master e011472b550b27a4644403c6fa99543ee9004a63
R origin 56b5e946f2ba4fd57bbe14f9e3ec2e0ae314d5e6
--
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
* bash completions code for git+porcelain
From: Ben Clifford @ 2005-12-04 2:05 UTC (permalink / raw)
To: Git Mailing List
just a note that I'm still plodding along slowly adding bits to the
bash completion code available by typing:
cg clone http://www.hawaga.org.uk/gitcompletion.git
handles (some of) git, gitk, cg, stg commands - enough to be useful
for me, at least ;-)
--
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: gitk - ewww
From: Linus Torvalds @ 2005-12-04 4:44 UTC (permalink / raw)
To: Ben Clifford; +Cc: Git Mailing List
In-Reply-To: <6CC092B0-101F-4D98-9761-B4E24A7CA35A@hawaga.org.uk>
On Sun, 4 Dec 2005, Ben Clifford wrote:
>
> Screen shot is at:
> http://www/hawaga.org.uk/ben/tech/gitk-eww-1.png
Yes. gitk doesn't look wonderful with octopus merges, the lines start
crossing. Oh well. I think you have to live with it, it's done this for a
long time.
What makes _me_ go "eww" in that screenshot is that tcl/tk doesn't do
anti-aliased fonts, but maybe that's just me, and that's apparently 8.5
has that fixed (at a horrible performance impact, I'm sure, but hey, one
look at your screenshot and I'm saying "bring it on").
Linus
^ permalink raw reply
* Re: gitk - ewww
From: H. Peter Anvin @ 2005-12-04 6:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ben Clifford, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0512032040240.3099@g5.osdl.org>
Linus Torvalds wrote:
>
> On Sun, 4 Dec 2005, Ben Clifford wrote:
>
>>Screen shot is at:
>>http://www/hawaga.org.uk/ben/tech/gitk-eww-1.png
>
>
> Yes. gitk doesn't look wonderful with octopus merges, the lines start
> crossing. Oh well. I think you have to live with it, it's done this for a
> long time.
>
> What makes _me_ go "eww" in that screenshot is that tcl/tk doesn't do
> anti-aliased fonts, but maybe that's just me, and that's apparently 8.5
> has that fixed (at a horrible performance impact, I'm sure, but hey, one
> look at your screenshot and I'm saying "bring it on").
>
It usually work OK for me, running on Fedora Core 4.
Clearly, though, it's Tcl/Tk version dependent; especially since it
looks absolutely *awful* on Cygwin.
-hpa
^ permalink raw reply
* Re: git-update-server-info crashes on hera.kernel.org:/pub/scm/libs/klibc/klibc.git
From: Junio C Hamano @ 2005-12-04 6:16 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <43921DAE.7060606@zytor.com>
I made a copy of that repository on hera and tried it but cannot
reproduce (with or without -f flag -- and running under gdb with
symbols did not make difference either). Sorry, I am baffled.
The same machine, the same set of input and binary.
junio@hera:~/t(0)$ echo $PATH
/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin
junio@hera:~/t(0)$ (cd /pub/scm/libs/klibc/ && tar cf - klibc.git ) | tar xf -
junio@hera:~/t(0)$ head -n 4 klibc.git/objects/info/packs
P pack-122eb314270865bdaaded7d02c7340014537abbf.pack
D 0
T 0 005146812e1e36309409128e0bbaf86e6745a637 tag
T 0 00aea41acad6d139679416a79ff9139a50b5001c tag
junio@hera:~/t(0)$ GIT_DIR=klibc.git /usr/bin/git-update-server-info ; echo $?
0
junio@hera:~/t(0)$ head -n 4 klibc.git/objects/info/packs
P pack-1433c87e76496ad3f628652c0cb81d288c178fc5.pack
P pack-f9db0b232716d835858232fbecfb410d22ae5afb.pack
D 0
junio@hera:~/t(0)$ rm -fr klibc.git
junio@hera:~/t(0)$ (cd /pub/scm/libs/klibc/ && tar cf - klibc.git ) | tar xf - junio@hera:~/t(0)$ head -n 4 klibc.git/objects/info/packs
P pack-122eb314270865bdaaded7d02c7340014537abbf.pack
D 0
T 0 005146812e1e36309409128e0bbaf86e6745a637 tag
T 0 00aea41acad6d139679416a79ff9139a50b5001c tag
junio@hera:~/t(0)$ GIT_DIR=klibc.git /usr/bin/git-update-server-info -f; echo $?
0
junio@hera:~/t(0)$ head -n 4 klibc.git/objects/info/packs
P pack-122eb314270865bdaaded7d02c7340014537abbf.pack
P pack-1433c87e76496ad3f628652c0cb81d288c178fc5.pack
P pack-f9db0b232716d835858232fbecfb410d22ae5afb.pack
D 0
junio@hera:~/t(0)$ exit
^ permalink raw reply
* Re: [PATCH] A few more options for git-cat-file
From: Junio C Hamano @ 2005-12-04 6:17 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <43924D1C.8070306@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> This adds the following options to git-cat-file:
>
> -n, to get the canonical name of a resource. This is for one thing
> useful in tagging scripts.
Isn't "git-rev-parse --verify" good enough?
> -e, to test for the existence of a file.
This might be useful and cleaner than "cat-file -s >/dev/null"
but marginally so. While reading the whole file and discarding
that to /dev/null is wasteful and would go against tastes of
many people, -t and -s flags do not need to read the whole thing
and not so expensive.
^ 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