* Re: Fw: git-core: SIGSEGV during {peek,ls}-remote on HTTP remotes.
From: Daniel Barkalow @ 2009-11-02 0:59 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Sverre Rabbelier, Samium Gromoff, git,
Tay Ray Chuan, Mike Hommey
In-Reply-To: <20091101230442.GA20264@coredump.intra.peff.net>
On Sun, 1 Nov 2009, Jeff King wrote:
> On Sun, Nov 01, 2009 at 04:19:34PM -0500, Daniel Barkalow wrote:
>
> > > > Do things like git_path() fail cleanly if there was no git directory? If
> > > > not, there should probably be tests of nongit on paths that actually need
> > > > a git directory,...
> > >
> > > I don't know. Again, you tell me ;-)
> >
> > I'm not an expert on that part. But it looks like it misbehaves, returning
> > ".git/foo" even when that path doesn't make sense.
>
> I will not admit to being an expert in that area, but yes, that is what
> I observed before while looking into some of our weird startup problems.
> We really have two systems for setting up the environment:
>
> - setup_git_directory, which tries to do everything at the outset (but
> which we don't necessarily run for all commands, and where "outset"
> is defined as when the git wrapper handles an actual command, which
> means we sometimes do quite a bit of stuff beforehand)
>
> - some lazy magic in environment.c, mostly setup_git_env. If
> setup_git_directory has been run, this does the right thing because
> it reads GIT_DIR from the environment as set previously. But if not,
> then it can quite often do the wrong thing (as you noticed).
>
> I tried simply ditching the lazy magic, but that doesn't work: there are
> many cases where setup_git_directory hasn't been run. Moving it to the
> very beginning doesn't quite work, either. I don't remember the details,
> sadly. It may be that the lazy setup_git_env magic should, rather than
> doing anything itself, call setup_git_directory if it has not been
> initialized. But at that point, you might as well setup_git_directory in
> every program, since just about every one is going to want to look at
> git_path at some point.
>
> Sorry, I know that is vague. Refactoring this area has been on my plate
> for so long that I have forgotten all the details, and it is such a
> messy area that I am continually procrastinating on diving back into it.
> ;)
I've been looking at it, just now, and I might try to clean stuff up. The
problem I'm running into is that, in some cases, you have to call
setup_git_directory_gently(), and it might determine that there is no git
repo, but then the various environment functions don't distinguish between
the situation where you haven't called it at all and the situation where
you called it and determined there to be no answer. Furthermore, a lot of
functions seem to be getting git_path(something), ignoring the fact that
there is no repo, and acting like there is a repo that has simply not got
the file it is looking for.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC PATCH 06/19] Factor ref updating out of fetch_with_import
From: Sverre Rabbelier @ 2009-11-02 1:33 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <alpine.LNX.2.00.0910301118070.14365@iabervon.org>
Heya,
On Fri, Oct 30, 2009 at 17:04, Daniel Barkalow <barkalow@iabervon.org> wrote:
> I think you have the sides backwards
Yup, sorry, got them the wrong way around for some reason.
> On the other hand, I think it would make sense to use the same style of
> refspec between the helper and transport-helper.c such that the helper
> reports something like:
>
> refs/svn/origin/trunk:refs/heads/trunkr
> refs/svn/origin/branches/*:refs/heads/*
> refs/svn/origin/tags/*:refs/tags/*
>
> "list" gives:
>
> 000000...000 refs/heads/trunkr
>
> "import refs/heads/trunkr" imports the objects, but the refspecs have to
> be consulted by transport-helper.c in order to determine what ref to read
> to get the value of refs/heads/trunkr. Instead of getting the value with
> read_ref("refs/heads/trunkr", ...) like it does now, it would do
> read_ref("refs/svn/origin/trunk", ...). And systems like p4 that don't
> have a useful standard just wouldn't support the "refspec" command and
> people would have to do site-specific configuration to get anything
> useful.
Yes, that sounds very reasonable, and I think that's the right way to
go. This leaves us with only one thing, we need a remote HEAD for 'git
clone hg::/path/to/repo' to work and have it check out a branch, I
think a seperate 'head' command might be appropriate? If supported it
returns the which local symref (e.g. 'refs/heads/trunkr' in the svn
case) should be pointed at by HEAD. If not supported we can just not
set it and clone will give the default 'no remote HEAD, nothing
checked out' message, which would probably be best for p4?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Makefile: add compat/bswap.h to LIB_H
From: Junio C Hamano @ 2009-11-02 2:59 UTC (permalink / raw)
To: Dmitry V. Levin; +Cc: git
In-Reply-To: <20091101230905.GA15675@wo.int.altlinux.org>
"Dmitry V. Levin" <ldv@altlinux.org> writes:
> Starting with commit 51ea55190b6e72c77c96754c1bf2f149a4714848,
> git-compat-util.h includes compat/bswap.h
>
> Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Thanks.
^ permalink raw reply
* Re: [PATCH] commit -c/-C/--amend: acquire authorship and restamp time with --claim
From: Junio C Hamano @ 2009-11-02 2:58 UTC (permalink / raw)
To: Erick Mattos; +Cc: git
In-Reply-To: <55bacdd30911011654k22eb6b13r28897bf71fc5e11b@mail.gmail.com>
Erick Mattos <erick.mattos@gmail.com> writes:
> 2009/11/1 Junio C Hamano <gitster@pobox.com>:
>> Erick Mattos <erick.mattos@gmail.com> writes:
>>
>>>> % git commit --claim --author='Erick Mattos <eric@mattos>' -C HEAD
>>>>
>>>> Should you detect an error? Does your code do so? Do you have a test
>>>> that catches this error?
>>>
>>> It works as intended. Both together.
>>
>> That does not make any sense. If you are saying this is yours and it is
>> his at the same time, there can be no sane way to work "as intended", no?.
>
> I am adding a new option not changing the option --author already in
> git. So it does work together.
Somebody who says "this commit is mine, and its author is this other
person" is not making any sense. The resulting commit can either have
that person (i.e. the committer) as the author, which is what the "claim"
option means, or it can have the person named with --author as the author,
but both cannot be true at the same time.
When you introduce a new option, sometimes it cannot sanely be used with
an existing option. In such a case, two options (the new one and the
existing one) are called mutually exclusive. And you add some code to
catch an user error to use them together.
>>>>> + git commit -c HEAD <<EOF
>>>>> + "Changed"
>>>>> + EOF &&
>>>>
>>>> What editor is reading this "Changed"?
>>>
>>> Nobody cares... Just a text to change the file.
>>
>> I actually care. Who uses that Changed string, and where does it end up
>> with? At the end of the log message? At the beginning? What "file"?
>
> I didn't get it. -c option does not accept -m option and starts an
> editor to change the message. The text "Changed is just a forced
> message. I can not use an editor in interactive mode in a script...
How are the existing tests that try "commit -c" do this? I do not think
there is any here-text redirect into "git commit".
It is sometimes easier to show by example than by giving nudging words
that only show direction, so here is a suggested rewrite on top of your
patch. I am not very happy with the option name "mine" either, but at
least I think this gets the semantics right.
Documentation/git-commit.txt | 10 ++--
Makefile | 1 +
builtin-commit.c | 9 ++-
t/t7509-commit.sh | 144 +++++++++++++++++++++++-------------------
4 files changed, 92 insertions(+), 72 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 01eeb3e..7832720 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]
- [(-c | -C) <commit>] [-F <file> | -m <msg>] [--claim]
+ [(-c | -C) <commit>] [-F <file> | -m <msg>] [--mine]
[--allow-empty] [--no-verify] [-e] [--author=<author>]
[--cleanup=<mode>] [--] [[-i | -o ]<file>...]
@@ -61,18 +61,18 @@ OPTIONS
-C <commit>::
--reuse-message=<commit>::
Take an existing commit object, and reuse the log message
- and the authorship information when creating the commit.
+ and the authorship information (including the timestamp)
+ when creating the commit.
-c <commit>::
--reedit-message=<commit>::
Like '-C', but with '-c' the editor is invoked, so that
the user can further edit the commit message.
---claim::
+--mine::
When used with -C/-c/--amend options, declare that the
authorship of the resulting commit now belongs of the committer.
- This also renews the author timestamp. Therefore this option
- sets the use of only the message from the original commit.
+ This also renews the author timestamp.
-F <file>::
--file=<file>::
diff --git a/Makefile b/Makefile
index 15ea32d..a9108b3 100644
--- a/Makefile
+++ b/Makefile
@@ -1944,3 +1944,4 @@ coverage-report:
grep '^function.*called 0 ' *.c.gcov \
| sed -e 's/\([^:]*\)\.gcov: *function \([^ ]*\) called.*/\1: \2/' \
| tee coverage-untested-functions
+
diff --git a/builtin-commit.c b/builtin-commit.c
index 1aeafa6..aa42989 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -51,7 +51,7 @@ static const char *template_file;
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, claim;
+static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
static char *untracked_files_arg;
/*
* The default commit message cleanup mode will remove the lines
@@ -93,7 +93,7 @@ static struct option builtin_commit_options[] = {
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"),
- OPT_BOOLEAN(0, "claim", &claim, "acquire authorship and restamp time of resulting commit"),
+ OPT_BOOLEAN(0, "mine", &renew_authorship, "the commit is authored by me now (used with -C-c/--amend)"),
OPT_BOOLEAN('s', "signoff", &signoff, "add Signed-off-by:"),
OPT_FILENAME('t', "template", &template_file, "use specified template file"),
OPT_BOOLEAN('e', "edit", &edit_flag, "force edit of commit"),
@@ -382,7 +382,7 @@ static void determine_author_info(void)
email = getenv("GIT_AUTHOR_EMAIL");
date = getenv("GIT_AUTHOR_DATE");
- if (use_message && !claim) {
+ if (use_message && !renew_authorship) {
const char *a, *lb, *rb, *eol;
a = strstr(use_message_buffer, "\nauthor ");
@@ -748,6 +748,9 @@ static int parse_and_validate_options(int argc, const char *argv[],
if (force_author && !strchr(force_author, '>'))
force_author = find_author_by_nickname(force_author);
+ if (force_author && renew_authorship)
+ die("Using both --mine and --author does not make sense");
+
if (logfile || message.len || use_message)
use_editor = 0;
if (edit_flag)
diff --git a/t/t7509-commit.sh b/t/t7509-commit.sh
index 6d9eb26..ec13cea 100755
--- a/t/t7509-commit.sh
+++ b/t/t7509-commit.sh
@@ -3,85 +3,101 @@
# Copyright (c) 2009 Erick Mattos
#
-test_description='git commit
-
-Tests for --claim option on a commit.'
+test_description='git commit --mine'
. ./test-lib.sh
-TEST_FILE="$PWD"/foo
+author_header () {
+ git cat-file commit "$1" |
+ sed -n -e '/^$/q' -e '/^author /p'
+}
+
+message_body () {
+ git cat-file commit "$1" |
+ sed -e '1,/^$/d'
+}
-test_expect_success '-C option should be working' '
- echo "Initial" > "$TEST_FILE" &&
- git add "$TEST_FILE" &&
+test_expect_success '-C option copies authorship and message' '
+ echo "Initial" >foo &&
+ git add foo &&
+ test_tick &&
git commit -m "Initial Commit" --author Frigate\ \<flying@over.world\> &&
- sleep 1 &&
- echo "Test 1" >> "$TEST_FILE" &&
- git add "$TEST_FILE" &&
- git commit -C HEAD &&
- git cat-file -p HEAD^ | sed -e '/^parent/d' -e '/^tree/d' -e '/^committer/d' > commit_1 &&
- git cat-file -p HEAD | sed -e '/^parent/d' -e '/^tree/d' -e '/^committer/d' > commit_2 &&
- cmp commit_1 commit_2
+ git tag Initial &&
+ echo "Test 1" >>foo &&
+ test_tick &&
+ git commit -a -C Initial &&
+ author_header Initial >expect &&
+ author_header HEAD >actual &&
+ test_cmp expect actual
'
-test_expect_success '-C option with --claim is working properly' '
- sleep 1 &&
- echo "Test 2" >> "$TEST_FILE" &&
- git add "$TEST_FILE" &&
- git commit -C HEAD^ --claim &&
- git cat-file -p HEAD^ | grep '^author' > commit_1 &&
- git cat-file -p HEAD | grep '^author' > commit_2 &&
- test_must_fail cmp commit_1 commit_2
+test_expect_success '-C option copies only the message with --mine' '
+ echo "Test 2" >>foo &&
+ test_tick &&
+ git commit -a -C Initial --mine &&
+ echo "author $GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL> $GIT_AUTHOR_DATE" >expect &&
+ author_header HEAD >actual
+ test_cmp expect actual &&
+
+ message_body Initial >expect &&
+ message_body HEAD >actual &&
+ test_cmp expect actual
'
-test_expect_success '-c option should be working' '
- echo "Initial" > "$TEST_FILE" &&
- git add "$TEST_FILE" &&
- git commit -m "Initial Commit" --author Frigate\ \<flying@over.world\> &&
- sleep 1 &&
- echo "Test 3" >> "$TEST_FILE" &&
- git add "$TEST_FILE" &&
- git commit -c HEAD <<EOF
- "Changed"
- EOF &&
- git cat-file -p HEAD^ | grep '^author' > commit_1 &&
- git cat-file -p HEAD | grep '^author' > commit_2 &&
- cmp commit_1 commit_2
+test_expect_success '-c option copies authorship and message' '
+ echo "Test 3" >>foo &&
+ test_tick &&
+ EDITOR=: VISUAL=: git commit -a -c Initial &&
+ author_header Initial >expect &&
+ author_header HEAD >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '-c option copies only the message with --mine' '
+ echo "Test 4" >>foo &&
+ test_tick &&
+ EDITOR=: VISUAL=: git commit -a -c Initial --mine &&
+ echo "author $GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL> $GIT_AUTHOR_DATE" >expect &&
+ author_header HEAD >actual &&
+ test_cmp expect actual &&
+
+ message_body Initial >expect &&
+ message_body HEAD >actual &&
+ test_cmp expect actual
'
-test_expect_success '-c option with --claim is working properly' '
- sleep 1 &&
- echo "Test 4" >> "$TEST_FILE" &&
- git add "$TEST_FILE" &&
- git commit -c HEAD^ --claim <<EOF
- "Changed again"
- EOF &&
- git cat-file -p HEAD^ | grep '^author' > commit_1 &&
- git cat-file -p HEAD | grep '^author' > commit_2 &&
- test_must_fail cmp commit_1 commit_2
+test_expect_success '--amend option copies authorship' '
+ git checkout Initial &&
+ echo "Test 5" >>foo &&
+ test_tick &&
+ git commit -a --amend -m "amend test" &&
+ author_header Initial >expect &&
+ author_header HEAD >actual &&
+
+ echo "amend test" >expect &&
+ message_body HEAD >actual &&
+ test_cmp expect actual
'
-test_expect_success '--amend option should be working' '
- echo "Initial" > "$TEST_FILE" &&
- git add "$TEST_FILE" &&
- git commit -m "Initial Commit" --author Frigate\ \<flying@over.world\> &&
- echo "Test 5" >> "$TEST_FILE" &&
- git add "$TEST_FILE" &&
- git commit -m "--amend test" &&
- git cat-file -p HEAD | grep '^author' > commit_1 &&
- sleep 1 &&
- git commit -m "Changed" --amend &&
- git cat-file -p HEAD | grep '^author' > commit_2 &&
- cmp commit_1 commit_2
+test_expect_success '--mine makes the commit ours even with --amend option' '
+ git checkout Initial &&
+ echo "Test 6" >>foo &&
+ test_tick &&
+ git commit -a --mine -m "Changed again" --amend &&
+ echo "author $GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL> $GIT_AUTHOR_DATE" >expect &&
+ author_header HEAD >actual &&
+ test_cmp expect actual &&
+
+ echo "Changed again" >expect &&
+ message_body HEAD >actual &&
+ test_cmp expect actual
'
-test_expect_success '--amend option with --claim is working properly' '
- sleep 1 &&
- echo "Test 6" >> "$TEST_FILE" &&
- git add "$TEST_FILE" &&
- git commit -m "Changed again" --amend --claim &&
- git cat-file -p HEAD | grep '^author' > commit_1 &&
- test_must_fail cmp commit_1 commit_2
+test_expect_success '--mine and --author are mutually exclusive' '
+ git checkout Initial &&
+ echo "Test 7" >>foo &&
+ test_tick &&
+ test_must_fail git commit -a --mine --author="Xyzzy <frotz@nitfol.xz>"
'
test_done
^ permalink raw reply related
* Re: [PATCH] commit -c/-C/--amend: acquire authorship and restamp time with --claim
From: Junio C Hamano @ 2009-11-02 3:07 UTC (permalink / raw)
To: Erick Mattos; +Cc: git
In-Reply-To: <7v1vkhy6n4.fsf@alter.siamese.dyndns.org>
The last one was probably harder to read since it was an interdiff. Here
is what I am considering to queue.
No, I didn't use --mine option when I ran "commit --amend" to record this
one ;-)
-- >8 --
From: Erick Mattos <erick.mattos@gmail.com>
Date: Sun, 1 Nov 2009 16:45:27 -0200
Subject: [PATCH] git commit --mine: ignore authorship information taken from -c/-C/--amend
When we use -c, -C, or --amend, we are trying one of two things: using the
source as a template or modifying a commit with corrections.
When these options are are used, the authorship and timestamp recorded in
the newly created commit is always taken from the original commit. This
is inconvenient when you want to just borrow the commit log message, or
your change is so significant that you should take over the authorship
(with the blame for bugs you introduced).
Signed-off-by: Erick Mattos <erick.mattos@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-commit.txt | 7 +++-
builtin-commit.c | 10 +++-
t/t7509-commit.sh | 103 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 116 insertions(+), 4 deletions(-)
create mode 100755 t/t7509-commit.sh
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 0578a40..7832720 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]
- [(-c | -C) <commit>] [-F <file> | -m <msg>]
+ [(-c | -C) <commit>] [-F <file> | -m <msg>] [--mine]
[--allow-empty] [--no-verify] [-e] [--author=<author>]
[--cleanup=<mode>] [--] [[-i | -o ]<file>...]
@@ -69,6 +69,11 @@ OPTIONS
Like '-C', but with '-c' the editor is invoked, so that
the user can further edit the commit message.
+--mine::
+ When used with -C/-c/--amend options, declare that the
+ authorship of the resulting commit now belongs of the committer.
+ This also renews the author timestamp.
+
-F <file>::
--file=<file>::
Take the commit message from the given file. Use '-' to
diff --git a/builtin-commit.c b/builtin-commit.c
index beddf01..aa42989 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -51,7 +51,7 @@ static const char *template_file;
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;
+static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
static char *untracked_files_arg;
/*
* The default commit message cleanup mode will remove the lines
@@ -91,8 +91,9 @@ 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_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', "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"),
+ OPT_BOOLEAN(0, "mine", &renew_authorship, "the commit is authored by me now (used with -C-c/--amend)"),
OPT_BOOLEAN('s', "signoff", &signoff, "add Signed-off-by:"),
OPT_FILENAME('t', "template", &template_file, "use specified template file"),
OPT_BOOLEAN('e', "edit", &edit_flag, "force edit of commit"),
@@ -381,7 +382,7 @@ static void determine_author_info(void)
email = getenv("GIT_AUTHOR_EMAIL");
date = getenv("GIT_AUTHOR_DATE");
- if (use_message) {
+ if (use_message && !renew_authorship) {
const char *a, *lb, *rb, *eol;
a = strstr(use_message_buffer, "\nauthor ");
@@ -747,6 +748,9 @@ static int parse_and_validate_options(int argc, const char *argv[],
if (force_author && !strchr(force_author, '>'))
force_author = find_author_by_nickname(force_author);
+ if (force_author && renew_authorship)
+ die("Using both --mine and --author does not make sense");
+
if (logfile || message.len || use_message)
use_editor = 0;
if (edit_flag)
diff --git a/t/t7509-commit.sh b/t/t7509-commit.sh
new file mode 100755
index 0000000..ec13cea
--- /dev/null
+++ b/t/t7509-commit.sh
@@ -0,0 +1,103 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Erick Mattos
+#
+
+test_description='git commit --mine'
+
+. ./test-lib.sh
+
+author_header () {
+ git cat-file commit "$1" |
+ sed -n -e '/^$/q' -e '/^author /p'
+}
+
+message_body () {
+ git cat-file commit "$1" |
+ sed -e '1,/^$/d'
+}
+
+test_expect_success '-C option copies authorship and message' '
+ echo "Initial" >foo &&
+ git add foo &&
+ test_tick &&
+ git commit -m "Initial Commit" --author Frigate\ \<flying@over.world\> &&
+ git tag Initial &&
+ echo "Test 1" >>foo &&
+ test_tick &&
+ git commit -a -C Initial &&
+ author_header Initial >expect &&
+ author_header HEAD >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '-C option copies only the message with --mine' '
+ echo "Test 2" >>foo &&
+ test_tick &&
+ git commit -a -C Initial --mine &&
+ echo "author $GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL> $GIT_AUTHOR_DATE" >expect &&
+ author_header HEAD >actual
+ test_cmp expect actual &&
+
+ message_body Initial >expect &&
+ message_body HEAD >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '-c option copies authorship and message' '
+ echo "Test 3" >>foo &&
+ test_tick &&
+ EDITOR=: VISUAL=: git commit -a -c Initial &&
+ author_header Initial >expect &&
+ author_header HEAD >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '-c option copies only the message with --mine' '
+ echo "Test 4" >>foo &&
+ test_tick &&
+ EDITOR=: VISUAL=: git commit -a -c Initial --mine &&
+ echo "author $GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL> $GIT_AUTHOR_DATE" >expect &&
+ author_header HEAD >actual &&
+ test_cmp expect actual &&
+
+ message_body Initial >expect &&
+ message_body HEAD >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '--amend option copies authorship' '
+ git checkout Initial &&
+ echo "Test 5" >>foo &&
+ test_tick &&
+ git commit -a --amend -m "amend test" &&
+ author_header Initial >expect &&
+ author_header HEAD >actual &&
+
+ echo "amend test" >expect &&
+ message_body HEAD >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '--mine makes the commit ours even with --amend option' '
+ git checkout Initial &&
+ echo "Test 6" >>foo &&
+ test_tick &&
+ git commit -a --mine -m "Changed again" --amend &&
+ echo "author $GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL> $GIT_AUTHOR_DATE" >expect &&
+ author_header HEAD >actual &&
+ test_cmp expect actual &&
+
+ echo "Changed again" >expect &&
+ message_body HEAD >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '--mine and --author are mutually exclusive' '
+ git checkout Initial &&
+ echo "Test 7" >>foo &&
+ test_tick &&
+ test_must_fail git commit -a --mine --author="Xyzzy <frotz@nitfol.xz>"
+'
+
+test_done
--
1.6.5.2.246.gc99575
^ permalink raw reply related
* Re: [RFC PATCH 06/19] Factor ref updating out of fetch_with_import
From: Daniel Barkalow @ 2009-11-02 3:16 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <fabb9a1e0911011733o7d8d95eem57e02d455e0bd86@mail.gmail.com>
On Mon, 2 Nov 2009, Sverre Rabbelier wrote:
> Yes, that sounds very reasonable, and I think that's the right way to
> go. This leaves us with only one thing, we need a remote HEAD for 'git
> clone hg::/path/to/repo' to work and have it check out a branch, I
> think a seperate 'head' command might be appropriate? If supported it
> returns the which local symref (e.g. 'refs/heads/trunkr' in the svn
> case) should be pointed at by HEAD. If not supported we can just not
> set it and clone will give the default 'no remote HEAD, nothing
> checked out' message, which would probably be best for p4?
Why not have the regular list report:
@refs/heads/trunkr HEAD
or whatever it is, again like native git? That is, SVN would have an
interaction like:
> list
< ? refs/heads/trunkr
< ? refs/heads/my-branch
< ? refs/tags/v1.0
< @refs/heads/trunkr HEAD
<
This is similar to the response from the curl helper, except that it uses
"?" for the sha1s because it doesn't know them until they're imported.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Fw: git-core: SIGSEGV during {peek,ls}-remote on HTTP remotes.
From: Junio C Hamano @ 2009-11-02 4:10 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Daniel Barkalow, Junio C Hamano, Samium Gromoff, git,
Tay Ray Chuan, Mike Hommey
In-Reply-To: <fabb9a1e0911011254j316920e6y63c4f129f7df186d@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Sun, Nov 1, 2009 at 21:16, Daniel Barkalow <barkalow@iabervon.org> wrote:
>> If we change the ls-remote.c case, it becomes impossible for a struct
>> transport to ever have a NULL remote field. And the change to ls-remote
>> removes a special case. I'd go so far as to say that ls-remote.c should
>> provide a struct remote, and transport_get should enforce that there's a
>> struct remote.
>
> If that is the case (that we can eliminate the only special case), I
> agree that we should fix it there, where it will be the least effort.
> I got the impression from Junio's original post that there are
> multiple places that would have to be fixed, and I figured that we
> should fix it where it will be the least amount of effort :).
No, I genuinely didn't know what Daniel's intention was when a transport
has NULL in its remote field. If it is much easier and cleaner not to
allow such a transport, then let's declare that and fix ls-remote that
should be the sole existing caller that used to use such a transport.
Thanks for looking into this, both of you.
^ permalink raw reply
* Re: [PATCH] Update packfile transfer protocol documentation
From: Junio C Hamano @ 2009-11-02 5:17 UTC (permalink / raw)
To: Scott Chacon; +Cc: git list, Shawn O. Pearce, Junio C Hamano
In-Reply-To: <d411cc4a0911011518q15a8267bn642e6937be8c9ab1@mail.gmail.com>
Scott Chacon <schacon@gmail.com> writes:
> The technical documentation for the packfile protocol is both sparse and
> incorrect. This documents the fetch-pack/upload-pack and send-pack/
> receive-pack protocols much more fully.
>
> Add documentation from Shawn's upcoming http-protocol docs that is shared
> by the packfile protocol. protocol-common.txt describes ABNF notation
> amendments, refname rules and the packet line format.
>
> Add documentation on the various capabilities supported by the
> upload-pack and receive-pack protocols. protocol-capabilities.txt describes
> multi-ack, thin-pack, side-band[-64k], shallow, no-progress, include-tag,
> ofs-delta, delete-refs and report-status.
>
> Signed-Off-By: Scott Chacon <schacon@gmail.com>
> ---
This is just for future reference, but please downcase O and B above.
> diff --git a/Documentation/technical/pack-protocol.txt
> b/Documentation/technical/pack-protocol.txt
> index 9cd48b4..1cc61d8 100644
> --- a/Documentation/technical/pack-protocol.txt
> +++ b/Documentation/technical/pack-protocol.txt
> +Packfile transfer protocols
> +===========================
> +
> +Git supports transferring data in packfiles over the ssh://, git:// and
> +file:// transports. There exist two sets of protocols, one for pushing
> +data from a client to a server and another for fetching data from a
> +server to a client. All three transports (ssh, git, file) use the same
> +protocol to transfer data.
> +
> +The processes invoked in the canonical Git implementation are 'upload-pack'
> +on the server side and 'fetch-pack' on the client side for fetching data;
> +then 'receive-pack' on the server and 'send-pack' on the client for pushing
> +data. The protocol functions to have a server tell a client what is
> +currently on the server, then for the two to negotiate the smallest amount
> +of data to send in order to fully update one or the other.
> +
> +Transports
> +----------
> +There are three transports over which the packfile protocol is
> +initiated. The Git transport is a simple, unauthenticated server that
> +simply takes the command (almost always 'upload-pack', though Git
> +servers can be configured to be globally writable, in which 'receive-
> +pack' initiation is also allowed) with which the client wishes to
> +communicate and executes it and connects it to the requesting
> +process.
> +
> +In the SSH transport, the client basically just runs the 'upload-pack'
> +or 'receive-pack' process on the server over the SSH protocol and then
> +communicates with that invoked process over the SSH connection.
> +
> +The file:// transport simply runs the 'upload-pack' or 'receive-pack'
> +process locally and communicates with it over a pipe.
Very nicely and concisely written. Noise words like "simply" and
"basically" might be better omitted, though (not just this part but in the
rest of the document as well).
Yes, I admit I have the tendency to excessively use them, too.
> +Git Protocol
> +------------
> +
> +The Git protocol starts off by sending "git-receive-pack 'repo.git'"
> +on the wire using the pkt-line format, followed by a null byte and a
> +hostname paramater, terminated by a null byte.
> +
> + 0032git-upload-pack /project.git\0host=myserver.com\0
Two-and-a-half issues.
- You are calling distinction between ssh/git/file "transport", and the
actual data exchange for pushing/fetching "protocol" in the first part
of the document, and I agree with the choice of words. The header for
this section should read "Git Transport", as that is what you are
describing.
- The example and the first line of the description contradict with each
other.
- As you already said that receive-pack could be requested over git
transport in the earlier part, I would fix the description on the first
line to say "... by sending 'command' and 'repository' on the wire ..."
to make it explain the _concept_.
> +--
> + git-proto-request = request-command SP pathname NUL [ host-parameter NUL ]
> + request-command = "git-upload-pack" / "git-receive-pack" /
> + "git-upload-archive" ; case sensitive
> + pathname = *( %x01-ff ) ; exclude NUL
> + host-parameter = "host=" hostname [ ":" port ]
> +--
> +Only host-parameter is allowed in the git-proto-request. Clients
> +MUST NOT attempt to send additional parameters. It is used for the
> +git-daemon name based virtual hosting. See --interpolated-path
> +option to git daemon, with the %H/%CH format characters.
> +Basically what the Git client is doing to connect to an 'upload-pack'
> +process on the server side over the Git protocol is this:
> +
> + $ echo -e -n \
> + "0039git-upload-pack /schacon/gitbook.git\0host=example.com\0" |
> + nc -v example.com 9418
> +
> +
> +SSH Protocol
> +------------
This is "SSH Transport", I think.
> +Initiating the upload-pack or receive-pack processes over SSH is
> +simply executing the binary on the server via SSH remote execution.
> +It is basically equivalent to running this:
> +
> + $ ssh git.example.com "git-upload-pack '/project.git'"
> +
> +For a server to support Git pushing and pulling for a given user over
> +SSH, that user needs to be able to execute one or both of those
> +commands via the SSH shell that they are provided on login. On some
> +systems, that shell access is limited to only being able to run those
> +two commands, or even just one of them.
> +
> +In an ssh:// format URI, it's absolute in the URI, so the '/' after
> +the host name (or port number) is sent as an argument, which is then
> +read by the remote git-upload-pack exactly as is, so it's effectively
> +an absolute path in the remote filesystem.
> +
> + git clone ssh://user@example.com/project.git
> + |
> + v
> + ssh user@example.com "git-upload-pack '/project.git'"
> +
> +In a "user@host:path" format URI, its relative to the user's home
> +directory, because the Git client will run:
> +
> + git clone user@example.com:project.git
> + |
> + v
> + ssh user@example.com "git-upload-pack 'project.git'"
> +
> +The exception is if a '~' is used, in which case
> +we execute it without the leading '/'.
> +
> + ssh://user@example.com/~alice/project.git,
> + |
> + v
> + ssh user@example.com "git-upload-pack '~alice/project.git'"
This depends on the intended audience of this document, but if we are
writing for people who want to implement their own gitosis and gitolite to
replace the login shell spawned by ssh daemon, you may want to explain the
"command line" given to it a bit more precisely. Specifically:
- The "command name" is spelled with dash (e.g. git-upload-pack), but
this can be overridden by the client;
- The repository path is always quoted with sq (i.e. by sq_quote_buf()).
> +Fetching Data From a Server
> +===========================
> +
> +When one Git repository wants to get all the data that a second
> +repository has, the first can 'fetch' from the second. This
> +operation determines what data the server has that the client does
> +not then streams that data down to the client in packfile format.
I've been disturbed by this "all" since your first draft, as fetching data
reachable from only a few refs but not all is perfectly a valid thing to
do, but I am not sure if it is worth complicating this document to clarify
this point. Probably not---but then the above would read perfectly well
without "all".
> +The server side binaries need to be executable as 'git-upload-pack'
> +for fetching and 'git-receive-pack' for pushing over SSH, since the
> +Git clients will connect to the server and attempt to run that command
> +directly. Over the Git protocol, one could write their own daemon
> +that sees that the client is trying to invoke those commands and
> +simply handle the requests.
I am not sure what audience this paragraph is trying to help by making it
sound as if git transport allows customized daemon but ssh transport
doesn't. gitosis and gitolite are examples of "own daemon that sees that
the client is trying to invoke those commands and simply handle the
requests" over SSH, aren't they? So if the purpose is to help server
authors, this paragraph does more harm than being useful. If the purpose
is to satisfy curiosity, I doubt this level of detail is necessary.
Also there is a terminology mix-up; the last sentence should begin with
"Over the Git transport".
> +Reference Discovery
> +-------------------
> +
> +When the client initially connects the server will immediately respond
> +with a listing of each reference it has (all branches and tags) along
> +with the commit SHA that each reference currently points to.
Not "the commit SHA", but "object name". a ref can point at a non-commit
object, such as a tag.
> + $ echo -e -n \
> + "0039git-upload-pack /schacon/gitbook.git\0host=example.com\0" |
> + nc -v example.com 9418
> + 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack \
> + thin-pack side-band side-band-64k ofs-delta shallow no-progress \
> + include-tag
We should explain this is actually a long single line, and line folding
with backslashes is solely for the readers of this document, after this
sample response.
> + 00441d3fcd5ced445d1abc402225c0b8a1299641f497 refs/heads/integration
> + 003f7217a7c7e582c46cec22a130adf4b9d7d950fba0 refs/heads/master
> + 003cb88d2441cac0977faf98efc80305012112238d9d refs/tags/v0.9
> + 003c525128480b96c89e6418b1e40909bf6c5b2d580f refs/tags/v1.0
> + 003fe92df48743b7bc7d26bcaabfddde0a1e20cae47c refs/tags/v1.0^{}
> + 0000
> +Server SHOULD terminate each non-flush line
> +using LF ("\n") terminator; client MUST NOT complain if there is no
> +terminator.
Hmm, LF ("\n") makes me wonder how precise we would want to be. We
probably should also say we use ASCII (meaning "not EBCDIC") somewhere but
that level of details can wait until a more later draft..
> +The returned response is a pkt-line stream describing each ref and
> +its known value. The stream SHOULD be sorted by name according to
> +the C locale ordering. The stream SHOULD include the default ref
> +named 'HEAD' as the first ref. The stream MUST include capability
> +declarations behind a NUL on the first ref.
I have a vague recollection that in a recent discussion (not discussion on
this documentation patch, but on a "builtin-fetch.c" patch around mid
September), we decided that the above two SHOULD should be MUST. Another
MUST that is missing from here is that a line that describes a peeled tag
MUST immediately follow the tag itself.
Shawn?
> +----
> + advertised-refs = (no-refs / list-of-refs)
> + flush-pkt
> +
> + no-refs = PKT-LINE(zero-id SP "capabilities^{}"
> + NUL capability-list LF)
> +
> + list-of-refs = first-ref *other-ref
> + first-ref = PKT-LINE(obj-id SP refname
> + NUL capability-list LF)
> +
> + other-ref = PKT-LINE(other-tip / other-peeled)
> + other-tip = obj-id SP refname LF
> + other-peeled = obj-id SP refname "^{}" LF
> +
> + capability-list = capability *(SP capability)
> + capability = 1*(ALPHA / DIGIT / "-" / "_")
> +----
> +
> +Server and client SHOULD use lowercase for SHA1, both MUST treat SHA1
> +as case-insensitive.
Why do we need to retroactively loosen these to allow uppercases? Are
there implementations that want this loosening?
> +Packfile Negotiation
> +--------------------
I'll look at the rest another day.
Thanks.
^ permalink raw reply
* Re: stgit, rebasing with 100 patches
From: Karl Wiberg @ 2009-11-02 8:22 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List, Catalin Marinas
In-Reply-To: <9e4733910910040600g2cbd1deah6e7ae3ad9a4aa54e@mail.gmail.com>
On Sun, Oct 4, 2009 at 2:00 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Thu, Oct 1, 2009 at 7:04 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>
> > Is there a better way to locate the patches the got applied?
>
> A solution to this is to make an option on rebase that walks the
> patch stack forward one commit at a time.
>
> What does the --merged option do on stg rebase? The doc is rather
> sparse.
Right, -m/--merged is what you want. Before applying any of the
patches, it tries to reverse-apply all of them in reverse
order---successful applications mean the patch was already in
upstream. It works surprisingly well.
--
Karl Wiberg, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] t1402: Make test executable
From: Stephen Boyd @ 2009-11-02 9:30 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
0 files changed, 0 insertions(+), 0 deletions(-)
mode change 100644 => 100755 t/t1402-check-ref-format.sh
diff --git a/t/t1402-check-ref-format.sh b/t/t1402-check-ref-format.sh
old mode 100644
new mode 100755
--
1.6.5.2.181.gd6f41
^ permalink raw reply
* Re: Headless tags don't have a follows or precedes?
From: Michael J Gruber @ 2009-11-02 9:42 UTC (permalink / raw)
To: Tim Mazid; +Cc: git
In-Reply-To: <1257067898626-3926483.post@n2.nabble.com>
Tim Mazid venit, vidit, dixit 01.11.2009 10:31:
>
> Hi all,
>
> I've noticed that if I create a headless tag (one that doesn't have a
> branch, right?), when I click on that commit, it doesn't have precedes or
> follows information. Is this by design? Is there a work-around I can use
> without creating a branch there?
Reposting (without even saying so) doesn't necessarily increase your
chance of getting responses. Would would help:
- saying you're talking about gitk/git view/whatever it is you're
"clicking" on
- providing a minimal example others can reproduce. That would be one
where a tag on a detached head (assuming that's what you mean) has no
precedes/follow but a tag "on a branch" does have that info
Cheers,
Michael
^ permalink raw reply
* Re: [ANNOUNCE] Stacked Git 0.15
From: Felipe Contreras @ 2009-11-02 10:05 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Git Mailing List
In-Reply-To: <b0943d9e0910241541n7b1091ecp6b21fa896405afa0@mail.gmail.com>
On Sun, Oct 25, 2009 at 12:41 AM, Catalin Marinas
<catalin.marinas@gmail.com> wrote:
> StGit is a Python application providing functionality similar to Quilt
> (i.e. pushing/popping patches to/from a stack) on top of Git. These
> operations are performed using Git commands, and the patches are
> stored as Git commit objects, allowing easy merging of the StGit
> patches into other repositories using standard Git functionality.
>
> Download: http://download.gna.org/stgit/stgit-0.15.tar.gz
> Main repository: git://repo.or.cz/stgit.git
> Project homepage: http://www.procode.org/stgit/
> Mailing list: git@vger.kernel.org (please use "StGit" in the subject)
> Bug tracker: https://gna.org/bugs/?group=stgit
>
> The main changes since release 0.14.3 are
>
> - New core infrastructure for repository operations, including
>
> + Infinite undo/redo operations and corresponding commands.
>
> + Automatic rollback of changes following a failed operation
> (using transactions)---this ensures that StGit commands either
> succeed or do nothing. Previously, every commands had its own
> ad hoc implementation of this.
>
> - Some commands were added, including
>
> + "stg squash", for combining two or more patches into one.
>
> + "stg publish", for maintaining merge-friendly branches (which
> are not rebased).
>
> + "stg prev/next" for printing the name of the previous or next
> patch in the series.
>
> - The commands "stg add", "stg rm", "stg cp", and "stg resolved"
> were removed, since there are corresponding Git equivalents.
>
> - The "stg import" and "stg fold" commands support the "-p N" option
> for stripping leading slashes from diff paths.
>
> - The "stg import" and "stg fold" commands support the "--reject"
> option for leaving rejected hunks in corresponding *.rej files.
>
> - New patch identification syntax: <branch>:<patch> (see
> documentation for the "stg id" command).
>
> - Autosigning of imported patches when "sign.autosign" configuration
> option is set.
>
> - A powerful Emacs mode for StGit was added to the "contrib"
> directory. It displays the patch stack in an Emacs buffer, and can
> handle all common StGit tasks.
>
> - Improved bash tab-completion, automatically generated from the stg
> command definitions.
>
> - Man pages and an improved tutorial.
>
> Special thanks go to Karl Wiberg for the hard work done on the new
> StGit features, to Catalin Marinas for many new features and bugfixes,
> and to David Kågedal and Gustav Hållberg for the Emacs mode.
I don't know why, but the announcement RSS feed breaks exactly here
due to some UTF-8 miss-match or something:
wget http://gitrss.q42.co.uk/announce.rss
--
Felipe Contreras
^ permalink raw reply
* Unhappy git in a jailshell?
From: Alex MDC @ 2009-11-02 12:16 UTC (permalink / raw)
To: git
Hello,
I'm trying to use git on a linux server, but unfortunately I've only
been granted jailshelled access. Most of git works, but some commands
just fail to run, e.g.
git repack
git rebase
git index-pack
All these commands fail with the error "git: git-xxx is not a
git-command. See git --help". However most other every-day commands
work just fine (add, status, commit...)
I've been in contact with the server admins and they kindly upgraded
git to the latest 1.6.5.2 release but that didn't help. I enquired
about the contents of `git --exec-path` (as I don't have access from
the jailshell) and they said that all the "missing" commands are
present in that directory.
I also tried "git --help -all" but that doesn't show any commands in
the output! In a way I'm wondering how it is working at all...
So I guess my question is, why are some commands working but not
others? If all commands are treated uniformly by using the command
binary from the libexec dir it would seem as though all commands
should work or all should be "missing".
Also, are they any ideas on how to get the missing commands to work?
Thanks for your help,
Alex MDC
^ permalink raw reply
* git pull --rebase and losing commits
From: Peter Krefting @ 2009-11-02 12:26 UTC (permalink / raw)
To: Git Mailing List
Hi!
I have put my web site under Git control, and am running into some problems.
Whenever I push changes, I go via a bare repository, which then is pulled
into a checked out tree in my "public_html" directory. However, some scripts
I have does create files directly under the "public_html", and some of them
I want to push into the Git history.
I am trying to use --rebase everywhere to get a linear history in the cases
where I have pushed changes to the bare repository while there were
uncommited changes to the public_html directory.
I have come up with a script that does this (I have removed the
uninteresting non-git commands):
# Commit local changes
git add path/to/script/output/*
for file in $(git diff-index --cached --name-only HEAD); do
havenew=1
done
if [ $havenew = 1 ]; then
git commit --quiet -m 'Automatic' path/to/script/output/*
fi
# Update tree (--strategy=ours avoids merge conflicts)
git pull --rebase --strategy=ours origin master
# Push rebased local changes
git push origin master
# Update all references
git fetch origin master:remotes/origin/master
However, this seems to lose commits. When I ran it today, it commited an
automatic change, and then pulled a tree that did not contain that change,
making the changed file just disappear. I had to dig through the reflog to
find it:
- This is the auto-commit:
608b7eda553552841f4a16167c680fc74ed3c55a
509926edd306bb2f09f563a7cfda800a4f0fdaed Peter Krefting
<peter@softwolves.pp.se> 1257162580 +0100 commit: Automatisk
bloggkommentarsuppdatering
- This is the "git pull":
509926edd306bb2f09f563a7cfda800a4f0fdaed
9088bd4801a9008fe3fca0d351f97544cee014f1 Peter Krefting
<peter@softwolves.pp.se> 1257162583 +0100 rebase finished:
refs/heads/master onto 9088bd4801a9008fe3fca0d351f97544cee014f1
The history of 9088bd... does not contain the rebased version of 509926...,
it just went missing.
I guess I am missing something vital here.
$ git --version
git version 1.5.6.5
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* [PATCH] Skip translation of wrong Tcl version text
From: Bernt Hansen @ 2009-11-02 12:41 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git, Paul Mackerras
In-Reply-To: <874opel7de.fsf@gollum.intra.norang.ca>
We check the required Tcl version number before we setup msgcat for
language translation. If the Tcl version is too old just display the
untranslated error text.
The caller of show_error can now pass an alternative function for mc.
The Tcl list function turns the transalation into a no-op.
This fixes the
Error in startup script: invalid command name "mc"
when attempting to start gitk with Tcl 8.3.
Signed-off-by: Bernt Hansen <bernt@norang.ca>
---
I tested this patch with both Tcl 8.3 and 8.4.
This is an alternative to the previous 2 patches I sent attempting
to initialize msgcat before first use. This patch is much simpler
but does not attempt to translate the wrong version message text.
This patch fixes the version number error message by displaying it
untranslated since msgcat is not initialized yet. The current
initialization code for msgcat uses normalize which is only available as
of Tcl 8.4 so moving the code up front didn't work in Tcl 8.3.
gitk | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gitk b/gitk
index a0214b7..d1f32a9 100755
--- a/gitk
+++ b/gitk
@@ -1787,10 +1787,10 @@ proc make_transient {window origin} {
}
}
-proc show_error {w top msg} {
+proc show_error {w top msg {mc mc}} {
message $w.m -text $msg -justify center -aspect 400
pack $w.m -side top -fill x -padx 20 -pady 20
- button $w.ok -text [mc OK] -command "destroy $top"
+ button $w.ok -text [$mc OK] -command "destroy $top"
pack $w.ok -side bottom -fill x
bind $top <Visibility> "grab $top; focus $top"
bind $top <Key-Return> "destroy $top"
@@ -11006,8 +11006,8 @@ proc get_path_encoding {path} {
# First check that Tcl/Tk is recent enough
if {[catch {package require Tk 8.4} err]} {
- show_error {} . [mc "Sorry, gitk cannot run with this version of Tcl/Tk.\n\
- Gitk requires at least Tcl/Tk 8.4."]
+ show_error {} . "Sorry, gitk cannot run with this version of Tcl/Tk.\n\
+ Gitk requires at least Tcl/Tk 8.4." list
exit 1
}
--
1.6.5.2.141.gc8a58
^ permalink raw reply related
* Re: Unhappy git in a jailshell?
From: Dmitry Potapov @ 2009-11-02 12:47 UTC (permalink / raw)
To: Alex MDC; +Cc: git
In-Reply-To: <130714cd0911020416r6a686026q697d843f47b68692@mail.gmail.com>
On Mon, Nov 02, 2009 at 11:16:43PM +1100, Alex MDC wrote:
> Hello,
>
> I'm trying to use git on a linux server, but unfortunately I've only
> been granted jailshelled access. Most of git works, but some commands
> just fail to run, e.g.
> git repack
> git rebase
> git index-pack
Most Git commands are builtin, so they are executed by git.exe directly,
but some commands are implemented as separate binaries or shell files.
These commands require `git --exec-path` in PATH to run. Normally, git
adds `git --exec-path` in its environment before running them.
Apparently, jailshelled access prevents that somehow. So, I suggest you
contact your system administrator and tell him that you need to be able
to run files from `git --exec-path` to being able to use git, as git
needs them internally for normal work.
Dmitry
^ permalink raw reply
* Re: Headless tags don't have a follows or precedes?
From: Tim Mazid @ 2009-11-02 13:07 UTC (permalink / raw)
To: git
In-Reply-To: <4AEEA96F.7080609@drmicha.warpmail.net>
Michael J Gruber-2 wrote:
>
> Tim Mazid venit, vidit, dixit 01.11.2009 10:31:
>>
>> Hi all,
>>
>> I've noticed that if I create a headless tag (one that doesn't have a
>> branch, right?), when I click on that commit, it doesn't have precedes or
>> follows information. Is this by design? Is there a work-around I can use
>> without creating a branch there?
>
> Reposting (without even saying so) doesn't necessarily increase your
> chance of getting responses.
>
I didn't repost. Or at the least, I didn't mean to repost. The mailing list
kept complaining (spamming me) that my post was pending, and I eventually
realised that was the old forum. I deleted it from there, and copy-pasted
here. I didn't even realise it had posted here, and that when I deleted from
the old forum, it didn't delete here.
Michael J Gruber-2 wrote:
>
> Would would help:
>
> - saying you're talking about gitk/git view/whatever it is you're
> "clicking" on
>
My apologies, yes, in gitk.
Michael J Gruber-2 wrote:
>
> - providing a minimal example others can reproduce. That would be one
> where a tag on a detached head (assuming that's what you mean) has no
> precedes/follow but a tag "on a branch" does have that info
>
Example (unless specified, commands as entered into bash)
mkdir temp
cd temp
git init
gitk --all &
git commit --allow-empty -m '1'
git tag v1
git commit --allow-empty -m '1.1'
git tag v1.1
git commit --allow-empty -m '1.2'
git tag v1.2
(in gitk, press ctrl+f5; all follows and precedes info is there)
git checkout v1.1
git commit --allow-empty -m '1.1.1'
git tag v1.1.1
(in gitk, press f5; follows and precedes info missing for v1.1 and v1.1.1)
(close gitk)
gitk --all &
(info still missing)
git commit --allow-empty -m '1.1.2'
git tag v1.1.2
(in gitk, press f5, info still missing)
git checkout master
git commit --allow-empty -m '1.3'
git tag v1.3
(in gitk, press f5, info still missing)
git commit --allow-empty -m '1.4'
git tag v1.4
(in gitk, press f5, info still missing)
git checkout -b temp v1.2
git commit --allow-empty -m '1.2.1'
git tag v1.2.1
(in gitk, press f5, info still missing)
git checkout master
git branch -D temp
git commit --allow-empty -m '1.5'
git tag v1.5
(in gitk, press f5, info still missing)
In the end, the only follows/precedes info is:
v1: precedes v1.1
v1.1: follows v1, precedes v1.2
v1.2: follows v1.1
All the rest is missing.
--
View this message in context: http://n2.nabble.com/Headless-tags-don-t-have-a-follows-or-precedes-tp3926483p3931674.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Headless tags don't have a follows or precedes?
From: Dmitry Potapov @ 2009-11-02 13:09 UTC (permalink / raw)
To: Tim Mazid; +Cc: git
In-Reply-To: <26093136.post@talk.nabble.com>
On Wed, Oct 28, 2009 at 04:36:59AM -0700, Tim Mazid wrote:
>
> I've noticed that if I create a headless tag (one that doesn't have a
> branch, right?),
I have never heard tag being described as headless... A tag is just a
pointer on some commit (annotated tag contains additional information
such as creater, data, message), in any case, it has no direct relation
to any branch.
> when I click on that commit, it doesn't have precedes or
> follows information. Is this by design?
Tags do not store any precedes or follows information, no matter how you
created them, but visualization tools can look at the tree and display
what was before some commit and what was after it. Without seeing your
tree, it is impossible to tell whether gitk (or what you use?) displayed
that correctly or not.
Dmitry
^ permalink raw reply
* Re: Headless tags don't have a follows or precedes?
From: Tim Mazid @ 2009-11-02 13:16 UTC (permalink / raw)
To: git
In-Reply-To: <20091102130919.GB27126@dpotapov.dyndns.org>
Dmitry Potapov wrote:
>
> I have never heard tag being described as headless... A tag is just a
> pointer on some commit (annotated tag contains additional information
> such as creater, data, message), in any case, it has no direct relation
> to any branch.
>
> Tags do not store any precedes or follows information, no matter how you
> created them, but visualization tools can look at the tree and display
> what was before some commit and what was after it. Without seeing your
> tree, it is impossible to tell whether gitk (or what you use?) displayed
> that correctly or not.
>
Well, not the tag itself, but the commit the tags points to. Same thing.
Like you're always bothered to say "the commit that the tag v1 points to"
rather than "the v1 tag".
Also, see my post above.
--
View this message in context: http://n2.nabble.com/Headless-tags-don-t-have-a-follows-or-precedes-tp3926483p3931717.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Unhappy git in a jailshell?
From: Michael J Gruber @ 2009-11-02 13:51 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Alex MDC, git
In-Reply-To: <20091102124746.GA27126@dpotapov.dyndns.org>
Dmitry Potapov venit, vidit, dixit 02.11.2009 13:47:
> On Mon, Nov 02, 2009 at 11:16:43PM +1100, Alex MDC wrote:
>> Hello,
>>
>> I'm trying to use git on a linux server, but unfortunately I've only
>> been granted jailshelled access. Most of git works, but some commands
>> just fail to run, e.g.
>> git repack
>> git rebase
>> git index-pack
>
> Most Git commands are builtin, so they are executed by git.exe directly,
> but some commands are implemented as separate binaries or shell files.
> These commands require `git --exec-path` in PATH to run. Normally, git
> adds `git --exec-path` in its environment before running them.
>
> Apparently, jailshelled access prevents that somehow. So, I suggest you
> contact your system administrator and tell him that you need to be able
> to run files from `git --exec-path` to being able to use git, as git
> needs them internally for normal work.
>
Can you (Alex) find out whether you are allowed to run those binaries
from that path directly? In that case we could rethink our strategy and
adjust for the case where we can't set the environment.
Michael
^ permalink raw reply
* Re: My custom cccmd
From: Felipe Contreras @ 2009-11-02 14:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr5skim76.fsf@alter.siamese.dyndns.org>
On Fri, Oct 30, 2009 at 11:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Tue, Oct 27, 2009 at 11:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> It might make more sense if your tool told you about such a case directly,
>>> rather than helping you find John so that he can tell you ;-).
>>
>> But that's not the purpose of the cccmd tool.
>>
>> I agree that such "patch series simplificator" tool would be very
>> useful, but that's out of scope for this. Isn't it?
>
> Exactly.
>
> So you agree that you _do_ want to "discard the previous commits in the
> patch series", because not doing so would mean the result would be a
> half-cooked "patch series simplificator" that tries to do something that
> is outside the scope of cccmd, right?
>
> The "discarding the previous commits" happens to match what I suggested
> earlier that lead to your "explored this a bit more":
>
> On Thu, Oct 15, 2009 at 11:37 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>> On Thu, Oct 15, 2009 at 11:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> #2. If you have two patch series that updates one file twice, some
>>> changes in your second patch could even be an update to the changes
>>> you introduced in your first patch. After you fix issue #1, you
>>> would probably want to fix this by excluding the commits you have
>>> already sent the blames for.
>
> so I think we are in agreement.
Cool. Is this script something that would make sense in the contrib section?
--
Felipe Contreras
^ permalink raw reply
* Re: git pull --rebase and losing commits
From: Thomas Rast @ 2009-11-02 15:04 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0911021318400.3919@ds9.cixit.se>
Peter Krefting wrote:
> # Update tree (--strategy=ours avoids merge conflicts)
> git pull --rebase --strategy=ours origin master
[...]
> However, this seems to lose commits. When I ran it today, it commited an
> automatic change, and then pulled a tree that did not contain that change,
> making the changed file just disappear.
Not very surprising if you use the 'ours' strategy, which doesn't
merge at all but instead takes the 'ours' side (IIRC that's the
upstream for a rebase, but I always have these mixed up). It is *not*
the often requested (but ill-defined and hence never implemented)
"resolve all conflict hunks in favour of ours" strategy.
So what happens is that git-rebase rebuilds some commit C from your
side on some base B from the remote, but the 'ours' strategy turns the
*tree* for C' into that of B. Then git-rebase sees that the trees
haven't changed, and concludes that C has already been applied and
drops it.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git pull --rebase and losing commits
From: Björn Steinbrink @ 2009-11-02 15:10 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0911021318400.3919@ds9.cixit.se>
On 2009.11.02 13:26:37 +0100, Peter Krefting wrote:
> # Update tree (--strategy=ours avoids merge conflicts)
> git pull --rebase --strategy=ours origin master
The "ours" strategy doesn't just avoid merge conflicts, it avoids making
any changes at all. The ours strategy means "just keep our state, just
pretend that we've merged". And rebase will see that there were no
changes and conclude:
Already applied: 0001 test commit
And thus it will drop the commit.
Björn
^ permalink raw reply
* Binary files in a linear repository
From: Markus Hitter @ 2009-11-02 15:08 UTC (permalink / raw)
To: git
In-Reply-To: <S1754797AbZKBONX/20091102141323Z+268@vger.kernel.org>
Hello all,
currently I'm planning a frontend tool which makes use of only a
small subset of git. The repo's contents is all binary (think of
pictures). Accordingly, I can't merge in a meaningful way, making
branches of very limited use.
The situation I'm trying to solve is:
- A revision earlier than the latest one is checked out.
- Files of this earlier commit are modified.
- I want to record this earlier commit along with it's modifications
as a new commit on top of master, ignoring intermediate commits:
com005 <-- master
com004
com003 <-- HEAD, files modified
com002
com001 (initial commit)
One solution to do this is to move all files somewhere else, check
out master, deleting all checked out files, placing the moved away
files back into place and committing the result as com006. Obviously,
this is a pretty complex operation, just waiting to exploit coding
mistakes. Additionally, this will be slow.
Now I'm thinking about a much simpler solution: Simply declare the
current set of files as (a modified) master/com005 and commit them. A
"cp $GIT_DIR/master $GIT_DIR/HEAD" followed by a commit would do it.
Now my question: Is it safe to tweak the files in $GIT_DIR this way
or will this corrupt the repository?
Thanks for any opinions,
Markus
^ permalink raw reply
* Re: [RFC PATCH 06/19] Factor ref updating out of fetch_with_import
From: Sverre Rabbelier @ 2009-11-02 15:12 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <alpine.LNX.2.00.0911012038120.14365@iabervon.org>
Heya,
On Mon, Nov 2, 2009 at 04:16, Daniel Barkalow <barkalow@iabervon.org> wrote:
> Why not have the regular list report:
>
> @refs/heads/trunkr HEAD
>
> or whatever it is, again like native git? That is, SVN would have an
> interaction like:
That's fine with me, but earlier you said you didn't like the whole
symlinking idea.
You said in another thread you'll be working on some patches, does
that include this 'refs' command? I want to avoid duplicate work if
possible :).
--
Cheers,
Sverre Rabbelier
^ 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