* 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
* Re: [PATCH] Use "" instead of "<unknown>" for placeholders
From: Michal Vitecek @ 2007-09-25 9:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <46F4D815.5050602@mageo.cz>
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.
---
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..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);
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..58fd055 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 == NULL) {
+ 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..5653332 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 (strlen(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.1
--
fuf (fuf@mageo.cz)
^ permalink raw reply related
* Re: My stash wants to delete all my files
From: Jonathan del Strother @ 2007-09-25 9:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vabrb8rin.fsf@gitster.siamese.dyndns.org>
On 25 Sep 2007, at 02:26, Junio C Hamano wrote:
> Jonathan del Strother <maillist@steelskies.com> writes:
>
>> $ git stash list
>> stash@{0}: On master: --apply
>> stash@{1}: WIP on master: 09e3c30... Better handling of cell sizes in
>> the grid
>>
>> $ git stash show stash@{1}
>> ...
>> 19 files changed, 0 insertions(+), 3805 deletions(-)
>>
>> Hmm. Looks like it's trying to delete all of my versioned files.
>> "git stash apply stash@{1}" confirms this. Obviously that's not
>> what
>> I tried to stash - my WIP when I stashed was a few additions, a
>> couple
>> of new unversioned files, and moving a few lines of code from one
>> file
>> to another.
>>
>> Any ideas what happened there? I can't seem to reproduce the problem
>> in a test repository.
>
> ...
> Whenever anybody wonders where inadvertent reverting changes
> come from, two most likely reasons are incorrect push into the
> current branch's tip initiated from elsewhere, or incorrect
> fetch into the current branch's tip initiated from the
> repository.
I'm working on a single isolated repository, so haven't pushed,
pulled, fetched, or anything.
> git ls-tree stash@{1}
> git rev-parse stash@{1}^1
> git diff stash@{1}^1 stash@{1}^2
>
ls-tree is empty. rev-parse confirms I was on the right revision when
I stashed, and the diff shows everything being deleted.
> Does the third command show you what you thought you have
> told "git add" to put in the index just before you made the
> stash?
I don't think I git-added anything - just made changes to the working
copy. (It *does* stash those, right??)
I'm at a loss to explain what happened here...
^ permalink raw reply
* [PATCH] Small cache_tree_write refactor.
From: Pierre Habouzit @ 2007-09-25 8:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This function cannot fail, make it void. Also make write_one act on a
const char* instead of a char*.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
cache-tree.c | 19 +++++--------------
cache-tree.h | 2 +-
read-cache.c | 19 +++++++++----------
3 files changed, 15 insertions(+), 25 deletions(-)
diff --git a/cache-tree.c b/cache-tree.c
index 5471844..50b3526 100644
--- 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)
{
int i;
@@ -407,20 +405,13 @@ static void write_one(struct cache_tree *it,
prev->name, prev->namelen) <= 0)
die("fatal - unsorted cache subtree");
}
- write_one(down->cache_tree, down->name, down->namelen, buffer);
+ write_one(buffer, down->cache_tree, down->name, down->namelen);
}
}
-void *cache_tree_write(struct cache_tree *root, unsigned long *size_p)
+void cache_tree_write(struct strbuf *sb, struct cache_tree *root)
{
- char path[PATH_MAX];
- struct strbuf buffer;
-
- path[0] = 0;
- strbuf_init(&buffer, 0);
- write_one(root, path, 0, &buffer);
- *size_p = buffer.len;
- return strbuf_detach(&buffer);
+ write_one(sb, root, "", 0);
}
static struct cache_tree *read_one(const char **buffer, unsigned long *size_p)
diff --git a/cache-tree.h b/cache-tree.h
index 119407e..8243228 100644
--- a/cache-tree.h
+++ b/cache-tree.h
@@ -22,7 +22,7 @@ void cache_tree_free(struct cache_tree **);
void cache_tree_invalidate_path(struct cache_tree *, const char *);
struct cache_tree_sub *cache_tree_sub(struct cache_tree *, const char *);
-void *cache_tree_write(struct cache_tree *root, unsigned long *size_p);
+void cache_tree_write(struct strbuf *, struct cache_tree *root);
struct cache_tree *cache_tree_read(const char *buffer, unsigned long size);
int cache_tree_fully_valid(struct cache_tree *);
diff --git a/read-cache.c b/read-cache.c
index 2e40a34..56202d1 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1136,7 +1136,7 @@ int write_index(struct index_state *istate, int newfd)
{
SHA_CTX c;
struct cache_header hdr;
- int i, removed;
+ int i, err, removed;
struct cache_entry **cache = istate->cache;
int entries = istate->cache_nr;
@@ -1165,16 +1165,15 @@ int write_index(struct index_state *istate, int newfd)
/* Write extension data here */
if (istate->cache_tree) {
- unsigned long sz;
- void *data = cache_tree_write(istate->cache_tree, &sz);
- if (data &&
- !write_index_ext_header(&c, newfd, CACHE_EXT_TREE, sz) &&
- !ce_write(&c, newfd, data, sz))
- free(data);
- else {
- free(data);
+ struct strbuf sb;
+
+ strbuf_init(&sb, 0);
+ cache_tree_write(&sb, istate->cache_tree);
+ err = write_index_ext_header(&c, newfd, CACHE_EXT_TREE, sb.len) < 0
+ || ce_write(&c, newfd, sb.buf, sb.len) < 0;
+ strbuf_release(&sb);
+ if (err)
return -1;
- }
}
return ce_flush(&c, newfd);
}
--
1.5.3.2.1067.g96579-dirty
^ permalink raw reply related
* Re: [PATCH] unexpected Make output (e.g. from --debug) causes build failure
From: David Kastrup @ 2007-09-25 7:59 UTC (permalink / raw)
To: git
In-Reply-To: <877imftfef.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
> Without this, the extra output produced e.g., by "make --debug"
> would go into $INSTLIBDIR and then cause the sed command to fail.
>
> Signed-off-by: Jim Meyering <jim@meyering.net>
> ---
> Makefile | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 0055eef..97ce687 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -805,7 +805,7 @@ perl/perl.mak: GIT-CFLAGS
>
> $(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
> $(QUIET_GEN)$(RM) $@ $@+ && \
> - INSTLIBDIR=`$(MAKE) -C perl -s --no-print-directory instlibdir` && \
> + INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C perl -s --no-print-directory instlibdir` && \
> sed -e '1{' \
> -e ' s|#!.*perl|#!$(PERL_PATH_SQ)|' \
> -e ' h' \
> --
> 1.5.3.2.99.ge4b2-dirty
Does this work with "make -n" ?
--
David Kastrup
^ permalink raw reply
* [PATCH] Do not over-quote the -f envelopesender value.
From: Jim Meyering @ 2007-09-25 6:48 UTC (permalink / raw)
To: git
Without this, the value passed to sendmail would have an extra set of
single quotes. At least exim's sendmail emulation would object to that:
exim: bad -f address "'list-addr@example.org'": malformed address: ' \
may not follow 'list-addr@example.org
error: hooks/post-receive exited with error code 1
Signed-off-by: Jim Meyering <jim@meyering.net>
---
contrib/hooks/post-receive-email | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index c589a39..1f88099 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -571,6 +571,15 @@ generate_delete_general_email()
echo $LOGEND
}
+send_mail()
+{
+ if [ -n "$envelopesender" ]; then
+ /usr/sbin/sendmail -t -f "$envelopesender"
+ else
+ /usr/sbin/sendmail -t
+ fi
+}
+
# ---------------------------- main()
# --- Constants
@@ -607,13 +616,8 @@ if [ -n "$1" -a -n "$2" -a -n "$3" ]; then
# resend an email; they could redirect the output to sendmail themselves
PAGER= generate_email $2 $3 $1
else
- if [ -n "$envelopesender" ]; then
- envelopesender="-f '$envelopesender'"
- fi
-
while read oldrev newrev refname
do
- generate_email $oldrev $newrev $refname |
- /usr/sbin/sendmail -t $envelopesender
+ generate_email $oldrev $newrev $refname | send_mail
done
fi
--
1.5.3.2.99.ge4b2-dirty
^ permalink raw reply related
* [PATCH] unexpected Make output (e.g. from --debug) causes build failure
From: Jim Meyering @ 2007-09-25 6:42 UTC (permalink / raw)
To: git
Without this, the extra output produced e.g., by "make --debug"
would go into $INSTLIBDIR and then cause the sed command to fail.
Signed-off-by: Jim Meyering <jim@meyering.net>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 0055eef..97ce687 100644
--- a/Makefile
+++ b/Makefile
@@ -805,7 +805,7 @@ perl/perl.mak: GIT-CFLAGS
$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
$(QUIET_GEN)$(RM) $@ $@+ && \
- INSTLIBDIR=`$(MAKE) -C perl -s --no-print-directory instlibdir` && \
+ INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!$(PERL_PATH_SQ)|' \
-e ' h' \
--
1.5.3.2.99.ge4b2-dirty
^ permalink raw reply related
* Re: [PATCH] git-submodule - allow a relative path as the subproject url
From: Junio C Hamano @ 2007-09-25 6:42 UTC (permalink / raw)
To: Mark Levedahl; +Cc: git
In-Reply-To: <1190600382-1648-1-git-send-email-mdl123@verizon.net>
Mark Levedahl <mdl123@verizon.net> writes:
> This allows a subproject's location to be specified and stored as relative
> to the parent project's location (e.g., ./foo, or ../foo). This url is
> stored in .gitmodules as given. It is resolved into an absolute url by
> appending it to the parent project's url when the information is written
> to .git/config (i.e., during submodule add for the originator, and
> submodule init for a downstream recipient). This allows cloning of the
> project to work "as expected" if the project is hosted on a different
> server than when the subprojects were added.
>
> Signed-off-by: Mark Levedahl <mdl123@verizon.net>
I like the idea here. If you maintain and serve a set related
projects you need to give the users a single URL (per where the
user is and how to reach the server).
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index 2c48936..d421677 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -21,6 +21,9 @@ add::
> repository is cloned at the specified path, added to the
> changeset and registered in .gitmodules. If no path is
> specified, the path is deduced from the repository specification.
> + If the repository url begins with ./ or ../, it is stored as
> + given but resolved as a relative path from the main project's
> + url when cloning.
Tabs vs spaces? Will fix up while applying.
Thanks.
^ permalink raw reply
* [PATCH] Make merge-recursive honor diff.renamelimit
From: Lars Hjemli @ 2007-09-25 6:36 UTC (permalink / raw)
To: Junio C Hamano, Linus Torvalds; +Cc: git
It might be a sign of source code management gone bad, but when two branches
has diverged almost beyond recognition and time has come for the branches to
merge, the user is going to need all the help his tool can give him. Honoring
diff.renamelimit has great potential as a painkiller in such situations.
The painkiller effect could have been achieved by e.g. 'merge.renamelimit',
but the flexibility gained by a separate option is questionable: our user
would probably expect git to detect renames equally good when merging as
when diffing (I known I did).
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
On 9/14/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> The choice of default value is of course very debatable. Limiting the
> rename matrix to a 100x100 size will mean that even if you have just one
> obvious rename, but you also create (or delete) 10,000 files, the rename
> matrix will be so big that we disable the heuristics. Sounds reasonable to
> me, but let's see if people hit this (and, perhaps more importantly,
> actually *care*) in real life.
Yeah, I got hit, and I care ;-)
merge-recursive.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 19d5f3b..97dcf9b 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -96,6 +96,7 @@ static struct path_list current_directory_set = {NULL, 0, 0, 1};
static int call_depth = 0;
static int verbosity = 2;
+static int rename_limit = -1;
static int buffer_output = 1;
static struct output_buffer *output_list, *output_end;
@@ -372,6 +373,7 @@ static struct path_list *get_renames(struct tree *tree,
diff_setup(&opts);
opts.recursive = 1;
opts.detect_rename = DIFF_DETECT_RENAME;
+ opts.rename_limit = rename_limit;
opts.output_format = DIFF_FORMAT_NO_OUTPUT;
if (diff_setup_done(&opts) < 0)
die("diff setup failed");
@@ -1693,6 +1695,10 @@ static int merge_config(const char *var, const char *value)
verbosity = git_config_int(var, value);
return 0;
}
+ if (!strcasecmp(var, "diff.renamelimit")) {
+ rename_limit = git_config_int(var, value);
+ return 0;
+ }
return git_default_config(var, value);
}
--
1.5.3.2.1054.g35b0b
^ permalink raw reply related
* Re: [PATCH] Supplant the "while case ... break ;; esac" idiom
From: Junio C Hamano @ 2007-09-25 6:29 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85hcljgtlr.fsf@lola.goethe.zz>
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...
^ 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