* Re: [PATCH] Rearrange git-format-patch synopsis to improve clarity.
From: David Symonds @ 2007-11-06 21:08 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Junio C Hamano, git
In-Reply-To: <473081C2.7060106@freescale.com>
On 11/7/07, Jon Loeliger <jdl@freescale.com> wrote:
> David Symonds wrote:
> > Now that I look at it again, it seems the long options look quite
> > inconsistent. I think it should be either
> > --numbered-files/--no-numbered-files or --numbered/--no-numbered. My
> > preference is with the latter (for brevity), but that breaks
> > backward-compatibility.
> >
> > Would you accept a patch that changed --numbered-files to --numbered,
> > and kept the former as a synonym?
>
> There are two forms of numbered file output names:
> the traditional "0001-Foo-the-bar" and just "1" styles.
> Please don't break that. Both are needed.
Oh, I certainly wasn't proposing removing any functionality; merely
renaming the option to select it so as to be consistent.
Dave.
^ permalink raw reply
* Re: [PATCH] Give git-am back the ability to add Signed-off-by lines.
From: Junio C Hamano @ 2007-11-06 21:07 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Pierre Habouzit
In-Reply-To: <200711062133.58903.johannes.sixt@telecom.at>
Good eyes, thanks.
^ permalink raw reply
* Re: [PATCH 3/5] Replace $((...)) with expr invocations.
From: Junio C Hamano @ 2007-11-06 21:06 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: git
In-Reply-To: <20071106202600.GH6361@ins.uni-bonn.de>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> * Ralf Wildenhues wrote on Tue, Nov 06, 2007 at 09:18:09PM CET:
>> ---
>> git-filter-branch.sh | 4 ++--
>> git-rebase--interactive.sh | 8 ++++----
>> git-rebase.sh | 8 ++++----
>> 3 files changed, 10 insertions(+), 10 deletions(-)
>
> Hmm, maybe this one is overkill. $((...)) is POSIX, I temporarily
> forgot (thanks Benoît!).
>
> I'm unsure whether git targets non-POSIX Bourne shells like Solaris
> /bin/sh. That would however mean replacing stuff like $(cmd) with
> `cmd` as well, and from grepping the source it looks like you'd rather
> avoid that.
For git, two rough rules are:
- Most importantly, we never say "It's in POSIX; we'll happily
screw your system that does not conform." We live in the
real world.
- However, we often say "Let's stay away from that construct,
it's not even in POSIX".
For shell scripts specifically (not exhaustive):
- We prefer $( ... ) for command substitution; unlike ``, it
properly nests. It should have been the way Bourne spelled
it from day one, but unfortunately isn't.
- We use ${parameter-word} and its [-=?+] siblings, and their
colon'ed "unset or null" form.
- We use ${parameter#word} and its [#%] siblings, and their
doubled "longest matching" form.
- We use Arithmetic Expansion $(( ... )).
- No "Substring Expansion" ${parameter:offset:length}.
- No shell arrays.
- No strlen ${#parameter}.
- No regexp ${parameter/pattern/string}.
- We do not use Process Substitution <(list) or >(list).
- We prefer "test" over "[ ... ]".
- We do not write noiseword "function" in front of shell
functions.
^ permalink raw reply
* Re: [PATCH 0/5] some shell portability fixes
From: Mike Hommey @ 2007-11-06 21:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ralf Wildenhues, git
In-Reply-To: <7v8x5bgl04.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 06, 2007 at 12:46:35PM -0800, Junio C Hamano wrote:
> [5/5] Again, have you covered all of them? I am not opposed to
> this one, although I am a bit curious who lacks -a/-o in
> practice.
Solaris's /bin/sh, but it already doesn't support $() and other stuff
used all over the place in git, so it's not like it's changing anything.
Maybe some other obscure old crappy shell ?
Mike
^ permalink raw reply
* Re: [PATCH 0/5] some shell portability fixes
From: Junio C Hamano @ 2007-11-06 20:46 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: git
In-Reply-To: <20071106201518.GA6361@ins.uni-bonn.de>
All missing Signed-off-by: lines.
[1/5] In addition to take advantage of the fact that the RHS of
assignment is not split, I'd prefer replacing `` with $()
with these cases. Much easier to read if your shell
supports it (and all the modern ones do).
[2/5] Gaah, AIX sed X-<. I am not opposed to this patch but
would want to get Yays from people with non GNU sed. Is
busybox sed good enough to grok our scripts these days?
Please ask help and collect Acks at least from folks on
Solaris, MacOS, FBSD, and OBSD.
[3/5] Arithmetic expansion. Have you caught _all_ of them, or
is this patch about only the ones you noticed?
We used to have expr all over the place as I was one of
the primary authors of our shell scripts, and I am
"80-ish" old fashioned. There was a long discussion on
scripts in the past and we ruled that $(( ... )) is easier
to read and supported widely enough to be acceptable.
This patch goes backwards. Will drop, unless you can
demonstrate that an implementation does not support it and
convince people that the implementation is important.
/bin/sh on Solaris does not count as you can configure
SHELL_PATH to point at xpg4 shell or ksh on that platform.
[4/5] I wonder if use of fgrep would be easier to read and more
portable with this one:
name=$( GIT_CONFIG=.gitmodules \
git config --get-regexp '^submodule\..*\.path$' |
fgrep "submodule.$1.path" |
sed -e 's/^submodule\.\(.*\)\.path$/\1/'
)
[5/5] Again, have you covered all of them? I am not opposed to
this one, although I am a bit curious who lacks -a/-o in
practice.
^ permalink raw reply
* [PATCH] Give git-am back the ability to add Signed-off-by lines.
From: Johannes Sixt @ 2007-11-06 20:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pierre Habouzit
This was lost in the migration to git-rev-parse --parseopt by commit
78443d90491c1b82afdffc3d5d2ab8c1a58928b5.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
git-am.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 876b973..e5af955 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -131,7 +131,7 @@ do
binary=t ;;
-3|--3way)
threeway=t ;;
- -s--signoff)
+ -s|--signoff)
sign=t ;;
-u|--utf8)
utf8=t ;; # this is now default
--
1.5.3.4.315.g2ce38
^ permalink raw reply related
* Re: [PATCH 3/5] Replace $((...)) with expr invocations.
From: Ralf Wildenhues @ 2007-11-06 20:26 UTC (permalink / raw)
To: git
In-Reply-To: <20071106201809.GD6361@ins.uni-bonn.de>
* Ralf Wildenhues wrote on Tue, Nov 06, 2007 at 09:18:09PM CET:
> ---
> git-filter-branch.sh | 4 ++--
> git-rebase--interactive.sh | 8 ++++----
> git-rebase.sh | 8 ++++----
> 3 files changed, 10 insertions(+), 10 deletions(-)
Hmm, maybe this one is overkill. $((...)) is POSIX, I temporarily
forgot (thanks Benoît!).
I'm unsure whether git targets non-POSIX Bourne shells like Solaris
/bin/sh. That would however mean replacing stuff like $(cmd) with
`cmd` as well, and from grepping the source it looks like you'd rather
avoid that.
Cheers,
Ralf
^ permalink raw reply
* Re: git pull opinion
From: Ralf Wildenhues @ 2007-11-06 20:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Benoit Sigoure, Aghiles, git list
In-Reply-To: <Pine.LNX.4.64.0711061154310.4362@racer.site>
* Johannes Schindelin wrote on Tue, Nov 06, 2007 at 12:59:07PM CET:
> On Tue, 6 Nov 2007, Ralf Wildenhues wrote:
> >
> > Since I simply don't have the time resources to just implement that,
> > I'll thank you for your attention and go back to lurking mode now.
>
> You might as well be honest, and say that they are not time constraints,
> but lack of motivation.
No. I will not do it, because the marginal cost of getting to
know not only git but also its source is too high for my precious
time ATM. Maybe next year.
Will you do it for me if I buy you some beer? If I promise to
(continue to) proofread git documentation for a couple of months?
If I do more audit of git's shell code, searching for nonportable
constructs? Or if I promise to try to help you with any autotools
issue you might have? Or would money be needed? This:
> Implementing that feature would be a piece of cake [...]
doesn't sound like it, but I would understand very well if it
needed that.
Please consider that division of work really can be advantageous
and that not all git users want to be or can be developers at all
times.
Cheers,
Ralf
^ permalink raw reply
* [PATCH 5/5] Avoid "test -o" and "test -a" which are not POSIX, only XSI.
From: Ralf Wildenhues @ 2007-11-06 20:20 UTC (permalink / raw)
To: git
In-Reply-To: <20071106201518.GA6361@ins.uni-bonn.de>
---
git-clone.sh | 2 +-
git-commit.sh | 4 ++--
git-merge-stupid.sh | 2 +-
git-merge.sh | 4 ++--
git-mergetool.sh | 2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 3f00693..1ae137a 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -462,7 +462,7 @@ then
case "$no_checkout" in
'')
- test "z$quiet" = z -a "z$no_progress" = z && v=-v || v=
+ test "z$quiet" = z && test "z$no_progress" = z && v=-v || v=
git read-tree -m -u $v HEAD HEAD
esac
fi
diff --git a/git-commit.sh b/git-commit.sh
index fcb8443..78fe518 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -50,7 +50,7 @@ run_status () {
export GIT_INDEX_FILE
fi
- if test "$status_only" = "t" -o "$use_status_color" = "t"; then
+ if test "$status_only" = "t" || test "$use_status_color" = "t"; then
color=
else
color=--nocolor
@@ -290,7 +290,7 @@ t,,[1-9]*)
die "No paths with -i does not make sense." ;;
esac
-if test ! -z "$templatefile" -a -z "$log_given"
+if test ! -z "$templatefile" && test -z "$log_given"
then
if test ! -f "$templatefile"
then
diff --git a/git-merge-stupid.sh b/git-merge-stupid.sh
index f612d47..95adbb3 100755
--- a/git-merge-stupid.sh
+++ b/git-merge-stupid.sh
@@ -44,7 +44,7 @@ case "$bases" in
2>/dev/null || continue
# Count the paths that are unmerged.
cnt=`GIT_INDEX_FILE=$G git ls-files --unmerged | wc -l`
- if test $best_cnt -le 0 -o $cnt -le $best_cnt
+ if test $best_cnt -le 0 || test $cnt -le $best_cnt
then
best=$c
best_cnt=$cnt
diff --git a/git-merge.sh b/git-merge.sh
index c2092a2..b6a35d4 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -124,7 +124,7 @@ merge_name () {
git show-ref -q --verify "refs/heads/$truname" 2>/dev/null
then
echo "$rh branch '$truname' (early part) of ."
- elif test "$remote" = "FETCH_HEAD" -a -r "$GIT_DIR/FETCH_HEAD"
+ elif test "$remote" = "FETCH_HEAD" && test -r "$GIT_DIR/FETCH_HEAD"
then
sed -e 's/ not-for-merge / /' -e 1q \
"$GIT_DIR/FETCH_HEAD"
@@ -478,7 +478,7 @@ do
git diff-files --name-only
git ls-files --unmerged
} | wc -l`
- if test $best_cnt -le 0 -o $cnt -le $best_cnt
+ if test $best_cnt -le 0 || test $cnt -le $best_cnt
then
best_strategy=$strategy
best_cnt=$cnt
diff --git a/git-mergetool.sh b/git-mergetool.sh
index a68b403..9f7386b 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -167,7 +167,7 @@ merge_file () {
local_present && git cat-file blob ":2:$prefix$path" >"$LOCAL" 2>/dev/null
remote_present && git cat-file blob ":3:$prefix$path" >"$REMOTE" 2>/dev/null
- if test -z "$local_mode" -o -z "$remote_mode"; then
+ if test -z "$local_mode" || test -z "$remote_mode"; then
echo "Deleted merge conflict for '$path':"
describe_file "$local_mode" "local" "$LOCAL"
describe_file "$remote_mode" "remote" "$REMOTE"
--
1.5.3.5.561.g140d
^ permalink raw reply related
* [PATCH 4/5] Fix sed string regex escaping in module_name.
From: Ralf Wildenhues @ 2007-11-06 20:20 UTC (permalink / raw)
To: git
In-Reply-To: <20071106201518.GA6361@ins.uni-bonn.de>
When escaping a string to be used as a sed regex, it is important
to only escape active characters. Escaping other characters is
undefined according to POSIX, and may lead to problems with some
sed's extensions.
---
With this one, I'm not sure whether it is necessary, simply because I
don't know what kinds of characters can be part of a submodule path.
It anyway should be safe though.
git-submodule.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 4aaaaab..5af28ec 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -73,7 +73,7 @@ resolve_relative_url ()
module_name()
{
# Do we have "submodule.<something>.path = $1" defined in .gitmodules file?
- re=$(printf '%s' "$1" | sed -e 's/\([^a-zA-Z0-9_]\)/\\\1/g')
+ re=$(printf '%s' "$1" | sed -e 's/[].[^$\\*]/\\&/g')
name=$( GIT_CONFIG=.gitmodules \
git config --get-regexp '^submodule\..*\.path$' |
sed -n -e 's|^submodule\.\(.*\)\.path '"$re"'$|\1|p' )
--
1.5.3.5.561.g140d
^ permalink raw reply related
* Re: [PATCH 3/5] Replace $((...)) with expr invocations.
From: Ralf Wildenhues @ 2007-11-06 20:18 UTC (permalink / raw)
To: git
In-Reply-To: <20071106201518.GA6361@ins.uni-bonn.de>
---
git-filter-branch.sh | 4 ++--
git-rebase--interactive.sh | 8 ++++----
git-rebase.sh | 8 ++++----
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index ffcc408..2d5c247 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -253,7 +253,7 @@ test $commits -eq 0 && die "Found nothing to rewrite"
i=0
while read commit parents; do
- i=$(($i+1))
+ i=$(expr $i + 1)
printf "\rRewrite $commit ($i/$commits)"
case "$filter_subdir" in
@@ -374,7 +374,7 @@ do
;;
esac
git update-ref -m "filter-branch: backup" "$orig_namespace$ref" $sha1
- count=$(($count+1))
+ count=$(expr $count + 1)
done < "$tempdir"/heads
# TODO: This should possibly go, with the semantics that all positive given
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index ecc6778..da48aaf 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -71,8 +71,8 @@ mark_action_done () {
sed -e 1q < "$TODO" >> "$DONE"
sed -e 1d < "$TODO" >> "$TODO".new
mv -f "$TODO".new "$TODO"
- count=$(($(grep -ve '^$' -e '^#' < "$DONE" | wc -l)))
- total=$(($count+$(grep -ve '^$' -e '^#' < "$TODO" | wc -l)))
+ count=$(grep -ve '^$' -e '^#' < "$DONE" | wc -l)
+ total=$(expr $count + $(grep -ve '^$' -e '^#' < "$TODO" | wc -l))
printf "Rebasing (%d/%d)\r" $count $total
test -z "$VERBOSE" || echo
}
@@ -205,8 +205,8 @@ nth_string () {
make_squash_message () {
if test -f "$SQUASH_MSG"; then
- COUNT=$(($(sed -n "s/^# This is [^0-9]*\([1-9][0-9]*\).*/\1/p" \
- < "$SQUASH_MSG" | tail -n 1)+1))
+ COUNT=$(expr $(sed -n "s/^# This is [^0-9]*\([1-9][0-9]*\).*/\1/p" \
+ < "$SQUASH_MSG" | tail -n 1) + 1)
echo "# This is a combination of $COUNT commits."
sed -n "2,\$p" < "$SQUASH_MSG"
else
diff --git a/git-rebase.sh b/git-rebase.sh
index 224cca9..daa347a 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -79,7 +79,7 @@ continue_merge () {
echo "$prev_head" > "$dotest/prev_head"
# onto the next patch:
- msgnum=$(($msgnum + 1))
+ msgnum=$(expr $msgnum + 1)
echo "$msgnum" >"$dotest/msgnum"
}
@@ -90,7 +90,7 @@ call_merge () {
cmt_name=$(git symbolic-ref HEAD)
msgnum=$(cat "$dotest/msgnum")
end=$(cat "$dotest/end")
- eval GITHEAD_$cmt='"${cmt_name##refs/heads/}~$(($end - $msgnum))"'
+ eval GITHEAD_$cmt='"${cmt_name##refs/heads/}~$(expr $end - $msgnum)"'
eval GITHEAD_$hd='$(cat "$dotest/onto_name")'
export GITHEAD_$cmt GITHEAD_$hd
git-merge-$strategy "$cmt^" -- "$hd" "$cmt"
@@ -163,7 +163,7 @@ do
prev_head=$(cat "$dotest/prev_head")
end=$(cat "$dotest/end")
msgnum=$(cat "$dotest/msgnum")
- msgnum=$(($msgnum + 1))
+ msgnum=$(expr $msgnum + 1)
onto=$(cat "$dotest/onto")
while test "$msgnum" -le "$end"
do
@@ -349,7 +349,7 @@ echo "$prev_head" > "$dotest/prev_head"
msgnum=0
for cmt in `git rev-list --reverse --no-merges "$upstream"..ORIG_HEAD`
do
- msgnum=$(($msgnum + 1))
+ msgnum=$(expr $msgnum + 1)
echo "$cmt" > "$dotest/cmt.$msgnum"
done
--
1.5.3.5.561.g140d
^ permalink raw reply related
* [PATCH 2/5] Fix sed script to work with AIX sed.
From: Ralf Wildenhues @ 2007-11-06 20:17 UTC (permalink / raw)
To: git
In-Reply-To: <20071106201518.GA6361@ins.uni-bonn.de>
\n is not portable in a s/// replacement string, only
in the regex part. backslash-newline helps.
---
git-bisect.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index b74f44d..1ed44e5 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -275,7 +275,8 @@ exit_if_skipped_commits () {
if expr "$_tried" : ".*[|].*" > /dev/null ; then
echo "There are only 'skip'ped commit left to test."
echo "The first bad commit could be any of:"
- echo "$_tried" | sed -e 's/[|]/\n/g'
+ echo "$_tried" | sed -e 's/[|]/\
+/g'
echo "We cannot bisect more!"
exit 2
fi
--
1.5.3.5.561.g140d
^ permalink raw reply related
* [PATCH 1/5] Avoid a few unportable, needlessly nested "...`...".
From: Ralf Wildenhues @ 2007-11-06 20:17 UTC (permalink / raw)
To: git
In-Reply-To: <20071106201518.GA6361@ins.uni-bonn.de>
Some shells wrongly interpret double-quote backquote double-quote
nesting. OTOH, the right hand side of an assignment is never split
in words, so the outer double quotes are needless there.
---
git-rebase--interactive.sh | 2 +-
git-request-pull.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 76dc679..ecc6778 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -391,7 +391,7 @@ do
-s|--strategy)
case "$#,$1" in
*,*=*)
- STRATEGY="-s `expr "z$1" : 'z-[^=]*=\(.*\)'`" ;;
+ STRATEGY="-s "`expr "z$1" : 'z-[^=]*=\(.*\)'` ;;
1,*)
usage ;;
*)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index a992430..ec367d7 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -24,7 +24,7 @@ headrev=`git rev-parse --verify "$head"^0` || exit
merge_base=`git merge-base $baserev $headrev` ||
die "fatal: No commits in common between $base and $head"
-url="`get_remote_url "$url"`"
+url=`get_remote_url "$url"`
branch=`git peek-remote "$url" \
| sed -n -e "/^$headrev refs.heads./{
s/^.* refs.heads.//
--
1.5.3.5.561.g140d
^ permalink raw reply related
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Mike Hommey @ 2007-11-06 20:13 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Johannes Schindelin, Junio C Hamano, Steven Grimm,
Pierre Habouzit, git
In-Reply-To: <200711062106.57083.robin.rosenberg.lists@dewire.com>
On Tue, Nov 06, 2007 at 09:06:56PM +0100, Robin Rosenberg wrote:
> tisdag 06 november 2007 skrev Johannes Schindelin:
> > Hi,
> >
> > On Mon, 5 Nov 2007, Junio C Hamano wrote:
> >
> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > >
> > > > On Mon, 5 Nov 2007, Junio C Hamano wrote:
> > > >
> > > >> Allowing people to revert or cherry pick partially by using paths
> > > >> limiter is a very good idea; the whole "it comes from a commit so we
> > > >> also commit" feels an utter nonsense, though.
> > > >
> > > > No.
> > > >
> > > > When "git revert <commit>" commits the result, "git revert <commit> --
> > > > <file>" should, too.
> > >
> > > I was not questioning about that part. "If 'git revert <some
> > > other form> foo' does not talk about commit, it should not
> > > commit" was what I was referring to.
> >
> > Well, I think that _if_ we allow "git revert <path>" to mean "revert the
> > changes to <path>, relative to the index" (which would be the same as "git
> > checkout <path>"), then committing that change just does not make sense.
> >
> > And it is this behaviour that people are seeking, not "git revert <commit>
> > <path>".
>
> I'm not convince making every command perform enitrely all kinds of actions
> just because other SCMs interpret a name differently. git revert today
> creates a *new* commit. Keep it simple. I think its ok that it mentions
> another comnand when it detects arguments that does not make sense. There is
> no right or wrong with interepreting reset either way, but not both ways
> please. The confusion with checkout and reset is enough.
Maybe the documentation could emphasise on how to undo things when the
user makes mistakes.
Sometimes, saving your repo can be as simple as git reset --hard HEAD@{1}.
This is not, unfortunately, a works-for-all-cases command.
Mike
^ permalink raw reply
* [PATCH 0/5] some shell portability fixes
From: Ralf Wildenhues @ 2007-11-06 20:15 UTC (permalink / raw)
To: git
Here's a bunch of rather trivial patches against master to fix
portability issues, mostly shell ones. FWIW I did not test the
patches other than ensuring the set of testsuite errors remains
the same, and that I only did on one system.
All of the issues are ones that are encountered on some real
system, most are documented either in POSIX or in the shell
portability section of the Autoconf manual.
Cheers,
Ralf
^ permalink raw reply
* [PATCH] Fix minor nits in configure.ac
From: Ralf Wildenhues @ 2007-11-06 20:12 UTC (permalink / raw)
To: git
Avoid "test -o" as it is only XSI not POSIX, and not portable.
Avoid exit(3) in test programs in favor of return, to accommodate
for newer Autoconf not providing a declaration for exit.
---
The missing declaration can cause needlessly wrong configure results
with some CFLAGS.
Cheers,
Ralf
configure.ac | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index ed7cc89..bd80517 100644
--- a/configure.ac
+++ b/configure.ac
@@ -73,7 +73,7 @@ fi \
AC_ARG_WITH([lib],
[AS_HELP_STRING([--with-lib=ARG],
[ARG specifies alternative name for lib directory])],
- [if test "$withval" = "no" -o "$withval" = "yes"; then \
+ [if test "$withval" = "no" || test "$withval" = "yes"; then \
AC_MSG_WARN([You should provide name for --with-lib=ARG]); \
else \
GIT_CONF_APPEND_LINE(lib=$withval); \
@@ -245,9 +245,9 @@ AC_RUN_IFELSE(
[AC_LANG_PROGRAM([AC_INCLUDES_DEFAULT],
[[char buf[64];
if (sprintf(buf, "%lld%hhd%jd%zd%td", (long long int)1, (char)2, (intmax_t)3, (size_t)4, (ptrdiff_t)5) != 5)
- exit(1);
+ return 1;
else if (strcmp(buf, "12345"))
- exit(2);]])],
+ return 2;]])],
[ac_cv_c_c99_format=yes],
[ac_cv_c_c99_format=no])
])
--
1.5.3.5.561.g140d
^ permalink raw reply related
* quilt upsets some recipient sites..
From: Matti Aarnio @ 2007-11-06 20:12 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 129 bytes --]
In my opinnion "Cc:" isn't a field where multiple occurrances are
in itself a sign of spam, but there are a lot of such sites..
[-- Attachment #2: Type: message/rfc822, Size: 9916 bytes --]
[-- Attachment #2.1.1: Type: text/plain, Size: 4034 bytes --]
This is a collection of reports about email delivery
process concerning a message you originated.
Some explanations/translations for these reports
can be found at:
http://www.zmailer.org/delivery-report-decoding.html
Generic VGER note: Joining/leaving VGER's lists thru server:
majordomo@vger.kernel.org
Reporting-MTA: dns; vger.kernel.org
Return-Path: <linux-kernel-owner@vger.kernel.org>
Arrival-Date: Tue, 6 Nov 2007 14:58:34 -0500
Local-Spool-ID: S1755552AbXKFT6e
FAILED:
Original Recipient:
rfc822;afds@cs.tu-berlin.de
Final Recipient:
RFC822;afds@cs.tu-berlin.de
Status:
5.6.0
Remote MTA:
dns; cartero.cs.tu-berlin.de (130.149.17.20|25|209.132.176.167|33024)
Last Attempt Date:
Tue, 6 Nov 2007 14:59:06 -0500
X-ZTAID:
smtp[31080]
Diagnostic Code:
smtp; 554 (Reject, id=18169-17 - BAD_HEADER: Header field occurs more than once: "Cc" occurs 5 times)
Control data:
smtp cs.tu-berlin.de afds@cs.tu-berlin.de 99
Diagnostic texts:
<<- MAIL From:<linux-kernel-owner+afds=40cs.tu-berlin.de-S1755552AbXKFT6e@vger.kernel.org> BODY=8BITMIME SIZE=4115
->> 250 2.1.0 Ok
<<- RCPT To:<afds@cs.tu-berlin.de>
->> 250 2.1.5 Ok
<<- DATA
->> 354 End data with <CR><LF>.<CR><LF>
<<- .
->> 554 5.6.0 Reject, id=18169-17 - BAD_HEADER: Header field occurs more than once: "Cc" occurs 5 times
Following is a copy of MESSAGE/DELIVERY-STATUS format section below.
It is copied here in case your email client is unable to show it to you.
The information here below is in Internet Standard format designed to
assist automatic, and accurate presentation and usage of said information.
In case you need human assistance from the Postmaster(s) of the system which
sent you this report, please include this information in your question!
Virtually Yours,
Automatic Email Delivery Software
Reporting-MTA: dns; vger.kernel.org
Arrival-Date: Tue, 6 Nov 2007 14:58:34 -0500
Local-Spool-ID: S1755552AbXKFT6e
Original-Recipient: rfc822;afds@cs.tu-berlin.de
Final-Recipient: RFC822;afds@cs.tu-berlin.de
Action: failed
Status: 5.6.0
Remote-MTA: dns; cartero.cs.tu-berlin.de (130.149.17.20|25|209.132.176.167|33024)
Last-Attempt-Date: Tue, 6 Nov 2007 14:59:06 -0500
Diagnostic-Code: smtp; 554 (Reject, id=18169-17 - BAD_HEADER: Header field occurs more than once: "Cc" occurs 5 times)
Following is copy of the message headers. Original message content may
be in subsequent parts of this MESSAGE/DELIVERY-STATUS structure.
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S1755552AbXKFT6e; Tue, 6 Nov 2007 14:58:34 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757493AbXKFTwa
(ORCPT <rfc822;linux-kernel-outgoing>);
Tue, 6 Nov 2007 14:52:30 -0500
Received: from netops-testserver-3-out.sgi.com ([192.48.171.28]:45386 "EHLO
relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org
with ESMTP id S1754321AbXKFTwE (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Tue, 6 Nov 2007 14:52:04 -0500
Received: from schroedinger.engr.sgi.com (schroedinger.engr.sgi.com [150.166.1.51])
by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id 20E6D908B3;
Tue, 6 Nov 2007 11:52:04 -0800 (PST)
Received: from clameter by schroedinger.engr.sgi.com with local (Exim 3.36 #1 (Debian))
id 1IpUSx-0008Jf-00; Tue, 06 Nov 2007 11:52:04 -0800
Message-Id: <20071106195203.825244760@sgi.com>
References: <20071106195144.983665861@sgi.com>
User-Agent: quilt/0.46-1
Date: Tue, 06 Nov 2007 11:52:11 -0800
From: Christoph Lameter <clameter@sgi.com>
To: akpm@linux-foundation.org
Cc: linux-mm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: David Miller <davem@davemloft.net>
Cc: Eric Dumazet <dada1@cosmosbay.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: [patch 27/28] cpu alloc: Use in the crypto subsystem.
Content-Disposition: inline; filename=cpu_alloc_crypto
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
[-- Attachment #2.1.2: Type: message/delivery-status, Size: 488 bytes --]
[-- Attachment #2.1.3: Type: message/rfc822, Size: 3994 bytes --]
From: Christoph Lameter <clameter@sgi.com>
To: akpm@linux-foundation.org
Cc: linux-mm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: David Miller <davem@davemloft.net>
Cc: Eric Dumazet <dada1@cosmosbay.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: [patch 27/28] cpu alloc: Use in the crypto subsystem.
Date: Tue, 06 Nov 2007 11:52:11 -0800
Message-ID: <20071106195203.825244760@sgi.com>
[-- Attachment #2.1.3.1: cpu_alloc_crypto --]
[-- Type: text/plain, Size: 2489 bytes --]
From: Christoph Lameter <clameter@sgi.com>
To: akpm@linux-foundation.org
Cc: linux-mm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: David Miller <davem@davemloft.net>
Cc: Eric Dumazet <dada1@cosmosbay.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: [patch 27/28] cpu alloc: Use in the crypto subsystem.
Date: Tue, 06 Nov 2007 11:52:11 -0800
Message-ID: <20071106195203.825244760@sgi.com>
Signed-off-by: Christoph Lameter <clameter@sgi.com>
---
crypto/async_tx/async_tx.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
Index: linux-2.6/crypto/async_tx/async_tx.c
===================================================================
--- linux-2.6.orig/crypto/async_tx/async_tx.c 2007-11-05 09:46:04.000000000 -0800
+++ linux-2.6/crypto/async_tx/async_tx.c 2007-11-05 09:49:56.000000000 -0800
@@ -207,10 +207,10 @@ static void async_tx_rebalance(void)
for_each_dma_cap_mask(cap, dma_cap_mask_all)
for_each_possible_cpu(cpu) {
struct dma_chan_ref *ref =
- per_cpu_ptr(channel_table[cap], cpu)->ref;
+ CPU_PTR(channel_table[cap], cpu)->ref;
if (ref) {
atomic_set(&ref->count, 0);
- per_cpu_ptr(channel_table[cap], cpu)->ref =
+ CPU_PTR(channel_table[cap], cpu)->ref =
NULL;
}
}
@@ -223,7 +223,7 @@ static void async_tx_rebalance(void)
else
new = get_chan_ref_by_cap(cap, -1);
- per_cpu_ptr(channel_table[cap], cpu)->ref = new;
+ CPU_PTR(channel_table[cap], cpu)->ref = new;
}
spin_unlock_irqrestore(&async_tx_lock, flags);
@@ -327,7 +327,8 @@ async_tx_init(void)
clear_bit(DMA_INTERRUPT, dma_cap_mask_all.bits);
for_each_dma_cap_mask(cap, dma_cap_mask_all) {
- channel_table[cap] = alloc_percpu(struct chan_ref_percpu);
+ channel_table[cap] = CPU_ALLOC(struct chan_ref_percpu,
+ GFP_KERNEL | __GFP_ZERO);
if (!channel_table[cap])
goto err;
}
@@ -343,7 +344,7 @@ err:
printk(KERN_ERR "async_tx: initialization failure\n");
while (--cap >= 0)
- free_percpu(channel_table[cap]);
+ CPU_FRE(channel_table[cap]);
return 1;
}
@@ -356,7 +357,7 @@ static void __exit async_tx_exit(void)
for_each_dma_cap_mask(cap, dma_cap_mask_all)
if (channel_table[cap])
- free_percpu(channel_table[cap]);
+ CPU_FREE(channel_table[cap]);
dma_async_client_unregister(&async_tx_dma);
}
@@ -378,7 +379,7 @@ async_tx_find_channel(struct dma_async_t
else if (likely(channel_table_initialized)) {
struct dma_chan_ref *ref;
int cpu = get_cpu();
- ref = per_cpu_ptr(channel_table[tx_type], cpu)->ref;
+ ref = CPU_PTR(channel_table[tx_type], cpu)->ref;
put_cpu();
return ref ? ref->chan : NULL;
} else
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Robin Rosenberg @ 2007-11-06 20:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Steven Grimm, Pierre Habouzit, git
In-Reply-To: <Pine.LNX.4.64.0711061230540.4362@racer.site>
tisdag 06 november 2007 skrev Johannes Schindelin:
> Hi,
>
> On Mon, 5 Nov 2007, Junio C Hamano wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > On Mon, 5 Nov 2007, Junio C Hamano wrote:
> > >
> > >> Allowing people to revert or cherry pick partially by using paths
> > >> limiter is a very good idea; the whole "it comes from a commit so we
> > >> also commit" feels an utter nonsense, though.
> > >
> > > No.
> > >
> > > When "git revert <commit>" commits the result, "git revert <commit> --
> > > <file>" should, too.
> >
> > I was not questioning about that part. "If 'git revert <some
> > other form> foo' does not talk about commit, it should not
> > commit" was what I was referring to.
>
> Well, I think that _if_ we allow "git revert <path>" to mean "revert the
> changes to <path>, relative to the index" (which would be the same as "git
> checkout <path>"), then committing that change just does not make sense.
>
> And it is this behaviour that people are seeking, not "git revert <commit>
> <path>".
I'm not convince making every command perform enitrely all kinds of actions
just because other SCMs interpret a name differently. git revert today
creates a *new* commit. Keep it simple. I think its ok that it mentions
another comnand when it detects arguments that does not make sense. There is
no right or wrong with interepreting reset either way, but not both ways
please. The confusion with checkout and reset is enough.
-- robin
^ permalink raw reply
* Re: [PATCH 04/10] Migrate git-clone to use git-rev-parse --parseopt
From: Nicolas Pitre @ 2007-11-06 19:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, git
In-Reply-To: <7vr6j3gof2.fsf@gitster.siamese.dyndns.org>
On Tue, 6 Nov 2007, Junio C Hamano wrote:
> Gaah.
>
> I'd blame Linus for suggesting to make parseopt part of
> rev-parse, the latter of which makes sense only inside git while
> the former of which makes sense outside git.
>
> Would something like this help?
>
> ---
> builtin-rev-parse.c | 4 ++--
> git.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
That does help indeed.
Nicolas
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Junio C Hamano @ 2007-11-06 19:42 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Johannes Schindelin, Steven Grimm, git
In-Reply-To: <20071106193959.GB4382@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> On Tue, Nov 06, 2007 at 06:27:54PM +0000, Johannes Schindelin wrote:
>> Hi,
>>
>> On Tue, 6 Nov 2007, Junio C Hamano wrote:
>>
>> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> >
>> > > Well, I think that _if_ we allow "git revert <path>" to mean "revert the
>> > > changes to <path>, relative to the index" (which would be the same as "git
>> > > checkout <path>"), then committing that change just does not make sense.
>> > >
>> > > And it is this behaviour that people are seeking, not "git revert <commit>
>> > > <path>".
>> >
>> > Heh, I found this in the recent log somewhere.
>> >
>> > <gitte> Really, I wonder how difficult git is for people who are not
>> > brainwashed by cvs/svn, and unfortunately enough, partly by bzr and hg.
>> > <gitte> From a user perspective, you might be correct. But then we have to
>> > add 1000 commands to reflect the English language.
>> > <gitte> Not what I want. [06:46]
>> >
>> > I am wondering who said it ;-).
>>
>> Now, that is not fair, using my own words against me ;-)
>
> That's very funny actually :]
Yeah, it was doubly funny after I saw you posted a list of "$scm revert"
and Dscho still sided with you in that thread.
^ permalink raw reply
* Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out.
From: Pierre Habouzit @ 2007-11-06 19:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Steven Grimm, git
In-Reply-To: <Pine.LNX.4.64.0711061827030.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]
On Tue, Nov 06, 2007 at 06:27:54PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 6 Nov 2007, Junio C Hamano wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > Well, I think that _if_ we allow "git revert <path>" to mean "revert the
> > > changes to <path>, relative to the index" (which would be the same as "git
> > > checkout <path>"), then committing that change just does not make sense.
> > >
> > > And it is this behaviour that people are seeking, not "git revert <commit>
> > > <path>".
> >
> > Heh, I found this in the recent log somewhere.
> >
> > <gitte> Really, I wonder how difficult git is for people who are not
> > brainwashed by cvs/svn, and unfortunately enough, partly by bzr and hg.
> > <gitte> From a user perspective, you might be correct. But then we have to
> > add 1000 commands to reflect the English language.
> > <gitte> Not what I want. [06:46]
> >
> > I am wondering who said it ;-).
>
> Now, that is not fair, using my own words against me ;-)
That's very funny actually :]
--
·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 04/10] Migrate git-clone to use git-rev-parse --parseopt
From: Junio C Hamano @ 2007-11-06 19:39 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Pierre Habouzit, git
In-Reply-To: <alpine.LFD.0.9999.0711061355330.21255@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Sun, 4 Nov 2007, Pierre Habouzit wrote:
>
>> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
>> ---
>> git-clone.sh | 102 +++++++++++++++++++++++++++++++++-------------------------
>> 1 files changed, 58 insertions(+), 44 deletions(-)
>
> Well, this patch was merged in "next" and broke git-clone rather badly.
>
> Just try something as fundamental as this:
>
> $ git clone git://git.kernel.org/pub/scm/git/git.git
> fatal: Not a git repository
>
> Don't we have test cases covering this really basic operation?
We do, but RUN_SETUP will happily go up to find the .git/ next
to t/ directory that is the parent of trash/ directory, in which
the tests run, without reporting errors. As parseopt does not
depend on anything in git, this will not do any harm other than
falsely succeeding the test that should not pass.
We could probably introduce an environment variable, GIT_CEILING,
that tells the setup_git_directory_gentry() never go up beyond
that point, and set it to the t/trash directory while running
the test.
Something like that may have other uses in practice. Often
people wonder what would happen if there is /.git repository and
they would want to make sure they would not accidentally add to
the repository controlled by /.git when they have bunch of other
repositories /some/where/.git in which they usually work.
^ permalink raw reply
* Re: [bug in next ?] git-fetch/git-push issue
From: Pierre Habouzit @ 2007-11-06 19:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Daniel Barkalow, Git ML
In-Reply-To: <7vwssvgrm6.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]
On Tue, Nov 06, 2007 at 06:23:45PM +0000, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Tue, Nov 06, 2007 at 06:56:27PM +0100, Pierre Habouzit wrote:
> >
> >> On the same vein, with today's next:
> >>
> >> $ git push origin :teaser
> >> To ssh://git.corp/srv/git/mmsx.git
> >> - [deleting] teaser
> >> refs/heads/teaser: 05518bc7df1af680447f58b034b108f66668db03 -> deleted
> >> Everything up-to-date
> >> fatal: Invalid revision range 05518bc7df1af680447f58b034b108f66668db03..0000000000000000000000000000000000000000
> >> fatal: ambiguous argument 'refs/heads/teaser': unknown revision or path not in the working tree.
> >> Use '--' to separate paths from revisions
>
> Isn't this coming from a loosely written post-receive hook that
> wants to send mail or something and forgets that a ref could be
> removed?
oooh you may be right indeed. it's probably it, I was too quick in
assuming this was a new issue with git push, I never removed a branch on
that remote yet, and it indeed has a post-receive hook.
thanks and sorry for the noise.
--
·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 04/10] Migrate git-clone to use git-rev-parse --parseopt
From: Junio C Hamano @ 2007-11-06 19:32 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Pierre Habouzit, git
In-Reply-To: <alpine.LFD.0.9999.0711061355330.21255@xanadu.home>
Gaah.
I'd blame Linus for suggesting to make parseopt part of
rev-parse, the latter of which makes sense only inside git while
the former of which makes sense outside git.
Would something like this help?
---
builtin-rev-parse.c | 4 ++--
git.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
index 054519b..d1038a0 100644
--- a/builtin-rev-parse.c
+++ b/builtin-rev-parse.c
@@ -337,11 +337,11 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
int i, as_is = 0, verify = 0;
unsigned char sha1[20];
- git_config(git_default_config);
-
if (argc > 1 && !strcmp("--parseopt", argv[1]))
return cmd_parseopt(argc - 1, argv + 1, prefix);
+ prefix = setup_git_directory();
+ git_config(git_default_config);
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
diff --git a/git.c b/git.c
index 6c5f9af..204a6f7 100644
--- a/git.c
+++ b/git.c
@@ -340,7 +340,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "rerere", cmd_rerere, RUN_SETUP },
{ "reset", cmd_reset, RUN_SETUP },
{ "rev-list", cmd_rev_list, RUN_SETUP },
- { "rev-parse", cmd_rev_parse, RUN_SETUP },
+ { "rev-parse", cmd_rev_parse },
{ "revert", cmd_revert, RUN_SETUP | NEED_WORK_TREE },
{ "rm", cmd_rm, RUN_SETUP },
{ "runstatus", cmd_runstatus, RUN_SETUP | NEED_WORK_TREE },
^ permalink raw reply related
* Re: Git-windows and git-svn?
From: Robin Rosenberg @ 2007-11-06 19:27 UTC (permalink / raw)
To: Pascal Obry
Cc: Peter Karlsson, Steffen Prohaska, Abdelrazak Younes,
Git Mailing List
In-Reply-To: <4730A9C3.1090006@obry.net>
tisdag 06 november 2007 skrev Pascal Obry:
> Peter Karlsson a écrit :
> > I got errors almost right away when trying that (I need text mode to
> > interface with some other programs), so Cygwin-git is a no-go for me at
>
> Won't it be possible for you to have a specific mount point using
> textmode and one with binmode ? This should allow you to have the best
> of both world. Note that I've never done that so I don't know if it is
> working fine.
I do that. It works fine. I've set up such paths so I have /cygdrive/c for textmode and
/binmode/c for binary mode and some other extra binary paths for convenience.
-- robin
^ 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