* Re: t5541-http-push hanging
From: Shawn O. Pearce @ 2009-11-12 4:26 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <B17AB159-E217-4E1F-BEA3-97E5892C13F4@gernhardtsoftware.com>
Brian Gernhardt <brian@gernhardtsoftware.com> wrote:
> My build script for git has been hanging at t5541.2 and I haven't had the tuits to discover why. Here's what I've gotten so far, in case anyone can figure it out faster:
...
> Initialized empty Git repository in /Users/brian/dev/git/t/trash directory.t5541-http-push/test_repo_clone/.git/
> error: RPC failed; result=22, HTTP code = 500
> ^CFATAL: Unexpected exit with code 130
...
>
> [Wed Nov 11 06:19:39 2009] [error] [client 127.0.0.1] git-http-backend(59490) malloc: *** error for object 0x100200340: incorrect checksum for freed object - object was probably modified after being freed.
> [Wed Nov 11 06:19:39 2009] [error] [client 127.0.0.1] *** set a breakpoint in malloc_error_break to debug
> [Wed Nov 11 06:19:40 2009] [error] [client 127.0.0.1] Premature end of script headers: git-http-backend
Probably caused by a missing cast:
diff --git a/http-backend.c b/http-backend.c
index f8ea9d7..957e4ef 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -136,7 +136,7 @@ static void hdr_str(const char *name, const char *value)
static void hdr_int(const char *name, size_t value)
{
- format_write(1, "%s: %" PRIuMAX "\r\n", name, value);
+ format_write(1, "%s: %" PRIuMAX "\r\n", name, (uintmax_t)value);
}
static void hdr_date(const char *name, unsigned long when)
--
Shawn.
^ permalink raw reply related
* [PATCH todo] dodoc: detect doctype-xsl version before making docs
From: Jonathan Nieder @ 2009-11-12 2:31 UTC (permalink / raw)
To: gitster; +Cc: git
The manpages in the man branch of git.git appear to have acquired
the dreaded escaped .ft disease when the docbook-xsl toolchain
was upgraded to v1.74.3.
---
It is hard work avoiding escaped nroff directives in output. I am a
bit confused at what happened here, since docbook-xsl v1.73.2 should
have required the same settings.
These changes are untested, unfortunately. I hope they can be of some
help nevertheless.
dodoc.sh | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/dodoc.sh b/dodoc.sh
index 5cbc269..bf49710 100755
--- a/dodoc.sh
+++ b/dodoc.sh
@@ -77,6 +77,19 @@ asciidoc' 8'.*)
export ASCIIDOC8 ;;
esac
+db_version_file=/usr/share/xml/docbook/stylesheet/nwalsh/VERSION
+case "$(grep "<fm:Version>" "$db_version_file" 2>/dev/null)" in
+*1.72*)
+ DOCBOOK_XSL_172=YesPlease
+ export DOCBOOK_XSL_172 ;;
+*1.69.[1-9]* | *1.70* | *1.71.0*)
+ DOCBOOK_SUPPRESS_SP=YesPlease
+ export DOCBOOK_SUPPRESS_SP ;;
+*1.7[3-9]* | *1.6[0-8]*)
+ ASCIIDOC_NO_ROFF=YesPlease
+ export ASCIIDOC_NO_ROFF ;;
+esac
+
make >./:html.log 2>&1 \
-C Documentation -j 2 \
WEBDOC_DEST="$DOCREPO/doc-html-inst" install-webdoc || exit
--
1.6.5.2
^ permalink raw reply related
* [PATCH] Update 'git remote' usage and man page to match.
From: Tim Henigan @ 2009-11-12 1:56 UTC (permalink / raw)
To: git
This commit:
1) Removes documentation of '--verbose' from the synopsis portion
of the usage string since it is a general option.
2) Removes the 'remote' option from 'git remote update' in the
man page. This option had already been removed from the usage
string in the code, but the man page was not updated to match.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
---
Documentation/git-remote.txt | 4 ++--
builtin-remote.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 82a3d29..32ff95b 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -9,14 +9,14 @@ git-remote - manage set of tracked repositories
SYNOPSIS
--------
[verse]
-'git remote' [-v | --verbose]
+'git remote'
'git remote add' [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
'git remote rename' <old> <new>
'git remote rm' <name>
'git remote set-head' <name> [-a | -d | <branch>]
'git remote show' [-n] <name>
'git remote prune' [-n | --dry-run] <name>
-'git remote update' [-p | --prune] [group | remote]...
+'git remote update' [-p | --prune] [group]...
DESCRIPTION
-----------
diff --git a/builtin-remote.c b/builtin-remote.c
index 0777dd7..3756e91 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -8,14 +8,14 @@
#include "refs.h"
static const char * const builtin_remote_usage[] = {
- "git remote [-v | --verbose]",
+ "git remote",
"git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>",
"git remote rename <old> <new>",
"git remote rm <name>",
"git remote set-head <name> [-a | -d | <branch>]",
"git remote show [-n] <name>",
"git remote prune [-n | --dry-run] <name>",
- "git remote [-v | --verbose] update [-p | --prune] [group]",
+ "git remote update [-p | --prune] [group]",
NULL
};
--
1.6.5.2.180.gc5b3e.dirty
^ permalink raw reply related
* Re: [PATCHv2] Update gitworkflows man page to include release workflow
From: Raman Gupta @ 2009-11-12 0:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Thomas Rast
In-Reply-To: <7vzl6soniu.fsf@alter.siamese.dyndns.org>
Thanks for your review. Comments inline.
Junio C Hamano wrote:
> rocketraman@fastmail.fm writes:
>
>> From: Raman Gupta <raman@rocketraman.com>
>>
>> The gitworkflows man page currently provides an overview of the workflows
>> used by git.git itself to serve as inspiration for people to use when
>> designing their own workflows. The current man page does a reasonable
>> job at describing the development process, but it does not contain any
>> guidance as to the workflow used for releases. Now add a basic
>> introduction to the branch management required for a release, so that a
>> reader may understand how the maint, master, next, and topic branches are
>> affected.
>> ---
>
> Is this meant to show how git.git does its release to serve as an
> inspiration to others? The document does not seem to describe how I make
> releases.
Here is the existing intro to gitworkflows:
===================
This document attempts to write down and motivate some of the workflow
elements used for git.git itself. Many ideas apply in general, though
the full workflow is rarely required for smaller projects with fewer
people involved.
We formulate a set of rules for quick reference, while the prose tries
to motivate each of them. Do not always take them literally; you
should value good reasons for your actions higher than manpages such
as this one.
===================
It is in this spirit that I am attempting to add to this document in
relation to the release process. If after you read through this email
you don't agree this patch has any value in gitworkflows, let me know
so that I can stop wasting my time and yours.
>> diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
>> index 2b021e3..69b789a 100644
>> --- a/Documentation/gitworkflows.txt
>> +++ b/Documentation/gitworkflows.txt
>> @@ -348,6 +348,103 @@ in patches to figure out the merge base. See linkgit:git-am[1] for
>> other options.
>>
>>
>> +RELEASE WORKFLOW
>> +----------------
>> +
>> +The maintainer may use the following release workflow:
>
> Please set the tone straight. If this is to suggest various possible
> workflows in general vague terms, "may use" would be good. If this is to
> precisely describe what I do, then there won't be "you could do this, or
> you could do that." Your "may use" suggests the former, but the commit
> log message claims the latter. Which document are you writing?
Ok. The current document is inconsistent. In places it uses "the
maintainer" and in other places it uses "you". In any case, it seems
that the "maintainer" here is not "Junio Hamano" -- rather, it is the
reader.
Let me create a separate (and first) cleanup patch to fix the existing
inconsistencies in this man page. I would prefer to use the pronoun
"you" consistently as also suggested by Thomas Rast.
In addition, I will update the commit log message to be consistent.
>
> Assuming that you are writing what I do...
>
>> +He first tags the tip of 'master' with a release tag, then he updates
>> +the 'maint' branch to the current tip of 'master' for managing future
>> +maintenance fixes on the current release, and lastly he optionally
>> +rebuilds 'next' from the tip of 'master'.
>
> Not in that order.
Ok, I'll work on the order.
> - doubly make sure that there is nothing left in 'maint' that
> is not in 'master';
> - review 'master' more thoroughly than usual;
As per the intro to the man page, I think you will agree these items
are not required. They follow under the category of the user thinking
about what they are doing -- the man page is not meant to provide the
user with a "monkey-see, monkey-do" series of steps.
> - review RelNotes symlink, Documentation/RelNotes-X.Y.Z.txt,
> the stalenotes section in Documentation/git.git, and
> GIT-VERSION-GEN for the last time;
> - tag it;
> - review it again for the last time;
> - test on buildfarm;
> - cut tarball;
> - cut RPM on FC11 i386 and FC11 x86_64;
I will update the commit log message to show that my intent was to
talk about how the git.git integration and topic branches are affected
by the release rather than providing a complete project release
process. General items like release notes, version files, reviews,
tests, and cutting distribution tarballs are not specific to git.git
nor git. For git.git, these items better belong in MaintNotes and the
release checklist.txt (as they do) rather than this user distributed
man page.
> - push the tag and master branch alone to the public server---this
> triggers an autobuilder for documentation pages, updates man and
> html branches and documentation tarballs;
I think it makes sense to include some verbiage around the push
aspect, as it is part of the distributed nature of git. I'll add this.
The autobuilder is not git specific so should be excluded via the
logic above -- except perhaps the hook part, which I could mention in
general terms when discussing the push e.g.
"You may decide to use a hook script on the public repository to
initiate release-related items such as building documentation."
> When making a maintenance release, everything is the same except that
> 'maint' is used instead of 'master'.
Good point -- I will add a section about maintenance releases.
> Then, after all the release task on 'master' (or 'maint') is done,
> propagate that upwards (i.e. merge 'master' to 'next' and 'pu').
Will add this.
> Merging 'master' to 'maint' is done totally as a separate step, often a
> few days later, "Now the big release is done, let's start maintenance
> track for that relase".
>
> And then after that, 'next' may be rebuilt.
Ok, I'll change the order/wording accordingly.
>> +Release Tagging
>> +~~~~~~~~~~~~~~~
>> +
>> +The new feature release is tagged on 'master' with a tag matching
>> +vX.Y.Z, where X.Y.Z is the new feature release version.
>> +
>> +.Release tagging
>> +[caption="Recipe: "]
>> +=====================================
>> +`git tag -s -m "GIT X.Y.Z" vX.Y.Z master`
>> +=====================================
>
> There is no incorrect information here, but I do not think there is
> anything particularly worth saying here, either. It is in "git tag"
> manpage and anybody can run "git cat-file tag v1.6.3" to learn what is in
> there.
The intention of this is not to illustrate the "git tag" syntax but
rather so that the user understands the tag description and naming
conventions used by git.git -- this prompts them mentally to consider
defining conventions for their project. Therefore, I'd like to keep this.
>> +Maintenance branch update
>> +~~~~~~~~~~~~~~~~~~~~~~~~~
>
> This section largely overlaps with Documentation/howto/maintain-git.txt; I
> am starting to doubt if we even need a new section in the workflows
> document. Perhaps we could have a release management section in the
> Documentation/howto/maintain-git.txt, though.
Based on my comments and changes above, do you still have this doubt?
Remember that the audience of a man page is not the git team -- it is
users. A new user to git who is considering developing branch
processes and conventions around their git project will have access to
a man page such as gitworkflows but will not have (easy) access to
maintain-git.txt.
This is in fact why I decided to make this patch submission -- I found
gitworkflows to be very helpful in creating a layout for my git
projects, but found that gitworkflows was missing any guidance as to
what to do with my integration and topic branches when I needed to cut
a release. It was a while before I found maintain-git.txt, and most
users will never find it.
>> +[caption="Recipe: "]
>> +=====================================
>> +* `git checkout maint`
>> +* `git merge master`
>> +=====================================
>> +
>> +This updates 'maint' from 'master', while preserving the 'maint'
>> +reflog.
>> +
>> +An alternative approach to updating the 'maint' branch is to run
>> +
>> + $ git branch -f maint master
>
> As I already said, I never do this "alternative", and I do not want
> anybody who will take over git.git maintenance to do so. There is no
> reason to encourage nor even mention "branch -f" here. As 'maint' is
> supposed to be a strict subset, pulling 'master' to 'maint' should fast
> forward and otherwise you (the maintainer) would notice that there was a
> mistake made. If you use "branch -f", you will never notice.
I know you do not do this alternative, however I added it as per our
previous discussion. I quote from
http://article.gmane.org/gmane.comp.version-control.git/115183:
>> I'll add some discussion about the branch -f bit -- I hope you agree
>> that in this document that is distributed with git, some
>> beginner-level explanation of the difference between the branch -f and
>> the merge approach is warranted?
>
> Surely and thanks.
I will try to make the reason why "branch -f" is not a good option
more clear. I'd like to keep this because many newbies coming from VCs
like subversion will default to taking the "branch -f" approach
because that is conceptually closer to the way subversion works (I
know I did).
Thanks for your comments.
Cheers,
Raman
^ permalink raw reply
* [PATCH 9/9] Provide a build time default-pager setting
From: Jonathan Nieder @ 2009-11-12 0:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
Provide a DEFAULT_PAGER knob so packagers can set the fallback
pager to something appropriate during the build.
Examples:
On (old) solaris systems, /usr/bin/less (typically the first less
found) doesn't understand the default arguments (FXRS), which
forces users to alter their environment (PATH, GIT_PAGER, LESS,
etc) or have a local or global gitconfig before paging works as
expected.
On Debian systems, by policy packages must fall back to the
'pager' command, so that changing the target of the
/usr/bin/pager symlink changes the default pager for all packages
at once.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
As in pu.
Makefile | 11 +++++++++++
| 6 +++++-
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 625866c..18fc50a 100644
--- a/Makefile
+++ b/Makefile
@@ -201,6 +201,10 @@ all::
#
# Define NO_REGEX if you have no or inferior regex support in your C library.
#
+# Define DEFAULT_PAGER to a sensible pager command (defaults to "less") if
+# you want to use something different. The value will be interpreted by the
+# shell at runtime when it is used.
+#
# Define DEFAULT_EDITOR to a sensible editor command (defaults to "vi") if you
# want to use something different. The value will be interpreted by the shell
# if necessary when it is used. Examples:
@@ -1380,6 +1384,13 @@ DEFAULT_EDITOR_CQ_SQ = $(subst ','\'',$(DEFAULT_EDITOR_CQ))
BASIC_CFLAGS += -DDEFAULT_EDITOR='$(DEFAULT_EDITOR_CQ_SQ)'
endif
+ifdef DEFAULT_PAGER
+DEFAULT_PAGER_CQ = "$(subst ",\",$(subst \,\\,$(DEFAULT_PAGER)))"
+DEFAULT_PAGER_CQ_SQ = $(subst ','\'',$(DEFAULT_PAGER_CQ))
+
+BASIC_CFLAGS += -DDEFAULT_PAGER='$(DEFAULT_PAGER_CQ_SQ)'
+endif
+
ALL_CFLAGS += $(BASIC_CFLAGS)
ALL_LDFLAGS += $(BASIC_LDFLAGS)
--git a/pager.c b/pager.c
index 0b63d99..92c03f6 100644
--- a/pager.c
+++ b/pager.c
@@ -2,6 +2,10 @@
#include "run-command.h"
#include "sigchain.h"
+#ifndef DEFAULT_PAGER
+#define DEFAULT_PAGER "less"
+#endif
+
/*
* This is split up from the rest of git so that we can do
* something different on Windows.
@@ -60,7 +64,7 @@ const char *git_pager(void)
if (!pager)
pager = getenv("PAGER");
if (!pager)
- pager = "less";
+ pager = DEFAULT_PAGER;
else if (!*pager || !strcmp(pager, "cat"))
pager = NULL;
--
1.6.5.2
^ permalink raw reply related
* [PATCH 8/9] Provide a build time default-editor setting
From: Jonathan Nieder @ 2009-11-12 0:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
Provide a DEFAULT_EDITOR knob to allow setting the fallback
editor to use instead of vi (when VISUAL, EDITOR, and GIT_EDITOR
are unset). The value can be set at build time according to a
system’s policy. For example, on Debian systems, the default
editor should be the 'editor' command.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Unchanged.
Makefile | 17 +++++++++++++++++
editor.c | 6 +++++-
t/t7005-editor.sh | 37 +++++++++++++++++++++++++------------
3 files changed, 47 insertions(+), 13 deletions(-)
diff --git a/Makefile b/Makefile
index 268aede..625866c 100644
--- a/Makefile
+++ b/Makefile
@@ -200,6 +200,14 @@ all::
# memory allocators with the nedmalloc allocator written by Niall Douglas.
#
# Define NO_REGEX if you have no or inferior regex support in your C library.
+#
+# Define DEFAULT_EDITOR to a sensible editor command (defaults to "vi") if you
+# want to use something different. The value will be interpreted by the shell
+# if necessary when it is used. Examples:
+#
+# DEFAULT_EDITOR='~/bin/vi',
+# DEFAULT_EDITOR='$GIT_FALLBACK_EDITOR',
+# DEFAULT_EDITOR='"C:\Program Files\Vim\gvim.exe" --nofork'
GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
@$(SHELL_PATH) ./GIT-VERSION-GEN
@@ -1363,6 +1371,15 @@ BASIC_CFLAGS += -DSHA1_HEADER='$(SHA1_HEADER_SQ)' \
$(COMPAT_CFLAGS)
LIB_OBJS += $(COMPAT_OBJS)
+# Quote for C
+
+ifdef DEFAULT_EDITOR
+DEFAULT_EDITOR_CQ = "$(subst ",\",$(subst \,\\,$(DEFAULT_EDITOR)))"
+DEFAULT_EDITOR_CQ_SQ = $(subst ','\'',$(DEFAULT_EDITOR_CQ))
+
+BASIC_CFLAGS += -DDEFAULT_EDITOR='$(DEFAULT_EDITOR_CQ_SQ)'
+endif
+
ALL_CFLAGS += $(BASIC_CFLAGS)
ALL_LDFLAGS += $(BASIC_LDFLAGS)
diff --git a/editor.c b/editor.c
index 70618f1..615f575 100644
--- a/editor.c
+++ b/editor.c
@@ -2,6 +2,10 @@
#include "strbuf.h"
#include "run-command.h"
+#ifndef DEFAULT_EDITOR
+#define DEFAULT_EDITOR "vi"
+#endif
+
const char *git_editor(void)
{
const char *editor = getenv("GIT_EDITOR");
@@ -19,7 +23,7 @@ const char *git_editor(void)
return NULL;
if (!editor)
- editor = "vi";
+ editor = DEFAULT_EDITOR;
return editor;
}
diff --git a/t/t7005-editor.sh b/t/t7005-editor.sh
index a95fe19..5257f4d 100755
--- a/t/t7005-editor.sh
+++ b/t/t7005-editor.sh
@@ -4,7 +4,21 @@ test_description='GIT_EDITOR, core.editor, and stuff'
. ./test-lib.sh
-for i in GIT_EDITOR core_editor EDITOR VISUAL vi
+unset EDITOR VISUAL GIT_EDITOR
+
+test_expect_success 'determine default editor' '
+
+ vi=$(TERM=vt100 git var GIT_EDITOR) &&
+ test -n "$vi"
+
+'
+
+if ! expr "$vi" : '^[a-z]*$' >/dev/null
+then
+ vi=
+fi
+
+for i in GIT_EDITOR core_editor EDITOR VISUAL $vi
do
cat >e-$i.sh <<-EOF
#!$SHELL_PATH
@@ -12,19 +26,18 @@ do
EOF
chmod +x e-$i.sh
done
-unset vi
-mv e-vi.sh vi
-unset EDITOR VISUAL GIT_EDITOR
+
+if ! test -z "$vi"
+then
+ mv e-$vi.sh $vi
+fi
test_expect_success setup '
- msg="Hand edited" &&
+ msg="Hand-edited" &&
+ test_commit "$msg" &&
echo "$msg" >expect &&
- git add vi &&
- test_tick &&
- git commit -m "$msg" &&
- git show -s --pretty=oneline |
- sed -e "s/^[0-9a-f]* //" >actual &&
+ git show -s --format=%s > actual &&
diff actual expect
'
@@ -54,7 +67,7 @@ test_expect_success 'dumb should prefer EDITOR to VISUAL' '
TERM=vt100
export TERM
-for i in vi EDITOR VISUAL core_editor GIT_EDITOR
+for i in $vi EDITOR VISUAL core_editor GIT_EDITOR
do
echo "Edited by $i" >expect
unset EDITOR VISUAL GIT_EDITOR
@@ -78,7 +91,7 @@ done
unset EDITOR VISUAL GIT_EDITOR
git config --unset-all core.editor
-for i in vi EDITOR VISUAL core_editor GIT_EDITOR
+for i in $vi EDITOR VISUAL core_editor GIT_EDITOR
do
echo "Edited by $i" >expect
case "$i" in
--
1.6.5.2
^ permalink raw reply related
* [PATCH 7/9] am -i, git-svn: use "git var GIT_PAGER"
From: Jonathan Nieder @ 2009-11-12 0:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
Use the new "git var GIT_PAGER" command to ask what pager to use.
Without this change, the core.pager configuration is ignored by
these commands.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Unchanged.
git-am.sh | 5 ++++-
git-svn.perl | 6 ++----
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index c132f50..2649487 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -649,7 +649,10 @@ do
[eE]*) git_editor "$dotest/final-commit"
action=again ;;
[vV]*) action=again
- LESS=-S ${PAGER:-less} "$dotest/patch" ;;
+ : ${GIT_PAGER=$(git var GIT_PAGER)}
+ : ${LESS=-FRSX}
+ export LESS
+ $GIT_PAGER "$dotest/patch" ;;
*) action=again ;;
esac
done
diff --git a/git-svn.perl b/git-svn.perl
index 42c9a72..c4ca548 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -5171,10 +5171,8 @@ sub git_svn_log_cmd {
# adapted from pager.c
sub config_pager {
- $pager ||= $ENV{GIT_PAGER} || $ENV{PAGER};
- if (!defined $pager) {
- $pager = 'less';
- } elsif (length $pager == 0 || $pager eq 'cat') {
+ chomp(my $pager = command_oneline(qw(var GIT_PAGER)));
+ if ($pager eq 'cat') {
$pager = undef;
}
$ENV{GIT_PAGER_IN_USE} = defined($pager);
--
1.6.5.2
^ permalink raw reply related
* [PATCH 6/9] add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"
From: Jonathan Nieder @ 2009-11-12 0:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
Use the new "git var GIT_EDITOR" feature to decide what editor to
use, instead of duplicating its logic elsewhere. This should make
the behavior of commands in edge cases (e.g., editor names with
spaces) a little more consistent.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Unchanged from pu.
Documentation/config.txt | 4 +---
Documentation/git-commit.txt | 2 +-
Documentation/git-send-email.txt | 4 ++--
contrib/fast-import/git-p4 | 5 +----
git-add--interactive.perl | 3 +--
git-send-email.perl | 3 ++-
git-sh-setup.sh | 19 ++++++-------------
git-svn.perl | 5 ++---
8 files changed, 16 insertions(+), 29 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d1e2120..5181b77 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -387,9 +387,7 @@ core.editor::
Commands such as `commit` and `tag` that lets you edit
messages by launching an editor uses the value of this
variable when it is set, and the environment variable
- `GIT_EDITOR` is not set. The order of preference is
- `GIT_EDITOR` environment, `core.editor`, `VISUAL` and
- `EDITOR` environment variables and then finally `vi`.
+ `GIT_EDITOR` is not set. See linkgit:git-var[1].
core.pager::
The command that git will use to paginate output. Can
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 0578a40..3ea80c8 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -323,7 +323,7 @@ ENVIRONMENT AND CONFIGURATION VARIABLES
The editor used to edit the commit log message will be chosen from the
GIT_EDITOR environment variable, the core.editor configuration variable, the
VISUAL environment variable, or the EDITOR environment variable (in that
-order).
+order). See linkgit:git-var[1] for details.
HOOKS
-----
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 767cf4d..c85d7f4 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -60,8 +60,8 @@ The --bcc option must be repeated for each user you want on the bcc list.
The --cc option must be repeated for each user you want on the cc list.
--compose::
- Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR to edit an
- introductory message for the patch series.
+ Invoke a text editor (see GIT_EDITOR in linkgit:git-var[1])
+ to edit an introductory message for the patch series.
+
When '--compose' is used, git send-email will use the From, Subject, and
In-Reply-To headers specified in the message. If the body of the message
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index e710219..48059d0 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -729,13 +729,10 @@ class P4Submit(Command):
tmpFile.write(submitTemplate + separatorLine + diff + newdiff)
tmpFile.close()
mtime = os.stat(fileName).st_mtime
- defaultEditor = "vi"
- if platform.system() == "Windows":
- defaultEditor = "notepad"
if os.environ.has_key("P4EDITOR"):
editor = os.environ.get("P4EDITOR")
else:
- editor = os.environ.get("EDITOR", defaultEditor);
+ editor = read_pipe("git var GIT_EDITOR")
system(editor + " " + fileName)
response = "y"
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 69aeaf0..0c74e5c 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -987,8 +987,7 @@ sub edit_hunk_manually {
EOF
close $fh;
- my $editor = $ENV{GIT_EDITOR} || $repo->config("core.editor")
- || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
+ chomp(my $editor = run_cmd_pipe(qw(git var GIT_EDITOR)));
system('sh', '-c', $editor.' "$@"', $editor, $hunkfile);
if ($? != 0) {
diff --git a/git-send-email.perl b/git-send-email.perl
index a0279de..4f5da4e 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -162,7 +162,8 @@ my $compose_filename;
# Handle interactive edition of files.
my $multiedit;
-my $editor = $ENV{GIT_EDITOR} || Git::config(@repo, "core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
+my $editor = Git::command_oneline('var', 'GIT_EDITOR');
+
sub do_edit {
if (defined($multiedit) && !$multiedit) {
map {
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index c41c2f7..99cceeb 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -99,19 +99,12 @@ set_reflog_action() {
}
git_editor() {
- : "${GIT_EDITOR:=$(git config core.editor)}"
- : "${GIT_EDITOR:=${VISUAL:-${EDITOR}}}"
- case "$GIT_EDITOR,$TERM" in
- ,dumb)
- echo >&2 "No editor specified in GIT_EDITOR, core.editor, VISUAL,"
- echo >&2 "or EDITOR. Tried to fall back to vi but terminal is dumb."
- echo >&2 "Please set one of these variables to an appropriate"
- echo >&2 "editor or run $0 with options that will not cause an"
- echo >&2 "editor to be invoked (e.g., -m or -F for git-commit)."
- exit 1
- ;;
- esac
- eval "${GIT_EDITOR:=vi}" '"$@"'
+ if test -z "${GIT_EDITOR:+set}"
+ then
+ GIT_EDITOR="$(git var GIT_EDITOR)" || return $?
+ fi
+
+ eval "$GIT_EDITOR" '"$@"'
}
is_bare_repository () {
diff --git a/git-svn.perl b/git-svn.perl
index 6a3b501..42c9a72 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1321,9 +1321,8 @@ sub get_commit_entry {
close $log_fh or croak $!;
if ($_edit || ($type eq 'tree')) {
- my $editor = $ENV{VISUAL} || $ENV{EDITOR} || 'vi';
- # TODO: strip out spaces, comments, like git-commit.sh
- system($editor, $commit_editmsg);
+ chomp(my $editor = command_oneline(qw(var GIT_EDITOR)));
+ system('sh', '-c', $editor.' "$@"', $editor, $commit_editmsg);
}
rename $commit_editmsg, $commit_msg or croak $!;
{
--
1.6.5.2
^ permalink raw reply related
* [PATCH 5/9] Teach git var about GIT_PAGER
From: Jonathan Nieder @ 2009-11-12 0:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
Expose the command found by setup_pager() for scripts to use.
Scripts can use this to avoid repeating the logic to look for a
proper pager in each command.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
The rest of the series is unchanged from pu.
Documentation/git-var.txt | 6 ++++++
cache.h | 1 +
| 18 +++++++++++++++---
var.c | 10 ++++++++++
4 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt
index 89e4b4f..ef6aa81 100644
--- a/Documentation/git-var.txt
+++ b/Documentation/git-var.txt
@@ -44,6 +44,12 @@ GIT_EDITOR::
environment variable, then `core.editor` configuration, then
`$VISUAL`, then `$EDITOR`, and then finally 'vi'.
+GIT_PAGER::
+ Text viewer for use by git commands (e.g., 'less'). The value
+ is meant to be interpreted by the shell. The order of preference
+ is the `$GIT_PAGER` environment variable, then `core.pager`
+ configuration, then `$PAGER`, and then finally 'less'.
+
Diagnostics
-----------
You don't exist. Go away!::
diff --git a/cache.h b/cache.h
index 311cfe1..5aaa4ba 100644
--- a/cache.h
+++ b/cache.h
@@ -751,6 +751,7 @@ extern const char *git_committer_info(int);
extern const char *fmt_ident(const char *name, const char *email, const char *date_str, int);
extern const char *fmt_name(const char *name, const char *email);
extern const char *git_editor(void);
+extern const char *git_pager(void);
struct checkout {
const char *base_dir;
--git a/pager.c b/pager.c
index 86facec..0b63d99 100644
--- a/pager.c
+++ b/pager.c
@@ -44,12 +44,14 @@ static void wait_for_pager_signal(int signo)
raise(signo);
}
-void setup_pager(void)
+const char *git_pager(void)
{
- const char *pager = getenv("GIT_PAGER");
+ const char *pager;
if (!isatty(1))
- return;
+ return NULL;
+
+ pager = getenv("GIT_PAGER");
if (!pager) {
if (!pager_program)
git_config(git_default_config, NULL);
@@ -60,6 +62,16 @@ void setup_pager(void)
if (!pager)
pager = "less";
else if (!*pager || !strcmp(pager, "cat"))
+ pager = NULL;
+
+ return pager;
+}
+
+void setup_pager(void)
+{
+ const char *pager = git_pager();
+
+ if (!pager)
return;
spawned_pager = 1; /* means we are emitting to terminal */
diff --git a/var.c b/var.c
index b502487..d9892f8 100644
--- a/var.c
+++ b/var.c
@@ -18,6 +18,15 @@ static const char *editor(int flag)
return pgm;
}
+static const char *pager(int flag)
+{
+ const char *pgm = git_pager();
+
+ if (!pgm)
+ pgm = "cat";
+ return pgm;
+}
+
struct git_var {
const char *name;
const char *(*read)(int);
@@ -26,6 +35,7 @@ static struct git_var git_vars[] = {
{ "GIT_COMMITTER_IDENT", git_committer_info },
{ "GIT_AUTHOR_IDENT", git_author_info },
{ "GIT_EDITOR", editor },
+ { "GIT_PAGER", pager },
{ "", NULL },
};
--
1.6.5.2
^ permalink raw reply related
* [PATCH 4/9] Teach git var about GIT_EDITOR
From: Jonathan Nieder @ 2009-11-12 0:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
Expose the command used by launch_editor() for scripts to use.
This should allow one to avoid searching for a proper editor
separately in each command.
git_editor(void) uses the logic to decide which editor to use
that used to live in launch_editor(). The function returns NULL
if there is no suitable editor; the caller is expected to issue
an error message when appropriate.
launch_editor() uses git_editor() and gives the error message the
same way as before when EDITOR is not set.
"git var GIT_EDITOR" gives the editor name, or an error message
when there is no appropriate one.
"git var -l" gives GIT_EDITOR=name only if there is an
appropriate editor.
Originally-submitted-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Changes from the version in pu:
* unsquashed with the previous patch;
* replaces Hannes’s sign-off with something more descriptive (see
<http://thread.gmane.org/gmane.comp.version-control.git/131471/focus=131851>);
* nicer commit message based on Junio’s summary.
Documentation/git-var.txt | 8 ++++++++
cache.h | 1 +
editor.c | 14 ++++++++++++--
var.c | 16 +++++++++++++++-
4 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt
index e2f4c09..89e4b4f 100644
--- a/Documentation/git-var.txt
+++ b/Documentation/git-var.txt
@@ -36,6 +36,14 @@ GIT_AUTHOR_IDENT::
GIT_COMMITTER_IDENT::
The person who put a piece of code into git.
+GIT_EDITOR::
+ Text editor for use by git commands. The value is meant to be
+ interpreted by the shell when it is used. Examples: `~/bin/vi`,
+ `$SOME_ENVIRONMENT_VARIABLE`, `"C:\Program Files\Vim\gvim.exe"
+ --nofork`. The order of preference is the `$GIT_EDITOR`
+ environment variable, then `core.editor` configuration, then
+ `$VISUAL`, then `$EDITOR`, and then finally 'vi'.
+
Diagnostics
-----------
You don't exist. Go away!::
diff --git a/cache.h b/cache.h
index 96840c7..311cfe1 100644
--- a/cache.h
+++ b/cache.h
@@ -750,6 +750,7 @@ extern const char *git_author_info(int);
extern const char *git_committer_info(int);
extern const char *fmt_ident(const char *name, const char *email, const char *date_str, int);
extern const char *fmt_name(const char *name, const char *email);
+extern const char *git_editor(void);
struct checkout {
const char *base_dir;
diff --git a/editor.c b/editor.c
index 3f13751..70618f1 100644
--- a/editor.c
+++ b/editor.c
@@ -2,7 +2,7 @@
#include "strbuf.h"
#include "run-command.h"
-int launch_editor(const char *path, struct strbuf *buffer, const char *const *env)
+const char *git_editor(void)
{
const char *editor = getenv("GIT_EDITOR");
const char *terminal = getenv("TERM");
@@ -16,11 +16,21 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
editor = getenv("EDITOR");
if (!editor && terminal_is_dumb)
- return error("terminal is dumb, but EDITOR unset");
+ return NULL;
if (!editor)
editor = "vi";
+ return editor;
+}
+
+int launch_editor(const char *path, struct strbuf *buffer, const char *const *env)
+{
+ const char *editor = git_editor();
+
+ if (!editor)
+ return error("Terminal is dumb, but EDITOR unset");
+
if (strcmp(editor, ":")) {
size_t len = strlen(editor);
int i = 0;
diff --git a/var.c b/var.c
index dacbaab..b502487 100644
--- a/var.c
+++ b/var.c
@@ -8,6 +8,16 @@
static const char var_usage[] = "git var [-l | <variable>]";
+static const char *editor(int flag)
+{
+ const char *pgm = git_editor();
+
+ if (!pgm && flag & IDENT_ERROR_ON_NO_NAME)
+ die("Terminal is dumb, but EDITOR unset");
+
+ return pgm;
+}
+
struct git_var {
const char *name;
const char *(*read)(int);
@@ -15,14 +25,18 @@ struct git_var {
static struct git_var git_vars[] = {
{ "GIT_COMMITTER_IDENT", git_committer_info },
{ "GIT_AUTHOR_IDENT", git_author_info },
+ { "GIT_EDITOR", editor },
{ "", NULL },
};
static void list_vars(void)
{
struct git_var *ptr;
+ const char *val;
+
for (ptr = git_vars; ptr->read; ptr++)
- printf("%s=%s\n", ptr->name, ptr->read(0));
+ if ((val = ptr->read(0)))
+ printf("%s=%s\n", ptr->name, val);
}
static const char *read_var(const char *var)
--
1.6.5.2
^ permalink raw reply related
* [PATCH 3/9] Suppress warnings from "git var -l"
From: Jonathan Nieder @ 2009-11-11 23:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
For scripts using "git var -l" to read all logical variables at
once, not all per-variable warnings will be relevant. So suppress
them.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
This is a separate issue that might even deserve to be ejected
from the series.
Changes from jn/editor-pager: unsquashed from the next patch, added
back comment-changing hunk. Of course, there’s no harm in omitting
the comment change, but it describes a change in reality: before this
patch, that code gets run multiple times by "git var -l"; afterwards,
by no one (except possible out-of-tree users).
ident.c | 2 +-
var.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/ident.c b/ident.c
index 99f1c85..26409b2 100644
--- a/ident.c
+++ b/ident.c
@@ -205,7 +205,7 @@ const char *fmt_ident(const char *name, const char *email,
if ((warn_on_no_name || error_on_no_name) &&
name == git_default_name && env_hint) {
fprintf(stderr, env_hint, au_env, co_env);
- env_hint = NULL; /* warn only once, for "git var -l" */
+ env_hint = NULL; /* warn only once */
}
if (error_on_no_name)
die("empty ident %s <%s> not allowed", name, email);
diff --git a/var.c b/var.c
index 125c0d1..dacbaab 100644
--- a/var.c
+++ b/var.c
@@ -22,7 +22,7 @@ static void list_vars(void)
{
struct git_var *ptr;
for (ptr = git_vars; ptr->read; ptr++)
- printf("%s=%s\n", ptr->name, ptr->read(IDENT_WARN_ON_NO_NAME));
+ printf("%s=%s\n", ptr->name, ptr->read(0));
}
static const char *read_var(const char *var)
--
1.6.5.2
^ permalink raw reply related
* [PATCH 2/9] Do not use VISUAL editor on dumb terminals
From: Jonathan Nieder @ 2009-11-11 23:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
Refuse to use $VISUAL and fall back to $EDITOR if TERM is unset
or set to "dumb". Traditionally, VISUAL is set to a screen
editor and EDITOR to a line-based editor, which should be more
useful in that situation.
vim, for example, is happy to assume a terminal supports ANSI
sequences even if TERM is dumb (e.g., when running from a text
editor like Acme). git already refuses to fall back to vi on a
dumb terminal if GIT_EDITOR, core.editor, VISUAL, and EDITOR are
unset, but without this patch, that check is suppressed by
VISUAL=vi.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Fixes broken sign-off, patch unchanged.
I am personally most interested in this for usage from a text editor,
but vim does not set TERM=dumb like it probably ought to. A more
realistic everyday example might be "ssh user@domain git commit".
editor.c | 12 ++++++------
t/t7005-editor.sh | 10 ++++++++++
t/t7501-commit.sh | 8 ++++----
t/test-lib.sh | 8 ++++----
4 files changed, 24 insertions(+), 14 deletions(-)
diff --git a/editor.c b/editor.c
index 941c0b2..3f13751 100644
--- a/editor.c
+++ b/editor.c
@@ -4,19 +4,19 @@
int launch_editor(const char *path, struct strbuf *buffer, const char *const *env)
{
- const char *editor, *terminal;
+ const char *editor = getenv("GIT_EDITOR");
+ const char *terminal = getenv("TERM");
+ int terminal_is_dumb = !terminal || !strcmp(terminal, "dumb");
- editor = getenv("GIT_EDITOR");
if (!editor && editor_program)
editor = editor_program;
- if (!editor)
+ if (!editor && !terminal_is_dumb)
editor = getenv("VISUAL");
if (!editor)
editor = getenv("EDITOR");
- terminal = getenv("TERM");
- if (!editor && (!terminal || !strcmp(terminal, "dumb")))
- return error("Terminal is dumb but no VISUAL nor EDITOR defined.");
+ if (!editor && terminal_is_dumb)
+ return error("terminal is dumb, but EDITOR unset");
if (!editor)
editor = "vi";
diff --git a/t/t7005-editor.sh b/t/t7005-editor.sh
index b647957..a95fe19 100755
--- a/t/t7005-editor.sh
+++ b/t/t7005-editor.sh
@@ -42,6 +42,16 @@ test_expect_success 'dumb should error out when falling back on vi' '
fi
'
+test_expect_success 'dumb should prefer EDITOR to VISUAL' '
+
+ EDITOR=./e-EDITOR.sh &&
+ VISUAL=./e-VISUAL.sh &&
+ export EDITOR VISUAL &&
+ git commit --amend &&
+ test "$(git show -s --format=%s)" = "Edited by EDITOR"
+
+'
+
TERM=vt100
export TERM
for i in vi EDITOR VISUAL core_editor GIT_EDITOR
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index d2de576..a603f6d 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -86,7 +86,7 @@ chmod 755 editor
test_expect_success \
"amend commit" \
- "VISUAL=./editor git commit --amend"
+ "EDITOR=./editor git commit --amend"
test_expect_success \
"passing -m and -F" \
@@ -107,7 +107,7 @@ chmod 755 editor
test_expect_success \
"editing message from other commit" \
"echo 'hula hula' >file && \
- VISUAL=./editor git commit -c HEAD^ -a"
+ EDITOR=./editor git commit -c HEAD^ -a"
test_expect_success \
"message from stdin" \
@@ -141,10 +141,10 @@ EOF
test_expect_success \
'editor not invoked if -F is given' '
echo "moo" >file &&
- VISUAL=./editor git commit -a -F msg &&
+ EDITOR=./editor git commit -a -F msg &&
git show -s --pretty=format:"%s" | grep -q good &&
echo "quack" >file &&
- echo "Another good message." | VISUAL=./editor git commit -a -F - &&
+ echo "Another good message." | EDITOR=./editor git commit -a -F - &&
git show -s --pretty=format:"%s" | grep -q good
'
# We could just check the head sha1, but checking each commit makes it
diff --git a/t/test-lib.sh b/t/test-lib.sh
index f2ca536..ec3336a 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -30,7 +30,7 @@ TZ=UTC
TERM=dumb
export LANG LC_ALL PAGER TERM TZ
EDITOR=:
-VISUAL=:
+unset VISUAL
unset GIT_EDITOR
unset AUTHOR_DATE
unset AUTHOR_EMAIL
@@ -58,7 +58,7 @@ GIT_MERGE_VERBOSITY=5
export GIT_MERGE_VERBOSITY
export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
-export EDITOR VISUAL
+export EDITOR
GIT_TEST_CMP=${GIT_TEST_CMP:-diff -u}
# Protect ourselves from common misconfiguration to export
@@ -207,8 +207,8 @@ trap 'die' EXIT
test_set_editor () {
FAKE_EDITOR="$1"
export FAKE_EDITOR
- VISUAL='"$FAKE_EDITOR"'
- export VISUAL
+ EDITOR='"$FAKE_EDITOR"'
+ export EDITOR
}
test_tick () {
--
1.6.5.2
^ permalink raw reply related
* [PATCH 1/9] Handle more shell metacharacters in editor names
From: Jonathan Nieder @ 2009-11-11 23:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091111235100.GA1140@progeny.tock>
Pass the editor name to the shell if it contains any susv3 shell
special character (globs, redirections, variable substitutions,
escapes, etc). This way, the meaning of some characters will not
meaninglessly change when others are added, and git commands
implemented in C and in shell scripts will interpret editor names
in the same way.
This does not make the GIT_EDITOR setting any more expressive,
since one could always use single quotes to force the editor to
be passed to the shell.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Unchanged from jn/editor-pager, included only for reference.
editor.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/editor.c b/editor.c
index 4d469d0..941c0b2 100644
--- a/editor.c
+++ b/editor.c
@@ -28,7 +28,7 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
const char *args[6];
struct strbuf arg0 = STRBUF_INIT;
- if (strcspn(editor, "$ \t'") != len) {
+ if (strcspn(editor, "|&;<>()$`\\\"' \t\n*?[#~=%") != len) {
/* there are specials */
strbuf_addf(&arg0, "%s \"$@\"", editor);
args[i++] = "sh";
--
1.6.5.2
^ permalink raw reply related
* [PATCH v4 0/9] Default pager and editor
From: Jonathan Nieder @ 2009-11-11 23:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, Johannes Sixt, David Roundy, GIT List
In-Reply-To: <20091031012050.GA5160@progeny.tock>
Junio C Hamano wrote:
> * jn/editor-pager (2009-10-30) 8 commits
> - Provide a build time default-pager setting
> - Provide a build time default-editor setting
> - am -i, git-svn: use "git var GIT_PAGER"
> - add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"
> - Teach git var about GIT_PAGER
> - Teach git var about GIT_EDITOR
> - Do not use VISUAL editor on dumb terminals
> - Handle more shell metacharacters in editor names
>
> Any comments?
Here’s a reroll. The interdiff is very small:
diff --git a/ident.c b/ident.c
index 99f1c85..26409b2 100644
--- a/ident.c
+++ b/ident.c
@@ -205,7 +205,7 @@ const char *fmt_ident(const char *name, const char *email,
if ((warn_on_no_name || error_on_no_name) &&
name == git_default_name && env_hint) {
fprintf(stderr, env_hint, au_env, co_env);
- env_hint = NULL; /* warn only once, for "git var -l" */
+ env_hint = NULL; /* warn only once */
}
if (error_on_no_name)
die("empty ident %s <%s> not allowed", name, email);
and the corresponding hunk in patch 3 could be safely discarded.
Aside from that, patch 3 has been unsquashed from patch 4, since it is
an independent fix that might be worth ejecting; the Signed-off-by
lines on patches 2 and 4 have been fixed; and the commit message for
patch 4 has been expanded to explain more.
In short, nothing of substance has changed. If you are reminded of
any thoughts on the series, please let me know.
I think it is fair to say every one of these patches except the first
was someone else’s idea. Thanks, everyone.
Jonathan Nieder (8):
Handle more shell metacharacters in editor names
Do not use VISUAL editor on dumb terminals
Suppress warnings from "git var -l"
Teach git var about GIT_EDITOR
Teach git var about GIT_PAGER
add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"
am -i, git-svn: use "git var GIT_PAGER"
Provide a build time default-editor setting
Junio C Hamano (1):
Provide a build time default-pager setting
Documentation/config.txt | 4 +--
Documentation/git-commit.txt | 2 +-
Documentation/git-send-email.txt | 4 +-
Documentation/git-var.txt | 14 +++++++++++
Makefile | 28 ++++++++++++++++++++++
cache.h | 2 +
contrib/fast-import/git-p4 | 5 +---
editor.c | 32 ++++++++++++++++++-------
git-add--interactive.perl | 3 +-
git-am.sh | 5 +++-
git-send-email.perl | 3 +-
git-sh-setup.sh | 19 +++++----------
git-svn.perl | 11 +++-----
ident.c | 2 +-
pager.c | 24 ++++++++++++++++---
t/t7005-editor.sh | 47 ++++++++++++++++++++++++++++---------
t/t7501-commit.sh | 8 +++---
t/test-lib.sh | 8 +++---
var.c | 26 ++++++++++++++++++++-
19 files changed, 178 insertions(+), 69 deletions(-)
^ permalink raw reply related
* Re: [PATCH] Re: Clarify documentation on the "ours" merge strategy.
From: Thomas Rast @ 2009-11-11 23:37 UTC (permalink / raw)
To: Nicolas Sebrecht
Cc: Junio C Hamano, Baz, Peter Krefting, Git Mailing List,
Johannes Schindelin, Björn Steinbrink
In-Reply-To: <20091111213049.GJ27518@vidovic>
Nicolas Sebrecht wrote:
> The 11/11/09, Junio C Hamano wrote:
> > Thomas Rast <trast@student.ethz.ch> writes:
> >
> > > ++
> > > +Because the sides in a rebase are swapped, using this strategy with
> > > +git-rebase is never a good idea.
> >
> > Looking very good.
>
> If this strategy is _never_ a good idea in this case, I tend to think
> that git should forbid this option, or at least, warn and refer to the
> documentation.
Then again, I'm not sure if resolve vs. recursive makes a difference
in a rebase. Octopus is weird for a two-head merge, I'm not sure why
the docs even talk about it. That would leave only subtree, which
indeed has its uses. Should we add a note to that effect to
git-rebase.txt? Like, say,
diff --git i/Documentation/git-rebase.txt w/Documentation/git-rebase.txt
index 33e0ef1..6e54a57 100644
--- i/Documentation/git-rebase.txt
+++ w/Documentation/git-rebase.txt
@@ -228,13 +228,19 @@ OPTIONS
Use merging strategies to rebase. When the recursive (default) merge
strategy is used, this allows rebase to be aware of renames on the
upstream side.
++
+Note that in a rebase merge (hence merge conflict), the sides are
+swapped: "theirs" is the to-be-applied patch, and "ours" is the so-far
+rebased series, starting with <upstream>.
-s <strategy>::
--strategy=<strategy>::
Use the given merge strategy.
- If there is no `-s` option, a built-in list of strategies
- is used instead ('git-merge-recursive' when merging a single
- head, 'git-merge-octopus' otherwise). This implies --merge.
+ If there is no `-s` option 'git-merge-recursive' is used
+ instead. This implies --merge.
++
+Due to the peculiarities of 'git-rebase' (see \--merge above) the only
+built-in strategy that is actually useful is 'subtree'.
-q::
--quiet::
diff --git i/Documentation/merge-strategies.txt w/Documentation/merge-strategies.txt
index 4365b7e..c1c3add 100644
--- i/Documentation/merge-strategies.txt
+++ w/Documentation/merge-strategies.txt
@@ -33,6 +33,9 @@ ours::
merge is always the current branch head. It is meant to
be used to supersede old development history of side
branches.
++
+Because the sides in a rebase are swapped, using this strategy with
+'git-rebase' is never a good idea.
subtree::
This is a modified recursive strategy. When merging trees A and
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.6.5.2
From: Todd Zullinger @ 2009-11-11 23:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vfx8kn1h7.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
Junio C Hamano wrote:
> Thanks; will try. Will that have adverse effect when instsalled to
> FC11 by the way?
None that I am aware of (aside from using a less secure file digest
algorith, of course :). I've installed packages built that way on
Fedora 12 systems without issue.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Blessed are they who can laugh at themselves for they shall never
cease to be amused.
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Felipe Contreras @ 2009-11-11 23:15 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, git, Michael J Gruber, J. Bruce Fields,
Hannu Koivisto, Jeff King, Wincent Colaiuta, Matthias Lederhofer
In-Reply-To: <20091025111438.GA11252@progeny.tock>
On Sun, Oct 25, 2009 at 1:14 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>> Supposing that color.ui is 'auto' by default,
>
> Should it be? I think it would not be too hard to detect a color
> terminal by checking $TERM. Are many people bothered by color? Do we
> need some way to make it more obvious how to turn color _off_?
I think it should be.
>> No, but "improving" needs "changing", and the discussion I see is
>> biased towards "not changing".
> [...]
>> I don't think the user manual is achieving that purpose. I don't know
>> if it's the user manual's fault, or git's UI. Both areas need a lot of
>> improvement (as the git user survey suggests), and I've tried to
>> improve both with a lot resistance in both. So I'm not very hopeful
>> anymore.
>
> I hope you have not misunderstood. I cannot speak for everyone else
> here, but I know I am happier when (1) fixes match problems to be
> solved in a documented way and (2) fixes do not unnecessarily break
> unrelated habits. One way to bring this about is to justify each
> change by explaining what real problem it will solve and how it avoids
> collateral damage. Without that justification, a change is indeed
> dangerous and might be worth resisting until it gets clarified. But
> this is not meant to prevent fixes from occuring at all.
Well. I've sent many patches, and gone through several iterations.
After fixing all outstanding issues, addressing all the comments, and
getting several "I like this" votes, Junio suddenly decides he doesn't
like the initial changes at all and doesn't provide any way forward.
I don't see how that's an environment that fosters changes.
> Could you list some UI patches that were overlooked or not properly
> addressed? Maybe people just forgot about them or were waiting for an
> updated version, or maybe the problems some solve weren’t articulated
> clearly yet. I would be glad to help out in any way I can.
For example there have been many attempts to bring the 'git stage' to
foreground of the UI; right now it's kind of hidden and many people
don't even realize it's there. Even simplistic attempts as
standardizing --index, --cache and so on into --stage have failed
miserably.
Again, there doesn't seem to be a path forward. Perhaps the git's
stage will remain an obscure feature of git forever. (all the input
from git user's survey points out that people are not really using it)
>> Judging from the luck I've had pushing even the simplest
>> changes I don't think it will improve much more, unfortunately.
>
> Even the simplest changes can be hard. But I hope they do not amount
> to nothing. I hope at the very least the git-config manual page will
> improve...
What I mean is: if the simplest changes are *impossible*, then there's
barely any hope of progress.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Unhelpful "branch.master.remote = <nickname>" advice?
From: Tomas Carnecky @ 2009-11-11 20:32 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: git list
In-Reply-To: <1257968052.26362.155.camel@heerbeest>
On Nov 11, 2009, at 8:34 PM, Jan Nieuwenhuizen wrote:
> Op woensdag 11-11-2009 om 20:10 uur [tijdzone +0100], schreef Tomas
> Carnecky:
>> On Nov 11, 2009, at 7:56 PM, Jan Nieuwenhuizen wrote:
>
> Hi Tomas,
>
>> You used this:
>> $ git config branch.master.remote = <something>
>> Do you see the difference between that and what I posted?
>
> Sure, I now know what syntax you and the advise mean. However,
> I'm just pointing out that the git pull advise makes no sense,
> however way you try to interpret it?
It didn't tell you to copy'n'paste the whole lines to a git-config(1)
commandline. But I do see that the output can be confusing for someone
not familiar with the git configuration files/git-config.
>>> I think it might be more helpful if this text said
>>> configuration file and gave a usable configuration file
>>> snippet, or alternatively said git config, and gave usable
>>> git config commands.
>>
>> Feel free to send a patch ;)
>
> [just maybe, if my uninstall patch goes in easily, but]
>
> First I need to know what the new advise should be. As you
> can see below, I'm still confused.
>
> I was hoping someone would say: Ah blast! That was me,
> stupid: Fixed in master :-) And everything would make
> sense and work.
You can use git-blame(1) to find out who wrote those lines ;)
>
>> branch.master.remote has two different values, git doesn't know which
>> remote to use.
>
> Well, it can see that there already is a value for
> branch.master.remote
> defined, and it /still/ advises to add one. It also uses <nickname>,
> which suggests there could be multiple values?
>
> For all I know, pull can only handle one nickname and it shouldn't
> give this advise at all?
>
>> Do you want to pull from origin or eddy?
>
> I'm publishing on origin -- that's what the original clone was
> from. Also, I use it to update from most often, when I work
> from different locations. All fine.
>
> Now this Eddy guy says: pull from here. I try it and get
> this advise. So, I'd like to have
>
> git pull # use origin by default
> git pull eddy # pull from eddy's url
I don't know the relationship between you and eddy, but usually you
shouldn't rebase (=rewrite) eddies commits. That also means you'd have
to live with the merge commits.
>
>> I would
>> recommend only keeping one [branch "master"] section and edit it
>> appropriately.
>
> Yes, I tried that and came up with
>
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> [remote "origin"]
> url = git@github.com:janneke/gub.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> # advise from git pull, using <nickname> = eddy
> # branch.master.remote = <nickname>
> # branch.master.merge = <remote-ref>
> # remote.<nickname>.url = <url>
> # remote.<nickname>.fetch = <refspec>
> #[branch "master"]
> # remote = eddy # ignore branch.master.remote advise
> # merge = refs/heads/master
> [remote "eddy"]
> url = http://github.com/epronk/gub.git
> fetch = +refs/heads/*:refs/remotes/origin/*
I see your mistake. Both the origin and eddy remote write to the same
namespace (refs/remotes/origin/*), and that's also why you get (force
update) below
. Change the fetch line of remote.eddy.fetch to +refs/heads/*:refs/
remotes/eddy/*. After that both command (pull -r / pull -r eddy)
should work (I hope).
>
> This /seems/ to work. However, I still get this
>
> $ git pull -r
> From git@github.com:janneke/gub
> + 7bb5905...8ff38da master -> origin/master (forced update)
> First, rewinding head to replay your work on top of it...
> Fast-forwarded master to 8ff38da0a7013a891de18a0b7bec12b9d1fa6637.
> 20:25:55 janneke@peder:~/vc/gub
>
> [looks okay]
>
> $ git pull -r eddy
> From http://github.com/epronk/gub
> + 8ff38da...7bb5905 master -> origin/master (forced update)
> [looks fine too, but still continues with]
> You asked me to pull without telling me which branch you
> want to merge with, and 'branch.master.merge' in
> your configuration file does not tell me either. Please
> specify which branch you want to merge on the command line and
> try again (e.g. 'git pull <repository> <refspec>').
> See git-pull(1) for details.
>
> If you often merge with the same branch, you may want to
> configure the following variables in your configuration
> file:
>
> branch.master.remote = <nickname>
> branch.master.merge = <remote-ref>
> remote.<nickname>.url = <url>
> remote.<nickname>.fetch = <refspec>
>
> See git-config(1) for details.
> [1]20:26:01 janneke@peder:~/vc/gub
> $
>
> so I'm still missing something?
>
>> Is 'git pull -r' not short enough for you?
>
> It's more of a usability thing. It annoys me that the most
> used functionality needs a command line option. Worse however,
> is that people [myself included] tend to forget that "-r",
> and our logs have lots of these ugly, unnecessary
>
> c377994 Merge branch 'master' of ssh+git://git.sv.gnu.org/srv/git/lilypond
>
> Also, we need to explain this to all newcomers.
I've found that all the available guides and books about git explain
merging pretty well (it's a central part of git after all).
tom
^ permalink raw reply
* Re: git-svn problem with v1.6.5
From: Eric Wong @ 2009-11-11 22:44 UTC (permalink / raw)
To: Pascal Obry; +Cc: Avery Pennarun, adambrewster, git list
In-Reply-To: <4AFB32DC.50505@obry.net>
Pascal Obry <pascal@obry.net> wrote:
> Eric,
>
>> Also, any chance you have multiple refs with "trunk" in the basename?
>>
>> git rev-parse --symbolic --all | grep '/trunk'
>
> This reports:
>
> $ git rev-parse --symbolic --all | grep '/trunk'
> refs/remotes/svn/trunk
Pascal,
OK, this is normal.
>> It could be a backwards compatibility issue with git svn looking
>> in multiple places for trunk.
>
> But I have multiple trunk:
>
> $ ls .git/svn/svn/trunk/
> ./ ../ .rev_map.936e1b1b-40f2-da11-902a-00137254ae57 unhandled.log
>
> $ ls .git/svn/refs/remotes/svn/trunk/
> ./ ../ .rev_map.936e1b1b-40f2-da11-902a-00137254ae57 unhandled.log
>
> Removing all the .rev_map* fix the problem.
>
> Removing only the one in .git/svn/refs/remotes/svn/trunk/ fix the
> problem too.
>
>> With Adam's commit, it'll try $GIT_DIR/svn/refs/remotes/trunk/* first
>> Then it'll try $GIT_DIR/svn/trunk/* as a fallback.
>
> Does this means that it was looking first in $GIT_DIR/svn/trunk/*
> before? And the confusion come because now it is looking in
> $GIT_DIR/svn/refs/remotes/trunk/* first?
Yes, but somehow $GIT_DIR/svn/refs/remotes/trunk should not have
been created since $GIT_DIR/svn/svn/trunk already existed. Both
of those directories existing at the same time should not
Did you try an early version of Adam's patch before it made it into
git.git by any chance?
Or, did you by any chance start a fresh import with a v1.6.5 and then
rsync $GIT_DIR to one created with 1.6.4 and not use --delete with
rsync?
--
Eric Wong
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.5.2
From: Junio C Hamano @ 2009-11-11 22:25 UTC (permalink / raw)
To: Todd Zullinger; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20091111215952.GR31109@inocybe.localdomain>
Todd Zullinger <tmz@pobox.com> writes:
> I don't know what the process is for creating the rpm's, but if it's
It is essentially "make rpm" at the top directory as you found out.
> under Junio's control, a fix to create packages which can be read by
> older rpm versions would be to add:
>
> --define "_source_filedigest_algorithm md5" \
> --define "_binary_filedigest_algorithm md5"
>
> to the rpmbuild invocation.
Thanks; will try. Will that have adverse effect when instsalled to FC11
by the way?
^ permalink raw reply
* [PATCH] give priority to progress messages
From: Nicolas Pitre @ 2009-11-11 22:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Nicolas Sebrecht, git
In-Reply-To: <20091111214216.GO12890@machine.or.cz>
In theory it is possible for sideband channel #2 to be delayed if
pack data is quick to come up for sideband channel #1. And because
data for channel #2 is read only 128 bytes at a time while pack data
is read 8192 bytes at a time, it is possible for many pack blocks to
be sent to the client before the progress message fifo is emptied,
making the situation even worse. This would result in totally garbled
progress display on the client's console as local progress gets mixed
with partial remote progress lines.
Let's prevent such situations by giving transmission priority to
progress messages over pack data at all times.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
---
On Wed, 11 Nov 2009, Petr Baudis wrote:
> On Wed, Nov 11, 2009 at 04:19:44PM -0500, Nicolas Pitre wrote:
> > On Wed, 11 Nov 2009, Petr Baudis wrote:
> >
> > > On Wed, Nov 11, 2009 at 02:50:22PM -0500, Nicolas Pitre wrote:
> > > > According to strace, data from sideband channel #2 (prefixed with
> > > > "remote: ") pertaining to object compression is printed way after pack
> > > > data has already started to arrive locally. This is really weird.
> > > >
> > > > And this occurs only when fetching from repo.or.cz and not from
> > > > git.kernel.org for example. So there is something to investigate on the
> > > > server side. Pasky: anything you changed in your git installation
> > > > lately?
> > >
> > > Yes, but nothing should have changed in git-daemon, that's the only part
> > > of the infrastructure that uses system-wide git (which it perhaps
> > > shouldn't). I cannot reproduce this problem, though. I have changed
> > > git-daemon to use my local git version (about one week old master), does
> > > this still happen for you?
> >
> > No, it doesn't happen anymore.
> >
> > What was the git-daemon version before?
>
> 1.5.6.5, the default version in debian lenny
I don't see why the issue couldn't happen with latest git as well.
This patch however would plug any possibilities for this to happen again
though.
diff --git a/builtin-upload-archive.c b/builtin-upload-archive.c
index c4cd1e1..29446e8 100644
--- a/builtin-upload-archive.c
+++ b/builtin-upload-archive.c
@@ -132,7 +132,6 @@ int cmd_upload_archive(int argc, const char **argv, const char *prefix)
while (1) {
struct pollfd pfd[2];
- ssize_t processed[2] = { 0, 0 };
int status;
pfd[0].fd = fd1[0];
@@ -147,15 +146,14 @@ int cmd_upload_archive(int argc, const char **argv, const char *prefix)
}
continue;
}
- if (pfd[0].revents & POLLIN)
- /* Data stream ready */
- processed[0] = process_input(pfd[0].fd, 1);
if (pfd[1].revents & POLLIN)
/* Status stream ready */
- processed[1] = process_input(pfd[1].fd, 2);
- /* Always finish to read data when available */
- if (processed[0] || processed[1])
- continue;
+ if (process_input(pfd[1].fd, 2))
+ continue;
+ if (pfd[0].revents & POLLIN)
+ /* Data stream ready */
+ if (process_input(pfd[0].fd, 1))
+ continue;
if (waitpid(writer, &status, 0) < 0)
error_clnt("%s", lostchild);
diff --git a/upload-pack.c b/upload-pack.c
index 70badcf..6bfb500 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -310,6 +310,23 @@ static void create_pack_file(void)
}
continue;
}
+ if (0 <= pe && (pfd[pe].revents & (POLLIN|POLLHUP))) {
+ /* Status ready; we ship that in the side-band
+ * or dump to the standard error.
+ */
+ sz = xread(pack_objects.err, progress,
+ sizeof(progress));
+ if (0 < sz)
+ send_client_data(2, progress, sz);
+ else if (sz == 0) {
+ close(pack_objects.err);
+ pack_objects.err = -1;
+ }
+ else
+ goto fail;
+ /* give priority to status messages */
+ continue;
+ }
if (0 <= pu && (pfd[pu].revents & (POLLIN|POLLHUP))) {
/* Data ready; we keep the last byte to ourselves
* in case we detect broken rev-list, so that we
@@ -347,21 +364,6 @@ static void create_pack_file(void)
if (sz < 0)
goto fail;
}
- if (0 <= pe && (pfd[pe].revents & (POLLIN|POLLHUP))) {
- /* Status ready; we ship that in the side-band
- * or dump to the standard error.
- */
- sz = xread(pack_objects.err, progress,
- sizeof(progress));
- if (0 < sz)
- send_client_data(2, progress, sz);
- else if (sz == 0) {
- close(pack_objects.err);
- pack_objects.err = -1;
- }
- else
- goto fail;
- }
}
if (finish_command(&pack_objects)) {
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.6.5.2
From: Jakub Narebski @ 2009-11-11 22:23 UTC (permalink / raw)
To: Todd Zullinger; +Cc: Junio C Hamano, git
In-Reply-To: <20091111215952.GR31109@inocybe.localdomain>
On Wed, 11 Nov 2009, Todd Zullinger wrote:
> Jakub Narebski wrote:
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> > > The RPM binary packages for a few architectures are found in:
> > >
> > > RPMS/$arch/git-*-1.6.5.2-1.fc9.$arch.rpm (RPM)
> >
> > I tried to install git from source RPM... and failed:
> >
> > $ rpmbuild --rebuild git-1.6.5.2-1.fc11.src.rpm
> > Installing git-1.6.5.2-1.fc11.src.rpm
> > warning: user junio does not exist - using root
> > warning: group junio does not exist - using root
> > error: unpacking of archive failed on file
> > /home/local/builddir/SOURCES/git-1.6.5.2.tar.gz;
> > 4afb1f6a: cpio: MD5 sum mismatch
> > error: git-1.6.5.2-1.fc11.src.rpm cannot be installed
> >
> > Error messages are line wrapped for better readibility.
>
> It looks like the kernel.org builders are now using Fedora 11 to
> create the packages. Unfortunately, there were backward-incompatible
> changes in rpm. Stronger hashes are now used and older rpm versions
> do not understand these, leading to the error you got.
Thanks for an information.
Well, it looks like I would have to use "make rpm" to generate RPM
to install, at least until I finally upgrade my Linux distribution.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: excerpts from tomorrow's "What's cooking" draft
From: Nicolas Pitre @ 2009-11-11 22:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Nicolas Sebrecht, Junio C Hamano, git
In-Reply-To: <20091111214216.GO12890@machine.or.cz>
On Wed, 11 Nov 2009, Petr Baudis wrote:
> On Wed, Nov 11, 2009 at 04:19:44PM -0500, Nicolas Pitre wrote:
> > On Wed, 11 Nov 2009, Petr Baudis wrote:
> >
> > > Yes, but nothing should have changed in git-daemon, that's the only part
> > > of the infrastructure that uses system-wide git (which it perhaps
> > > shouldn't). I cannot reproduce this problem, though. I have changed
> > > git-daemon to use my local git version (about one week old master), does
> > > this still happen for you?
> >
> > No, it doesn't happen anymore.
> >
> > What was the git-daemon version before?
>
> 1.5.6.5, the default version in debian lenny
Go figure. I don't see anything that would explain the difference in
behavior with latest git from a quick look.
Nicolas
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.5.2
From: Todd Zullinger @ 2009-11-11 21:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <m3ljicsrg0.fsf@localhost.localdomain>
Jakub Narebski wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> The RPM binary packages for a few architectures are found in:
>>
>> RPMS/$arch/git-*-1.6.5.2-1.fc9.$arch.rpm (RPM)
>
> I tried to install git from source RPM... and failed:
>
> $ rpmbuild --rebuild git-1.6.5.2-1.fc11.src.rpm
> Installing git-1.6.5.2-1.fc11.src.rpm
> warning: user junio does not exist - using root
> warning: group junio does not exist - using root
> error: unpacking of archive failed on file
> /home/local/builddir/SOURCES/git-1.6.5.2.tar.gz;
> 4afb1f6a: cpio: MD5 sum mismatch
> error: git-1.6.5.2-1.fc11.src.rpm cannot be installed
>
> Error messages are line wrapped for better readibility.
>
> Redownloading the file didn't help
>
> $ ls -l git-1.6.5.2-1.fc11.src.rpm
> -rw-r--r-- 1 jnareb users 2713416 Oct 26 03:59 git-1.6.5.2-1.fc11.src.rpm
> $ md5sum git-1.6.5.2-1.fc11.src.rpm
> 9f89a01b65e1b8e8934c3a2252064632 git-1.6.5.2-1.fc11.src.rpm
It looks like the kernel.org builders are now using Fedora 11 to
create the packages. Unfortunately, there were backward-incompatible
changes in rpm. Stronger hashes are now used and older rpm versions
do not understand these, leading to the error you got.
I don't know what the process is for creating the rpm's, but if it's
under Junio's control, a fix to create packages which can be read by
older rpm versions would be to add:
--define "_source_filedigest_algorithm md5" \
--define "_binary_filedigest_algorithm md5"
to the rpmbuild invocation.
Perhaps like this (I didn't test this, though the defines are what we
use in Fedora to create packages on Fedora >= 11 for building on
CentOS and older releases):
-- >8 --
From: Todd Zullinger <tmz@pobox.com>
Subject: [PATCH] Makefile: Ensure rpm packages can be read by older rpm versions
The kernel.org hosts where the packages are built are now using Fedora
11, which defaults to sha256 for file digests instead of md5. Older
versions of rpm can not handle these packages. Tell rpmbuild to use md5
file digests for better compatibility.
Signed-off-by: Todd Zullinger <tmz@pobox.com>
---
Makefile | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 5d5976f..35f5294 100644
--- a/Makefile
+++ b/Makefile
@@ -1806,7 +1806,10 @@ dist: git.spec git-archive$(X) configure
gzip -f -9 $(GIT_TARNAME).tar
rpm: dist
- $(RPMBUILD) -ta $(GIT_TARNAME).tar.gz
+ $(RPMBUILD) \
+ --define "_source_filedigest_algorithm md5" \
+ --define "_binary_filedigest_algorithm md5" \
+ -ta $(GIT_TARNAME).tar.gz
htmldocs = git-htmldocs-$(GIT_VERSION)
manpages = git-manpages-$(GIT_VERSION)
--
1.6.5.2
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Does it follow that I reject all authority? Perish the thought. In the
matter of boots, I defer to the authority of the boot-maker.
-- Mikhail Bakunin
^ permalink raw reply related
* ks/precompute-completion
From: Jonathan Nieder @ 2009-11-11 22:08 UTC (permalink / raw)
To: Kirill Smelkov
Cc: Sverre Rabbelier, Junio C Hamano, Stephen Boyd, Shawn O. Pearce,
git
In-Reply-To: <fabb9a1e0911110957k599ac3dfmd1a44a0499c72b2d@mail.gmail.com>
Hi,
>> * ks/precompute-completion (2009-10-26) 3 commits.
>> (merged to 'next' on 2009-10-28 at cd5177f)
>> + completion: ignore custom merge strategies when pre-generating
>> (merged to 'next' on 2009-10-22 at f46a28a)
>> + bug: precomputed completion includes scripts sources
>> (merged to 'next' on 2009-10-14 at adf722a)
>> + Speedup bash completion loading
>>
>> What's the status of this thing? Last time I polled the list I had an
>> impression that it was not quite ready...
As a distro user, I don’t think I would be able to use it until there
is a command to update the installed completion, to call after adding
a new git command to my $PATH. This could mean:
- git-completion.bash.generate learns to read the .in file and
write the completion script to arbitrary paths (or just always
uses stdin and stdout?)
- distros install git-completion.bash.{generate,in} to /usr/share/git-core
- distros install a simple completion script to /etc/bash_completion.d
that passes the buck, e.g.
-- %< --
# bash completion support for core Git.
#
# Run update-git-completion to generate these files.
#
__git_user_completion=~/.cache/git-core/git-completion.bash
__git_system_completion=/var/cache/git-core/git-completion.bash
if test -r "$__git_user_completion"
then
. "$__git_user_completion"
elif test -r "$__git_system_completion"
then
. "$__git_system_completion"
fi
-- >% --
- new update-git-completion script, something like this:
-- %< --
#!/bin/sh
USAGE="update-git-completion {--system | --user | <filename>}"
datadir=/usr/share/git-core
die() {
echo >&2 "$*"
exit 1
}
if ! test $# -eq 1
then
die "usage: $USAGE"
fi
if test "$1" = "--system"
then
output=/var/cache/git-core/git-completion.bash
elif test "$1" = "--user"
then
output=$HOME/.cache/git-core/git-completion.bash
else
output=$1
fi
rm -f "$output+" || die "cannot remove $output+"
sh "$datadir"/git-completion.bash.generate \
< "$datadir"/git-completion.bash.in \
> "$output+" || die "failed to generate completion script"
bash -n "$output+" || {
rm -f "$output+"
die "generated script fails syntax check"
}
mv -f "$output+" "$output" || {
rm -f "$output+"
die "failed to install completion script"
}
-- >% --
Thoughts?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox