* 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
* Re: git svn dcommit -n rebuilds revmap w/ 1.5.4.rc0.1187.gc1e8d
From: Eric Wong @ 2007-12-20 6:55 UTC (permalink / raw)
To: Bill Priest; +Cc: git
In-Reply-To: <784879.48443.qm@web55007.mail.re4.yahoo.com>
Bill Priest <priestwilliaml@yahoo.com> wrote:
> All,
> I had been experiencing commit slow downs (> 15
> seconds) so I decided to test it out on 1.5.4.rc0. I
> use committed a file and it too ~5 seconds which is
> slower than it used to be but much better (I'll need
> to do an apples to apples test to quantify it better;
> e.g. check in the same file w/ a repository in the
> same state). In the course of using 1.5.4.rc0 I did a
> git svn dcommit -n and observed the following:
Are these slowdowns for commits using git-commit? or for using git-svn
dcommit?
The new rev_map format is very space-efficient, but I haven't optimized
for performance, yet. It seems to do well enough on Linux that I
don't notice any performance penalty/improvement. I'm also network
I/O bound for real-world SVN usage, too.
I haven't benchmarked .rev_map much, but the binary search could
certainly be optimized to avoid extra seeks if needed.
> > git svn dcommit -n
> Rebuilding
> .git/svn/mss_release_2.1B3/.rev_map.59aec714-b326-0410-a24e-830352df6fdd
> ...
> r2918 = 992aa04a75fffdbdb65bae815905f96d5e3ef6bd
> r2920 = e68e7f5aead05fc9e7a151e95f43b8283b0ed670
> Done rebuilding
> .git/svn/mss_release_2.1B3/.rev_map.59aec714-b326-0410-a24e-830352df6fdd
> Committing to
> svn://lucille/var/lib/svnrepos/svnMSS/branches/mss_release_2.1B3
> ...
> diff-tree b7cc4c3d32478277c1cdf13e3abdc9dd4a225826~1
> b7cc4c3d32478277c1cdf13e3abdc9dd4a225826
> diff-tree 0bbb656391f5a888d07c98ccce01a4c753ef4997~1
> 0bbb656391f5a888d07c98ccce01a4c753ef4997
> > git svn dcommit -n
> Committing to
> svn://lucille/var/lib/svnrepos/svnMSS/branches/mss_release_2.1B3
> ...
> diff-tree b7cc4c3d32478277c1cdf13e3abdc9dd4a225826~1
> b7cc4c3d32478277c1cdf13e3abdc9dd4a225826
> diff-tree 0bbb656391f5a888d07c98ccce01a4c753ef4997~1
> 0bbb656391f5a888d07c98ccce01a4c753ef4997
> > git --version
> git version 1.5.4.rc0.1187.gc1e8d
>
> Notice the Rebuilding doesn't seem to be honoring the
> -n "dry run" switch.
>
> I'm not sure of the implications. Is this something
> that I should worry about the .revmap being out of
> sync w/ what has actually been dcommit'ed?
--dry-run only means that it won't write to the SVN repository.
There's no need to worry about stuff that's out of sync, .rev_map only
stores information about commits already made to SVN, and is more of an
internal cache for most repositories.
All .rev_map and .rev_db files it replaces are safely deletable
unless you're using noMetadata or useSvmProps with git-svn.
--
Eric Wong
^ permalink raw reply
* Re: kha/safe updated
From: Karl Hasselström @ 2007-12-20 6:39 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <b0943d9e0712191529u5e54eca4rd0ab4ecd73217a7e@mail.gmail.com>
On 2007-12-19 23:29:13 +0000, Catalin Marinas wrote:
> On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:
>
> > You hadn't pushed any of it out when I last checked about two
> > hours ago ...
>
> I just pushed the changes a few minutes ago.
So I guessed. :-)
> > Will do, but not tonight. In fact, it may be a few days, I'm
> > afraid.
>
> No problem. Anyway, if I don't here from you in the meantime, have a
> good Christmas :-).
You too! (Or anything else you may prefer to celebrate this time of
year.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: kha/safe updated
From: Karl Hasselström @ 2007-12-20 6:38 UTC (permalink / raw)
To: David Kågedal; +Cc: Catalin Marinas, git
In-Reply-To: <87r6hijmjo.fsf@lysator.liu.se>
On 2007-12-20 00:24:11 +0100, David Kågedal wrote:
> Karl Hasselström <kha@treskal.com> writes:
>
> > And with that, I don't see any reason to not recommend that you
> > pull every patch I have. Which is:
>
> The conflict series of patches from me works for me, but I know that
> I don't use all the merging features that other users use, so I
> can't guarantee that everything works. But it seems that Catalin has
> been looking over it, so I guess it's ok.
I've been running it for quite some time too. And the criteria for
getting into kha/stable aren't _that_ onerous: I don't guarantee that
there are no bugs, just that the patches seem to be ready for
widespread testing.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Git-to-svn convert
From: Andrew McMillan @ 2007-12-20 5:32 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Thomas Harning, Junio C Hamano, git
In-Reply-To: <46a038f90712191554t2c1adc79s7948c7002c145143@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]
My code is an embarrasingly ugly, gruesome hack, but it (sort of)
works...
I use it to keep the SVN and CVS trees up to date on Sourceforge for
DAViCal ( http://rscds.sf.net/ ) from the Git tree.
Cheers,
Andrew.
On Thu, 2007-12-20 at 12:54 +1300, Martin Langhoff wrote:
> Hi Thomas,
>
> I think Andrew McMillan had written a few scripts to "export" a git
> repo to SVN and CVS. Not sure whether the code is public. But at least
> for a while, the Mahara project was using git with SVN and CVS
> "readonly" exported repos, a bit like the BK->CVS of yore. He may have
> been using git-svn though.
>
> cheers,
>
>
> martin
>
-------------------------------------------------------------------------
Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267
Is this really happening?
-------------------------------------------------------------------------
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git rebase -i / git-gui bug
From: Bernt Hansen @ 2007-12-20 4:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <87ve6ub3u7.fsf@gollum.intra.norang.ca>
Bernt Hansen <bernt@alumni.uwaterloo.ca> writes:
> Now cd /tmp/t1 and do the following:
>
> $ git rebase -i HEAD~9
>
> Change all lines with 'pick' to 'edit'
>
> For each of the 10 commits use git-gui to select 'Amend Last Commit' and
> just hit the [Commit] button (you can change the text if you want but
> it's not necessary to show the problem)
>
> $ git rebase --continue
> after each commit and repeat until the rebase is complete.
>
I can't do this at all with
$ git --version
git version 1.5.4.rc1
If I
$ git rebase -i HEAD~9
and use git-gui to edit the commit then git-rebase --continue fails
$ git rebase --continue
Could not commit staged changes.
-Bernt
^ permalink raw reply
* Re: git commit does not show all added files in subdirectories
From: Dan McGee @ 2007-12-20 4:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4peerpgi.fsf@gitster.siamese.dyndns.org>
On Dec 19, 2007 9:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Should be fixed already by 3eb2a15eb385749fbfe59b4e37fc754416275760
> (builtin-commit: make summary output consistent with status).
Darn, I looked through the log but must have looked right over that.
Thanks for the quick response.
-Dan
^ permalink raw reply
* Re: git commit does not show all added files in subdirectories
From: Junio C Hamano @ 2007-12-20 3:54 UTC (permalink / raw)
To: Dan McGee; +Cc: git
In-Reply-To: <449c10960712191947y3125f782t6ce7ec7b25ded30f@mail.gmail.com>
Should be fixed already by 3eb2a15eb385749fbfe59b4e37fc754416275760
(builtin-commit: make summary output consistent with status).
^ permalink raw reply
* git commit does not show all added files in subdirectories
From: Dan McGee @ 2007-12-20 3:47 UTC (permalink / raw)
To: git
The output below should help explain this bug better than words can.
This is with version 1.5.4.rc0.
Note that all files were added with git add before the below output begins.
dmcgee@dublin ~/projects/abs
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: abs
# new file: etc/abs/abs.conf
# new file: etc/abs/supfile.community
# new file: etc/abs/supfile.core
# new file: etc/abs/supfile.extra
# new file: etc/abs/supfile.testing
# new file: etc/abs/supfile.unstable
#
dmcgee@dublin ~/projects/abs
$ git commit -s
Created initial commit 5f5f8d3: Initial creation of abs git repository
1 files changed, 171 insertions(+), 0 deletions(-)
create mode 100755 abs
create mode 040000 etc
I assume that all files should be listed by git commit, but they are
not. I'm willing to look into fixing this if someone could point me in
the right direction.
-Dan
^ permalink raw reply
* [PATCH] fix git commit --amend -m "new message"
From: Junio C Hamano @ 2007-12-20 3:23 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
The prepare_log_message() function serves two purposes:
- Prepares the commit log message template, to be given to the end
user;
- Return true if there is something committable;
7168624c3530d8c7ee32f930f8fb2ba302b9801f (Do not generate full commit
log message if it is not going to be used) cheated to omit the former
when we know the log message template is not going to be used. However,
its replacement logic to see if there is something committable was
botched. When amending, it should compare the index with the parent of
the HEAD, not the current HEAD. Otherwise you cannot run --amend to
fix only the message without changing the tree.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I think the other cheat to return !!active_nr is checking if it is
the initial commit, and its test that appear in the context of this
patch should be replaced with "if (initial_commit)", but I wanted to
first fix the bug.
builtin-commit.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 0a91013..96410de 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -375,6 +375,7 @@ static int prepare_log_message(const char *index_file, const char *prefix)
if (no_edit) {
struct rev_info rev;
unsigned char sha1[40];
+ const char *parent = "HEAD";
fclose(fp);
@@ -384,9 +385,12 @@ static int prepare_log_message(const char *index_file, const char *prefix)
if (get_sha1("HEAD", sha1) != 0)
return !!active_nr;
+ if (amend)
+ parent = "HEAD^1";
+
init_revisions(&rev, "");
rev.abbrev = 0;
- setup_revisions(0, NULL, &rev, "HEAD");
+ setup_revisions(0, NULL, &rev, parent);
DIFF_OPT_SET(&rev.diffopt, QUIET);
DIFF_OPT_SET(&rev.diffopt, EXIT_WITH_STATUS);
run_diff_index(&rev, 1 /* cached */);
^ permalink raw reply related
* Re: Draft release notes for 1.5.4 as of -rc1
From: Georgi Chorbadzhiyski @ 2007-12-20 3:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhciers0o.fsf@gitster.siamese.dyndns.org>
On 12/20/07 04:58, Junio C Hamano 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.
--
Georgi Chorbadzhiyski
http://georgi.unixsol.org/
^ 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