* Re: [ANNOUNCE] Git 1.6.5.4
From: Michael J Gruber @ 2009-12-03 12:15 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Junio C Hamano, git
In-Reply-To: <m2hbs85koj.fsf@igel.home>
Andreas Schwab venit, vidit, dixit 03.12.2009 13:03:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Unconditionally set man.base.url.for.relative.links
>
> rm -f git-add.1 && \
> xmlto -m manpage-normal.xsl --stringparam man.base.url.for.relative.links= man git-add.xml
> xmlto: unrecognized option '--stringparam'
> make[1]: *** [git-add.1] Error 1
>
> Andreas.
>
and
uname -a
xmlto --version
says?
Michael
^ permalink raw reply
* Speedlimit at "git clone"
From: Stefan Kuhne @ 2009-12-03 12:09 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 90 bytes --]
Hello,
how can i limit the download speed at "git clone"?
Regards,
Stefan Kuhne
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.6.5.4
From: Andreas Schwab @ 2009-12-03 12:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v638o76ra.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Unconditionally set man.base.url.for.relative.links
rm -f git-add.1 && \
xmlto -m manpage-normal.xsl --stringparam man.base.url.for.relative.links= man git-add.xml
xmlto: unrecognized option '--stringparam'
make[1]: *** [git-add.1] Error 1
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* git reset --hard in .git causes a checkout in that directory
From: Maarten Lankhorst @ 2009-12-03 11:30 UTC (permalink / raw)
To: git
Hi all,
When I was working on my code and made a mess that I wanted to undo, I
accidentally did it in the .git directory, and had a whole clone of my
last committed tree there.
It can be triggered easily:
mkdir test; cd test; git init; touch foo; git add foo; git commit -m
'add foo'; cd .git; git reset --hard; [ -f foo ] && echo hello beauty
Other parts of git could be affected, I haven't checked where exactly
the bug hides, so I was afraid to send in a patch
Cheers,
Maarten
^ permalink raw reply
* Re: [PATCH] pull: clarify advice for the unconfigured error case
From: Jan Krüger @ 2009-12-03 10:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Jeff King, Jan Nieuwenhuizen, Tomas Carnecky,
git list
In-Reply-To: <7vk4x57z4e.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Is this a good replacement for 31971b3 (git-pull.sh --rebase: overhaul
> error handling when no candidates are found, 2009-11-12) that is on
> 'pu' and does the lack of follow-up mean everybody involved in the
> discussion is happy with this version?
I'm not deliriously happy but I can't think of a better version, and I
suppose it's better than what I suggested. In other words, I'm fine
with the patch.
Jan
^ permalink raw reply
* Re: [PATCH] reset: add --quiet option
From: Stephen Boyd @ 2009-12-03 9:46 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4530912030133n7e2fbf2asfea6e3896980dc7c@mail.gmail.com>
On Thu, 2009-12-03 at 11:33 +0200, Felipe Contreras wrote:
> On Mon, Nov 30, 2009 at 11:45 PM, Stephen Boyd <bebarino@gmail.com> wrote:
> > If you're already touching the line why not just do it once? I agree a
> > follow-up patch to cover the other commands would be good.
>
> Because the less trivial the patches, the less luck I have of getting
> them applied :)
Heh, still seems pretty trivial to me ;-)
>
> Anyway, I sent a patch to use OPT__QUIET directly in two places.
>
Great. Thanks for making it more consistent.
^ permalink raw reply
* Re: [PATCH] reset: add --quiet option
From: Felipe Contreras @ 2009-12-03 9:33 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <780e0a6b0911301345v42c2b22bs34092fb69b21a2a0@mail.gmail.com>
On Mon, Nov 30, 2009 at 11:45 PM, Stephen Boyd <bebarino@gmail.com> wrote:
> If you're already touching the line why not just do it once? I agree a
> follow-up patch to cover the other commands would be good.
Because the less trivial the patches, the less luck I have of getting
them applied :)
Anyway, I sent a patch to use OPT__QUIET directly in two places.
--
Felipe Contreras
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.6.5.4
From: Jeff King @ 2009-12-03 9:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v638o76ra.fsf@alter.siamese.dyndns.org>
On Thu, Dec 03, 2009 at 01:21:13AM -0800, Junio C Hamano wrote:
> * "git pack-objects --all-progress" is an option to ask progress output
> from write-object phase _if_ progress output were to be produced, and
> shouldn't have forced the progress output.
Shouldn't this actually be --all-progress-implied? Nico's patch
intentionally kept --all-progress with the same behavior.
-Peff
^ permalink raw reply
* [ANNOUNCE] Git 1.6.5.4
From: Junio C Hamano @ 2009-12-03 9:21 UTC (permalink / raw)
To: git
The latest maintenance release Git 1.6.5.4 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.5.4.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.5.4.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.5.4.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
RPMS/$arch/git-*-1.6.5.4-1.fc11.$arch.rpm (RPM)
Contains some minor fixes that have been accumulated; all of them
appear in the upcoming 1.6.6 release as well.
This should fix the problem that man pages formatted on FC11 boxes are
littered with "man.base.url.for.relative.link" strings reported earlier
today.
Git v1.6.5.4 Release Notes
==========================
Fixes since v1.6.5.3
--------------------
* "git help" (without argument) used to check if you are in a directory
under git control. There was no breakage in behaviour per-se, but this
was unnecessary.
* "git prune-packed" gave progress output even when its standard error is
not connected to a terminal; this caused cron jobs that run it to
produce crufts.
* "git pack-objects --all-progress" is an option to ask progress output
from write-object phase _if_ progress output were to be produced, and
shouldn't have forced the progress output.
* "git apply -p<n> --directory=<elsewhere>" did not work well for a
non-default value of n.
* "git merge foo HEAD" was misparsed as an old-style invocation of the
command and produced a confusing error message. As it does not specify
any other branch to merge, it shouldn't be mistaken as such. We will
remove the old style "git merge <message> HEAD <commit>..." syntax in
future versions, but not in this release,
* "git merge -m <message> <branch>..." added the standard merge message
on its own after user-supplied message, which should have overrided the
standard one.
Other minor documentation updates are included.
----------------------------------------------------------------
Changes since v1.6.5.3 are as follows:
David Aguilar (1):
help: Do not unnecessarily look for a repository
David Soria Parra (1):
Documentation: Document --branch option in git clone synopsis
Greg Price (1):
Documentation: undocument gc'd function graph_release()
Jeff King (1):
prune-packed: only show progress when stderr is a tty
Junio C Hamano (7):
builtin-apply.c: pay attention to -p<n> when determining the name
Do not misidentify "git merge foo HEAD" as an old-style invocation
merge: do not add standard message when message is given with -m option
Prepare for 1.6.5.4
Documentation/Makefile: allow man.base.url.for.relative.link to be set from Make
Unconditionally set man.base.url.for.relative.links
Git 1.6.5.4
Michael J Gruber (1):
Documentation: Fix a few i.e./e.g. mix-ups
Nicolas Pitre (1):
pack-objects: split implications of --all-progress from progress activation
Stephen Boyd (1):
instaweb: restart server if already running
^ permalink raw reply
* Re: [PATCH] pull: clarify advice for the unconfigured error case
From: Jan Nieuwenhuizen @ 2009-12-03 8:49 UTC (permalink / raw)
To: Jeff King
Cc: Jonathan Nieder, Junio C Hamano, Jan Krüger, Tomas Carnecky,
git list
In-Reply-To: <20091203014315.GA12061@coredump.intra.peff.net>
Op woensdag 02-12-2009 om 20:43 uur [tijdzone -0500], schreef Jeff King:
> On Wed, Dec 02, 2009 at 07:26:14PM -0600, Jonathan Nieder wrote:
>
> > > and does the lack of follow-up mean everybody involved in the discussion
> > > is happy with this version?
> Yeah, that was my main complaint, and I withdrew it after getting a
> clue. :) I gave the patch another quick look, and I think it is fine.
Great, thanks!
Jan.
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl | http://lilypond.org
^ permalink raw reply
* [PATCH RESEND] git config: clarify bool types
From: Felipe Contreras @ 2009-12-03 8:21 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
The value is what it is, the --bool and --bool-or-int options don't
specify the value type, just how it is interpreted. For example: a value
of '1' can be interpreted as 'true'.
Comments by Michael J Gruber.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
builtin-config.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-config.c b/builtin-config.c
index a2d656e..d81928c 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -66,9 +66,9 @@ static struct option builtin_config_options[] = {
OPT_STRING(0, "get-color", &get_color_slot, "slot", "find the color configured: [default]"),
OPT_STRING(0, "get-colorbool", &get_colorbool_slot, "slot", "find the color setting: [stdout-is-tty]"),
OPT_GROUP("Type"),
- OPT_BIT(0, "bool", &types, "value is \"true\" or \"false\"", TYPE_BOOL),
+ OPT_BIT(0, "bool", &types, "value is interpreted as a boolean (\"true\" or \"false\")", TYPE_BOOL),
OPT_BIT(0, "int", &types, "value is decimal number", TYPE_INT),
- OPT_BIT(0, "bool-or-int", &types, "value is --bool or --int", TYPE_BOOL_OR_INT),
+ OPT_BIT(0, "bool-or-int", &types, "value is interpreted either as --bool or --int", TYPE_BOOL_OR_INT),
OPT_GROUP("Other"),
OPT_BOOLEAN('z', "null", &end_null, "terminate values with NUL byte"),
OPT_END(),
--
1.6.6.rc1.1.ge4e9b
^ permalink raw reply related
* Re: [PATCH] git-pull.sh: Fix call to git-merge for new command format
From: Michael J Gruber @ 2009-12-03 8:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Horst H. von Brand, git
In-Reply-To: <7viqcpgtbf.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 02.12.2009 18:49:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>>> Yes. Anything that sets GIT_EXEC_PATH correctly can use git-foo form.
>>
>> I know they can. That was in the part you snipped ;)
>
> You asked about the presense of "a policy", and you got an answer.
I guess that was a language issue (on both sides) then, since "can"
could be "is able to" as well as "is allowed to", and I read your answer
in the former sense; the latter makes it a policy.
>> The questions is: Should they? Should we avoid mixing both forms in one
>> script?
>
> Should we avoid it? Yes but not very enthusiastically. We should make
> sure that new invocations anybody adds use dashless form, but I would
> recommend against a "let's remove use of dashed form" patch _unless_ you
> find a time when the project is really quiet and there is nothing else
> going on.
OK, that's all I wanted to know. Thanks.
Michael
^ permalink raw reply
* Re: Git documentation consistency
From: Jeff King @ 2009-12-03 7:45 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <m1NG61U-000kn4C@most.weird.com>
On Thu, Dec 03, 2009 at 02:22:41AM -0500, Greg A. Woods wrote:
> > I think you are showing ignorance here, as -? is *not* even close to
> > standard, nor even widely used practice at all.
>
> I think I should know something about Unix command line and option
> parsers, having used them for some 25 years or so now. In fact I've
> used most every kind of unix that ever was, and I've worked on the
> source to more than a few.
I don't want to nitpick, because the main thrust of your point (that
"git foo --bogus" should show a more useful message) is not affected by
this subpoint at all. But if we are considering special-casing "-?", I
would like to see some evidence that it is actually in use.
I can't seem to find it respected anywhere, as shown below (and note
that yes, some of this output does show a useful help message, but that
is because --bogus would show the same message, and I am not disputing
that we should handle that case):
# My linux box
$ uname -sr
Linux 2.6.31-1-686
$ ls -?
ls: invalid option -- '?'
Try `ls --help' for more information.
# Solaris
$ uname -sr
SunOS 5.8
$ /bin/ls -?
/bin/ls: illegal option -- ?
usage: ls -1RaAdCxmnlogrtucpFbqisfL [files]
$ /usr/ucb/ls -? ;# appears to ignore bogus options entirely?
foo
$ /usr/ucb/fold -?
/usr/ucb/fold: illegal option -- ?
Usage: fold [-bs] [-w width | -width ] [file...]
$ /usr/xpg4/bin/ls -?
/usr/xpg4/bin/ls: illegal option -- ?
usage: ls -1RaAdCxmnlogrtucpFbqisfL [files]
$ /usr/xpg6/bin/ls -?
bash: /usr/xpg6/bin/ls: No such file or directory
# AIX
$ uname -svr
AIX 1 6
$ /bin/ls -?
/bin/ls: illegal option -- ?
usage: ls [-1ACFHLNRabcdefgilmnopqrstuxEUX] [File...]
So what systems _do_ treat "-?" specially?
-Peff
^ permalink raw reply
* Re: git gsoc money
From: Greg A. Woods @ 2009-12-03 7:41 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <20091203052220.GA22582@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 593 bytes --]
I'm a newcomer here so don't pay too much attention to me.
I would suggest that becoming associated with an existing non-profit
group who do similar kinds of project and financial management for other
similar projects would be the ideal option. There could be many
benefits further down the road other than just having them act as a bank.
I've heard something good of spi-inc.org before, but
softwarefreedom.org's web site looks a lot better in "links". :-)
--
Greg A. Woods
Planix, Inc.
<woods@planix.com> +1 416 218 0099 http://www.planix.com/
[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: Git documentation consistency
From: Greg A. Woods @ 2009-12-03 7:22 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <7vaay096ye.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2399 bytes --]
At Wed, 02 Dec 2009 17:34:01 -0800, Junio C Hamano <gitster@pobox.com> wrote:
Subject: Re: Git documentation consistency
>
> I think you are showing ignorance here, as -? is *not* even close to
> standard, nor even widely used practice at all.
I think I should know something about Unix command line and option
parsers, having used them for some 25 years or so now. In fact I've
used most every kind of unix that ever was, and I've worked on the
source to more than a few.
> I somehow doubt your ls
> would respond to "ls -X" any differently from "ls -?", but is giving the
> same canned response to any unknown option.
Indeed. Whether it is useful for "-?" to give a more detailed summary
than the basic one-line usage message often depends on how complex the
command-line features are. My preference is for '-?' (and if possible
'-h' as well) to give detailed usage info, though hopefully limited to
just one screen full if possible (though with Git's free use of $PAGER
in many contexts it might be OK to feed longer usage info to $PAGER
too).
So, the basic usage messages for command-line "syntax" problems should
be a one-line summary (following the error message).
If more detail could be useful then '-?' (and if possible '-h') should
display a more detailed usage message. (and if one line suffices then
'-?' and '-h' don't really have to be treated specially)
> The "usage: ls [-AaBbC...] [file...]" indeed is much better than abstract
> "usage: frotz <options> <args>" that does not list what <options> are, but
> that is a totally different thing. On that point, I think Peff already
> made a good suggestion of giving the full help text in such a case.
Indeed the abstract content-free "<options>" style message is almost
useless in most cases.
It would also be useful to reflect in the usage message what the driver
program saw as its argv[0], not what the internal command saw:
$ git rebase -X
Usage: /usr/pkg/libexec/git-core//git-rebase [--interactive | -i] [-v] [--onto <newbase>] <upstream> [<branch>]
Or perhaps this could be cleaned up with something as simple as always
stripping off the pathname with the likes of:
argv0 = (argv0 = strrchr(argv[0], '/')) ? argv0 + 1 : argv[0];
--
Greg A. Woods
Planix, Inc.
<woods@planix.com> +1 416 218 0099 http://www.planix.com/
[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [PATCH v2] Add --track option to git clone
From: Björn Steinbrink @ 2009-12-03 5:31 UTC (permalink / raw)
To: Jeff King; +Cc: Nanako Shiraishi, David Soria Parra, git
In-Reply-To: <20091202190807.GB30778@coredump.intra.peff.net>
On 2009.12.02 14:08:07 -0500, Jeff King wrote:
> And for convenience of the user, you would want a way to avoid repeating
> the name of the "I want to check this out" branch. So either:
>
> 1. Add "--track foo" as a convenience wrapper for "-f foo -b foo".
Hm, we already have --track for "remote add", and that supports being
supplied multiple times, so I guess for clone, that should work too. But
if track implies -b, having multiple --track seems rather weird. Which
branch head would be created? One for the first --track? Or the last
one? Or one for each? So I'd rather not make --track imply -b.
> 2. If no "-b" is given, the first "-f" is assumed as "-b". So "git
> clone -f foo" becomes equivalent to David's --track.
Won't work if the first one is -f refs/heads/subst/*:refs/remotes/origin/*
> And of course the name "-f" (for --fetch, if you were wondering) is open
> to suggestion.
>
> What do you think?
I'd prefer to see just --track for consistency with "remote add". That
could even learn to use globs, but allowing to specify the right side of
the refspec seems wrong given the option name, so it would be more
limited than your -f option.
Björn
^ permalink raw reply
* git gsoc money
From: Jeff King @ 2009-12-03 5:22 UTC (permalink / raw)
To: git
As a result of our participation in the Summer of Code project last
summer and this summer, Google gave the git community some money. Most
of that money went to defraying travel costs to the SoC mentor summit
and the GitTogether, both last year and this year.
However, we still have about $500 USD remaining. Because of the way
Google hands out the money (they want to deal with one entity per
project, and git has no legal entity), all of the remaining money is
being held personally by me.
For accounting and tax reasons, I don't want to hold it later than Dec
31st. So I am soliciting suggestions from the community on what to do
with the money.
Some possibilities are:
1. Become an affiliated project of an organization like The Software
Freedom Conservancy or Software in the Public Interest. These are
non-profit groups to whom we (or anyone else who wants to, for that
matter) can donate money earmarked for a particular project. They
handle the accounting and hold the money, and then we get it out
when we need it for something.
Of course, then we still have the question of what that "something"
is. So far, all money has been used for travel aid. Suggestions
welcome.
The upsides of this path are that it would handle the issue for
future years, and it would make it easy for people to donate money
to git if they wanted to. The downside is that the process may take
a while, so it may not actually happen in the next month.
Some relevant links for further reading:
http://conservancy.softwarefreedom.org/overview/
http://www.spi-inc.org/treasurer/associated-project-howto.html
2. Donate the money to some non-profit (by the way, all discussion of
taxes and non-profit here is with respect to the United States, as
the money is being held in the US). Possible recipients include a
software freedom organization like those listed above, or something
not software-specific like the EFF. It might be nice to contribute
to projects that help us build git, like curl, libxdiff, or
asciidoc, but AFAIK we can't do so in a tax-exempt way. gcc/mingw
is another candidate; we can probably donate to the Free Software
Foundation for that.
Basically I don't want to hold on to this money, I want it to go
somewhere useful, and I don't want to make a unilateral decision.
Please let me know what people think would be useful.
-Peff
^ permalink raw reply
* [PATCH v3 2/3] run test suite without dashed git-commands in PATH
From: Matthew Ogilvie @ 2009-12-03 5:14 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1259817247-3724-2-git-send-email-mmogilvi_git@miniinfo.net>
Only put bin-wrappers in the PATH (not GIT_EXEC_PATH), to emulate the
default installed user environment, and ensure all the programs run
correctly in such an environment. This is now the default, although
it can be overridden with a --with-dashes test option when running
tests.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
t/README | 9 +++++++++
t/test-lib.sh | 33 +++++++++++++++++++++------------
2 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/t/README b/t/README
index 4e1d7dd..dcd3ebb 100644
--- a/t/README
+++ b/t/README
@@ -75,6 +75,15 @@ appropriately before running "make".
As the names depend on the tests' file names, it is safe to
run the tests with this option in parallel.
+--with-dashes::
+ By default tests are run without dashed forms of
+ commands (like git-commit) in the PATH (it only uses
+ wrappers from ../bin-wrappers). Use this option to include
+ the build directory (..) in the PATH, which contains all
+ the dashed forms of commands. This option is currently
+ implied by other options like --valgrind and
+ GIT_TEST_INSTALLED.
+
You can also set the GIT_TEST_INSTALLED environment variable to
the bindir of an existing git installation to test that installation.
You still need to have built this git sandbox, from which various
diff --git a/t/test-lib.sh b/t/test-lib.sh
index ec3336a..85377c8 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -105,6 +105,8 @@ do
verbose=t; shift ;;
-q|--q|--qu|--qui|--quie|--quiet)
quiet=t; shift ;;
+ --with-dashes)
+ with_dashes=t; shift ;;
--no-color)
color=; shift ;;
--no-python)
@@ -551,19 +553,8 @@ test_done () {
# Test the binaries we have just built. The tests are kept in
# t/ subdirectory and are run in 'trash directory' subdirectory.
TEST_DIRECTORY=$(pwd)
-if test -z "$valgrind"
+if test -n "$valgrind"
then
- if test -z "$GIT_TEST_INSTALLED"
- then
- PATH=$TEST_DIRECTORY/..:$PATH
- GIT_EXEC_PATH=$TEST_DIRECTORY/..
- else
- GIT_EXEC_PATH=$($GIT_TEST_INSTALLED/git --exec-path) ||
- error "Cannot run git from $GIT_TEST_INSTALLED."
- PATH=$GIT_TEST_INSTALLED:$TEST_DIRECTORY/..:$PATH
- GIT_EXEC_PATH=${GIT_TEST_EXEC_PATH:-$GIT_EXEC_PATH}
- fi
-else
make_symlink () {
test -h "$2" &&
test "$1" = "$(readlink "$2")" || {
@@ -625,6 +616,24 @@ else
PATH=$GIT_VALGRIND/bin:$PATH
GIT_EXEC_PATH=$GIT_VALGRIND/bin
export GIT_VALGRIND
+elif test -n "$GIT_TEST_INSTALLED" ; then
+ GIT_EXEC_PATH=$($GIT_TEST_INSTALLED/git --exec-path) ||
+ error "Cannot run git from $GIT_TEST_INSTALLED."
+ PATH=$GIT_TEST_INSTALLED:$TEST_DIRECTORY/..:$PATH
+ GIT_EXEC_PATH=${GIT_TEST_EXEC_PATH:-$GIT_EXEC_PATH}
+else # normal case, use ../bin-wrappers only unless $with_dashes:
+ git_bin_dir="$TEST_DIRECTORY/../bin-wrappers"
+ if ! test -x "$git_bin_dir/git" ; then
+ if test -z "$with_dashes" ; then
+ say "$git_bin_dir/git is not executable; using GIT_EXEC_PATH"
+ fi
+ with_dashes=t
+ fi
+ PATH="$git_bin_dir:$PATH"
+ GIT_EXEC_PATH=$TEST_DIRECTORY/..
+ if test -n "$with_dashes" ; then
+ PATH="$TEST_DIRECTORY/..:$PATH"
+ fi
fi
GIT_TEMPLATE_DIR=$(pwd)/../templates/blt
unset GIT_CONFIG
--
1.6.6.rc1
^ permalink raw reply related
* [PATCH v3 3/3] INSTALL: document a simpler way to run uninstalled builds
From: Matthew Ogilvie @ 2009-12-03 5:14 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1259817247-3724-3-git-send-email-mmogilvi_git@miniinfo.net>
The new scripts automatically saved in the bin-wrappers directory allow
you to run a build when you have neither installed git nor tweaked
environment variables. Mention this in INSTALL, along with the slight
performance issue of doing so.
This can be especially handy for manually testing network-invoked git
(from ssh, web servers, or similar), but it is also handy with a plain
command prompt.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
INSTALL | 18 +++++++++++-------
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/INSTALL b/INSTALL
index be504c9..61086ab 100644
--- a/INSTALL
+++ b/INSTALL
@@ -38,13 +38,17 @@ Issues of note:
Interactive Tools package still can install "git", but you can build it
with --disable-transition option to avoid this.
- - You can use git after building but without installing if you
- wanted to. Various git commands need to find other git
- commands and scripts to do their work, so you would need to
- arrange a few environment variables to tell them that their
- friends will be found in your built source area instead of at
- their standard installation area. Something like this works
- for me:
+ - You can use git after building but without installing if you want
+ to test drive it. Simply run git found in bin-wrappers directory
+ in the build directory, or prepend that directory to your $PATH.
+ This however is less efficient than running an installed git, as
+ you always need an extra fork+exec to run any git subcommand.
+
+ It is still possible to use git without installing by setting a few
+ environment variables, which was the way this was done
+ traditionally. But using git found in bin-wrappers directory in
+ the build directory is far simpler. As a historical reference, the
+ old way went like this:
GIT_EXEC_PATH=`pwd`
PATH=`pwd`:$PATH
--
1.6.6.rc1
^ permalink raw reply related
* [PATCH v3 0/3] bin-wrappers: test without dashed commands in PATH
From: Matthew Ogilvie @ 2009-12-03 5:14 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
This patch series allows running the test suite and/or running an
uninstalled build without dashed commands in the PATH.
Changes since version 2:
merged - The first 3 old patches (fixes to tests to avoid dashed
commands, and added GIT_TEST_INSTALLED documentation) are
now in master, so I am not duplicating them here.
1/3 - Changed to use "@@BUILD_DIR@@" instead of "__GIT_EXEC_DIR__"
for sed substitution, and to use single quotes around it
when setting environment variables in wrap-for-bin.sh.
But this patch still does not really try to handle
strange characters in $(shell pwd); see earlier email
thread about this. (This is newer than pu.)
2/3 - Fixed a couple of spelling errors in the --with-dashes
documentation, and avoid "TOP". (This is newer than pu.)
3/3 - Replaced wording for running an uninstalled git.
It now uses Junio's text: no change compared to his
version of this patch that is currently in pu.
Matthew Ogilvie (3):
build dashless "bin-wrappers" directory similar to installed bindir
run test suite without dashed git-commands in PATH
INSTALL: document a simpler way to run uninstalled builds
.gitignore | 1 +
INSTALL | 18 +++++++++++-------
Makefile | 49 ++++++++++++++++++++++++++++++++++++-------------
t/README | 9 +++++++++
t/test-lib.sh | 33 +++++++++++++++++++++------------
wrap-for-bin.sh | 15 +++++++++++++++
6 files changed, 93 insertions(+), 32 deletions(-)
create mode 100644 wrap-for-bin.sh
^ permalink raw reply
* [PATCH v3 1/3] build dashless "bin-wrappers" directory similar to installed bindir
From: Matthew Ogilvie @ 2009-12-03 5:14 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1259817247-3724-1-git-send-email-mmogilvi_git@miniinfo.net>
The new bin-wrappers directory contains wrapper scripts
for executables that will be installed into the standard
bindir. It explicitly does not contain most dashed-commands.
The scripts automatically set environment variables to run out
of the source tree, not the installed directory.
This will allow running the test suite without dashed commands in
the PATH. It also provides a simplified way to test run custom
built git executables without installing them first.
bin-wrappers also contains wrappers for some test suite support
executables, where the test suite will soon make use of them.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
.gitignore | 1 +
Makefile | 49 ++++++++++++++++++++++++++++++++++++-------------
wrap-for-bin.sh | 15 +++++++++++++++
3 files changed, 52 insertions(+), 13 deletions(-)
create mode 100644 wrap-for-bin.sh
diff --git a/.gitignore b/.gitignore
index ac02a58..5d32289 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,6 +2,7 @@
/GIT-CFLAGS
/GIT-GUI-VARS
/GIT-VERSION-FILE
+/bin-wrappers/
/git
/git-add
/git-add--interactive
diff --git a/Makefile b/Makefile
index 4a1e5bc..378962e 100644
--- a/Makefile
+++ b/Makefile
@@ -427,6 +427,15 @@ ALL_PROGRAMS = $(PROGRAMS) $(SCRIPTS)
# what 'all' will build but not install in gitexecdir
OTHER_PROGRAMS = git$X
+# what test wrappers are needed and 'install' will install, in bindir
+BINDIR_PROGRAMS_NEED_X += git
+BINDIR_PROGRAMS_NEED_X += git-upload-pack
+BINDIR_PROGRAMS_NEED_X += git-receive-pack
+BINDIR_PROGRAMS_NEED_X += git-upload-archive
+BINDIR_PROGRAMS_NEED_X += git-shell
+
+BINDIR_PROGRAMS_NO_X += git-cvsserver
+
# Set paths to tools early so that they can be used for version tests.
ifndef SHELL_PATH
SHELL_PATH = /bin/sh
@@ -1714,19 +1723,30 @@ endif
### Testing rules
-TEST_PROGRAMS += test-chmtime$X
-TEST_PROGRAMS += test-ctype$X
-TEST_PROGRAMS += test-date$X
-TEST_PROGRAMS += test-delta$X
-TEST_PROGRAMS += test-dump-cache-tree$X
-TEST_PROGRAMS += test-genrandom$X
-TEST_PROGRAMS += test-match-trees$X
-TEST_PROGRAMS += test-parse-options$X
-TEST_PROGRAMS += test-path-utils$X
-TEST_PROGRAMS += test-sha1$X
-TEST_PROGRAMS += test-sigchain$X
+TEST_PROGRAMS_NEED_X += test-chmtime
+TEST_PROGRAMS_NEED_X += test-ctype
+TEST_PROGRAMS_NEED_X += test-date
+TEST_PROGRAMS_NEED_X += test-delta
+TEST_PROGRAMS_NEED_X += test-dump-cache-tree
+TEST_PROGRAMS_NEED_X += test-genrandom
+TEST_PROGRAMS_NEED_X += test-match-trees
+TEST_PROGRAMS_NEED_X += test-parse-options
+TEST_PROGRAMS_NEED_X += test-path-utils
+TEST_PROGRAMS_NEED_X += test-sha1
+TEST_PROGRAMS_NEED_X += test-sigchain
+
+TEST_PROGRAMS = $(patsubst %,%$X,$(TEST_PROGRAMS_NEED_X))
-all:: $(TEST_PROGRAMS)
+test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X) $(TEST_PROGRAMS_NEED_X))
+
+all:: $(TEST_PROGRAMS) $(test_bindir_programs)
+
+bin-wrappers/%: wrap-for-bin.sh
+ @mkdir -p bin-wrappers
+ $(QUIET_GEN)sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
+ -e 's|@@BUILD_DIR@@|$(shell pwd)|' \
+ -e 's|@@PROG@@|$(@F)|' < $< > $@ && \
+ chmod +x $@
# GNU make supports exporting all variables by "export" without parameters.
# However, the environment gets quite big, and some programs have problems
@@ -1787,11 +1807,13 @@ endif
gitexec_instdir_SQ = $(subst ','\'',$(gitexec_instdir))
export gitexec_instdir
+install_bindir_programs := $(patsubst %,%$X,$(BINDIR_PROGRAMS_NEED_X)) $(BINDIR_PROGRAMS_NO_X)
+
install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
- $(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver '$(DESTDIR_SQ)$(bindir_SQ)'
+ $(INSTALL) $(install_bindir_programs) '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
ifndef NO_PERL
$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
@@ -1902,6 +1924,7 @@ clean:
$(LIB_FILE) $(XDIFF_LIB)
$(RM) $(ALL_PROGRAMS) $(BUILT_INS) git$X
$(RM) $(TEST_PROGRAMS)
+ $(RM) -r bin-wrappers
$(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags cscope*
$(RM) -r autom4te.cache
$(RM) config.log config.mak.autogen config.mak.append config.status config.cache
diff --git a/wrap-for-bin.sh b/wrap-for-bin.sh
new file mode 100644
index 0000000..c5075c9
--- /dev/null
+++ b/wrap-for-bin.sh
@@ -0,0 +1,15 @@
+#!/bin/sh
+
+# wrap-for-bin.sh: Template for git executable wrapper scripts
+# to run test suite against sandbox, but with only bindir-installed
+# executables in PATH. The Makefile copies this into various
+# files in bin-wrappers, substituting
+# @@BUILD_DIR@@ and @@PROG@@.
+
+GIT_EXEC_PATH='@@BUILD_DIR@@'
+GIT_TEMPLATE_DIR='@@BUILD_DIR@@/templates/blt'
+GITPERLLIB='@@BUILD_DIR@@/perl/blib/lib'
+PATH='@@BUILD_DIR@@/bin-wrappers:'"$PATH"
+export GIT_EXEC_PATH GIT_TEMPLATE_DIR GITPERLLIB PATH
+
+exec "${GIT_EXEC_PATH}/@@PROG@@" "$@"
--
1.6.6.rc1
^ permalink raw reply related
* Re: multiple working directories for long-running builds (was: "git merge" merges too much!)
From: Greg A. Woods @ 2009-12-03 5:11 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <20091202001020.GF11235@dpotapov.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 4674 bytes --]
At Wed, 2 Dec 2009 03:10:21 +0300, Dmitry Potapov <dpotapov@gmail.com> wrote:
Subject: Re: multiple working directories for long-running builds (was: "git merge" merges too much!)
>
> My point was that I do not see why you believe "git archive" is more
> expensive than "git clone". Accordingly to Jeff Epler's numbers,
> "git archive" is 20% faster than "git clone"...
Really!?!?!? You don't see it? Why is this so hard to understand?
Sorry for my incredulity, but I thought this issue was obvious.
The slightly more expensive "git clone" happens only _ONCE_. After that
you just run "git pull" I think (plus maybe "git reset --hard"?), but in
any case it's a heck of a lot less I/O and CPU than "git archive".
And of course you skip even the one-time "git clone" operation if you
use the even faster and simpler git-new-workdir script.
"git archive" has to be run _EVERY_ time you need to update a working
directory and it currently has no choice but to toss every bit of the
whole working directory, up from the filesystem, across a pipe, and back
down to the filesystem. It literally couldn't be more expensive!
Sure, no matter how you do it, updating the working directory might not
always be the biggest part of the operation, but it's insane to use the
most expensive mechanism ever possible when there are far cheaper
alternatives.
BTW, there cannot, and MUST NOT, be any integrity advantage to using
"git archive" over using multiple working directories. "git archive
branch" must, by definition, produce exactly the same result as if you
did "git checkout branch; rm -rf .git" or else it is buggy.
Note also that the build directories created with git-new-workdir can be
treated as read-only, and perhaps even forced to be read-only by mount
options or maybe just by a corporate policy directive. (in all projects
I'm working on the source tree can be read-only -- product files are
always generated elsewhere)
> Multiple copies of the same repo is never a problem (except taking some
> disks space).
Exactly -- gigabytes of disk space per copy in the cases I'm concerned
about (i.e. where hard links are impossible). I've heard that at least
one very large project has an 8GB repository currently. Three of the
large projects I work on now are about a gigabyte per copy. That's just
what's under .git too, not including the whole working directory as
well. I can't even manage a "git clone" from HTTP of one of them
without increasing my default process limits as it is so big and uses up
too much memory.
I guess one could skip the initial more-expensive "git clone" operation
by copying the repo using low-level bit moving commands, like "cp -r" or
whatever, and then tweak the result to make it appear as if it had been
cloned, but even that requires moving gigabytes of data unnecessarily
across what is likely to be a network connection of some sort.
Are you fighting against git-new-workdir, or the concept of multiple
working directories?
> > A major further advantage of multiple working directories is that this
> > eliminates one more point of failure -- i.e. you don't end up with
> > multiple copies of the repo that _should_ be effectively read-only for
> > everything but "push", and perhaps then only to one branch.
>
> I really do not understand why you say that some copies
> should be effectively read-only... You can start to work on some feature
> at one place (using one repo) and then continue in another place using
> another repo. (Obviously, it will require to fetch changes from the
> first repo, before you will be able to continue, but it is just one
> command). In other words, I really do not understand what are you
> talking about here.
Developers, especially more junior ones, work on code, and they (are
supposed to) spend almost all of their intellectual energy on the issues
to do with creating and modifying code -- they are not expected to be
integration engineers, nor are they expected to be VCS and SCM experts.
The more steps you put in place for them to do, and the more places you
allow them to store changes, etc., etc., etc., the more mistakes that
they will make.
Besides, in some scenarios build directories will be checked out from
integration branches which shouldn't have any direct commits made to
them, especially not to fix a problem in a build.
BTW, pkgsrc has well over 50,000 files, FreeBSD ports is over 100,000.
Neither can really be split in any rational way.
--
Greg A. Woods
Planix, Inc.
<woods@planix.com> +1 416 218 0099 http://www.planix.com/
[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* [PATCH for v1.6.6] Fix crasher on encountering SHA1-like non-note in notes tree
From: Johan Herland @ 2009-12-03 3:53 UTC (permalink / raw)
To: gitster; +Cc: git, johan, spearce
When loading a notes tree, the code primarily looks for SHA1-like paths
whose total length (discounting directory separators) are 40 chars
(interpreted as valid note entries) or less (interpreted as subtree
entries that may in turn contain note entries when unpacked).
However, there is an additional condition that must hold for valid
subtree entries: They must be _tree_ objects (duh).
This patch adds an appropriate test for this condition, thereby fixing
the crash that occured when passing a non-tree object to the tree-walk
API.
The patch also adds another selftest verifying correct behaviour of
non-notes in note trees.
Signed-off-by: Johan Herland <johan@herland.net>
---
Junio,
I believe this should be included in v1.6.6. It fixes an existing crasher in
the early part of the notes series.
...Johan
notes.c | 2 +
t/t3304-notes-mixed.sh | 172 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 174 insertions(+), 0 deletions(-)
create mode 100755 t/t3304-notes-mixed.sh
diff --git a/notes.c b/notes.c
index 50a4672..023adce 100644
--- a/notes.c
+++ b/notes.c
@@ -331,6 +331,8 @@ static void load_subtree(struct leaf_node *subtree, struct int_node *node,
hashcpy(l->key_sha1, commit_sha1);
hashcpy(l->val_sha1, entry.sha1);
if (len < 20) {
+ if (!S_ISDIR(entry.mode))
+ continue; /* entry cannot be subtree */
l->key_sha1[19] = (unsigned char) len;
type = PTR_TYPE_SUBTREE;
}
diff --git a/t/t3304-notes-mixed.sh b/t/t3304-notes-mixed.sh
new file mode 100755
index 0000000..256687f
--- /dev/null
+++ b/t/t3304-notes-mixed.sh
@@ -0,0 +1,172 @@
+#!/bin/sh
+
+test_description='Test notes trees that also contain non-notes'
+
+. ./test-lib.sh
+
+number_of_commits=100
+
+start_note_commit () {
+ test_tick &&
+ cat <<INPUT_END
+commit refs/notes/commits
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data <<COMMIT
+notes
+COMMIT
+
+from refs/notes/commits^0
+deleteall
+INPUT_END
+
+}
+
+verify_notes () {
+ git log | grep "^ " > output &&
+ i=$number_of_commits &&
+ while [ $i -gt 0 ]; do
+ echo " commit #$i" &&
+ echo " note for commit #$i" &&
+ i=$(($i-1));
+ done > expect &&
+ test_cmp expect output
+}
+
+test_expect_success "setup: create a couple of commits" '
+
+ test_tick &&
+ cat <<INPUT_END >input &&
+commit refs/heads/master
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data <<COMMIT
+commit #1
+COMMIT
+
+M 644 inline file
+data <<EOF
+file in commit #1
+EOF
+
+INPUT_END
+
+ test_tick &&
+ cat <<INPUT_END >>input &&
+commit refs/heads/master
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data <<COMMIT
+commit #2
+COMMIT
+
+M 644 inline file
+data <<EOF
+file in commit #2
+EOF
+
+INPUT_END
+ git fast-import --quiet <input
+'
+
+test_expect_success "create a notes tree with both notes and non-notes" '
+
+ commit1=$(git rev-parse refs/heads/master^) &&
+ commit2=$(git rev-parse refs/heads/master) &&
+ test_tick &&
+ cat <<INPUT_END >input &&
+commit refs/notes/commits
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data <<COMMIT
+notes commit #1
+COMMIT
+
+N inline $commit1
+data <<EOF
+note for commit #1
+EOF
+
+N inline $commit2
+data <<EOF
+note for commit #2
+EOF
+
+INPUT_END
+ test_tick &&
+ cat <<INPUT_END >>input &&
+commit refs/notes/commits
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data <<COMMIT
+notes commit #2
+COMMIT
+
+M 644 inline foobar/non-note.txt
+data <<EOF
+A non-note in a notes tree
+EOF
+
+N inline $commit2
+data <<EOF
+edited note for commit #2
+EOF
+
+INPUT_END
+ test_tick &&
+ cat <<INPUT_END >>input &&
+commit refs/notes/commits
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE
+data <<COMMIT
+notes commit #3
+COMMIT
+
+N inline $commit1
+data <<EOF
+edited note for commit #1
+EOF
+
+M 644 inline deadbeef
+data <<EOF
+non-note with SHA1-like name
+EOF
+
+M 644 inline de/adbeef
+data <<EOF
+another non-note with SHA1-like name
+EOF
+
+INPUT_END
+ git fast-import --quiet <input &&
+ git config core.notesRef refs/notes/commits
+'
+
+cat >expect <<EXPECT_END
+ commit #2
+ edited note for commit #2
+ commit #1
+ edited note for commit #1
+EXPECT_END
+
+test_expect_success "verify contents of notes" '
+
+ git log | grep "^ " > actual &&
+ test_cmp expect actual
+'
+
+cat >expect_nn1 <<EXPECT_END
+A non-note in a notes tree
+EXPECT_END
+cat >expect_nn2 <<EXPECT_END
+non-note with SHA1-like name
+EXPECT_END
+cat >expect_nn3 <<EXPECT_END
+another non-note with SHA1-like name
+EXPECT_END
+
+test_expect_success "verify contents of non-notes" '
+
+ git cat-file -p refs/notes/commits:foobar/non-note.txt > actual_nn1 &&
+ test_cmp expect_nn1 actual_nn1 &&
+ git cat-file -p refs/notes/commits:deadbeef > actual_nn2 &&
+ test_cmp expect_nn2 actual_nn2 &&
+ git cat-file -p refs/notes/commits:de/adbeef > actual_nn3 &&
+ test_cmp expect_nn3 actual_nn3
+'
+
+test_done
--
1.6.5.3.433.g11067
^ permalink raw reply related
* Re: [RFC/PATCHv9 01/11] fast-import: Proper notes tree manipulation
From: Johan Herland @ 2009-12-03 3:45 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, gitster
In-Reply-To: <20091202203953.GE31648@spearce.org>
(Oops. I forgot to answer a couple of your questions...)
On Wednesday 02 December 2009, Shawn O. Pearce wrote:
> Johan Herland <johan@herland.net> wrote:
> > +static unsigned int do_change_note_fanout(
> > + struct tree_entry *orig_root, struct tree_entry *root,
> > + char *hex_sha1, unsigned int hex_sha1_len,
> > + char *fullpath, unsigned int fullpath_len,
> > + unsigned char fanout)
> > +{
> > + struct tree_content *t = root->tree;
> > + struct tree_entry *e, leaf;
> > + unsigned int i, tmp_hex_sha1_len, tmp_fullpath_len, num_notes = 0;
> > + unsigned char sha1[20];
> > + char realpath[60];
> > + int is_note;
> > +
> > + for (i = 0; i < t->entry_count; i++) {
> > + e = t->entries[i];
> > + is_note = (e->versions[1].mode & NOTE_MODE) == NOTE_MODE;
> > + tmp_hex_sha1_len = hex_sha1_len + e->name->str_len;
> > + tmp_fullpath_len = fullpath_len;
> > +
> > + if (tmp_hex_sha1_len <= 40 && e->name->str_len >= 2) {
> > + memcpy(hex_sha1 + hex_sha1_len, e->name->str_dat,
> > + e->name->str_len);
> > + if (tmp_fullpath_len)
> > + fullpath[tmp_fullpath_len++] = '/';
> > + memcpy(fullpath + tmp_fullpath_len, e->name->str_dat,
> > + e->name->str_len);
> > + tmp_fullpath_len += e->name->str_len;
> > + assert(tmp_fullpath_len < 60);
> > + fullpath[tmp_fullpath_len] = '\0';
> > + } else {
> > + assert(!is_note);
> > + continue;
> > + }
>
> Are we rejecting a mixed content-tree here? I thought a notes
> tree was allowed to hold anything, e.g. isn't it ok to put a
> ".gitattributes" file into a notes tree.
>
> I think we'd do better to have at the top of our loop:
>
> if (!is_note && !S_ISDIR(e->versions[1].mode))
> continue;
>
> so that we ignore non-notes and non-subdirectories which might
> contain notes.
AFAICS, the current code does not reject ".gitattributes", but instead
simply ignores it presence (i.e. does not change its fanout). However, it
certainly does some unnecessary work (setting up hex_sha1 and fullpath)
which is ignored in the bottom part of the loop (where it fails both the "if
(is_note)" and the following "else if").
However, while adding a test to verify the handling of non-notes, I came
across an unrelated crasher in the notes.c code. Will send a fix for this
ASAP.
In any case, I think your proposed if-condition is better, and I will
rewrite the code accordingly.
> > @@ -2080,8 +2195,10 @@ static void note_change_n(struct branch *b)
> > typename(type), command_buf.buf);
> > }
> >
> > - tree_content_set(&b->branch_tree, sha1_to_hex(commit_sha1), sha1,
> > - S_IFREG | 0644, NULL);
> > + construct_path_with_fanout(sha1_to_hex(commit_sha1), fanout, path);
> > + b->num_notes += adjust_num_notes(&b->branch_tree, path, sha1);
> > + mode = (is_null_sha1(sha1) ? S_IFREG : NOTE_MODE) | 0644;
> > + tree_content_set(&b->branch_tree, path, sha1, mode, NULL);
>
> I wonder if it wouldn't be better to compute the fan out here on
> each put. That way if an importer drives 2,000,000 notes at once
> to us in a single commit, we don't wind up with a flat 0 fan-out
> tree and trying to perform a linear insert on each one, but instead
> will start to increase the fan out as the number of entries goes up.
>
> Basically, tree_content_set/remove are O(N) operations on N paths
> in the tree, because their structures aren't necessarily sorted.
> IIRC at one point in time I tried to do this with a binary search but
> gave up and just did it unsorted. At least using the fan out here
> would help partition the search space dramatically on large inserts.
This is a really good idea, but it's a bit more complicated than that:
An 'N' command may not only add new notes, but also rewrite existing notes,
and when rewriting an existing note we must take care to _replace_ the old
note, and not merely adding a new note at a different fanout level. The
above code implicitly guarantees this, by calling note_change_n() with the
'old' fanout level (which will cause the new note to overwrite the old note
in-place).
However, as long as we remember to check for (and remove, if found) the note
at the old fanout level, we might still be able to place the new note at the
_current_ fanout level [1], and thus avoid the worst case you describe
above. Hmm. I need to think some more about this...
Have fun! :)
...Johan
[1] This is actually not _completely_ right: If you have several 'N'
commands in the same commit that act on the same note, but happen to do so
in at least two different fanout levels, you will end up with two notes for
the same object (at least until do_change_note_fanout() arbitrarily
overwrites one of them with the other). However, this might be such a far-
fetched scenario, that we don't have to worry about it in practice.
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [RFC PATCH] Documentation: set a base URL for relative links
From: Junio C Hamano @ 2009-12-03 2:16 UTC (permalink / raw)
To: Todd Zullinger; +Cc: git
In-Reply-To: <20091203015005.GH23717@inocybe.localdomain>
Todd Zullinger <tmz@pobox.com> writes:
> I don't know the doc toolchain well enough to know how best to fix
> this without breaking anything. It would be ideal if the base URL
> used was substituted and controllable via make variables. That would
> allow packagers to make it point to the on-disk documentation and make
> git's documentation even easier to use when disconnected.
Thanks. It indeed appears that update to FC11 at k.org brought a few
issues to the documentation area.
I think we can do something like this and let distro people to decide what
URL to use.
Documentation/Makefile | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 3f59952..abb75eb 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -104,6 +104,10 @@ ifdef DOCBOOK_SUPPRESS_SP
XMLTO_EXTRA += -m manpage-suppress-sp.xsl
endif
+ifdef MAN_BASE_URL
+XMLTO_EXTRA += --stringparam man.base.url.for.relative.links=$(MAN_BASE_URL)
+endif
+
# If your target system uses GNU groff, it may try to render
# apostrophes as a "pretty" apostrophe using unicode. This breaks
# cut&paste, so you should set GNU_ROFF to force them to be ASCII
^ 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