* Re: Serious bug with pretty format strings & empty bodies?
From: Johannes Schindelin @ 2007-12-20 12:34 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: René Scharfe, Alex Riesen, git
In-Reply-To: <57518fd10712200338m19c1def9n747dc9353ae41615@mail.gmail.com>
Hi,
On Thu, 20 Dec 2007, Jonathan del Strother wrote:
> I ended up trying to filter-branch my repository, see if I could come
> up with a version stripped of all our private code, suitable for
> making public. Disappointingly, filter-branch magically fixes all the
> commits, even when simply run as "git filter-branch HEAD".
>
> However, looking at the rewritten repository vs the original, they
> share a lot of commits, then diverge halfway through their history. I
> can't see anything notable about the commit where they diverge, with
> the exception that the rewritten commit has a newline after the
> subject and the original doesn't. Neither has a commit message body.
I do not see how Rene's patch could _not_ have fixed that problem.
As it is, I cannot even reproduce without that patch. This is what I was
trying:
-- snip --
diff --git a/t/t4025-pretty-format.sh b/t/t4025-pretty-format.sh
new file mode 100644
index 0000000..2826bcb
--- /dev/null
+++ b/t/t4025-pretty-format.sh
@@ -0,0 +1,23 @@
+#!/bin/sh
+
+test_description='git pretty formats'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+
+ : > file &&
+ git add file &&
+ tree=$(git write-tree) &&
+ commit=$(echo No newlin | tr "\\012" e | git commit-tree $tree) &&
+ git update-ref HEAD $commit
+
+'
+
+test_expect_success 'format:%b' '
+
+ test -z "$(git log -1 --pretty=format:%b)"
+
+'
+
+test_done
-- snap --
Seems I cannot help any more, but at least this is a starting point to
try to reproduce.
Ciao,
Dscho
^ permalink raw reply related
* Re: gitk font configuration
From: Charles Bailey @ 2007-12-20 12:26 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712201318270.27181@ds9.cixit.se>
On Thu, Dec 20, 2007 at 01:19:54PM +0100, Peter Karlsson wrote:
> Hi!
>
> I can configure git gui's fonts through its preferences, but gitk does
> not have font settings. And I can't find any documentation on how to
> change the fonts either in the gitk or git-config manual pages. Is
> there any way to change them? I'd really love getting rid of Courier...
gitk creates a .gitk file in your home directory. If you point your
editor at that file it should be fairly obvious how to change the
fonts.
^ permalink raw reply
* Re: Serious bug with pretty format strings & empty bodies?
From: René Scharfe @ 2007-12-20 12:20 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Alex Riesen, git
In-Reply-To: <57518fd10712200244o656c7f44j426cc71c89515de3@mail.gmail.com>
Jonathan del Strother schrieb:
> On Dec 19, 2007 11:23 PM, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>> Just a shot in the dark: does this patch on top of master make a difference?
> No luck with that, I'm afraid.
And how is this one?
The first chunk is the same as in the last try -- it guards against commit
messages ending with a NUL without a prior \n _and_ being followed by a \n
(in memory which shouldn't be accessed by us at all as it doesn't belong to
the commit message). I guess that's quite rare.
The second chunk keeps the body offset from being incremented by the for
loop if we've already found a terminating NUL.
diff --git a/pretty.c b/pretty.c
index 9db75b4..5b1078b 100644
--- a/pretty.c
+++ b/pretty.c
@@ -412,7 +412,7 @@ static void parse_commit_header(struct format_commit_context *context)
if (i == eol) {
state++;
/* strip empty lines */
- while (msg[eol + 1] == '\n')
+ while (msg[eol] == '\n' && msg[eol + 1] == '\n')
eol++;
} else if (!prefixcmp(msg + i, "author ")) {
context->author.off = i + 7;
@@ -425,6 +425,8 @@ static void parse_commit_header(struct format_commit_context *context)
context->encoding.len = eol - i - 9;
}
i = eol;
+ if (!msg[i])
+ break;
}
context->body_off = i;
context->commit_header_parsed = 1;
^ permalink raw reply related
* gitk font configuration
From: Peter Karlsson @ 2007-12-20 12:19 UTC (permalink / raw)
To: git
Hi!
I can configure git gui's fonts through its preferences, but gitk does
not have font settings. And I can't find any documentation on how to
change the fonts either in the gitk or git-config manual pages. Is
there any way to change them? I'd really love getting rid of Courier...
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Draft release notes for 1.5.4 as of -rc1
From: Jeff King @ 2007-12-20 12:12 UTC (permalink / raw)
To: Georgi Chorbadzhiyski; +Cc: Junio C Hamano, git
In-Reply-To: <4769DDC9.1030108@unixsol.org>
On Thu, Dec 20, 2007 at 05:13:13AM +0200, Georgi Chorbadzhiyski wrote:
> > * "git peek-remote" is deprecated, as "git ls-remote" was written in C
> > and works for all transports, and will be removed in the future.
>
> For me it is not clear from the above which command will be removed. If
> I understand it correctly probably this should sound better:
>
> * "git peek-remote" is deprecated and will be removed in the future.
> The command was replaced by "git ls-remote" which works for all
> transports.
Agreed. A rewording is in the patch I just sent.
-Peff
^ permalink raw reply
* [PATCH] clean up 1.5.4 release notes
From: Jeff King @ 2007-12-20 12:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhciers0o.fsf@gitster.siamese.dyndns.org>
Mostly typo and small grammatical fixes with one or two rewordings for
clarity. But note the important fix for status.relativepaths.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/RelNotes-1.5.4.txt | 33 +++++++++++++++++----------------
1 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/Documentation/RelNotes-1.5.4.txt b/Documentation/RelNotes-1.5.4.txt
index cd79124..4a5d060 100644
--- a/Documentation/RelNotes-1.5.4.txt
+++ b/Documentation/RelNotes-1.5.4.txt
@@ -14,28 +14,28 @@ Removal
Deprecation notices
-------------------
- * Next feature release of git (this change is scheduled for v1.6.0)
+ * The next feature release of git (this change is scheduled for v1.6.0)
will by default install dashed form of commands (e.g. "git-commit")
outside of users' normal $PATH, and will install only selected
commands ("git" itself, and "gitk") in $PATH. This implies:
- - Using dashed form of git commands (e.g. "git-commit") from the
+ - Using dashed forms of git commands (e.g. "git-commit") from the
command line has been informally deprecated since early 2006, but
now it officially is, and will be removed in the future. Use
- dashless form (e.g. "git commit") instead.
+ dashless forms (e.g. "git commit") instead.
- - Using dashed from from your scripts, without first prepending the
+ - Using dashed forms from your scripts, without first prepending the
return value from "git --exec-path" to the scripts' PATH, has been
informally deprecated since early 2006, but now it officially is.
- - Use of dashed form with "PATH=$(git --exec-path):$PATH; export
+ - Use of dashed forms with "PATH=$(git --exec-path):$PATH; export
PATH" early in your script is not deprecated with this change.
Users are strongly encouraged to adjust their habits and scripts now
to prepare for this.
* The post-receive hook was introduced in March 2007 to supersede
- post-update hook, primarily to overcome the command line length
+ the post-update hook, primarily to overcome the command line length
limitation of the latter. Use of post-update hook will be deprecated
in future versions of git, starting from v1.6.0.
@@ -43,10 +43,11 @@ Deprecation notices
option, and will be removed in the future.
* "git peek-remote" is deprecated, as "git ls-remote" was written in C
- and works for all transports, and will be removed in the future.
+ and works for all transports; "git peek-remote" will be removed in
+ the future.
* From v1.6.0, the repack.usedeltabaseoffset config option will default
- to true, which will give denser packfile (i.e. more efficient storage).
+ to true, which will give denser packfiles (i.e. more efficient storage).
The downside is that git older than version 1.4.4 will not be able
to directly use a repository packed using this setting.
@@ -67,7 +68,7 @@ Updates since v1.5.3
* gitk is now merged as a subdirectory of git.git project, in
preparation for its i18n.
- * progress display from many commands are a lot nicer to the eye.
+ * progress displays from many commands are a lot nicer to the eye.
Transfer commands show throughput data.
* many commands that pay attention to per-directory .gitignore now do
@@ -76,12 +77,12 @@ Updates since v1.5.3
* Output processing for '--pretty=format:<user format>' has been
optimized.
- * Rename detection of diff family, while detecting exact matches, has
+ * Rename detection of diff family while detecting exact matches has
been greatly optimized.
- * Rename detection of diff family tries to make more naturally looking
- pairing. Earlier if more than one identical rename sources were
- found in the preimage, they were picked pretty much at random.
+ * Rename detection of diff family tries to make more natural looking
+ pairing. Earlier, if multiple identical rename sources were
+ found in the preimage, the source used was picked pretty much at random.
* Value "true" for color.diff and color.status configuration used to
mean "always" (even when the output is not going to a terminal).
@@ -114,7 +115,7 @@ Updates since v1.5.3
* "git rebase --interactive" mode can now work on detached HEAD.
- * Other minor to serious bugs in "git rebase -i" has been fixed.
+ * Other minor to serious bugs in "git rebase -i" have been fixed.
* "git rebase" now detaches head during its operation, so after a
successful "git rebase" operation, the reflog entry branch@{1} for
@@ -245,7 +246,7 @@ Updates since v1.5.3
* The format "git show" outputs an annotated tag has been updated to
include "Tagger: " and "Date: " lines from the tag itself. Strictly
speaking this is a backward incompatible change, but this is a
- reasonable usability fix and people's script shouldn't have been
+ reasonable usability fix and people's scripts shouldn't have been
relying on the exact output from "git show" Porcelain anyway.
* "git cvsexportcommit" learned -w option to specify and switch to the
@@ -281,7 +282,7 @@ Updates since v1.5.3
makes copy-and-pasting for git-checkout/git-add/git-rm easier. The
traditional behaviour to show the full path relative to the top of
the work tree can be had by setting status.relativepaths
- configuration variable to true.
+ configuration variable to false.
* "git blame" kept text for each annotated revision in core needlessly;
this has been corrected.
--
1.5.4.rc1.1095.g7251f
^ permalink raw reply related
* Re: [PATCH v2] builtin-tag.c: allow arguments in $EDITOR
From: Luciano Rocha @ 2007-12-20 12:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712201255510.14355@wbgn129.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 731 bytes --]
On Thu, Dec 20, 2007 at 12:58:59PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 20 Dec 2007, Luciano Rocha wrote:
>
> > The previous sh version of git-commit evaluated the value of the defined
> > editor, thus allowing arguments.
> >
> > Make the builtin version work the same, by adding an explicit check for
> > arguments in the editor command, and extract them to an additional
> > argument.
>
> Anything wrong with that patch?
>
> http://article.gmane.org/gmane.comp.version-control.git/68444
No, I just missed it in the mailing list. That patch also supports any
number of whitespace/arguments.
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v2] builtin-tag.c: allow arguments in $EDITOR
From: Johannes Schindelin @ 2007-12-20 11:58 UTC (permalink / raw)
To: Luciano Rocha; +Cc: git
In-Reply-To: <20071220095706.GA9685@bit.office.eurotux.com>
Hi,
On Thu, 20 Dec 2007, Luciano Rocha wrote:
> The previous sh version of git-commit evaluated the value of the defined
> editor, thus allowing arguments.
>
> Make the builtin version work the same, by adding an explicit check for
> arguments in the editor command, and extract them to an additional
> argument.
Anything wrong with that patch?
http://article.gmane.org/gmane.comp.version-control.git/68444
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Mention git-shell's "cvs" substitution in the RelNotes
From: Johannes Schindelin @ 2007-12-20 11:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhciers0o.fsf@gitster.siamese.dyndns.org>
git shell became much more powerful for existing CVS setups. Tis is a
benefit that we should not hide from those people who only read release
notes.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
diff --git a/Documentation/RelNotes-1.5.4.txt b/Documentation/RelNotes-1.5.4.txt
index cd79124..fb521c3 100644
--- a/Documentation/RelNotes-1.5.4.txt
+++ b/Documentation/RelNotes-1.5.4.txt
@@ -175,7 +175,9 @@ Updates since v1.5.3
* "git remote" learned "rm" subcommand.
- * "git cvsserver" can be run via "git shell".
+ * "git cvsserver" can be run via "git shell". Also, "cvs" is
+ recognized as a synonym for "git cvsserver", so that CVS users
+ can be switched to git just by changing their login shell.
* "git cvsserver" acts more like receive-pack by running post-receive
and post-update hooks.
^ permalink raw reply related
* Re: Serious bug with pretty format strings & empty bodies?
From: Jonathan del Strother @ 2007-12-20 11:38 UTC (permalink / raw)
To: René Scharfe; +Cc: Alex Riesen, git
In-Reply-To: <4769A7FB.1070904@lsrfire.ath.cx>
I ended up trying to filter-branch my repository, see if I could come
up with a version stripped of all our private code, suitable for
making public. Disappointingly, filter-branch magically fixes all the
commits, even when simply run as "git filter-branch HEAD".
However, looking at the rewritten repository vs the original, they
share a lot of commits, then diverge halfway through their history. I
can't see anything notable about the commit where they diverge, with
the exception that the rewritten commit has a newline after the
subject and the original doesn't. Neither has a commit message body.
^ permalink raw reply
* Re: [PATCH v0] sha1_name: grok <revision>:./<relative-path>
From: Johannes Schindelin @ 2007-12-20 10:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dana How, Linus Torvalds, Alex Riesen, Jakub Narebski, git
In-Reply-To: <7vr6hirx5l.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 19 Dec 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > diff --git a/cache.h b/cache.h
> > index 39331c2..83a2c31 100644
> > --- a/cache.h
> > +++ b/cache.h
> > @@ -225,6 +225,7 @@ extern char *get_index_file(void);
> > extern char *get_graft_file(void);
> > extern int set_git_dir(const char *path);
> > extern const char *get_git_work_tree(void);
> > +extern const char *get_current_prefix(void);
> >
> > #define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
> >
> > diff --git a/setup.c b/setup.c
> > index b59dbe7..fb9b680 100644
> > --- a/setup.c
> > +++ b/setup.c
> > @@ -3,6 +3,12 @@
> >
> > static int inside_git_dir = -1;
> > static int inside_work_tree = -1;
> > +static const char *current_prefix;
> > +
> > +const char *get_current_prefix()
> > +{
> > + return current_prefix;
> > +}
>
> Didn't you just make libification harder?
Well, yes.
Actually, no:
- I marked this explicitely not ready for application,
- it is not entirely clear if a libgit.a user would not want to
set a default prefix, and
- I decided that I will not be the only one who tries to make
libification easy. ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: Serious bug with pretty format strings & empty bodies?
From: Jonathan del Strother @ 2007-12-20 10:46 UTC (permalink / raw)
To: René Scharfe; +Cc: git
In-Reply-To: <57518fd10712200243o26641b3bjf9be3898a2f0c7e1@mail.gmail.com>
> Hmmm. I wonder if it's coincidence that I can only seem to spot this
> problem in my repos that have been set up via submodule init...
Ignore that last bit, red herring.
^ permalink raw reply
* Re: Serious bug with pretty format strings & empty bodies?
From: Jonathan del Strother @ 2007-12-20 10:44 UTC (permalink / raw)
To: René Scharfe; +Cc: Alex Riesen, git
In-Reply-To: <4769A7FB.1070904@lsrfire.ath.cx>
On Dec 19, 2007 11:23 PM, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> Jonathan del Strother schrieb:
> > On Dec 19, 2007 6:44 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
> >> Could you try
> >>
> >> git cat-file 18d2480ab689b483ef1ebbdb3f7420904049ba0b
> >>
> >> (or any other problematic commit) and post its output here?
> >
> > You mean git cat-file commit ... ?
> > I get the normal output, but the problematic commits don't show a
> > newline character at the end of the cat-file output.
>
> Just a shot in the dark: does this patch on top of master make a difference?
>
> diff --git a/pretty.c b/pretty.c
> index 9db75b4..5f95a59 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -412,7 +412,7 @@ static void parse_commit_header(struct format_commit_context *context)
> if (i == eol) {
> state++;
> /* strip empty lines */
> - while (msg[eol + 1] == '\n')
> + while (msg[eol] == '\n' && msg[eol + 1] == '\n')
> eol++;
> } else if (!prefixcmp(msg + i, "author ")) {
> context->author.off = i + 7;
>
No luck with that, I'm afraid.
^ permalink raw reply
* Re: Serious bug with pretty format strings & empty bodies?
From: Jonathan del Strother @ 2007-12-20 10:43 UTC (permalink / raw)
To: René Scharfe; +Cc: git
In-Reply-To: <476962D5.3050409@lsrfire.ath.cx>
On Dec 19, 2007 6:28 PM, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> That's strange. Could you check if this happens with e52a5de, too?
> That's the commit that introduced --pretty=format. If it doesn't, could
> you then please try to bisect the bug?
As far as I can tell, e52a... never compiled - it's missing prefixcmp
from git-compat-util.h, which doesn't get merged in till 8ab3e18.
And yes, I still get junk output from that build. (Shame, I was
looking forward to trying out the bisect tool...)
> How many '<unknown>' markers are there in the output of version 1.5.3.7
> (and e52a5de)? One per %b? Are they the only output or are they
> combined with parts of unrelated commits, too?
Only one per %b, and where they appear, they're the only output.
However, even with those builds, I get junk output in addition to the
<unknown> markers.
That is, with a format string of "**%b**", there are three possible outputs :
The correct one - eg **Added test for NSDictionary generator**
The unknown one - eg **<unknown>**
The complete junk one - eg **n del
Strothereb0d794bacc1761e8a0681e9b144c514702d9b7a**
The latter's 'body' is almost always terminated by an unprintable
character, which always seems to be 03.
Hmmm. I wonder if it's coincidence that I can only seem to spot this
problem in my repos that have been set up via submodule init...
^ permalink raw reply
* [PATCH v2] builtin-tag.c: allow arguments in $EDITOR
From: Luciano Rocha @ 2007-12-20 9:57 UTC (permalink / raw)
To: git
In-Reply-To: <20071219232326.GA4135@bit.office.eurotux.com>
The previous sh version of git-commit evaluated the value of the defined
editor, thus allowing arguments.
Make the builtin version work the same, by adding an explicit check for
arguments in the editor command, and extract them to an additional argument.
Signed-off-by: Luciano Rocha <luciano@eurotux.com>
---
builtin-tag.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
I personally use EDITOR="gvim -f", thus this patch.
Now with free() of temporary buffer.
diff --git a/builtin-tag.c b/builtin-tag.c
index 274901a..0e8575e 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -46,7 +46,19 @@ void launch_editor(const char *path, struct strbuf *buffer, const char *const *e
if (!editor)
editor = "vi";
- if (strcmp(editor, ":")) {
+ if (strstr(editor, " -")) {
+ char *editor_cmd = xstrdup(editor);
+ char *editor_sep = strstr(editor_cmd, " -");
+ const char *args[] = { editor_cmd, editor_sep + 1,
+ path, NULL };
+
+ *editor_sep = '\0';
+
+ if (run_command_v_opt_cd_env(args, 0, NULL, env))
+ die("There was a problem with the editor %s.",
+ editor_cmd);
+ free(editor_cmd);
+ } else if (strcmp(editor, ":")) {
const char *args[] = { editor, path, NULL };
if (run_command_v_opt_cd_env(args, 0, NULL, env))
--
Luciano Rocha <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>
^ permalink raw reply related
* [PATCH] gitweb: fix whitespace in config_to_multi (indent with tab)
From: Jakub Narebski @ 2007-12-20 9:48 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
I'm very sorry for sending whitespace-mangled patch in first place.
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 28bb8c3..6256641 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1511,7 +1511,7 @@ sub config_to_int {
sub config_to_multi {
my $val = shift;
- return ref($val) ? $val : (defined($val) ? [ $val ] : []);
+ return ref($val) ? $val : (defined($val) ? [ $val ] : []);
}
sub git_get_project_config {
--
1.5.3.7
^ permalink raw reply related
* Re: [PATCH] Re-re-re-fix common tail optimization
From: Junio C Hamano @ 2007-12-20 9:40 UTC (permalink / raw)
To: Charles Bailey; +Cc: Wincent Colaiuta, Jeff King, Linus Torvalds, git
In-Reply-To: <20071220092315.GA31337@hashpling.org>
Charles Bailey <charles@hashpling.org> writes:
> Perhaps a comment saying tha zc is designed for <= 9999 z's? Given
> this, a lot of the /g are redundant.
Yeah, /g redundancy is a leftover from the time when it did not have
these sawtooth patterns.
^ permalink raw reply
* Re: [PATCH] Reallow git-rebase --interactive --continue if commit is unnecessary
From: Junio C Hamano @ 2007-12-20 9:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Bernt Hansen, git
In-Reply-To: <20071220073113.GJ14735@spearce.org>
Will do, but the code looks quite bad (not entirely your fault).
Line by line comment to show my puzzlement.
# commit if necessary
Ok, the user has prepared the index for us, and we are going to do some
tests and conditionally create commit.
git rev-parse --verify HEAD > /dev/null &&
Do we have HEAD commit? Why check this --- we do not want to rebase
from the beginning of time? No, that's not it. If this fails, there is
something seriously wrong. This is not about "will we make a commit?"
check at all. This is a basic sanity check and if it fails we must
abort, not just skip.
git update-index --refresh &&
git diff-files --quiet &&
Is the work tree clean with respect to the index? Why check this --- we
want to skip the commit if work tree is dirty? Or is this trying to
enforce the invariant that during the rebase the work tree and index and
HEAD should all match? If the latter, failure from this again is a
reason to abort.
! git diff-index --cached --quiet HEAD -- &&
Do we have something to commit? This needs to be checked so that we can
skip a commit that results in emptyness, so using this as a check to see
if we should commit makes sense.
. "$DOTEST"/author-script && {
test ! -f "$DOTEST"/amend || git reset --soft HEAD^
} &&
Find GIT_AUTHOR_* variables and if we are amending rewind the HEAD. The
failure from this is a grave problem and reason to abort, isn't it?
export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
git commit --no-verify -F "$DOTEST"/message -e
Then we go on to create commit. As you said, failure from this is a
grave error.
If my commentary above is right, how many bugs did we find in these 10
lines?
Grumpy I am...
---
git-rebase--interactive.sh | 29 +++++++++++++++++++----------
1 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 090c3e5..7aa4278 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -363,17 +363,26 @@ do
test -d "$DOTEST" || die "No interactive rebase running"
- # commit if necessary
- git rev-parse --verify HEAD > /dev/null &&
- git update-index --refresh &&
- git diff-files --quiet &&
- ! git diff-index --cached --quiet HEAD -- &&
- . "$DOTEST"/author-script && {
- test ! -f "$DOTEST"/amend || git reset --soft HEAD^
- } &&
- export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
- if ! git commit --no-verify -F "$DOTEST"/message -e
+ # Sanity check
+ git rev-parse --verify HEAD >/dev/null ||
+ die "Cannot read HEAD"
+ git update-index --refresh && git diff-files --quiet ||
+ die "Working tree is dirty"
+
+ # do we have anything to commit?
+ if git diff-index --cached --quiet HEAD --
then
+ : Nothing to commit -- skip this
+ else
+ . "$DOTEST"/author-script ||
+ die "Cannot find the author identity"
+ if test -f "$DOTEST"/amend
+ then
+ git reset --soft HEAD^ ||
+ die "Cannot rewind the HEAD"
+ fi
+ export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
+ git commit --no-verify -F "$DOTEST"/message -e ||
die "Could not commit staged changes."
fi
^ permalink raw reply related
* Re: [PATCH] Re-re-re-fix common tail optimization
From: Charles Bailey @ 2007-12-20 9:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wincent Colaiuta, Jeff King, Linus Torvalds, git
In-Reply-To: <7vy7bqrzat.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 19, 2007 at 04:21:30PM -0800, Junio C Hamano wrote:
>
> By the way, how does this rewrite look?
>
It looks good and the test works on my fedora and Mac OS X boxes.
(Just for reference I'm on 10.4.3, not 'Leopard'.)
I've snipped everything except zc that I wanted to comment on.
The only two really minor nits I have is that zc does bizarre things
without warning for more than 9999 "z" ( e.g. 17000 = 9000 + 8000 =
98000 (!) ) and that, from a function responsibility point of view,
the /^index/d looks rather out of place.
Perhaps a comment saying tha zc is designed for <= 9999 z's? Given
this, a lot of the /g are redundant.
But hey, it's a test script and it works and I don't have any better
suggestions. :)
Charles.
> +zc () {
> + sed -e "/^index/d" \
> + -e "s/$z1000/Q/g" \
> + -e "s/QQQQQQQQQ/Z9000/g" \
> + -e "s/QQQQQQQQ/Z8000/g" \
> + -e "s/QQQQQQQ/Z7000/g" \
> + -e "s/QQQQQQ/Z6000/g" \
> + -e "s/QQQQQ/Z5000/g" \
> + -e "s/QQQQ/Z4000/g" \
> + -e "s/QQQ/Z3000/g" \
> + -e "s/QQ/Z2000/g" \
> + -e "s/Q/Z1000/g" \
> + -e "s/$z100/Q/g" \
> + -e "s/QQQQQQQQQ/Z900/g" \
> + -e "s/QQQQQQQQ/Z800/g" \
> + -e "s/QQQQQQQ/Z700/g" \
> + -e "s/QQQQQQ/Z600/g" \
> + -e "s/QQQQQ/Z500/g" \
> + -e "s/QQQQ/Z400/g" \
> + -e "s/QQQ/Z300/g" \
> + -e "s/QQ/Z200/g" \
> + -e "s/Q/Z100/g" \
> + -e "s/000Z//g" \
> + -e "s/$z10/Q/g" \
> + -e "s/QQQQQQQQQ/Z90/g" \
> + -e "s/QQQQQQQQ/Z80/g" \
> + -e "s/QQQQQQQ/Z70/g" \
> + -e "s/QQQQQQ/Z60/g" \
> + -e "s/QQQQQ/Z50/g" \
> + -e "s/QQQQ/Z40/g" \
> + -e "s/QQQ/Z30/g" \
> + -e "s/QQ/Z20/g" \
> + -e "s/Q/Z10/g" \
> + -e "s/00Z//g" \
> + -e "s/z/Q/g" \
> + -e "s/QQQQQQQQQ/Z9/g" \
> + -e "s/QQQQQQQQ/Z8/g" \
> + -e "s/QQQQQQQ/Z7/g" \
> + -e "s/QQQQQQ/Z6/g" \
> + -e "s/QQQQQ/Z5/g" \
> + -e "s/QQQQ/Z4/g" \
> + -e "s/QQQ/Z3/g" \
> + -e "s/QQ/Z2/g" \
> + -e "s/Q/Z1/g" \
> + -e "s/0Z//g" \
> + ;
> +}
^ permalink raw reply
* Re: [PATCH] Reallow git-rebase --interactive --continue if commit is unnecessary
From: Matthieu Moy @ 2007-12-20 7:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Johannes Schindelin, Bernt Hansen, git
In-Reply-To: <20071220071212.GA20534@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> - git commit --no-verify -F "$DOTEST"/message -e ||
^
Wouldn't it be sufficient to add a backslash here ----------------' ?
> + if ! git commit --no-verify -F "$DOTEST"/message -e
> die "Could not commit staged changes."
> + fi
>
> require_clean_work_tree
> do_rest
--
Matthieu
^ permalink raw reply
* Re: [PATCH] HP-UX does not have select.h
From: Junio C Hamano @ 2007-12-20 7:52 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Andreas Ericsson, git
In-Reply-To: <20071220081806.0ccdf636@pc09.procura.nl>
"H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
>> > Also because these are the *only* _POSIX_VERSION defines in the entire
>> > include tree, and 11.23 does have a select.h, which makes the patch below
>> > to be not OK on 11.23. I'm not stating that HP follows the rules in any
>> > correct way, but if this is to be sure that select.h gets included if the
>> > OS supports it, it will fail.
>> ...
>> But your grep did not catch their definition of _POSIX1_VERSION_$YEAR
>> which are used to define the actual value of _POSIX_VERSION.
>
> If it is used to *define* _POSIX_VERSION, it should have come up too,
> wouldn't it?
Sorry, I should re-read your grep output. It is possible that I am
quite confused.
Your grep session begins like this:
>> >> > /usr/include 103 > grep -r POSIX_VERSION *
>> >> > sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_88
>> >> > sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_90
>> >> > sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_93
Now, if they had
#define _POSIX1_VERSION_88 198808L
#define _POSIX1_VERSION_90 199009L
#define _POSIX1_VERSION_93 199309L
#define _POSIX1_VERSION_95 199506L
#define _POSIX1_VERSION_01 200112L
elsewhere in their include files, then
(1) "grep -r POSIX_VERSION *" wouldn't have matched them;
(2) not all of the three output form sys/unistd.h could be in effect at
the same time. There may be #ifdef around it to control which
definition is used, but your "grep" wouldn't have shown them
either.
Maybe HP-UX include files #ifdef the definition of _POSIX_VERSION
depending on what is asked for with feature test macros? We do not
define _POSIX_C_SOURCE to 200112L but we do define _XOPEN_SOURCE to 600.
According to:
http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_02.html
this should be sufficient to ask for POSIX.1-2001 features.
But in any case, 88/90/93 are all too old (predates 2001-12) so if these
three definitions are only possible values in their include files, then
we wouldn't see _POSIX_VERSION set to 200112L. That is unfortunate.
It seems we need to go back to that "NO_SYS_SELECT_H=YesPlease" thing.
^ permalink raw reply
* Re: [PATCH] Reallow git-rebase --interactive --continue if commit is unnecessary
From: Shawn O. Pearce @ 2007-12-20 7:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Bernt Hansen, git
In-Reply-To: <7vzlw5rg53.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> > index 47581ce..39f32b1 100755
> > --- a/git-rebase--interactive.sh
> > +++ b/git-rebase--interactive.sh
> > @@ -372,8 +372,9 @@ do
> > test ! -f "$DOTEST"/amend || git reset --soft HEAD^
> > } &&
> > export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
> > - git commit --no-verify -F "$DOTEST"/message -e ||
> > + if ! git commit --no-verify -F "$DOTEST"/message -e
> > die "Could not commit staged changes."
> > + fi
>
> This looks like a syntax error to me.
Whoops. This looks like a syntax error to me too.
Its late. I totally missed a "then". Would you mind doing an amend?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] HP-UX does not have select.h
From: H.Merijn Brand @ 2007-12-20 7:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vzlw6tlpt.fsf@gitster.siamese.dyndns.org>
On Wed, 19 Dec 2007 13:31:58 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
>
> > On Wed, 19 Dec 2007 11:57:21 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> >
> >> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
> >>
> >> > On Tue, 18 Dec 2007 01:47:53 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> >> > ...
> >> >> Merijn, discarding the earlier patch I did to configure it out for
> >> >> HP-UX, does the following patch based on Andreas's idea work for you?
> >> >
> >> > Probably not:
> >> >
> >> > HP-UX 10.20, 11.00, 11.11, 11.23/PA, and 11.23/IPF all have:
> >> >
> >> > /usr/include 103 > grep -r POSIX_VERSION *
> >> > sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_88
> >> > sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_90
> >> > sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_93
> >> > sys/unistd.h:# define _SC_1_VERSION_88 7 /* _POSIX_VERSION: Date of POSIX.1-1988 */
> >> > sys/unistd.h:# define _SC_1_VERSION_90 102 /* _POSIX_VERSION: Date of POSIX.1-1990 */
> >> > sys/unistd.h:# define _SC_1_VERSION_93 103 /* _POSIX_VERSION: Date of POSIX.1b-1993 */
> >> > sys/unistd.h:# if (_POSIX_VERSION == _POSIX1_VERSION_88)
> >> > sys/unistd.h:# if (_POSIX_VERSION == _POSIX1_VERSION_90)
> >> >
> >> > and the two 11.23 do have select.h
> >>
> >> Does that prove anything? unistd.h seem to define _POSIX_VERSION to
> >> various values but we do not see surrounding "#ifdef WE_DO_NOT_KNOW"
> >> from the grep output above unfortunately.
> >
> > What I tried to demonstrate is that I have no clue about the actual value
> > of this define, and if values like 88, 90, and 93 (7, 102, and 103) do
> > have any relation with the higher value of 200112L that you use.
> >
> > Also because these are the *only* _POSIX_VERSION defines in the entire
> > include tree, and 11.23 does have a select.h, which makes the patch below
> > to be not OK on 11.23. I'm not stating that HP follows the rules in any
> > correct way, but if this is to be sure that select.h gets included if the
> > OS supports it, it will fail.
> >
> >> If the folllowing actually works I think that is the cleanest fix for
> >> this issue (note that I added defined(_POSIX_VERSION) there just to be
> >> safe if it is not defined at all).
>
> But your grep did not catch their definition of _POSIX1_VERSION_$YEAR
> which are used to define the actual value of _POSIX_VERSION.
If it is used to *define* _POSIX_VERSION, it should have come up too,
wouldn't it?
The only define that comes close to something like YYYYMM is:
X11/Xosdefs.h:#define X_POSIX_C_SOURCE 199300L
usr/include 111 > grep -r POSIX.*YEAR .
Exit 1
/usr/include 112 > grep -P -r 'POSIX.*\b(19\d\d|200\d)' .
./sys/buf.h:#if (_POSIX_C_SOURCE >= 199309)
./sys/buf.h:#endif /* (_POSIX_C_SOURCE >= 199309) */
./sys/stdsyms.h:/* XPG3 semantics gets POSIX.1-1988 semantics by default */
./sys/stdsyms.h: * This usage is obsolescent, "-D_POSIX_C_SOURCE=199506" is preferred */
./sys/stdsyms.h:# if (_POSIX_C_SOURCE >= 199506) && !defined(_INCLUDE_POSIX1C_SOURCE)
./sys/stdsyms.h:# endif /* _POSIX_C_SOURCE >= 199506 && !_INCLUDE_POSIX1C_SOURCE */
./sys/stdsyms.h:# if (_POSIX_C_SOURCE >= 199506) && !defined(_REENTRANT)
./sys/stdsyms.h:# endif /* _POSIX_C_SOURCE >= 199506 && !_REENTRANT */
./sys/stdsyms.h:# if (_POSIX_C_SOURCE >= 199309) && !defined(_INCLUDE_POSIX4_SOURCE)
./sys/stdsyms.h:# endif /* _POSIX_C_SOURCE >= 199309 && !_INCLUDE_POSIX4_SOURCE */
./sys/unistd.h:# define _POSIX1_VERSION_88 198808L /* We support POSIX.1-1988 */
./sys/unistd.h:# define _POSIX1_VERSION_90 199009L /* We support POSIX.1-1990 */
./sys/unistd.h:# define _POSIX1_VERSION_93 199309L /* We support POSIX.1b-1993 */
./sys/unistd.h:# if !defined(_POSIX_C_SOURCE) || (_POSIX_C_SOURCE < 199309L)
./sys/unistd.h:# else /* _POSIX_C_SOURCE && _POSIX_C_SOURCE >= 199309L */
./sys/unistd.h:# endif /* _POSIX_C_SOURCE && _POSIX_C_SOURCE >= 199309L */
./sys/unistd.h:/* Symbolic constants for sysconf() variables defined by POSIX.1-1988: 0-7 */
./sys/unistd.h:# define _SC_1_VERSION_88 7 /* _POSIX_VERSION: Date of POSIX.1-1988 */
./sys/unistd.h:/* Symbolic constants for sysconf() variables added by POSIX.1-1990: 100-199 */
./sys/unistd.h:# define _SC_1_VERSION_90 102 /* _POSIX_VERSION: Date of POSIX.1-1990 */
./sys/unistd.h:# define _SC_1_VERSION_93 103 /* _POSIX_VERSION: Date of POSIX.1b-1993 */
./sys/unistd.h:# define _POSIX2_VERSION 199209L /* IEEE POSIX.2-1992 base standard */
./sys/unistd.h:# define _POSIX2_C_VERSION 199209L /* IEEE POSIX.2-1992 C language binding */
./limits.h:# define _POSIX_CLOCKRES_MIN 20000000 /* The CLOCK_REALTIME clock
./X11/Xosdefs.h:#define X_POSIX_C_SOURCE 199300L
./dce/cdsclerk.h:#if _POSIX_C_SOURCE >= 199506L
./dce/rpcexc.h:#if _POSIX_C_SOURCE >= 199506L
./dce/stubbase.h:#if _POSIX_C_SOURCE >= 199506L
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: [PATCH] Reallow git-rebase --interactive --continue if commit is unnecessary
From: Junio C Hamano @ 2007-12-20 7:15 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Bernt Hansen, git
In-Reply-To: <20071220071212.GA20534@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> During git-rebase --interactive's --continue implementation we used
> to silently restart the rebase if the user had made the commit
> for us. This is common if the user stops to edit a commit and
> does so by amending it. My recent change to watch git-commit's
> exit status broke this behavior.
>
> Thanks to Bernt Hansen for catching it in 1.5.4-rc1.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> git-rebase--interactive.sh | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 47581ce..39f32b1 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -372,8 +372,9 @@ do
> test ! -f "$DOTEST"/amend || git reset --soft HEAD^
> } &&
> export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
> - git commit --no-verify -F "$DOTEST"/message -e ||
> + if ! git commit --no-verify -F "$DOTEST"/message -e
> die "Could not commit staged changes."
> + fi
This looks like a syntax error to me.
^ permalink raw reply
* [PATCH] Reallow git-rebase --interactive --continue if commit is unnecessary
From: Shawn O. Pearce @ 2007-12-20 7:12 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin, Bernt Hansen; +Cc: git
In-Reply-To: <87r6hias5s.fsf@gollum.intra.norang.ca>
During git-rebase --interactive's --continue implementation we used
to silently restart the rebase if the user had made the commit
for us. This is common if the user stops to edit a commit and
does so by amending it. My recent change to watch git-commit's
exit status broke this behavior.
Thanks to Bernt Hansen for catching it in 1.5.4-rc1.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-rebase--interactive.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 47581ce..39f32b1 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -372,8 +372,9 @@ do
test ! -f "$DOTEST"/amend || git reset --soft HEAD^
} &&
export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
- git commit --no-verify -F "$DOTEST"/message -e ||
+ if ! git commit --no-verify -F "$DOTEST"/message -e
die "Could not commit staged changes."
+ fi
require_clean_work_tree
do_rest
--
1.5.4.rc1.1090.gab2276
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox