* [PATCH] Don't use "<unknown>" for unknown values of placeholders and suppress printing of empty user formats.
From: Michal Vitecek @ 2007-09-25 14:38 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Junio C Hamano
---
Sending the patch again in correct form (hopefully) as instructed by
Johannes Schindelin. Sorry for the hassle.
builtin-rev-list.c | 3 ++-
commit.c | 3 ---
interpolate.c | 6 +++++-
log-tree.c | 10 ++++++----
t/t6006-rev-list-format.sh | 8 --------
t/t7500-commit.sh | 4 ++--
6 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 3894633..0b74eb3 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -85,7 +85,8 @@ static void show_commit(struct commit *commit)
pretty_print_commit(revs.commit_format, commit, ~0,
&buf, &buflen,
revs.abbrev, NULL, NULL, revs.date_mode);
- printf("%s%c", buf, hdr_termination);
+ if (*buf)
+ printf("%s%c", buf, hdr_termination);
free(buf);
}
maybe_flush_or_die(stdout, "stdout");
diff --git a/commit.c b/commit.c
index 99f65ce..c9a1818 100644
--- a/commit.c
+++ b/commit.c
@@ -917,9 +917,6 @@ long format_commit_message(const struct commit *commit, const void *format,
}
if (msg[i])
table[IBODY].value = xstrdup(msg + i);
- for (i = 0; i < ARRAY_SIZE(table); i++)
- if (!table[i].value)
- interp_set_entry(table, i, "<unknown>");
do {
char *buf = *buf_p;
diff --git a/interpolate.c b/interpolate.c
index 0082677..2f727cd 100644
--- a/interpolate.c
+++ b/interpolate.c
@@ -76,8 +76,12 @@ unsigned long interpolate(char *result, unsigned long reslen,
/* Check for valid interpolation. */
if (i < ninterps) {
value = interps[i].value;
- valuelen = strlen(value);
+ if (!value) {
+ src += namelen;
+ continue;
+ }
+ valuelen = strlen(value);
if (newlen + valuelen + 1 < reslen) {
/* Substitute. */
strncpy(dest, value, valuelen);
diff --git a/log-tree.c b/log-tree.c
index a642371..79502f4 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -175,14 +175,15 @@ void show_log(struct rev_info *opt, const char *sep)
* - The pretty-printed commit lacks a newline at the end
* of the buffer, but we do want to make sure that we
* have a newline there. If the separator isn't already
- * a newline, add an extra one.
+ * a newline, add an extra one and do the same for the
+ * user format as well.
* - unlike other log messages, the one-line format does
* not have an empty line between entries.
*/
extra = "";
- if (*sep != '\n' && opt->commit_format == CMIT_FMT_ONELINE)
+ if (*sep != '\n' && (opt->commit_format == CMIT_FMT_ONELINE || opt->commit_format == CMIT_FMT_USERFORMAT))
extra = "\n";
- if (opt->shown_one && opt->commit_format != CMIT_FMT_ONELINE)
+ if (opt->shown_one && opt->commit_format != CMIT_FMT_ONELINE && opt->commit_format != CMIT_FMT_USERFORMAT)
putchar(opt->diffopt.line_termination);
opt->shown_one = 1;
@@ -298,7 +299,8 @@ void show_log(struct rev_info *opt, const char *sep)
if (opt->show_log_size)
printf("log size %i\n", len);
- printf("%s%s%s", msgbuf, extra, sep);
+ if (*msgbuf)
+ printf("%s%s%s", msgbuf, extra, sep);
free(msgbuf);
}
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index ad6d0b8..1e4541a 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -79,9 +79,7 @@ EOF
test_format encoding %e <<'EOF'
commit 131a310eb913d107dd3c09a65d1651175898735d
-<unknown>
commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-<unknown>
EOF
test_format subject %s <<'EOF'
@@ -93,9 +91,7 @@ EOF
test_format body %b <<'EOF'
commit 131a310eb913d107dd3c09a65d1651175898735d
-<unknown>
commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-<unknown>
EOF
test_format colors %Credfoo%Cgreenbar%Cbluebaz%Cresetxyzzy <<'EOF'
@@ -121,9 +117,7 @@ test_format complex-encoding %e <<'EOF'
commit f58db70b055c5718631e5c61528b28b12090cdea
iso8859-1
commit 131a310eb913d107dd3c09a65d1651175898735d
-<unknown>
commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-<unknown>
EOF
test_format complex-subject %s <<'EOF'
@@ -142,9 +136,7 @@ and it will be encoded in iso8859-1. We should therefore
include an iso8859 character: ÂĄbueno!
commit 131a310eb913d107dd3c09a65d1651175898735d
-<unknown>
commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-<unknown>
EOF
test_done
diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
index f11ada8..abbf54b 100755
--- a/t/t7500-commit.sh
+++ b/t/t7500-commit.sh
@@ -81,7 +81,7 @@ test_expect_success 'explicit commit message should override template' '
git add foo &&
GIT_EDITOR=../t7500/add-content git commit --template "$TEMPLATE" \
-m "command line msg" &&
- commit_msg_is "command line msg<unknown>"
+ commit_msg_is "command line msg"
'
test_expect_success 'commit message from file should override template' '
@@ -90,7 +90,7 @@ test_expect_success 'commit message from file should override template' '
echo "standard input msg" |
GIT_EDITOR=../t7500/add-content git commit \
--template "$TEMPLATE" --file - &&
- commit_msg_is "standard input msg<unknown>"
+ commit_msg_is "standard input msg"
'
test_done
--
1.5.3.2
--
fuf (fuf@mageo.cz)
^ permalink raw reply related
* Re: [PATCH] rebase -i: commit when continuing after "edit"
From: Johannes Schindelin @ 2007-09-25 14:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Dmitry Potapov, git
In-Reply-To: <46F91879.6030301@viscovery.net>
Hi,
On Tue, 25 Sep 2007, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
>
> > On Tue, 25 Sep 2007, Johannes Sixt wrote:
> > > How about:
> > >
> > > eval "$author_script"
> > > GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
> > > GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
> > > GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
> > > $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
> > >
> > > and if you dislike that, put the two questionable lines in parenthesis.
> >
> > That looks ugly. I'd rather have something like
> >
> > eval "$USE_OUTPUT $author_script git commit -F \"$MSG\" $EDIT_COMMIT"
> >
> > but I'm not quite certain if that is enough, what with the funny
> > characters people put into path names these days ($MSG points to
> > "$DOTEST"/message).
>
> I, too, find it ugly, but I think it's the most readable way to do it.
> Your version is certainly underquoted.
>
> I poked around a bit, but one major obstacle is that the assignments in
> $author_script are on separate lines, which you would have to splice
> into a single line before you can insert them in the eval.
But is your version not underquoted, too? For example, if the author name
is, say 'Johannes "Dscho" Schindelin', would your version still get the \"
in the name?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] rebase -i: commit when continuing after "edit"
From: Johannes Sixt @ 2007-09-25 14:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Dmitry Potapov, git
In-Reply-To: <Pine.LNX.4.64.0709251439070.28395@racer.site>
Johannes Schindelin schrieb:
> Hi,
>
> On Tue, 25 Sep 2007, Johannes Sixt wrote:
>> How about:
>>
>> eval "$author_script"
>> GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
>> GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
>> GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
>> $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
>>
>> and if you dislike that, put the two questionable lines in parenthesis.
>
> That looks ugly. I'd rather have something like
>
> eval "$USE_OUTPUT $author_script git commit -F \"$MSG\" $EDIT_COMMIT"
>
> but I'm not quite certain if that is enough, what with the funny
> characters people put into path names these days ($MSG points to
> "$DOTEST"/message).
I, too, find it ugly, but I think it's the most readable way to do it. Your
version is certainly underquoted.
I poked around a bit, but one major obstacle is that the assignments in
$author_script are on separate lines, which you would have to splice into a
single line before you can insert them in the eval.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Move convert-objects to contrib.
From: Johannes Schindelin @ 2007-09-25 14:06 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <20070925140425.GA6061@ftbfs.org>
Hi,
On Tue, 25 Sep 2007, Matt Kraai wrote:
> On Tue, Sep 25, 2007 at 11:01:58AM +0100, Johannes Schindelin wrote:
> > the commit message looks a little bit empty to me. I'd at least
> > mention why convert-objects was needed, why it is no longer needed,
> > and that Linus, the original author, is okay with it.
> >
> > And you might want to use the "-M" flag to format-patch next time
> > (detect renames).
>
> OK, thanks. I've resubmitted the patch, (hopefully) taking both
> suggestions into account.
Yep, thanks, a pleasure to the eye.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Move convert-objects to contrib.
From: Matt Kraai @ 2007-09-25 14:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0709251100560.28395@racer.site>
On Tue, Sep 25, 2007 at 11:01:58AM +0100, Johannes Schindelin wrote:
> the commit message looks a little bit empty to me. I'd at least mention
> why convert-objects was needed, why it is no longer needed, and that
> Linus, the original author, is okay with it.
>
> And you might want to use the "-M" flag to format-patch next time (detect
> renames).
OK, thanks. I've resubmitted the patch, (hopefully) taking both
suggestions into account.
--
Matt
^ permalink raw reply
* [PATCH] Move convert-objects to contrib.
From: Matt Kraai @ 2007-09-25 14:03 UTC (permalink / raw)
To: git; +Cc: Matt Kraai
convert-objects was needed to convert from an old-style repository,
which hashed the compressed contents and used a different date format.
Such repositories are presumably no longer common and, if such
conversions are necessary, should be done by writing a frontend for
git-fast-import.
Linus, the original author, is OK with moving it to contrib.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
I've expanded the commit message and used -M to detect renamed
files, based on feedback from Johannes Schindelin.
.gitignore | 1 -
Documentation/cmd-list.perl | 1 -
Makefile | 2 +-
contrib/completion/git-completion.bash | 1 -
.../convert-objects/convert-objects.c | 0
.../convert-objects}/git-convert-objects.txt | 0
6 files changed, 1 insertions(+), 4 deletions(-)
rename convert-objects.c => contrib/convert-objects/convert-objects.c (100%)
rename {Documentation => contrib/convert-objects}/git-convert-objects.txt (100%)
diff --git a/.gitignore b/.gitignore
index 63c918c..e0b91be 100644
--- a/.gitignore
+++ b/.gitignore
@@ -25,7 +25,6 @@ git-clone
git-commit
git-commit-tree
git-config
-git-convert-objects
git-count-objects
git-cvsexportcommit
git-cvsimport
diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl
index 4ee76ea..1061fd8 100755
--- a/Documentation/cmd-list.perl
+++ b/Documentation/cmd-list.perl
@@ -94,7 +94,6 @@ git-clone mainporcelain
git-commit mainporcelain
git-commit-tree plumbingmanipulators
git-config ancillarymanipulators
-git-convert-objects ancillarymanipulators
git-count-objects ancillaryinterrogators
git-cvsexportcommit foreignscminterface
git-cvsimport foreignscminterface
diff --git a/Makefile b/Makefile
index 0055eef..94b16d0 100644
--- a/Makefile
+++ b/Makefile
@@ -233,7 +233,7 @@ SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
# ... and all the rest that could be moved out of bindir to gitexecdir
PROGRAMS = \
- git-convert-objects$X git-fetch-pack$X \
+ git-fetch-pack$X \
git-hash-object$X git-index-pack$X git-local-fetch$X \
git-fast-import$X \
git-daemon$X \
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index cad842a..e760930 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -299,7 +299,6 @@ __git_commands ()
check-attr) : plumbing;;
check-ref-format) : plumbing;;
commit-tree) : plumbing;;
- convert-objects) : plumbing;;
cvsexportcommit) : export;;
cvsimport) : import;;
cvsserver) : daemon;;
diff --git a/convert-objects.c b/contrib/convert-objects/convert-objects.c
similarity index 100%
rename from convert-objects.c
rename to contrib/convert-objects/convert-objects.c
diff --git a/Documentation/git-convert-objects.txt b/contrib/convert-objects/git-convert-objects.txt
similarity index 100%
rename from Documentation/git-convert-objects.txt
rename to contrib/convert-objects/git-convert-objects.txt
--
1.5.3.2
^ permalink raw reply related
* [PATCH 1/2] gitattributes.txt: Remove a duplicated paragraph about 'ident' and 'crlf' interaction.
From: Johannes Sixt @ 2007-09-25 13:05 UTC (permalink / raw)
To: gitster; +Cc: git, Johannes Sixt
The order in which 'ident' and 'crlf' are carried out is documented a few paragraphs
later again, after 'filter' was introduced.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
I don't have the tools to check whether the formatting is still correct.
-- Hannes
Documentation/gitattributes.txt | 11 -----------
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index d0e951e..168a598 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -145,17 +145,6 @@ sign `$` upon checkout. Any byte sequence that begins with
with `$Id$` upon check-in.
-Interaction between checkin/checkout attributes
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-In the check-in codepath, the worktree file is first converted
-with `ident` (if specified), and then with `crlf` (again, if
-specified and applicable).
-
-In the check-out codepath, the blob content is first converted
-with `crlf`, and then `ident`.
-
-
`filter`
^^^^^^^^
--
1.5.3.3.gcc9e
^ permalink raw reply related
* Re: [PATCH] rebase -i: commit when continuing after "edit"
From: Johannes Schindelin @ 2007-09-25 13:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Dmitry Potapov, git
In-Reply-To: <46F90C95.5060903@viscovery.net>
Hi,
On Tue, 25 Sep 2007, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > On Mon, 24 Sep 2007, Junio C Hamano wrote:
> > > > do_next () {
> > > > test -f "$DOTEST"/message && rm "$DOTEST"/message
> > > > test -f "$DOTEST"/author-script && rm "$DOTEST"/author-script
> > > > + test -f "$DOTEST"/amend && rm "$DOTEST"/amend
> > > As you do not check the error from "rm", how are these different from rm
> > > -f "$DOTEST/frotz"?
> >
> > The difference: the user will not see many irritating error messages.
> >
> > I changed this code to use a newly written function "remove_if_exists",
> > which die()s if the file exists and could not be removed.
>
> Why? rm -f does nothing if the file does not exist, and fails if it cannot
> remove an existing file. It all boils down to:
>
> rm -f "$DOTEST"/message "$DOTEST"/author-script \
> "$DOTEST"/amend || exit
You're completely right. I somehow assumed that it would print an
annoying message, but I was wrong.
BTW I am continually amazed at the ease of rebase -i to fix issues like
these in a patch series. Thanks Eric!
> > > > # This is like --amend, but with a different message
> > > > eval "$author_script"
> > > > export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
> > > > GIT_AUTHOR_DATE
> > > > $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
> > > > ;;
> > > The "export" here makes me somewhat nervous -- no chance these
> > > leak into the next round?
> >
> > I am somewhat wary: I get quoting wrong all the time. Would
> >
> > $USE_OUTPUT $author_script git commit -F "$MSG" $EDIT_COMMIT
> >
> > work? I have the slight suspicion that it would not, since
> >
> > eval "$author_script"
> >
> > needs extra quoting in $author_script, no?
>
> How about:
>
> eval "$author_script"
> GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
> GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
> GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
> $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
>
> and if you dislike that, put the two questionable lines in parenthesis.
That looks ugly. I'd rather have something like
eval "$USE_OUTPUT $author_script git commit -F \"$MSG\" $EDIT_COMMIT"
but I'm not quite certain if that is enough, what with the funny
characters people put into path names these days ($MSG points to
"$DOTEST"/message).
BTW I just realised that the _same_ issue should have occurred in the
"squash" case, but there I _forgot_ to export the environment variables.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 2/2] gitattributes.txt: Be more to the point in the filter driver description.
From: Johannes Sixt @ 2007-09-25 13:05 UTC (permalink / raw)
To: gitster; +Cc: git, Johannes Sixt
In-Reply-To: <11907255291239-git-send-email-johannes.sixt@telecom.at>
The description was meant to emphasizes that the project should remain
usable even if the filter driver was not used. This makes it more explicit
and removes the "here is rope to hang yourself" paraphrase.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Documentation/gitattributes.txt | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 168a598..20cf8ff 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -164,11 +164,10 @@ but makes the filter a no-op passthru.
The content filtering is done to massage the content into a
shape that is more convenient for the platform, filesystem, and
the user to use. The keyword here is "more convenient" and not
-"turning something unusable into usable". In other words, it is
-"hanging yourself because we gave you a long rope" if your
-project uses filtering mechanism in such a way that it makes
-your project unusable unless the checkout is done with a
-specific filter in effect.
+"turning something unusable into usable". In other words, the
+intent is that if someone unsets the filter driver definition,
+or does not have the appropriate filter program, the project
+should still be usable.
Interaction between checkin/checkout attributes
--
1.5.3.3.gcc9e
^ permalink raw reply related
* Re: [PATCH] rebase -i: commit when continuing after "edit"
From: Johannes Sixt @ 2007-09-25 13:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Dmitry Potapov, git
In-Reply-To: <Pine.LNX.4.64.0709251249450.28395@racer.site>
Johannes Schindelin schrieb:
> On Mon, 24 Sep 2007, Junio C Hamano wrote:
>>> do_next () {
>>> test -f "$DOTEST"/message && rm "$DOTEST"/message
>>> test -f "$DOTEST"/author-script && rm "$DOTEST"/author-script
>>> + test -f "$DOTEST"/amend && rm "$DOTEST"/amend
>> As you do not check the error from "rm", how are these different from rm
>> -f "$DOTEST/frotz"?
>
> The difference: the user will not see many irritating error messages.
>
> I changed this code to use a newly written function "remove_if_exists",
> which die()s if the file exists and could not be removed.
Why? rm -f does nothing if the file does not exist, and fails if it cannot
remove an existing file. It all boils down to:
rm -f "$DOTEST"/message "$DOTEST"/author-script \
"$DOTEST"/amend || exit
>>> # This is like --amend, but with a different message
>>> eval "$author_script"
>>> export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE
>>> $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
>>> ;;
>> The "export" here makes me somewhat nervous -- no chance these
>> leak into the next round?
>
> I am somewhat wary: I get quoting wrong all the time. Would
>
> $USE_OUTPUT $author_script git commit -F "$MSG" $EDIT_COMMIT
>
> work? I have the slight suspicion that it would not, since
>
> eval "$author_script"
>
> needs extra quoting in $author_script, no?
How about:
eval "$author_script"
GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
$USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
and if you dislike that, put the two questionable lines in parenthesis.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Use "" instead of "<unknown>" for placeholders
From: Johannes Schindelin @ 2007-09-25 12:46 UTC (permalink / raw)
To: Michal Vitecek; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0709251120120.28395@racer.site>
Hi,
On Tue, 25 Sep 2007, Johannes Schindelin wrote:
> On Tue, 25 Sep 2007, Michal Vitecek wrote:
>
> > [lots of quoted mails]
> >
> > Here comes the patch. I hope it will be ok this time :) Thanks.
> >
> > Don't use "<unknown>" for unknown values of placeholders and suppress
> > printing of empty user formats.
> >
> > ---
>
> Please move the discussion which should not be in the commit message
> _after_ the "---".
What about this comment?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] user-manual: Explain what submodules are good for.
From: Michael Smith @ 2007-09-25 12:44 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Miklos Vajna, git, Michael Smith
In-Reply-To: <Pine.LNX.4.64.0709250841410.6203@juice.ott.cti.com>
Rework the introduction to the Submodules section to explain why
someone would use them, and fix up submodule references from the
tree-object and todo sections.
Signed-off-by: Michael Smith <msmith@cbnco.com>
---
Documentation/user-manual.txt | 54 +++++++++++++++++++++++++++++++---------
1 files changed, 42 insertions(+), 12 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index a085ca1..c7fdf25 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2856,8 +2856,7 @@ between two related tree objects, since it can ignore any entries with
identical object names.
(Note: in the presence of submodules, trees may also have commits as
-entries. See gitlink:git-submodule[1] and gitlink:gitmodules.txt[1]
-for partial documentation.)
+entries. See <<submodules>> for documentation.)
Note that the files all have mode 644 or 755: git actually only pays
attention to the executable bit.
@@ -3163,12 +3162,45 @@ information as long as you have the name of the tree that it described.
Submodules
==========
-This tutorial explains how to create and publish a repository with submodules
-using the gitlink:git-submodule[1] command.
-
-Submodules maintain their own identity; the submodule support just stores the
-submodule repository location and commit ID, so other developers who clone the
-superproject can easily clone all the submodules at the same revision.
+Large projects are often composed of smaller, self-contained modules. For
+example, an embedded Linux distribution's source tree would include every
+piece of software in the distribution with some local modifications; a movie
+player might need to build against a specific, known-working version of a
+decompression library; several independent programs might all share the same
+build scripts.
+
+With centralized revision control systems this is often accomplished by
+including every module in one single repository. Developers can check out
+all modules or only the modules they need to work with. They can even modify
+files across several modules in a single commit while moving things around
+or updating APIs and translations.
+
+Git does not allow partial checkouts, so duplicating this approach in Git
+would force developers to keep a local copy of modules they are not
+interested in touching. Commits in an enormous checkout would be slower
+than you'd expect as Git would have to scan every directory for changes.
+If modules have a lot of local history, clones would take forever.
+
+On the plus side, distributed revision control systems can much better
+integrate with external sources. In a centralized model, a single arbitrary
+snapshot of the external project is exported from its own revision control
+and then imported into the local revision control on a vendor branch. All
+the history is hidden. With distributed revision control you can clone the
+entire external history and much more easily follow development and re-merge
+local changes.
+
+Git's submodule support allows a repository to contain, as a subdirectory, a
+checkout of an external project. Submodules maintain their own identity;
+the submodule support just stores the submodule repository location and
+commit ID, so other developers who clone the containing project
+("superproject") can easily clone all the submodules at the same revision.
+Partial checkouts of the superproject are possible: you can tell Git to
+clone none, some or all of the submodules.
+
+The gitlink:git-submodule[1] command is available since Git 1.5.3. Users
+with Git 1.5.2 can look up the submodule commits in the repository and
+manually check them out; earlier versions won't recognize the submodules at
+all.
To see how submodule support works, create (for example) four example
repositories that can be used later as a submodule:
@@ -3213,8 +3245,8 @@ The `git submodule add` command does a couple of things:
- It clones the submodule under the current directory and by default checks out
the master branch.
-- It adds the submodule's clone path to the `.gitmodules` file and adds this
- file to the index, ready to be committed.
+- It adds the submodule's clone path to the gitlink:gitmodules[5] file and
+ adds this file to the index, ready to be committed.
- It adds the submodule's current commit ID to the index, ready to be
committed.
@@ -4277,5 +4309,3 @@ Write a chapter on using plumbing and writing scripts.
Alternates, clone -reference, etc.
git unpack-objects -r for recovery
-
-submodules
--
1.5.3
^ permalink raw reply related
* Re: [PATCH] user-manual: Explain what submodules are good for.
From: Michael Smith @ 2007-09-25 12:44 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git, Miklos Vajna
In-Reply-To: <20070924213342.GL26387@fieldses.org>
On Mon, 24 Sep 2007, J. Bruce Fields wrote:
> That looks helpful, thanks, but a little more detail might be nice.
OK, let's find out if I'm awake enough to git-send-email.
Mike
^ permalink raw reply
* Re: [PATCH] rebase -i: commit when continuing after "edit"
From: Johannes Schindelin @ 2007-09-25 12:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dmitry Potapov, git
In-Reply-To: <7vlkav71bv.fsf@gitster.siamese.dyndns.org>
Hi,
I'll send out a fixed patch series later, where the "commit when
continuing" is th first one, and the style nits are addressed in the
second one. A third one will have a minor fixup, a 4th will address the
detached HEAD issue.
But I need some clarification of the quoting, as detailed below.
On Mon, 24 Sep 2007, Junio C Hamano wrote:
> > case "$VERBOSE" in
> > '')
> > "$@" > "$DOTEST"/output 2>&1
> > status=$?
> > test $status != 0 &&
> > cat "$DOTEST"/output
> > return $status
> > ;;
>
> One more level of indent, please.
Sorry, of course.
> > *)
> > "$@"
> > esac
>
> I find it is usually less error prone to help the longer term
> maintainability if you do not omit double-semicolon before esac.
There were quite a few instances; I fixed them all.
> > make_patch () {
> > parent_sha1=$(git rev-parse --verify "$1"^ 2> /dev/null)
> > git diff "$parent_sha1".."$1" > "$DOTEST"/patch
>
> What's the point of using --verify when you do not error out upon error?
> I find this quite inconsistent; your require_clean_work_tree above is so
> nicely written.
Thanks (for the latter). I changed that (the former).
> Is there anything (other than user's common sense, which we cannot
> always count on these days) that prevents the caller to feed a root
> commit to this function, I wonder?
There is a corner case, where it is possible:
A - B - C
D - E - F
$ git checkout F
$ git rebase -i C
I am not quite certain how to fix it... And besides, this fix has no place
in a style patch.
> > -die_with_patch () {
> > test -f "$DOTEST"/message ||
> > git cat-file commit $sha1 | sed "1,/^$/d" > "$DOTEST"/message
> > test -f "$DOTEST"/author-script ||
> > get_author_ident_from_commit $sha1 > "$DOTEST"/author-script
> > +}
>
> Are these "$sha1" still valid, or do you need "$1" given to the
> make_patch function?
They were not even valid before. "$1" it is.
> > pick_one () {
> > no_ff=
> > case "$1" in -n) sha1=$2; no_ff=t ;; *) sha1=$1 ;; esac
> > output git rev-parse --verify $sha1 || die "Invalid commit name: $sha1"
> > test -d "$REWRITTEN" &&
> > pick_one_preserving_merges "$@" && return
> > parent_sha1=$(git rev-parse --verify $sha1^ 2>/dev/null)
> > current_sha1=$(git rev-parse --verify HEAD)
>
> Again --verify without verifying.
Okay, fixed.
> > for p in $(git rev-list --parents -1 $sha1 | cut -d\ -f2-)
>
> Just a style nit. A string literal for a SP is easier to read if
> written as a SP inside sq pair (i.e. ' ') not backslash followed by a SP
> (i.e. \ ).
Right.
> > case $fast_forward in
> > t)
> > output warn "Fast forward to $sha1"
> > test $preserve=f && echo $sha1 > "$REWRITTEN"/$sha1
>
> Testing if concatenation of $preserve and "=f" is not an empty string,
> which would almost always yield true?
Ouch. This is wrong. And fixing that exposed another error: it should be
an "||" instead of a "&&".
Since it did not trigger erroneous behaviour, just unnecessary writing, I
put it into the style fixes category.
> > first_parent=$(expr "$new_parents" : " \([^ ]*\)")
>
> Style; typically regexp form of expr and sed expression are easier to
> read with quoted with sq, not dq.
But in this case, the expression does not change, right? Fixed.
> > # redo merge
> > author_script=$(get_author_ident_from_commit $sha1)
> > eval "$author_script"
> > msg="$(git cat-file commit $sha1 | \
> > sed -e '1,/^$/d' -e "s/[\"\\]/\\\\&/g")"
>
> What's this backquoting about? Your "output" does not eval (and it
> shouldn't), so that's not it. Working around incompatible echo that
> does auto magic used to write MERGE_MSG? Can we lose the backquoting by
> using printf "%s\n" there?
I think so. I never was good with quoting, but I guess that the more
important part is the '-m "$msg"'. This part could use a sanity check of
somebody who gets quoting right, i.e. you.
> > do_next () {
> > test -f "$DOTEST"/message && rm "$DOTEST"/message
> > test -f "$DOTEST"/author-script && rm "$DOTEST"/author-script
> > + test -f "$DOTEST"/amend && rm "$DOTEST"/amend
>
> As you do not check the error from "rm", how are these different from rm
> -f "$DOTEST/frotz"?
The difference: the user will not see many irritating error messages.
I changed this code to use a newly written function "remove_if_exists",
which die()s if the file exists and could not be removed.
So this is not technically a style fix, but minor enough that I'll put it
into that patch, too.
> > \#|'')
> > mark_action_done
> > ;;
>
> Perhaps '#'*?
Yeah. It did not matter much, as not many users wrote "#something"
anyway.
> > ...
> > edit)
> > comment_for_reflog edit
> >
> > mark_action_done
> > pick_one $sha1 ||
> > die_with_patch $sha1 "Could not apply $sha1... $rest"
> > make_patch $sha1
> > + : > "$DOTEST"/amend
>
> Good catch, but ':' is redundant ;-)
?
This idiom ": > file" is what I used ever since you said that "touch" is
not so good (not builtin, may behave differently, etc)
Besides, it is not a catch... rebase -i needs to know if it
continues after "edit", so it can amend the current commit (instead of
making a new commit, as in the other cases) before continuing.
> > test -z "$(grep -ve '^$' -e '^#' < $DONE)" &&
> > die "Cannot 'squash' without a previous commit"
>
> Why "test -z"? Wouldn't this be equivalent?
>
> grep -v -q -e '^$' -e '^#' "$DONE" || die ...
Yep. I introduced a new function, "has_action".
> > pick_one -n $sha1 || failed=t
> > author_script=$(get_author_ident_from_commit $sha1)
> > echo "$author_script" > "$DOTEST"/author-script
> > case $failed in
> > f)
> > # This is like --amend, but with a different message
> > eval "$author_script"
> > export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE
> > $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
> > ;;
>
> The "export" here makes me somewhat nervous -- no chance these
> leak into the next round?
I am somewhat wary: I get quoting wrong all the time. Would
$USE_OUTPUT $author_script git commit -F "$MSG" $EDIT_COMMIT
work? I have the slight suspicion that it would not, since
eval "$author_script"
needs extra quoting in $author_script, no?
> > ...
> > HEAD=$(git rev-parse --verify HEAD) || die "No HEAD?"
> > UPSTREAM=$(git rev-parse --verify "$1") || die "Invalid base"
> >
> > test -z "$ONTO" && ONTO=$UPSTREAM
> >
> > : > "$DOTEST"/interactive || die "Could not mark as interactive"
> > git symbolic-ref HEAD > "$DOTEST"/head-name ||
> > die "Could not get HEAD"
>
> It was somewhat annoying that you cannot "rebase -i" the
> detached HEAD state.
Will fix in a separate patch.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Small cache_tree_write refactor.
From: Pierre Habouzit @ 2007-09-25 11:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0709251135530.28395@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]
On Tue, Sep 25, 2007 at 10:38:16AM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 25 Sep 2007, Pierre Habouzit wrote:
>
> > --- a/cache-tree.c
> > +++ b/cache-tree.c
> > @@ -369,10 +369,8 @@ int cache_tree_update(struct cache_tree *it,
> > return 0;
> > }
> >
> > -static void write_one(struct cache_tree *it,
> > - char *path,
> > - int pathlen,
> > - struct strbuf *buffer)
> > +static void write_one(struct strbuf *buffer, struct cache_tree *it,
> > + const char *path, int pathlen)
>
> I don't know... is this really needed? In some other projects, the coding
> standard prefers the parameters in "in"..."out" order.
Well, this is thought in an OO way, buffer would be the "this". This
method could be named strbuf_addtree(...) hence I felt that having the
buffer as a first argument to be right.
But I don't care that much about that.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Use "" instead of "<unknown>" for placeholders
From: Michal Vitecek @ 2007-09-25 10:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0709251120120.28395@racer.site>
Hi,
Johannes Schindelin wrote:
>> >>>>>>> I made it because I want to use my own pretty format which currently
>> >>>>>>> only allows '%s' for subject and '%b' for body. But '%b' is
>> >>>>>>> substituted with <undefined> if the body is "missing" which I
>> >>>>>>> obviously don't like :)
>> >>>>>> Then you should fix %b not to show "<undefined>".
>> >>>>> I'll do it if it is okay. Shall I do the same for the other
>> >>>>> placeholders as well?
>> >>>> Yeah. Don't know why I did it that way.
>> >>> Here comes the big patch :)
>> >> Now, this breaks t6006 which needs this patch.
>> >
>> > Oops - I'm sorry about that. I ran the test suite (1.5.3.1) but it failed
>> > in 2 tests before the patch and in 2 tests after it so I considered it
>> > okay.
>> >
>> >> Looking at this patch, I am not sure if your change is really a
>> >> desirable one --- shouldn't it be removing the line itself, not
>> >> just <unknown> token?
>> >
>> > This sounds as the best solution. I'll look into it. Thanks for your time.
>>
>> Here comes the patch. I hope it will be ok this time :) Thanks.
>>
>> Don't use "<unknown>" for unknown values of placeholders and suppress
>> printing of empty user formats.
>>
>> ---
>
>We use tabs for indentation, not spaces.
>
>Also, instead of the expensive "strlen(buf)", you rather want to check "if
>(*buf)".
---
Thanks for the notes - here comes the patch with the above fixes.
builtin-rev-list.c | 3 ++-
commit.c | 3 ---
interpolate.c | 6 +++++-
log-tree.c | 10 ++++++----
t/t6006-rev-list-format.sh | 8 --------
t/t7500-commit.sh | 4 ++--
6 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 3894633..0b74eb3 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -85,7 +85,8 @@ static void show_commit(struct commit *commit)
pretty_print_commit(revs.commit_format, commit, ~0,
&buf, &buflen,
revs.abbrev, NULL, NULL, revs.date_mode);
- printf("%s%c", buf, hdr_termination);
+ if (*buf)
+ printf("%s%c", buf, hdr_termination);
free(buf);
}
maybe_flush_or_die(stdout, "stdout");
diff --git a/commit.c b/commit.c
index 99f65ce..c9a1818 100644
--- a/commit.c
+++ b/commit.c
@@ -917,9 +917,6 @@ long format_commit_message(const struct commit *commit, const void *format,
}
if (msg[i])
table[IBODY].value = xstrdup(msg + i);
- for (i = 0; i < ARRAY_SIZE(table); i++)
- if (!table[i].value)
- interp_set_entry(table, i, "<unknown>");
do {
char *buf = *buf_p;
diff --git a/interpolate.c b/interpolate.c
index 0082677..2f727cd 100644
--- a/interpolate.c
+++ b/interpolate.c
@@ -76,8 +76,12 @@ unsigned long interpolate(char *result, unsigned long reslen,
/* Check for valid interpolation. */
if (i < ninterps) {
value = interps[i].value;
- valuelen = strlen(value);
+ if (!value) {
+ src += namelen;
+ continue;
+ }
+ valuelen = strlen(value);
if (newlen + valuelen + 1 < reslen) {
/* Substitute. */
strncpy(dest, value, valuelen);
diff --git a/log-tree.c b/log-tree.c
index a642371..79502f4 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -175,14 +175,15 @@ void show_log(struct rev_info *opt, const char *sep)
* - The pretty-printed commit lacks a newline at the end
* of the buffer, but we do want to make sure that we
* have a newline there. If the separator isn't already
- * a newline, add an extra one.
+ * a newline, add an extra one and do the same for the
+ * user format as well.
* - unlike other log messages, the one-line format does
* not have an empty line between entries.
*/
extra = "";
- if (*sep != '\n' && opt->commit_format == CMIT_FMT_ONELINE)
+ if (*sep != '\n' && (opt->commit_format == CMIT_FMT_ONELINE || opt->commit_format == CMIT_FMT_USERFORMAT))
extra = "\n";
- if (opt->shown_one && opt->commit_format != CMIT_FMT_ONELINE)
+ if (opt->shown_one && opt->commit_format != CMIT_FMT_ONELINE && opt->commit_format != CMIT_FMT_USERFORMAT)
putchar(opt->diffopt.line_termination);
opt->shown_one = 1;
@@ -298,7 +299,8 @@ void show_log(struct rev_info *opt, const char *sep)
if (opt->show_log_size)
printf("log size %i\n", len);
- printf("%s%s%s", msgbuf, extra, sep);
+ if (*msgbuf)
+ printf("%s%s%s", msgbuf, extra, sep);
free(msgbuf);
}
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index ad6d0b8..1e4541a 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -79,9 +79,7 @@ EOF
test_format encoding %e <<'EOF'
commit 131a310eb913d107dd3c09a65d1651175898735d
-<unknown>
commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-<unknown>
EOF
test_format subject %s <<'EOF'
@@ -93,9 +91,7 @@ EOF
test_format body %b <<'EOF'
commit 131a310eb913d107dd3c09a65d1651175898735d
-<unknown>
commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-<unknown>
EOF
test_format colors %Credfoo%Cgreenbar%Cbluebaz%Cresetxyzzy <<'EOF'
@@ -121,9 +117,7 @@ test_format complex-encoding %e <<'EOF'
commit f58db70b055c5718631e5c61528b28b12090cdea
iso8859-1
commit 131a310eb913d107dd3c09a65d1651175898735d
-<unknown>
commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-<unknown>
EOF
test_format complex-subject %s <<'EOF'
@@ -142,9 +136,7 @@ and it will be encoded in iso8859-1. We should therefore
include an iso8859 character: ÂĄbueno!
commit 131a310eb913d107dd3c09a65d1651175898735d
-<unknown>
commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
-<unknown>
EOF
test_done
diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
index f11ada8..abbf54b 100755
--- a/t/t7500-commit.sh
+++ b/t/t7500-commit.sh
@@ -81,7 +81,7 @@ test_expect_success 'explicit commit message should override template' '
git add foo &&
GIT_EDITOR=../t7500/add-content git commit --template "$TEMPLATE" \
-m "command line msg" &&
- commit_msg_is "command line msg<unknown>"
+ commit_msg_is "command line msg"
'
test_expect_success 'commit message from file should override template' '
@@ -90,7 +90,7 @@ test_expect_success 'commit message from file should override template' '
echo "standard input msg" |
GIT_EDITOR=../t7500/add-content git commit \
--template "$TEMPLATE" --file - &&
- commit_msg_is "standard input msg<unknown>"
+ commit_msg_is "standard input msg"
'
test_done
--
1.5.3.2
--
fuf (fuf@mageo.cz)
^ permalink raw reply related
* Re: My stash wants to delete all my files
From: Johannes Schindelin @ 2007-09-25 10:41 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <0F9BDBCD-06AA-4AB1-9DDA-9C98E8796AA1@steelskies.com>
Hi,
On Tue, 25 Sep 2007, Jonathan del Strother wrote:
> On 25 Sep 2007, at 10:56, Johannes Schindelin wrote:
>
> > On Tue, 25 Sep 2007, Jonathan del Strother wrote:
> >
> > > I don't think I git-added anything - just made changes to the
> > > working copy. (It *does* stash those, right??)
> >
> > Stash does not care about things that are not tracked, so no, it does
> > not stash those. Imagine a stash saving all those .o, .a and .so
> > files... Insanity!
>
>
> Mm, ok - fair point. I was actually thinking of files that are already
> tracked, but haven't been added to the staging area with git add.
Ah. I read your statement as "I don't think I git-added anything, ever".
So this is what stash is supposed to do:
- save the differences between the HEAD and the index
- save the differences between the HEAD and the working tree
- reset the index and the working tree to the state of the HEAD
So indeed, I am as puzzled as you are. Maybe it was your initial commit?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Small cache_tree_write refactor.
From: Johannes Schindelin @ 2007-09-25 10:38 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git
In-Reply-To: <20070925082341.DF412BDBCF@madism.org>
Hi,
On Tue, 25 Sep 2007, Pierre Habouzit wrote:
> --- a/cache-tree.c
> +++ b/cache-tree.c
> @@ -369,10 +369,8 @@ int cache_tree_update(struct cache_tree *it,
> return 0;
> }
>
> -static void write_one(struct cache_tree *it,
> - char *path,
> - int pathlen,
> - struct strbuf *buffer)
> +static void write_one(struct strbuf *buffer, struct cache_tree *it,
> + const char *path, int pathlen)
I don't know... is this really needed? In some other projects, the coding
standard prefers the parameters in "in"..."out" order.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Supplant the "while case ... break ;; esac" idiom
From: Avi Kivity @ 2007-09-25 10:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Kastrup, git
In-Reply-To: <7v4phj6yxb.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> David Kastrup <dak@gnu.org> writes:
>
>
>> As a completely irrelevant side note: the autoconf documentation
>> mentions that "false" is more portable than "true" since calling it
>> returns a non-zero exit status even when it is not installed or
>> built-in.
>>
>
> Ah, I like that ;-) It is obvious when you think about it, and
> it is so true but in a very twisted way...
>
>
You mean, it is not false but in a twisted way, don't you?
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
^ permalink raw reply
* Re: [PATCH] Supplant the "while case ... break ;; esac" idiom
From: Johannes Schindelin @ 2007-09-25 10:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4phj6yxb.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 24 Sep 2007, Junio C Hamano wrote:
> David Kastrup <dak@gnu.org> writes:
>
> > As a completely irrelevant side note: the autoconf documentation
> > mentions that "false" is more portable than "true" since calling it
> > returns a non-zero exit status even when it is not installed or
> > built-in.
>
> Ah, I like that ;-) It is obvious when you think about it, and it is so
> true but in a very twisted way...
But would you not have to redirect stderr to /dev/null, then?
In the same vein, we could replace "true" by "! false".
That's such a good idea that I'll go and make a patch.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Use "" instead of "<unknown>" for placeholders
From: Johannes Schindelin @ 2007-09-25 10:25 UTC (permalink / raw)
To: Michal Vitecek; +Cc: Junio C Hamano, git
In-Reply-To: <20070925094320.GN22869@mageo.cz>
Hi,
On Tue, 25 Sep 2007, Michal Vitecek wrote:
> Hello again,
>
> Michal Vitecek wrote:
> > Junio C Hamano wrote:
> >>>>>>> I made it because I want to use my own pretty format which currently
> >>>>>>> only allows '%s' for subject and '%b' for body. But '%b' is
> >>>>>>> substituted with <undefined> if the body is "missing" which I
> >>>>>>> obviously don't like :)
> >>>>>> Then you should fix %b not to show "<undefined>".
> >>>>> I'll do it if it is okay. Shall I do the same for the other
> >>>>> placeholders as well?
> >>>> Yeah. Don't know why I did it that way.
> >>> Here comes the big patch :)
> >> Now, this breaks t6006 which needs this patch.
> >
> > Oops - I'm sorry about that. I ran the test suite (1.5.3.1) but it failed
> > in 2 tests before the patch and in 2 tests after it so I considered it
> > okay.
> >
> >> Looking at this patch, I am not sure if your change is really a
> >> desirable one --- shouldn't it be removing the line itself, not
> >> just <unknown> token?
> >
> > This sounds as the best solution. I'll look into it. Thanks for your time.
>
> Here comes the patch. I hope it will be ok this time :) Thanks.
>
> Don't use "<unknown>" for unknown values of placeholders and suppress
> printing of empty user formats.
>
> ---
Please move the discussion which should not be in the commit message
_after_ the "---".
> diff --git a/builtin-rev-list.c b/builtin-rev-list.c
> index 3894633..1de981d 100644
> --- a/builtin-rev-list.c
> +++ b/builtin-rev-list.c
> @@ -85,7 +85,8 @@ static void show_commit(struct commit *commit)
> pretty_print_commit(revs.commit_format, commit, ~0,
> &buf, &buflen,
> revs.abbrev, NULL, NULL, revs.date_mode);
> - printf("%s%c", buf, hdr_termination);
> + if (strlen(buf))
> + printf("%s%c", buf, hdr_termination);
We use tabs for indentation, not spaces.
Also, instead of the expensive "strlen(buf)", you rather want to check "if
(*buf)".
> diff --git a/log-tree.c b/log-tree.c
> index a642371..5653332 100644
> --- a/log-tree.c
> +++ b/log-tree.c
> @@ -298,7 +299,8 @@ void show_log(struct rev_info *opt, const char *sep)
> if (opt->show_log_size)
> printf("log size %i\n", len);
>
> - printf("%s%s%s", msgbuf, extra, sep);
> + if (strlen(msgbuf))
> + printf("%s%s%s", msgbuf, extra, sep);
Again, "if (*msgbuf)" is way more efficient.
Ciao,
Dscho
^ permalink raw reply
* Re: My stash wants to delete all my files
From: Jonathan del Strother @ 2007-09-25 10:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0709251054440.28395@racer.site>
On 25 Sep 2007, at 10:56, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 25 Sep 2007, Jonathan del Strother wrote:
>
>> I don't think I git-added anything - just made changes to the working
>> copy. (It *does* stash those, right??)
>
> Stash does not care about things that are not tracked, so no, it
> does not
> stash those. Imagine a stash saving all those .o, .a and .so files...
> Insanity!
Mm, ok - fair point. I was actually thinking of files that are
already tracked, but haven't been added to the staging area with git
add.
^ permalink raw reply
* Re: [PATCH] Move convert-objects to contrib.
From: Johannes Schindelin @ 2007-09-25 10:01 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <1190690061-6720-1-git-send-email-kraai@ftbfs.org>
Hi,
the commit message looks a little bit empty to me. I'd at least mention
why convert-objects was needed, why it is no longer needed, and that
Linus, the original author, is okay with it.
And you might want to use the "-M" flag to format-patch next time (detect
renames).
Ciao,
Dscho
^ permalink raw reply
* Re: My stash wants to delete all my files
From: Johannes Schindelin @ 2007-09-25 9:56 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <DCBF8566-9B43-4EFA-A8B2-2EAB516C273F@steelskies.com>
Hi,
On Tue, 25 Sep 2007, Jonathan del Strother wrote:
> I don't think I git-added anything - just made changes to the working
> copy. (It *does* stash those, right??)
Stash does not care about things that are not tracked, so no, it does not
stash those. Imagine a stash saving all those .o, .a and .so files...
Insanity!
Ciao,
Dscho
^ permalink raw reply
* Re: [EGIT PATCH] Change to simplified icon.
From: Johannes Schindelin @ 2007-09-25 9:53 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070925011636.GH3099@spearce.org>
Hi,
On Mon, 24 Sep 2007, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Mon, 24 Sep 2007, Shawn O. Pearce wrote:
> > >
> > > [...] Maybe I'll take a stab at creating
> > > a git-gui icon [...]
> >
> > You might want to look at http://git.or.cz/gitwiki/GitRelatedLogos (I
> > especially like Henrik Nyh's, we use it in git-gui). Might be a good
> > starting point.
>
> What do you mean you "use it in git-gui" ? Have you patched git-gui to
> set the window icon to Henrik's? And not tried to contribute the patch
> upstream? Come on, show the GPL love... :-)
Oops. I meant to say that we use it in msysGit.
Sorry,
Dscho
^ 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