* [PATCH 2/2] Document date formats accepted by parse_date()
From: Miklos Vajna @ 2009-12-02 22:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <3d547f4e32c026efc76a7dfe1572da617714f8c9.1259791789.git.vmiklos@frugalware.org>
---
Documentation/date-formats.txt | 23 +++++++++++++++++++++++
Documentation/git-commit-tree.txt | 1 +
Documentation/git-commit.txt | 2 ++
3 files changed, 26 insertions(+), 0 deletions(-)
create mode 100644 Documentation/date-formats.txt
diff --git a/Documentation/date-formats.txt b/Documentation/date-formats.txt
new file mode 100644
index 0000000..626c887
--- /dev/null
+++ b/Documentation/date-formats.txt
@@ -0,0 +1,23 @@
+DATE FORMATS
+------------
+
+The GIT_AUTHOR_DATE, GIT_COMMITTER_DATE environment variables
+ifdef::git-commit[]
+and the `--date` option
+endif::git-commit[]
+support the following date formats:
+
+Git native format::
+ It is `<unix timestamp> <timezone offset>`, where `<unix
+ timestamp>` is the number of seconds since the UNIX epoch.
+ `<timezone offset>` is a positive or negative offset from UTC.
+ For example CET (which is 2 hours ahead UTC) is `+0200`.
+
+RFC 2822::
+ The standard email format as described by RFC 2822, for example
+ `Thu, 07 Apr 2005 22:13:13 +0200`.
+
+ISO 8601::
+ Time and date specified by the ISO 8601 standard, for example
+ `2005-04-07T22:13:13`. The parser accepts a space instead of the
+ `T` character as well.
diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt
index b8834ba..4fec5d5 100644
--- a/Documentation/git-commit-tree.txt
+++ b/Documentation/git-commit-tree.txt
@@ -73,6 +73,7 @@ A commit comment is read from stdin. If a changelog
entry is not provided via "<" redirection, 'git-commit-tree' will just wait
for one to be entered and terminated with ^D.
+include::date-formats.txt[]
Diagnostics
-----------
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index cbbbeeb..17783b4 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -220,6 +220,8 @@ specified.
these files are also staged for the next commit on top
of what have been staged before.
+:git-commit: 1
+include::date-formats.txt[]
EXAMPLES
--------
--
1.6.5.2
^ permalink raw reply related
* [PATCH 1/2] builtin-commit: add --date option
From: Miklos Vajna @ 2009-12-02 22:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vpr6xcgki.fsf@alter.siamese.dyndns.org>
This is like --author: allow a user to specify a given date without
using the GIT_AUTHOR_DATE environment variable.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Wed, Dec 02, 2009 at 11:38:05AM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> So I do not think --date is something we urgently need, even though it
> might be nice to have it to be consistent with --author.
Changes from the previous version:
* updated the commit message
* rebased on top of current master that has --reset-author
Documentation/git-commit.txt | 5 ++++-
builtin-commit.c | 6 +++++-
t/t7501-commit.sh | 15 +++++++++++++++
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index d227cec..cbbbeeb 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -11,7 +11,7 @@ SYNOPSIS
'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]
[(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author]
[--allow-empty] [--no-verify] [-e] [--author=<author>]
- [--cleanup=<mode>] [--] [[-i | -o ]<file>...]
+ [--date=<date>] [--cleanup=<mode>] [--] [[-i | -o ]<file>...]
DESCRIPTION
-----------
@@ -85,6 +85,9 @@ OPTIONS
an existing commit that matches the given string and its author
name is used.
+--date=<date>::
+ Override the date used in the commit.
+
-m <msg>::
--message=<msg>::
Use the given <msg> as the commit message.
diff --git a/builtin-commit.c b/builtin-commit.c
index e93a647..9a1264a 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -52,7 +52,7 @@ static char *edit_message, *use_message;
static char *author_name, *author_email, *author_date;
static int all, edit_flag, also, interactive, only, amend, signoff;
static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
-static char *untracked_files_arg;
+static char *untracked_files_arg, *force_date;
/*
* The default commit message cleanup mode will remove the lines
* beginning with # (shell comments) and leading and trailing
@@ -90,6 +90,7 @@ static struct option builtin_commit_options[] = {
OPT_FILENAME('F', "file", &logfile, "read log from file"),
OPT_STRING(0, "author", &force_author, "AUTHOR", "override author for commit"),
+ OPT_STRING(0, "date", &force_date, "DATE", "override date for commit"),
OPT_CALLBACK('m', "message", &message, "MESSAGE", "specify commit message", opt_parse_m),
OPT_STRING('c', "reedit-message", &edit_message, "COMMIT", "reuse and edit message from specified commit"),
OPT_STRING('C', "reuse-message", &use_message, "COMMIT", "reuse message from specified commit"),
@@ -410,6 +411,9 @@ static void determine_author_info(void)
email = xstrndup(lb + 2, rb - (lb + 2));
}
+ if (force_date)
+ date = force_date;
+
author_name = name;
author_email = email;
author_date = date;
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index a603f6d..a529701 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -211,6 +211,21 @@ test_expect_success 'amend commit to fix author' '
'
+test_expect_success 'amend commit to fix date' '
+
+ test_tick &&
+ newtick=$GIT_AUTHOR_DATE &&
+ git reset --hard &&
+ git cat-file -p HEAD |
+ sed -e "s/author.*/author $author $newtick/" \
+ -e "s/^\(committer.*> \).*$/\1$GIT_COMMITTER_DATE/" > \
+ expected &&
+ git commit --amend --date="$newtick" &&
+ git cat-file -p HEAD > current &&
+ test_cmp expected current
+
+'
+
test_expect_success 'sign off (1)' '
echo 1 >positive &&
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH] builtin-commit: add --date option
From: Jeff King @ 2009-12-02 22:22 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20091202221232.GF31763@genesis.frugalware.org>
On Wed, Dec 02, 2009 at 11:12:32PM +0100, Miklos Vajna wrote:
> No, I want to set it to two days ago, for example when I forgot to
> commit at the end of the day and I notice it two days later before I
> start to work on something again.
OK. I think you are being overly meticulous about your commit date, but
that is your right. ;)
> > Also, is there a good reason why GIT_AUTHOR_DATE is not respected in
> > this case? If not, should we simply be fixing that bug instead?
>
> GIT_AUTHOR_DATE is respected by --reset-author, just given that we have
> --author already, using environment variables for a user can be
> uncomfortable.
OK, I can agree with that reasoning.
-Peff
^ permalink raw reply
* Re: [StGit PATCH v2 0/6] add support for git send-email
From: Catalin Marinas @ 2009-12-02 22:35 UTC (permalink / raw)
To: Alex Chiang; +Cc: git, Karl Wiberg
In-Reply-To: <20091202003503.7737.51579.stgit@bob.kio>
Hi Alex,
2009/12/2 Alex Chiang <achiang@hp.com>:
> This is v2 of the series that starts teaching stg mail how to
> call git send-email.
Thanks for posting these patches (and thanks to Karl for reviewing
them). I don't have much to comment (Karl did the hard work here) but
I'll give them a try tomorrow and let you know.
Thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCH 2/2] Document date formats accepted by parse_date()
From: Nanako Shiraishi @ 2009-12-02 22:33 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <831fc8f48429d5a21e29d04760b46b2ddfcb7d80.1259791789.git.vmiklos@frugalware.org>
Quoting Miklos Vajna <vmiklos@frugalware.org>
> ---
I don't think any message needs to be there, but a Signed-Off-By:
line should be.
> +The GIT_AUTHOR_DATE, GIT_COMMITTER_DATE environment variables
> +ifdef::git-commit[]
> +and the `--date` option
> +endif::git-commit[]
> +support the following date formats:
> +
> +Git native format::
> + It is `<unix timestamp> <timezone offset>`, where `<unix
> + timestamp>` is the number of seconds since the UNIX epoch.
> + `<timezone offset>` is a positive or negative offset from UTC.
> + For example CET (which is 2 hours ahead UTC) is `+0200`.
It is better to call it 'internal' format, instead of 'native'.
I think 'native' means the most natural way to Git, and users
view what 'git show' outputs as 'native'.
nana.git% git show -s v1.6.5^0 | grep Date
Date: Sat Oct 10 00:05:19 2009 -0700
nana.git% ./test-date parse 'Sat Oct 10 00:05:19 2009 -0700'
Sat Oct 10 00:05:19 2009 -0700 -> 2009-10-10 07:05:19 +0000
And 'Git native' format is also supported, I think.
> +RFC 2822::
> + The standard email format as described by RFC 2822, for example
> + `Thu, 07 Apr 2005 22:13:13 +0200`.
> +
> +ISO 8601::
> + Time and date specified by the ISO 8601 standard, for example
> + `2005-04-07T22:13:13`. The parser accepts a space instead of the
> + `T` character as well.
I didn't know about "T", but it works (^_^).
nana.git% ./test-date parse '2005-04-07T22:13:13'
2005-04-07T22:13:13 -> 2005-04-07 13:13:13 +0000
Is there something wrong with 'show'?
nana.git% ./test-date show '2005-04-07T22:13:13'
2005-04-07T22:13:13 -> 40 years ago
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH v2] Add --track option to git clone
From: Jeff King @ 2009-12-02 22:37 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: David Soria Parra, git
In-Reply-To: <20091203060708.6117@nanako3.lavabit.com>
On Thu, Dec 03, 2009 at 06:07:08AM +0900, Nanako Shiraishi wrote:
> > # most general case
> > git clone -f 'refs/heads/subset/*:refs/remotes/origin/*' remote.git
>
> Because this is only about branches and no other kinds of
> references, I think this is an overkill.
Perhaps. I'm not sure this has to be only about branches. You could do:
git clone -f tags/v1.6.1 git.git
though I admit I don't really have a burning desire to do so. I just
think it will be simple to make it flexible (since you have to build
such a refspec _anyway_), and there is no reason to restrict people who
might use it creatively.
The biggest argument against it would be that we are confusing the user
by giving too much rope, but I don't think that is the case here. If
you just use branches, you need never know that the full refspec exists
(just as some people use "git fetch origin master" without ever
understanding how "master" can be replaced by a full refspec).
> > git clone -f 'subset/*' remote.git
>
> But I think this is a good idea.
One question on this: does it fetch to "refs/remotes/origin/subset/*"
or to "refs/remotes/origin/*"?
I think the latter makes more sense (presumably you don't care that your
branches are in "subset/", since you by definition have asked for
nothing outside of that namespace).
> > # choose your favorite branch
> > git clone -f maint -f master -f next -f pu -b next git.git
> > ...
> > What do you think?
>
> I think your rule to make first branch given by -f the default
> for -b is a good idea. But I'm not very happy with the example
> with four -f. Can we probably write it like this?
>
> git clone -f maint,master,next,pu git.git
Yeah, that is much nicer. I think "," is allowed in ref names, but I
am tempted not to care here. It is not as if this is a low-level
feature, and most people will not be crazy enough to use commas in their
branch-names. IOW, you will get into trouble only if you have crazy
names _and_ you want to use this particular feature. If we wanted to be
complete, we could provide a quoting mechanism, but that is perhaps
excessive.
> If it isn't a good idea to use comma, we can use colon to split
> the list of branch names instead.
Colon would work (though of course it would imply not allowing full
refspecs with "-f"). However, I actually find
git clone -f maint:master:next:pu git.git
to be a bit ugly and confusing.
-Peff
^ permalink raw reply
* Re: [RFC/PATCHv9 01/11] fast-import: Proper notes tree manipulation
From: Johan Herland @ 2009-12-02 22:41 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, gitster
In-Reply-To: <20091202203953.GE31648@spearce.org>
On Wednesday 02 December 2009, Shawn O. Pearce wrote:
> Johan Herland <johan@herland.net> wrote:
> > diff --git a/fast-import.c b/fast-import.c
> > index b41d29f..b51ffbc 100644
> > --- a/fast-import.c
> > +++ b/fast-import.c
>
> This new version is much cleaner, thank you.
Thank you for the suggestions that made it so :)
The rest of your comments all make perfect sense. I'll whip up a replacement
patch shortly.
Thanks for the review!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH 2/2] Document date formats accepted by parse_date()
From: Jeff King @ 2009-12-02 22:42 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Miklos Vajna, Junio C Hamano, git
In-Reply-To: <20091203073313.6117@nanako3.lavabit.com>
On Thu, Dec 03, 2009 at 07:33:13AM +0900, Nanako Shiraishi wrote:
> Is there something wrong with 'show'?
>
> nana.git% ./test-date show '2005-04-07T22:13:13'
> 2005-04-07T22:13:13 -> 40 years ago
No. It doesn't call parse_date, but instead accepts a time_t-like
"seconds since epoch". I intentionally didn't use parse_date because I
didn't want bugs in parse_date to affect 'show' output, to keep testing
simple.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] Document date formats accepted by parse_date()
From: Junio C Hamano @ 2009-12-02 22:54 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Miklos Vajna, Junio C Hamano, Jeff King, git
In-Reply-To: <20091203073313.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Is there something wrong with 'show'?
>
> nana.git% ./test-date show '2005-04-07T22:13:13'
> 2005-04-07T22:13:13 -> 40 years ago
Heh, you fooled me, and Peff is right. "test-date show" does not
interpret its input any way other than as seconds-since-epoch.
I agree with the "native->internal" part of the suggestion. What see by
default in "git show" output is merely the ctime(3) format followed by
timezone. I don't mind if we call that "git native", even though I
suspect we do _not have to_ invent new word for that.
Also "test-date parse" seems to accept things like these:
'2009.04.07 20:21:22 -0000'
'04/07/2009 20:21:22 -0000'
'07.04.2009 20:21:22 -0000'
^ permalink raw reply
* Re: [PATCH] transport-helper: remove duplicate free()
From: Tay Ray Chuan @ 2009-12-02 23:00 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Sverre Rabbelier, Junio C Hamano
In-Reply-To: <alpine.LNX.2.00.0912021120440.14365@iabervon.org>
Hi,
On Thu, Dec 3, 2009 at 12:23 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> You need to remove the one in disconnect_helper, because the entire point
> of disconnect_helper as opposed to release_helper is to *not* free that
> memory. If you remove this one, you'll access freed memory in any case
> where the helper has to be quit and restarted.
I see. I guess I should have looked more closely at f2a3715 (Fix
memory leak in helper method for disconnect).
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH v2] Add --track option to git clone
From: Junio C Hamano @ 2009-12-02 23:02 UTC (permalink / raw)
To: Jeff King; +Cc: Nanako Shiraishi, David Soria Parra, git
In-Reply-To: <20091202223728.GB9691@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> git clone -f maint,master,next,pu git.git
>
> Yeah, that is much nicer. I think "," is allowed in ref names, but I
> am tempted not to care here. It is not as if this is a low-level
> feature, and most people will not be crazy enough to use commas in their
> branch-names. IOW, you will get into trouble only if you have crazy
> names _and_ you want to use this particular feature. If we wanted to be
> complete, we could provide a quoting mechanism, but that is perhaps
> excessive.
Yeah, I agree it is Ok not to support crazy people in this case. Not
supporting from the very beginning is quite different from _breaking_ them
;-)
^ permalink raw reply
* Re: [PATCH] pull: clarify advice for the unconfigured error case
From: Junio C Hamano @ 2009-12-02 23:08 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jan Krüger, Jeff King, Jan Nieuwenhuizen, Tomas Carnecky,
git list
In-Reply-To: <20091127141704.GA24080@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> From: Jan Krüger <jk@jk.gs>
>
> When pull --rebase fails because it cannot find what branch to
> merge against, the error message implies we are trying to merge.
> Say "rebase against" instead of "merge with" to avoid confusion.
I was going over the mail archive to see if I missed any important fixes
that should be in before 1.6.6 final and noticed that this is not applied,
and there was no follow-up to this message either.
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?
> diff --git a/git-pull.sh b/git-pull.sh
> index 37f3d93..2c384c4 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -91,45 +91,63 @@ error_on_no_merge_candidates () {
> esac
> done
>
> + if test true = "$rebase"
> + then
> + op_type=rebase
> + op_prep=against
> + else
> + op_type=merge
> + op_prep=with
> + fi
> +
> curr_branch=${curr_branch#refs/heads/}
> upstream=$(git config "branch.$curr_branch.merge")
> remote=$(git config "branch.$curr_branch.remote")
>
> if [ $# -gt 1 ]; then
> - echo "There are no candidates for merging in the refs that you just fetched."
> + if [ "$rebase" = true ]; then
> + printf "There is no candidate for rebasing against "
> + else
> + printf "There are no candidates for merging "
> + fi
> + echo "among the refs that you just fetched."
> echo "Generally this means that you provided a wildcard refspec which had no"
> echo "matches on the remote end."
> elif [ $# -gt 0 ] && [ "$1" != "$remote" ]; then
> echo "You asked to pull from the remote '$1', but did not specify"
> - echo "a branch to merge. Because this is not the default configured remote"
> + echo "a branch. Because this is not the default configured remote"
> echo "for your current branch, you must specify a branch on the command line."
> elif [ -z "$curr_branch" ]; then
> echo "You are not currently on a branch, so I cannot use any"
> echo "'branch.<branchname>.merge' in your configuration file."
> - echo "Please specify which branch you want to merge on the command"
> + echo "Please specify which remote branch you want to use on the command"
> echo "line and try again (e.g. 'git pull <repository> <refspec>')."
> echo "See git-pull(1) for details."
> elif [ -z "$upstream" ]; then
> echo "You asked me to pull without telling me which branch you"
> - echo "want to merge with, and 'branch.${curr_branch}.merge' in"
> - echo "your configuration file does not tell me either. Please"
> - echo "specify which branch you want to merge on the command line and"
> + echo "want to $op_type $op_prep, and 'branch.${curr_branch}.merge' in"
> + echo "your configuration file does not tell me, either. Please"
> + echo "specify which branch you want to use on the command line and"
> echo "try again (e.g. 'git pull <repository> <refspec>')."
> echo "See git-pull(1) for details."
> echo
> - echo "If you often merge with the same branch, you may want to"
> - echo "configure the following variables in your configuration"
> - echo "file:"
> + echo "If you often $op_type $op_prep the same branch, you may want to"
> + echo "use something like the following in your configuration file:"
> + echo
> + echo " [branch \"${curr_branch}\"]"
> + echo " remote = <nickname>"
> + echo " merge = <remote-ref>"
> + test rebase = "$op_type" &&
> + echo " rebase = true"
> echo
> - echo " branch.${curr_branch}.remote = <nickname>"
> - echo " branch.${curr_branch}.merge = <remote-ref>"
> - echo " remote.<nickname>.url = <url>"
> - echo " remote.<nickname>.fetch = <refspec>"
> + echo " [remote \"<nickname>\"]"
> + echo " url = <url>"
> + echo " fetch = <refspec>"
> echo
> echo "See git-config(1) for details."
> else
> - echo "Your configuration specifies to merge the ref '${upstream#refs/heads/}' from the"
> - echo "remote, but no such ref was fetched."
> + echo "Your configuration specifies to $op_type $op_prep the ref '${upstream#refs/heads/}'"
> + echo "from the remote, but no such ref was fetched."
> fi
> exit 1
> }
> --
> 1.6.5.3
^ permalink raw reply
* [ANNOUNCE] GIT 1.6.6.rc1
From: Junio C Hamano @ 2009-12-02 23:24 UTC (permalink / raw)
To: git
A release candidate GIT 1.6.6.rc1 is available at the usual places
for testing:
http://www.kernel.org/pub/software/scm/git/
git-1.6.6.rc1.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.6.rc1.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.6.rc1.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
testing/git-*-1.6.6.rc1-1.fc11.$arch.rpm (RPM)
Git v1.6.6 Release Notes (draft)
================================
Notes on behaviour change
-------------------------
* In this release, "git fsck" defaults to "git fsck --full" and
checks packfiles, and because of this it will take much longer to
complete than before. If you prefer a quicker check only on loose
objects (the old default), you can say "git fsck --no-full". This
has been supported by 1.5.4 and newer versions of git, so it is
safe to write it in your script even if you use slightly older git
on some of your machines.
Preparing yourselves for compatibility issues in 1.7.0
------------------------------------------------------
In git 1.7.0, which is planned to be the release after 1.6.6, there will
be a handful of behaviour changes that will break backward compatibility.
These changes were discussed long time ago and existing behaviours have
been identified as more problematic to the userbase than keeping them for
the sake of backward compatibility.
When necessary, transition strategy for existing users has been designed
not to force them running around setting configuration variables and
updating their scripts in order to either keep the traditional behaviour
or use the new behaviour on the day their sysadmin decides to install
the new version of git. When we switched from "git-foo" to "git foo" in
1.6.0, even though the change had been advertised and the transition
guide had been provided for a very long time, the users procrastinated
during the entire transtion period, and ended up panicking on the day
their sysadmins updated their git installation. We tried very hard to
avoid repeating that unpleasantness.
For changes decided to be in 1.7.0, we have been much louder to strongly
discourage such procrastination. If you have been using recent versions
of git, you would have already seen warnings issued when you exercised
features whose behaviour will change, with the instruction on how to
keep the existing behaviour if you want to. You hopefully should be
well prepared already.
Of course, we have also given "this and that will change in 1.7.0;
prepare yourselves" warnings in the release notes and announcement
messages. Let's see how well users will fare this time.
* "git push" into a branch that is currently checked out (i.e. pointed by
HEAD in a repository that is not bare) will be refused by default.
Similarly, "git push $there :$killed" to delete the branch $killed
in a remote repository $there, when $killed branch is the current
branch pointed at by its HEAD, will be refused by default.
Setting the configuration variables receive.denyCurrentBranch and
receive.denyDeleteCurrent to 'ignore' in the receiving repository
can be used to override these safety features. Versions of git
since 1.6.2 have issued a loud warning when you tried to do them
without setting the configuration, so repositories of people who
still need to be able to perform such a push should already have
been future proofed.
Please refer to:
http://git.or.cz/gitwiki/GitFaq#non-bare
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
for more details on the reason why this change is needed and the
transition process that already took place so far.
* "git send-email" will not make deep threads by default when sending a
patch series with more than two messages. All messages will be sent
as a reply to the first message, i.e. cover letter. Git 1.6.6 (this
release) will issue a warning about the upcoming default change, when
it uses the traditional "deep threading" behaviour as the built-in
default. To squelch the warning but still use the "deep threading"
behaviour, give --chain-reply-to option or set sendemail.chainreplyto
to true.
It has been possible to configure send-email to send "shallow thread"
by setting sendemail.chainreplyto configuration variable to false.
The only thing 1.7.0 release will do is to change the default when
you haven't configured that variable.
* "git status" will not be "git commit --dry-run". This change does not
affect you if you run the command without pathspec.
Nobody sane found the current behaviour of "git status Makefile" useful
nor meaningful, and it confused users. "git commit --dry-run" has been
provided as a way to get the current behaviour of this command since
1.6.5.
* "git diff" traditionally treated various "ignore whitespace" options
only as a way to filter the patch output. "git diff --exit-code -b"
exited with non-zero status even if all changes were about changing the
ammount of whitespace and nothing else. and "git diff -b" showed the
"diff --git" header line for such a change without patch text.
In 1.7.0, the "ignore whitespaces" will affect the semantics of the
diff operation itself. A change that does not affect anything but
whitespaces will be reported with zero exit status when run with
--exit-code, and there will not be "diff --git" header for such a
change.
Updates since v1.6.5
--------------------
(subsystems)
* various git-gui updates including new translations, wm states, etc.
* git-svn updates.
* "git fetch" over http learned a new mode that is different from the
traditional "dumb commit walker".
(portability)
* imap-send can be built on mingw port.
(performance)
* "git diff -B" has smaller memory footprint.
(usability, bells and whistles)
* The object replace mechanism can be bypassed with --no-replace-objects
global option given to the "git" program.
* In configuration files, a few variables that name paths can begin with ~/
and ~username/ and they are expanded as expected.
* "git subcmd -h" now shows short usage help for many more subcommands.
* "git bisect reset" can reset to an arbitrary commit.
* "git checkout frotz" when there is no local branch "frotz" but there
is only one remote tracking branch "frotz" is taken as a request to
start the named branch at the corresponding remote tracking branch.
* "git commit -c/-C/--amend" can be told with a new "--reset-author" option
to ignore authorship information in the commit it is taking the message
from.
* "git describe" can be told to add "-dirty" suffix with "--dirty" option.
* "git diff" learned --submodule option to show a list of one-line logs
instead of differences between the commit object names.
* "git diff" learned to honor diff.color.func configuration to paint
function name hint printed on the hunk header "@@ -j,k +l,m @@" line
in the specified color.
* "git fetch" learned --all and --multiple options, to run fetch from
many repositories, and --prune option to remove remote tracking
branches that went stale. These make "git remote update" and "git
remote prune" less necessary (there is no plan to remove "remote
update" nor "remote prune", though).
* "git fsck" by default checks the packfiles (i.e. "--full" is the
default); you can turn it off with "git fsck --no-full".
* "git grep" can use -F (fixed strings) and -i (ignore case) together.
* import-tars contributed fast-import frontend learned more types of
compressed tarballs.
* "git instaweb" knows how to talk with mod_cgid to apache2.
* "git log --decorate" shows the location of HEAD as well.
* "git log" and "git rev-list" learned to take revs and pathspecs from
the standard input with the new "--stdin" option.
* "--pretty=format" option to "log" family of commands learned:
. to wrap text with the "%w()" specifier.
. to show reflog information with "%g[sdD]" specifier.
* "git notes" command to annotate existing commits.
* "git merge" (and "git pull") learned --ff-only option to make it fail
if the merge does not result in a fast-forward.
* The ancient "git merge <message> HEAD <branch>..." syntax will be
removed in later versions of git. A warning is given and tells
users to use the "git merge -m <message> <branch>..." instead.
* "git mergetool" learned to use p4merge.
* "git rebase -i" learned "reword" that acts like "edit" but immediately
starts an editor to tweak the log message without returning control to
the shell, which is done by "edit" to give an opportunity to tweak the
contents.
* "git send-email" can be told with "--envelope-sender=auto" to use the
same address as "From:" address as the envelope sender address.
* "git send-email" will issue a warning when it defaults to the
--chain-reply-to behaviour without being told by the user and
instructs to prepare for the change of the default in 1.7.0 release.
* In "git submodule add <repository> <path>", <path> is now optional and
inferred from <repository> the same way "git clone <repository>" does.
* "git svn" learned to read SVN 1.5+ and SVK merge tickets.
* "gitweb" can optionally render its "blame" output incrementally (this
requires JavaScript on the client side).
* Author names shown in gitweb output are links to search commits by the
author.
Fixes since v1.6.5
------------------
All of the fixes in v1.6.5.X maintenance series are included in this
release, unless otherwise noted.
* Enumeration of available merge strategies iterated over the list of
commands in a wrong way, sometimes producing an incorrect result.
Will backport by merging ed87465 (builtin-merge.c: call
exclude_cmds() correctly., 2009-11-25).
* "git format-patch revisions... -- path" issued an incorrect error
message that suggested to use "--" on the command line when path
does not exist in the current work tree (it is a separate matter if
it makes sense to limit format-patch with pathspecs like that
without using the --full-diff option). Will backport by merging
7e93d3b (format-patch: add test for parsing of "--", 2009-11-26).
* "git shortlog" did not honor the "encoding" header embedded in the
commit object like "git log" did. Will backport by merging 79f7ca0
(shortlog: respect commit encoding, 2009-11-25).
----------------------------------------------------------------
Changes since v1.6.6-rc0 are as follows:
Avery Pennarun (1):
builtin-merge.c: call exclude_cmds() correctly.
Benjamin Kramer (1):
Explicitly truncate bswap operand to uint32_t
Bert Wesarg (2):
Give the hunk comment its own color
get_ref_states: strdup entries and free util in stale list
Björn Gustavsson (11):
Teach the --all option to 'git fetch'
Teach the --multiple option to 'git fetch'
Add the configuration option skipFetchAll
Add missing test for 'git remote update --prune'
Re-implement 'git remote update' using 'git fetch'
Clarify and correct -z
apply: apply works outside a repository
apply: Format all options using back-quotes
apply: Use the term "working tree" consistently
Fix over-simplified documentation for 'git log -z'
gitworkflows: Consistently back-quote git commands
Brian Gernhardt (1):
t/gitweb-lib: Split HTTP response with non-GNU sed
Christian Couder (6):
Documentation: add "Fighting regressions with git bisect" article
replace: use a GIT_NO_REPLACE_OBJECTS env variable
Documentation: fix typos and spelling in replace documentation
Documentation: talk a little bit about GIT_NO_REPLACE_OBJECTS
bisect: simplify calling visualizer using '--bisect' option
Documentation: update descriptions of revision options related to '--bisect'
David Aguilar (1):
help: Do not unnecessarily look for a repository
David Soria Parra (1):
Documentation: Document --branch option in git clone synopsis
Erick Mattos (1):
commit -c/-C/--amend: reset timestamp and authorship to committer with --reset-author
Felipe Contreras (3):
format-patch: fix parsing of "--" on the command line
format-patch: add test for parsing of "--"
send-email: automatic envelope sender
Horst H. von Brand (1):
git-pull.sh: Fix call to git-merge for new command format
Jakub Narebski (10):
gitweb: Add optional "time to generate page" info in footer
gitweb: Incremental blame (using JavaScript)
gitweb: Colorize 'blame_incremental' view during processing
gitweb: Create links leading to 'blame_incremental' using JavaScript
gitweb: Minify gitweb.js if JSMIN is defined
t/gitweb-lib.sh: Split gitweb output into headers and body
gitweb: Document current snapshot rules via new tests
gitweb.js: Harden setting blamed commit info in incremental blame
gitweb: Make linking to actions requiring JavaScript a feature
gitweb: Add link to other blame implementation in blame views
Jay Soffian (4):
remote: refactor some logic into get_stale_heads()
teach warn_dangling_symref to take a FILE argument
builtin-fetch: add --prune option
builtin-fetch: add --dry-run option
Jeff King (1):
prune-packed: only show progress when stderr is a tty
Johannes Sixt (2):
t4014-format-patch: do not assume 'test' is available as non-builtin
Add a notice that only certain functions can print color escape codes
Jonathan Nieder (1):
Makefile: do not clean arm directory
Junio C Hamano (19):
mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Pretty-format: %[+-]x to tweak inter-item newlines
read_revision_from_stdin(): use strbuf
Teach --stdin option to "log" family
setup_revisions(): do not call get_pathspec() too early
Make --stdin option to "log" family read also pathspecs
t9001: test --envelope-sender option of send-email
Add trivial tests for --stdin option to log family
Protect scripted Porcelains from GREP_OPTIONS insanity
builtin-apply.c: pay attention to -p<n> when determining the name
Remove dead code from "git am"
emit_line(): don't emit an empty <SET><RESET> followed by a newline
Update draft release notes to 1.6.6 before merging topics for -rc1
git-merge: a deprecation notice of the ancient command line syntax
Update draft release notes to 1.6.6 before -rc1
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
Git 1.6.6-rc1
Mark Rada (2):
gitweb: check given hash before trying to create snapshot
gitweb: Smarter snapshot names
Martin Storsjö (3):
Disable CURLOPT_NOBODY before enabling CURLOPT_PUT and CURLOPT_POST
Refactor winsock initialization into a separate function
Enable support for IPv6 on MinGW
Matthew Ogilvie (5):
cvsserver doc: database generally can not be reproduced consistently
config documentation: some configs are auto-set by git-init
t2300: use documented technique to invoke git-sh-setup
t3409 t4107 t7406 t9150: use dashless commands
t/README: Document GIT_TEST_INSTALLED and GIT_TEST_EXEC_PATH
Matthieu Moy (4):
merge-recursive: point the user to commit when file would be overwritten.
user-manual: Document that "git merge" doesn't like uncommited changes.
merge-recursive: make the error-message generation an extern function
builtin-merge: show user-friendly error messages for fast-forward too.
Michael J Gruber (1):
Documentation: Fix a few i.e./e.g. mix-ups
Nanako Shiraishi (2):
t1200: fix a timing dependent error
prepare send-email for smoother change of --chain-reply-to default
Nicolas Pitre (1):
pack-objects: split implications of --all-progress from progress activation
Ramsay Allan Jones (1):
git-count-objects: Fix a disk-space under-estimate on Cygwin
René Scharfe (2):
strbuf_add_wrapped_text(): skip over colour codes
mergetool--lib: simplify guess_merge_tool()
Stephen Boyd (3):
gitweb.js: fix null object exception in initials calculation
instaweb: restart server if already running
gitweb.js: fix padLeftStr() and its usage
Tay Ray Chuan (1):
remote-curl.c: fix rpc_out()
Uwe Kleine-König (1):
shortlog: respect commit encoding
^ permalink raw reply
* [PATCH 2/2 v2] Document date formats accepted by parse_date()
From: Miklos Vajna @ 2009-12-02 23:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Jeff King, git
In-Reply-To: <7v638p9ebz.fsf@alter.siamese.dyndns.org>
---
On Wed, Dec 02, 2009 at 02:54:40PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> I agree with the "native->internal" part of the suggestion.
Changed.
> Also "test-date parse" seems to accept things like these:
>
> '2009.04.07 20:21:22 -0000'
> '04/07/2009 20:21:22 -0000'
> '07.04.2009 20:21:22 -0000'
Ah OK, I just tried 2009.04.07 (without the time part) and thought it
was about approxidate() as well. I added them.
Documentation/date-formats.txt | 26 ++++++++++++++++++++++++++
Documentation/git-commit-tree.txt | 1 +
Documentation/git-commit.txt | 2 ++
3 files changed, 29 insertions(+), 0 deletions(-)
create mode 100644 Documentation/date-formats.txt
diff --git a/Documentation/date-formats.txt b/Documentation/date-formats.txt
new file mode 100644
index 0000000..c000f08
--- /dev/null
+++ b/Documentation/date-formats.txt
@@ -0,0 +1,26 @@
+DATE FORMATS
+------------
+
+The GIT_AUTHOR_DATE, GIT_COMMITTER_DATE environment variables
+ifdef::git-commit[]
+and the `--date` option
+endif::git-commit[]
+support the following date formats:
+
+Git internal format::
+ It is `<unix timestamp> <timezone offset>`, where `<unix
+ timestamp>` is the number of seconds since the UNIX epoch.
+ `<timezone offset>` is a positive or negative offset from UTC.
+ For example CET (which is 2 hours ahead UTC) is `+0200`.
+
+RFC 2822::
+ The standard email format as described by RFC 2822, for example
+ `Thu, 07 Apr 2005 22:13:13 +0200`.
+
+ISO 8601::
+ Time and date specified by the ISO 8601 standard, for example
+ `2005-04-07T22:13:13`. The parser accepts a space instead of the
+ `T` character as well.
++
+NOTE: In addition, the date part is accepted in the following formats:
+`YYYY.MM.DD`, `MM/DD/YYYY` and `DD.MM.YYYY`.
diff --git a/Documentation/git-commit-tree.txt b/Documentation/git-commit-tree.txt
index b8834ba..4fec5d5 100644
--- a/Documentation/git-commit-tree.txt
+++ b/Documentation/git-commit-tree.txt
@@ -73,6 +73,7 @@ A commit comment is read from stdin. If a changelog
entry is not provided via "<" redirection, 'git-commit-tree' will just wait
for one to be entered and terminated with ^D.
+include::date-formats.txt[]
Diagnostics
-----------
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index cbbbeeb..17783b4 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -220,6 +220,8 @@ specified.
these files are also staged for the next commit on top
of what have been staged before.
+:git-commit: 1
+include::date-formats.txt[]
EXAMPLES
--------
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH] pull: clarify advice for the unconfigured error case
From: Jonathan Nieder @ 2009-12-03 1:26 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jan Krüger, Jeff King, Jan Nieuwenhuizen, Tomas Carnecky,
git list
In-Reply-To: <7vk4x57z4e.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> From: Jan Krüger <jk@jk.gs>
>>
>> When pull --rebase fails because it cannot find what branch to
>> merge against, the error message implies we are trying to merge.
>> Say "rebase against" instead of "merge with" to avoid confusion.
[...]
> 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'
Yes, that is the intent.
> and does the lack of follow-up mean everybody involved in the discussion
> is happy with this version?
I’m not sure. I know I like it. :-)
I was the only one with nitpicks about the wording (sorry). Re
whether to use configuration file syntax or a 'git config' command
line snippet, it seemed like there was some consensus once it was
clear that the user would have to modify the lines anyway to fill in
the right values. But others can speak up if this seems wrong.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: Git documentation consistency (was: "git merge" merges too much!)
From: Greg A. Woods @ 2009-12-03 1:21 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <20091202200904.GA7631@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 3500 bytes --]
At Wed, 2 Dec 2009 15:09:04 -0500, Jeff King <peff@peff.net> wrote:
Subject: Re: "git merge" merges too much!
>
> I find git is much simpler to use and understand if you start "at the
> bottom" with the basic concepts (because for the most part, git is
> really a set of tools for manipulating the few basic data structures).
I think that's the problem actually -- I don't really want to know too
much about how it works under the hood (yet), I just want to use it in
the most effective way for my purposes.
There's lots of talk about using Git as the basis for a true high-level
VCS and SCM system, yet it doesn't look to me that anyone has created
such a VCS or SCMS using Git.
> I skimmed it and didn't see any inconsistency. If you have something
> specific in mind, please point it out so we can fix it.
I think anyone who's been participating on this list for any significant
amount of time is far too close to the subject to be able to serve as a
candid independent technical editor who could really help clean things
up and make the documentation much more consistent. Obviously such an
editor would also require the help of experts at all the details too. :-)
Unfortunately I'm not a very good technical editor, and I don't really
have time to devote to doing such editing of documentation either.
> > (git-log(1) is worse than ls(1) for having too many options, but worst
> > of all in the release I'm still using it doesn't respond sensibly nor
> > consistently with other commands when given the "-?" option.)
>
> $ ls -?
> ls: invalid option -- '?'
> Try `ls --help' for more information.
Please keep in mind all the world is not GNU:
$ ls -?
ls: unknown option -- ?
usage: ls [-AaBbCcdFfghikLlmnopqRrSsTtuWwx1] [file ...]
My point was that _most_ other Git sub-commands already do respond to
"-?" sensibly with real, helpful, information; usually a summary of the
command options and parameters.
I.e. this is yet another form of inconsistency in "documentation" in
Git. :-)
The reference to "ls" was just as a comparison with it's somewhat
extensive variety of options. In fact "git log" is way more complex
than "ls" because its parameters are not all just simple flags like
those for "ls" -- they often have their own parameters too.
> $ git log -h
> usage: git log [<options>] [<since>..<until>] [[--] <path>...]
> or: git show [options] <object>...
Indeed, so why the heck can't it do something similar with '-?'. That's
just sloppy programming, no? Most other commands know '-?', and despite
the silliness with GNU Ls, use of '-?' to request summary usage
information is pretty much a de facto standard for unix commands.
Your point about mentioning "--help" in the summary usage information is
a good one though -- especially for a command with a very complex set of
command-line parameters. However that alone isn't sufficient -- users
still need the summary as that alone helps trigger associations and may
be sufficient to allow a user to proceed quickly to get the command to
do what they want.
(the whole "fatal: not a git repository" error for "git foo -[h?]"
handling is also a rather silly one -- but I guess when something grows
quickly and from many inputs there's not always time to keep some of
these basic things clean and consistent)
--
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: Junio C Hamano @ 2009-12-03 1:34 UTC (permalink / raw)
To: Greg A. Woods; +Cc: The Git Mailing List
In-Reply-To: <m1NG0O6-000kmgC@most.weird.com>
"Greg A. Woods" <woods@planix.com> writes:
> $ ls -?
> ls: unknown option -- ?
> usage: ls [-AaBbCcdFfghikLlmnopqRrSsTtuWwx1] [file ...]
> ...
> Most other commands know '-?', and despite
> the silliness with GNU Ls, use of '-?' to request summary usage
> information is pretty much a de facto standard for unix commands.
I think you are showing ignorance here, as -? is *not* even close to
standard, nor even widely used practice at all. 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.
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.
^ permalink raw reply
* Re: [PATCH] pull: clarify advice for the unconfigured error case
From: Jeff King @ 2009-12-03 1:43 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Jan Krüger, Jan Nieuwenhuizen,
Tomas Carnecky, git list
In-Reply-To: <20091203012535.GA16259@progeny.tock>
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?
>
> I’m not sure. I know I like it. :-)
>
> I was the only one with nitpicks about the wording (sorry). Re
> whether to use configuration file syntax or a 'git config' command
> line snippet, it seemed like there was some consensus once it was
> clear that the user would have to modify the lines anyway to fill in
> the right values. But others can speak up if this seems wrong.
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.
-Peff
^ permalink raw reply
* [RFC PATCH] Documentation: set a base URL for relative links
From: Todd Zullinger @ 2009-12-03 1:50 UTC (permalink / raw)
To: git
The man.base.url.for.relative.links setting is used when generating the
NOTES sections of various man pages. If unset, the output looks like
this:
1. Everyday Git
[set $man.base.url.for.relative.links]/everyday.html
Reported-by: Michal Schmidt (Fedora bug #543481)
Signed-off-by: Todd Zullinger <tmz@pobox.com>
---
This was reported to the Fedora bugzilla. I checked and it's been
broken in the Fedora builds for quite a while. In origin/man, the
first time it appeared was 3ae5cb60 (Autogenerated manpages for
v1.6.5.1-75-g02d56), which looks to be around the time that kernel.org
switched from F9 to F11.
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.
Any help or suggestions to refine this and test it on various docbook
versions would be most welcome.
Documentation/manpage-base.xsl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/manpage-base.xsl b/Documentation/manpage-base.xsl
index a264fa6..50ce029 100644
--- a/Documentation/manpage-base.xsl
+++ b/Documentation/manpage-base.xsl
@@ -7,6 +7,10 @@
<xsl:param name="man.output.quietly" select="1"/>
<xsl:param name="refentry.meta.get.quietly" select="1"/>
+<!-- set a base URL for relative links -->
+<xsl:param name="man.base.url.for.relative.links"
+ >http://www.kernel.org/pub/software/scm/git/docs/</xsl:param>
+
<!-- convert asciidoc callouts to man page format;
git.docbook.backslash and git.docbook.dot params
must be supplied by another XSL file or other means -->
--
1.6.6.rc0
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Just because everything is different doesn't mean anything has
changed.
-- Irene Peter
^ permalink raw reply related
* Re: Git documentation consistency (was: "git merge" merges too much!)
From: Jeff King @ 2009-12-03 2:07 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <m1NG0O6-000kmgC@most.weird.com>
On Wed, Dec 02, 2009 at 08:21:39PM -0500, Greg A. Woods wrote:
> > I find git is much simpler to use and understand if you start "at the
> > bottom" with the basic concepts (because for the most part, git is
> > really a set of tools for manipulating the few basic data structures).
>
> I think that's the problem actually -- I don't really want to know too
> much about how it works under the hood (yet), I just want to use it in
> the most effective way for my purposes.
>
> There's lots of talk about using Git as the basis for a true high-level
> VCS and SCM system, yet it doesn't look to me that anyone has created
> such a VCS or SCMS using Git.
Sure, I can understand that. And I invite you (or anyone) to work on
such a VCS, and I am sure I am not alone on the list in sincerely hoping
you succeed and offering to help support however core git developers
can. But we have seen people try this in the past, and it never quite
seems to work.
All of the cogito people ended up migrating to git. I was one of them.
In my case, the git tools offered better access to the fundamental
operations, which is what I found interesting and powerful about it. I
suspect some others migrated for the same reasons, though perhaps many
did simply because cogito did not keep up with core git in terms of
features.
There is also "eg" these days, which attempts to do what you're saying.
I don't know how big a userbase it has; I've never been personally
interested in it.
> I think anyone who's been participating on this list for any significant
> amount of time is far too close to the subject to be able to serve as a
> candid independent technical editor who could really help clean things
> up and make the documentation much more consistent. Obviously such an
> editor would also require the help of experts at all the details too. :-)
Sure, I think an outsider doing a really nice job of overhauling the
documentation would be nice. There are some git books, some by insiders,
and some not. For the same reason that you mention, it would hard for me
to assess their quality with too much objectivity. :)
My question was more of a "leaving aside overhauling the documentation,
did you see something obvious that we can fix right now" kind of thing.
> > $ ls -?
> > ls: invalid option -- '?'
> > Try `ls --help' for more information.
>
> Please keep in mind all the world is not GNU:
>
> $ ls -?
> ls: unknown option -- ?
> usage: ls [-AaBbCcdFfghikLlmnopqRrSsTtuWwx1] [file ...]
Right, but my point is unchanged. Neither ls actually _recognizes_
"-?". They do the same for "--bogosity".
> My point was that _most_ other Git sub-commands already do respond to
> "-?" sensibly with real, helpful, information; usually a summary of the
> command options and parameters.
Yes, for the same reason that "ls" does: they don't recognize it. But if
you are asking for "git log" to produce the short usage message, then
that is part of my issue (1) from the last message: "log" doesn't use
the same parseopt library as (most of) the rest of git[1].
Yes, it's inconsistent. Those inconsistencies were introduced over time
(before we had parseopt), and we are slowly fixing them over time.
Patches welcome. :)
[1] There are other inconsistencies because of this, too. You can't say
"git log -pz", but must say "git log -p -z".
> > $ git log -h
> > usage: git log [<options>] [<since>..<until>] [[--] <path>...]
> > or: git show [options] <object>...
>
> Indeed, so why the heck can't it do something similar with '-?'. That's
> just sloppy programming, no? Most other commands know '-?', and despite
> the silliness with GNU Ls, use of '-?' to request summary usage
> information is pretty much a de facto standard for unix commands.
Nothing "knows" -?, but it is true that the parseopt-ified commands
behave differently (and IMHO, better). You can call it sloppy, I guess;
it is really an artifact of commands being written and changing over
time. As I said, we are slowly converging on consistency.
And no, I don't want to get into a big debate over whether it is better
to plan your software up front, or to let it evolve over time. I have
opinions that do not necessarily line up with how git came into being,
but the end product is useful enough that I like to use it and hack on
it. :)
> (the whole "fatal: not a git repository" error for "git foo -[h?]"
> handling is also a rather silly one -- but I guess when something grows
> quickly and from many inputs there's not always time to keep some of
> these basic things clean and consistent)
The problem here is that there are two chunks of code: the "git"
wrapper, and the "log" command. The wrapper knows a few things about
each command like "does it need to be in a git repository?", and checks
that before we even look at the command-line options. There is an
explicit "check for --help" hack. Fixing that startup procedure to be
more sane would be possible, but there are a lot of hidden demons
lurking in changing the order of the startup sequence. Again, patches
welcome. :)
-Peff
^ 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
* 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
* [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: 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 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
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