* Re: [OT] Re: C++ *for Git*
From: Robin Rosenberg @ 2007-09-23 23:10 UTC (permalink / raw)
To: David Kastrup
Cc: Dmitry Potapov, Linus Torvalds, Marco Costalba, Pierre Habouzit,
Frank Lichtenheld, Alex Unleashed, Kyle Rose, Miles Bader,
Dmitry Kakurin, Git
In-Reply-To: <85ejgpkr13.fsf@lola.goethe.zz>
söndag 23 september 2007 skrev David Kastrup:
> Dmitry Potapov <dpotapov@nbs-eng.ru> writes:
>
> > On Sun, Sep 23, 2007 at 09:54:10AM -0700, Linus Torvalds wrote:
> >
> >> - the stuff C++ *does* have is usually nasty. Implicit
> >> initializers and destructors and the magic lifetime rules of
> >> objects etc
> >
> > I am not sure what is wrong with initializers and destructors in
> > C++, but certainly there is no magic lifetime rules in C++, as it is
> > fully determined by the scope.
>
> It has been some time since I last looked, but the lifetime of objects
> constructed in return statements was a moving target through several
> standards. The last standard I bothered looking at had the object
> survive until the statement with the function call expression ended:
> quite a strange synchronization point with regard to language design.
The idea is that you should be able to use temporaries by reference and
trust them to be valid over function calls end even function returns, so
you can write efficient matrix math libraries that do not copy data much while
retaining value semantics with overloaded operators. It is a purely practical
matter, what actually works and is efficient, not dogmatic language "design".
Earlier versions failed to make up something useful here.
> > In fact, other high level languages that use GC have much more
> > unpredictable lifetime rules for objects.
>
> Mostly objects are alive as long as you can refer to them. Not really
> complicated.
What could be simpler, besides all static variables.
-- robin
^ permalink raw reply
* [PATCH 4/6] git-merge: add support for branch.<name>.mergeoptions
From: Lars Hjemli @ 2007-09-23 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1190587905-700-4-git-send-email-hjemli@gmail.com>
This enables per branch configuration of merge options. Currently, the most
useful options to specify per branch are --squash, --summary/--no-summary
and possibly --strategy, but all options are supported.
Note: Options containing whitespace will _not_ be handled correctly. Luckily,
the only option which can include whitespace is --message and it doesn't
make much sense to give that option a default value.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Documentation/config.txt | 6 ++++
Documentation/git-merge.txt | 4 +++
git-merge.sh | 21 ++++++++++++++++
t/t7600-merge.sh | 54 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 015910f..d3c25f3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -337,6 +337,12 @@ branch.<name>.merge::
branch.<name>.merge to the desired branch, and use the special setting
`.` (a period) for branch.<name>.remote.
+branch.<name>.mergeoptions::
+ Sets default options for merging into branch <name>. The syntax and
+ supported options are equal to that of gitlink:git-merge[1], but
+ option values containing whitespace characters are currently not
+ supported.
+
clean.requireForce::
A boolean to make git-clean do nothing unless given -f or -n. Defaults
to false.
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 144bc16..b1771a1 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -58,6 +58,10 @@ merge.verbosity::
above outputs debugging information. The default is level 2.
Can be overriden by 'GIT_MERGE_VERBOSITY' environment variable.
+branch.<name>.mergeoptions::
+ Sets default options for merging into branch <name>. The syntax and
+ supported options are equal to that of git-merge, but option values
+ containing whitespace characters are currently not supported.
HOW MERGE WORKS
---------------
diff --git a/git-merge.sh b/git-merge.sh
index 68b3503..e95d4a7 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -168,9 +168,30 @@ parse_option () {
args_left="$#"
}
+parse_config () {
+ while test $# -gt 0
+ do
+ parse_option "$@" || usage
+ while test $args_left -lt $#
+ do
+ shift
+ done
+ done
+}
+
case "$#" in 0) usage ;; esac
have_message=
+
+if branch=$(git-symbolic-ref -q HEAD)
+then
+ mergeopts=$(git config "branch.${branch#refs/heads/}.mergeoptions")
+ if test -n "$mergeopts"
+ then
+ parse_config $mergeopts
+ fi
+fi
+
while parse_option "$@"
do
while test $args_left -lt $#
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index dec6ea2..110974c 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -341,4 +341,58 @@ test_expect_success 'merge c1 with c2 and c3 (squash)' '
test_debug 'gitk --all'
+test_expect_success 'merge c1 with c2 (no-commit in config)' '
+ git reset --hard c1 &&
+ git config branch.master.mergeoptions "--no-commit" &&
+ git merge c2 &&
+ verify_merge file result.1-5 &&
+ verify_head $c1 &&
+ verify_mergeheads $c2
+'
+
+test_debug 'gitk --all'
+
+test_expect_success 'merge c1 with c2 (squash in config)' '
+ git reset --hard c1 &&
+ git config branch.master.mergeoptions "--squash" &&
+ git merge c2 &&
+ verify_merge file result.1-5 &&
+ verify_head $c1 &&
+ verify_no_mergehead &&
+ verify_diff squash.1-5 .git/SQUASH_MSG "[OOPS] bad squash message"
+'
+
+test_debug 'gitk --all'
+
+test_expect_success 'override config option -n' '
+ git reset --hard c1 &&
+ git config branch.master.mergeoptions "-n" &&
+ test_tick &&
+ git merge --summary c2 >diffstat.txt &&
+ verify_merge file result.1-5 msg.1-5 &&
+ verify_parents $c1 $c2 &&
+ if ! grep -e "^ file | \+2 +-$" diffstat.txt
+ then
+ echo "[OOPS] diffstat was not generated"
+ fi
+'
+
+test_debug 'gitk --all'
+
+test_expect_success 'override config option --summary' '
+ git reset --hard c1 &&
+ git config branch.master.mergeoptions "--summary" &&
+ test_tick &&
+ git merge -n c2 >diffstat.txt &&
+ verify_merge file result.1-5 msg.1-5 &&
+ verify_parents $c1 $c2 &&
+ if grep -e "^ file | \+2 +-$" diffstat.txt
+ then
+ echo "[OOPS] diffstat was generated"
+ false
+ fi
+'
+
+test_debug 'gitk --all'
+
test_done
--
1.5.3.2.82.g75c8d
^ permalink raw reply related
* [PATCH 0/6] per branch options for git-merge
From: Lars Hjemli @ 2007-09-23 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch-series implements support for per branch configuration of
git-merge, using entries (branch.<name>.mergeoptions) in .git/config.
Since this makes it possible to specify --no-commit and --squash as
default options for git-merge, the new options --commit and --no-squash
are added to enable users to override such defaults.
There is also a new option, --no-ff, which can be used to force git-merge
to create a merge commit even when the merge was a fast-forward (and a
matching --ff option to allow overrides).
Shortlog:
Add test-script for git-merge porcelain
git-merge: fix faulty SQUASH_MSG
git-merge: refactor option parsing
git-merge: add support for branch.<name>.mergeoptions
git-merge: add support for --commit and --no-squash
git-merge: add --ff and --no-ff options
Diffstat:
Documentation/config.txt | 6 +
Documentation/git-merge.txt | 4 +
Documentation/merge-options.txt | 17 ++
git-merge.sh | 65 +++++-
t/t7600-merge.sh | 440 +++++++++++++++++++++++++++++++++++++++
5 files changed, 521 insertions(+), 11 deletions(-)
^ permalink raw reply
* [PATCH 1/6] Add test-script for git-merge porcelain
From: Lars Hjemli @ 2007-09-23 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1190587905-700-1-git-send-email-hjemli@gmail.com>
This test-script excercises the porcelainish aspects of git-merge, and
does it thoroughly enough to detect a small bug already noticed by Junio:
squashing an octopus generates a faulty .git/SQUASH_MSG.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
t/t7600-merge.sh | 344 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 344 insertions(+), 0 deletions(-)
create mode 100755 t/t7600-merge.sh
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
new file mode 100755
index 0000000..dec6ea2
--- /dev/null
+++ b/t/t7600-merge.sh
@@ -0,0 +1,344 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Lars Hjemli
+#
+
+test_description='git-merge
+
+Testing basic merge operations/option parsing.'
+
+. ./test-lib.sh
+
+cat >file <<EOF
+1
+2
+3
+4
+5
+6
+7
+8
+9
+EOF
+
+cat >file.1 <<EOF
+1 X
+2
+3
+4
+5
+6
+7
+8
+9
+EOF
+
+cat >file.5 <<EOF
+1
+2
+3
+4
+5 X
+6
+7
+8
+9
+EOF
+
+cat >file.9 <<EOF
+1
+2
+3
+4
+5
+6
+7
+8
+9 X
+EOF
+
+cat >result.1 <<EOF
+1 X
+2
+3
+4
+5
+6
+7
+8
+9
+EOF
+
+cat >result.1-5 <<EOF
+1 X
+2
+3
+4
+5 X
+6
+7
+8
+9
+EOF
+
+cat >result.1-5-9 <<EOF
+1 X
+2
+3
+4
+5 X
+6
+7
+8
+9 X
+EOF
+
+create_merge_msgs() {
+ echo "Merge commit 'c2'" >msg.1-5 &&
+ echo "Merge commit 'c2'; commit 'c3'" >msg.1-5-9 &&
+ echo "Squashed commit of the following:" >squash.1 &&
+ echo >>squash.1 &&
+ git log --no-merges ^HEAD c1 >>squash.1 &&
+ echo "Squashed commit of the following:" >squash.1-5 &&
+ echo >>squash.1-5 &&
+ git log --no-merges ^HEAD c2 >>squash.1-5 &&
+ echo "Squashed commit of the following:" >squash.1-5-9 &&
+ echo >>squash.1-5-9 &&
+ git log --no-merges ^HEAD c2 c3 >>squash.1-5-9
+}
+
+verify_diff() {
+ if ! diff -u "$1" "$2"
+ then
+ echo "$3"
+ false
+ fi
+}
+
+verify_merge() {
+ verify_diff "$2" "$1" "[OOPS] bad merge result" &&
+ if test $(git ls-files -u | wc -l) -gt 0
+ then
+ echo "[OOPS] unmerged files"
+ false
+ fi &&
+ if ! git diff --exit-code
+ then
+ echo "[OOPS] working tree != index"
+ false
+ fi &&
+ if test -n "$3"
+ then
+ git show -s --pretty=format:%s HEAD >msg.act &&
+ verify_diff "$3" msg.act "[OOPS] bad merge message"
+ fi
+}
+
+verify_head() {
+ if test "$1" != "$(git rev-parse HEAD)"
+ then
+ echo "[OOPS] HEAD != $1"
+ false
+ fi
+}
+
+verify_parents() {
+ i=1
+ while test $# -gt 0
+ do
+ if test "$1" != "$(git rev-parse HEAD^$i)"
+ then
+ echo "[OOPS] HEAD^$i != $1"
+ return 1
+ fi
+ i=$(expr $i + 1)
+ shift
+ done
+}
+
+verify_mergeheads() {
+ i=1
+ if ! test -f .git/MERGE_HEAD
+ then
+ echo "[OOPS] MERGE_HEAD is missing"
+ false
+ fi &&
+ while test $# -gt 0
+ do
+ head=$(head -n $i .git/MERGE_HEAD | tail -n 1)
+ if test "$1" != "$head"
+ then
+ echo "[OOPS] MERGE_HEAD $i != $1"
+ return 1
+ fi
+ i=$(expr $i + 1)
+ shift
+ done
+}
+
+verify_no_mergehead() {
+ if test -f .git/MERGE_HEAD
+ then
+ echo "[OOPS] MERGE_HEAD exists"
+ false
+ fi
+}
+
+
+test_expect_success 'setup' '
+ git add file &&
+ test_tick &&
+ git commit -m "commit 0" &&
+ git tag c0 &&
+ c0=$(git rev-parse HEAD) &&
+ cp file.1 file &&
+ git add file &&
+ test_tick &&
+ git commit -m "commit 1" &&
+ git tag c1 &&
+ c1=$(git rev-parse HEAD) &&
+ git reset --hard "$c0" &&
+ cp file.5 file &&
+ git add file &&
+ test_tick &&
+ git commit -m "commit 2" &&
+ git tag c2 &&
+ c2=$(git rev-parse HEAD) &&
+ git reset --hard "$c0" &&
+ cp file.9 file &&
+ git add file &&
+ test_tick &&
+ git commit -m "commit 3" &&
+ git tag c3 &&
+ c3=$(git rev-parse HEAD)
+ git reset --hard "$c0" &&
+ create_merge_msgs
+'
+
+test_debug 'gitk --all'
+
+test_expect_success 'test option parsing' '
+ if git merge -$ c1
+ then
+ echo "[OOPS] -$ accepted"
+ false
+ fi &&
+ if git merge --no-such c1
+ then
+ echo "[OOPS] --no-such accepted"
+ false
+ fi &&
+ if git merge -s foobar c1
+ then
+ echo "[OOPS] -s foobar accepted"
+ false
+ fi &&
+ if git merge -s=foobar c1
+ then
+ echo "[OOPS] -s=foobar accepted"
+ false
+ fi &&
+ if git merge -m
+ then
+ echo "[OOPS] missing commit msg accepted"
+ false
+ fi &&
+ if git merge
+ then
+ echo "[OOPS] missing commit references accepted"
+ false
+ fi
+'
+
+test_expect_success 'merge c0 with c1' '
+ git reset --hard c0 &&
+ git merge c1 &&
+ verify_merge file result.1 &&
+ verify_head "$c1"
+'
+
+test_debug 'gitk --all'
+
+test_expect_success 'merge c1 with c2' '
+ git reset --hard c1 &&
+ test_tick &&
+ git merge c2 &&
+ verify_merge file result.1-5 msg.1-5 &&
+ verify_parents $c1 $c2
+'
+
+test_debug 'gitk --all'
+
+test_expect_success 'merge c1 with c2 and c3' '
+ git reset --hard c1 &&
+ test_tick &&
+ git merge c2 c3 &&
+ verify_merge file result.1-5-9 msg.1-5-9 &&
+ verify_parents $c1 $c2 $c3
+'
+
+test_debug 'gitk --all'
+
+test_expect_success 'merge c0 with c1 (no-commit)' '
+ git reset --hard c0 &&
+ git merge --no-commit c1 &&
+ verify_merge file result.1 &&
+ verify_head $c1
+'
+
+test_debug 'gitk --all'
+
+test_expect_success 'merge c1 with c2 (no-commit)' '
+ git reset --hard c1 &&
+ git merge --no-commit c2 &&
+ verify_merge file result.1-5 &&
+ verify_head $c1 &&
+ verify_mergeheads $c2
+'
+
+test_debug 'gitk --all'
+
+test_expect_success 'merge c1 with c2 and c3 (no-commit)' '
+ git reset --hard c1 &&
+ git merge --no-commit c2 c3 &&
+ verify_merge file result.1-5-9 &&
+ verify_head $c1 &&
+ verify_mergeheads $c2 $c3
+'
+
+test_debug 'gitk --all'
+
+test_expect_success 'merge c0 with c1 (squash)' '
+ git reset --hard c0 &&
+ git merge --squash c1 &&
+ verify_merge file result.1 &&
+ verify_head $c0 &&
+ verify_no_mergehead &&
+ verify_diff squash.1 .git/SQUASH_MSG "[OOPS] bad squash message"
+'
+
+test_debug 'gitk --all'
+
+test_expect_success 'merge c1 with c2 (squash)' '
+ git reset --hard c1 &&
+ git merge --squash c2 &&
+ verify_merge file result.1-5 &&
+ verify_head $c1 &&
+ verify_no_mergehead &&
+ verify_diff squash.1-5 .git/SQUASH_MSG "[OOPS] bad squash message"
+'
+
+test_debug 'gitk --all'
+
+test_expect_success 'merge c1 with c2 and c3 (squash)' '
+ git reset --hard c1 &&
+ git merge --squash c2 c3 &&
+ verify_merge file result.1-5-9 &&
+ verify_head $c1 &&
+ verify_no_mergehead &&
+ verify_diff squash.1-5-9 .git/SQUASH_MSG "[OOPS] bad squash message"
+'
+
+test_debug 'gitk --all'
+
+test_done
--
1.5.3.2.82.g75c8d
^ permalink raw reply related
* [PATCH 6/6] git-merge: add --ff and --no-ff options
From: Lars Hjemli @ 2007-09-23 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1190587905-700-6-git-send-email-hjemli@gmail.com>
These new options can be used to control the policy for fast-forward
merges: --ff allows it (this is the default) while --no-ff will create
a merge commit.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Documentation/merge-options.txt | 9 +++++++++
git-merge.sh | 22 ++++++++++++++++------
t/t7600-merge.sh | 20 ++++++++++++++++++++
3 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 0464a34..9f1fc82 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -27,6 +27,15 @@
Perform the merge and commit the result. This option can
be used to override --squash.
+--no-ff::
+ Generate a merge commit even if the merge resolved as a
+ fast-forward.
+
+--ff::
+ Do not generate a merge commit if the merge resolved as
+ a fast-forward, only update the branch pointer. This is
+ the default behavior of git-merge.
+
-s <strategy>, \--strategy=<strategy>::
Use the given merge strategy; can be supplied more than
once to specify them in the order they should be tried.
diff --git a/git-merge.sh b/git-merge.sh
index ee8342d..212e0ee 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2005 Junio C Hamano
#
-USAGE='[-n] [--summary] [--[no-]commit] [--[no-]squash] [-s <strategy>] [-m=<merge-message>] <commit>+'
+USAGE='[-n] [--summary] [--[no-]commit] [--[no-]squash] [--[no-]ff] [-s <strategy>] [-m=<merge-message>] <commit>+'
SUBDIRECTORY_OK=Yes
. git-sh-setup
@@ -127,13 +127,17 @@ parse_option () {
--summary)
show_diffstat=t ;;
--sq|--squ|--squa|--squas|--squash)
- squash=t no_commit=t ;;
+ allow_fast_forward=t squash=t no_commit=t ;;
--no-sq|--no-squ|--no-squa|--no-squas|--no-squash)
- squash= no_commit= ;;
+ allow_fast_forward=t squash= no_commit= ;;
--c|--co|--com|--comm|--commi|--commit)
- squash= no_commit= ;;
+ allow_fast_forward=t squash= no_commit= ;;
--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
- squash= no_commit=t ;;
+ allow_fast_forward=t squash= no_commit=t ;;
+ --ff)
+ allow_fast_forward=t squash= no_commit= ;;
+ --no-ff)
+ allow_fast_forward=false squash= no_commit= ;;
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
@@ -477,7 +481,13 @@ done
# auto resolved the merge cleanly.
if test '' != "$result_tree"
then
- parents=$(git show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
+ if test "$allow_fast_forward" = "t"
+ then
+ parents=$(git show-branch --independent "$head" "$@")
+ else
+ parents=$(git rev-parse "$head" "$@")
+ fi
+ parents=$(echo "$parents" | sed -e 's/^/-p /')
result_commit=$(printf '%s\n' "$merge_msg" | git commit-tree $result_tree $parents) || exit
finish "$result_commit" "Merge made by $wt_strategy."
dropsave
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index b0ef488..6424c6e 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -417,4 +417,24 @@ test_expect_success 'merge c1 with c2 (override --squash)' '
test_debug 'gitk --all'
+test_expect_success 'merge c0 with c1 (no-ff)' '
+ git reset --hard c0 &&
+ test_tick &&
+ git merge --no-ff c1 &&
+ verify_merge file result.1 &&
+ verify_parents $c0 $c1
+'
+
+test_debug 'gitk --all'
+
+test_expect_success 'merge c0 with c1 (ff overrides no-ff)' '
+ git reset --hard c0 &&
+ git config branch.master.mergeoptions "--no-ff" &&
+ git merge --ff c1 &&
+ verify_merge file result.1 &&
+ verify_head $c1
+'
+
+test_debug 'gitk --all'
+
test_done
--
1.5.3.2.82.g75c8d
^ permalink raw reply related
* [PATCH 5/6] git-merge: add support for --commit and --no-squash
From: Lars Hjemli @ 2007-09-23 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1190587905-700-5-git-send-email-hjemli@gmail.com>
These options can be used to override --no-commit and --squash, which is
needed since --no-commit and --squash now can be specified as default merge
options in $GIT_DIR/config.
The change also introduces slightly different behavior for --no-commit:
when specified, it explicitly overrides --squash. Earlier,
'git merge --squash --no-commit' would result in a squashed merge (i.e. no
$GIT_DIR/MERGE_HEAD was created) but with this patch the command will
behave as if --squash hadn't been specified.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
Documentation/merge-options.txt | 8 ++++++++
git-merge.sh | 8 ++++++--
t/t7600-merge.sh | 22 ++++++++++++++++++++++
3 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index d64c259..0464a34 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -10,6 +10,10 @@
not autocommit, to give the user a chance to inspect and
further tweak the merge result before committing.
+--commit::
+ Perform the merge and commit the result. This option can
+ be used to override --no-commit.
+
--squash::
Produce the working tree and index state as if a real
merge happened, but do not actually make a commit or
@@ -19,6 +23,10 @@
top of the current branch whose effect is the same as
merging another branch (or more in case of an octopus).
+--no-squash::
+ Perform the merge and commit the result. This option can
+ be used to override --squash.
+
-s <strategy>, \--strategy=<strategy>::
Use the given merge strategy; can be supplied more than
once to specify them in the order they should be tried.
diff --git a/git-merge.sh b/git-merge.sh
index e95d4a7..ee8342d 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2005 Junio C Hamano
#
-USAGE='[-n] [--summary] [--no-commit] [--squash] [-s <strategy>] [-m=<merge-message>] <commit>+'
+USAGE='[-n] [--summary] [--[no-]commit] [--[no-]squash] [-s <strategy>] [-m=<merge-message>] <commit>+'
SUBDIRECTORY_OK=Yes
. git-sh-setup
@@ -128,8 +128,12 @@ parse_option () {
show_diffstat=t ;;
--sq|--squ|--squa|--squas|--squash)
squash=t no_commit=t ;;
+ --no-sq|--no-squ|--no-squa|--no-squas|--no-squash)
+ squash= no_commit= ;;
+ --c|--co|--com|--comm|--commi|--commit)
+ squash= no_commit= ;;
--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
- no_commit=t ;;
+ squash= no_commit=t ;;
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index 110974c..b0ef488 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -395,4 +395,26 @@ test_expect_success 'override config option --summary' '
test_debug 'gitk --all'
+test_expect_success 'merge c1 with c2 (override --no-commit)' '
+ git reset --hard c1 &&
+ git config branch.master.mergeoptions "--no-commit" &&
+ test_tick &&
+ git merge --commit c2 &&
+ verify_merge file result.1-5 msg.1-5 &&
+ verify_parents $c1 $c2
+'
+
+test_debug 'gitk --all'
+
+test_expect_success 'merge c1 with c2 (override --squash)' '
+ git reset --hard c1 &&
+ git config branch.master.mergeoptions "--squash" &&
+ test_tick &&
+ git merge --no-squash c2 &&
+ verify_merge file result.1-5 msg.1-5 &&
+ verify_parents $c1 $c2
+'
+
+test_debug 'gitk --all'
+
test_done
--
1.5.3.2.82.g75c8d
^ permalink raw reply related
* [PATCH 3/6] git-merge: refactor option parsing
From: Lars Hjemli @ 2007-09-23 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1190587905-700-3-git-send-email-hjemli@gmail.com>
Move the option parsing into a separate function as preparation for reuse
by the next commit.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
git-merge.sh | 20 ++++++++++++++------
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/git-merge.sh b/git-merge.sh
index 3857634..68b3503 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -119,11 +119,7 @@ merge_name () {
fi
}
-case "$#" in 0) usage ;; esac
-
-have_message=
-while case "$#" in 0) break ;; esac
-do
+parse_option () {
case "$1" in
-n|--n|--no|--no-|--no-s|--no-su|--no-sum|--no-summ|\
--no-summa|--no-summar|--no-summary)
@@ -166,9 +162,21 @@ do
have_message=t
;;
-*) usage ;;
- *) break ;;
+ *) return 1 ;;
esac
shift
+ args_left="$#"
+}
+
+case "$#" in 0) usage ;; esac
+
+have_message=
+while parse_option "$@"
+do
+ while test $args_left -lt $#
+ do
+ shift
+ done
done
if test -z "$show_diffstat"; then
--
1.5.3.2.82.g75c8d
^ permalink raw reply related
* [PATCH 2/6] git-merge: fix faulty SQUASH_MSG
From: Lars Hjemli @ 2007-09-23 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1190587905-700-2-git-send-email-hjemli@gmail.com>
Only the first 'remote' head is currently specified as an argument to 'git
log' when generating a SQUSH_MSG, which makes the generated message fail
to mention every commit involved in the merge. This fixes the problem.
Noticed-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
git-merge.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-merge.sh b/git-merge.sh
index 3a01db0..3857634 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -59,7 +59,7 @@ finish_up_to_date () {
squash_message () {
echo Squashed commit of the following:
echo
- git log --no-merges ^"$head" $remote
+ git log --no-merges ^"$head" $remoteheads
}
finish () {
--
1.5.3.2.82.g75c8d
^ permalink raw reply related
* git-rebase--interactive needs a better message
From: Dmitry Potapov @ 2007-09-23 22:45 UTC (permalink / raw)
To: git
I have tried to use git-rebase --interactive today, and run into a strange
error message saying:
/usr/bin/git-rebase--interactive: line 333: $GIT_DIR/.dotest-merge/author-script: No such file or directory
I had to scratch my head for a while before I realized that I forgot to
say git-commit. So, it was mine mistake, but I think that it should be
possible to have a better error message suggesting the user what to do.
I have looked at the git-rebase--interactive script, but I am not sure
that I understand it good enough to propose a patch.
To reproduce the problem, run the following script in an empty directory:
===
#!/bin/sh
set -e
git-init
echo 'version 1' > foo
git-add foo
git-commit -m 'commit 1' foo
echo 'versionn 2' >> foo
git-commit -m 'commit 2' foo
echo 'version 3' >> foo
git-commit -m 'commit 3' foo
GIT_EDITOR='sed -i -e "/commit 2/{s/^pick/edit/}"' git-rebase -i HEAD~2
sed -i -e "s/versionn/version/" foo
git-update-index foo
# Missing git-commit --amend
git-rebase --continue
===
Error message:
==
/usr/bin/git-rebase--interactive: line 333: /tmp/zzz/.git/.dotest-merge/author-script: No such file or directory
===
I use git version 1.5.3.1
Dmitry Potapov
^ permalink raw reply
* git-send-email is omitting author and date lines
From: Hanspeter Kunz @ 2007-09-23 22:13 UTC (permalink / raw)
To: git
Hi,
sorry if this is a stupid question, but I'm new to git.
When sending a patch to myself using `git-send-email` I realized that
the lines containing the author and the date (lines 5 and 6 in the patch
file) were not in the sent email.
Is this on purpose? And if so, why?
Thanks,
Hp.
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: Reece Dunn @ 2007-09-23 22:25 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Linus Torvalds, Marco Costalba, Pierre Habouzit, David Kastrup,
Frank Lichtenheld, Alex Unleashed, Kyle Rose, Miles Bader,
Dmitry Kakurin, Git
In-Reply-To: <20070923212239.GA7249@potapov>
On 23/09/2007, Dmitry Potapov <dpotapov@nbs-eng.ru> wrote:
> On Sun, Sep 23, 2007 at 09:54:10AM -0700, Linus Torvalds wrote:
> > The same goes for things like memory allocation. Memory allocation issues
> > are often some of the *biggest* performance issues, and that means that
> > they have to be explicit. I'm actually a big fan of GC, but most languages
> > that implement GC do it exactly the wrong way in my opinion: they make it
> > a fundamental thing that covers everything, and it all happens implicitly,
> > instead of making it explicit.
>
> Stroustrup was not a big fan of GC, so he made the language to be useful
> in absence of any GC, and it allows to manage memory and some other
> resources though not automatically, but with much less efforts than in C.
The next version of C++ is going to have garbage collection that the
user can enable, disable or remain neutral about. However, this is
program-wide and has many traps that you could fall into.
> > But other parts of C++ are just nasty. The whole OO layer seems designed
> > to do a lot of things implicitly and in the wrong way.
>
> It could do a lot of things implicitly, but it does not force you,
> except calling destructor when the control leaves the scope of
> declaration, but I hardly can consider it as implicit.
You have to add the explicit keyword to any constructor to prevent an
automatic conversion. Therefore, the constructors that are called are
implicit by default. If you have a conversion operator, this is always
implicitly called when there is a match by the compiler.
I agree with Linus here, there are a lot of things that happen implicily.
> > I also disagree with exception handling,
>
> Perhaps, you look at it from the kernel point of view. Otherwise, I
> would like to hear your arguments against it. In fact, I don't think
> it is possible to write generic algorithms without exceptions. Of
> course, if you write a program that can print an error to stderr and
> exit, there is no much need for them. So, it may depend on the task.
There are many issues with exceptions.
Firstly, there is throwing an exception from a destructor, which is
warned against in any good C++ book, but does not prevent you from
doing so (even if it is inadvertantly)! If the program is in the
process of handling an exception, the program is toast.
More importantly though, is the loss of contextual information.
Consider throwing the same exception on all calls to API that return
the same error code type. The code that processes this may be anywhere
in the system. This makes it impossible to do any sensible recovery
(if possible), or error reporting. The exception can be rethrown or
translated to another exception, making it impossible to find the
originator of the exception. This makes it harder, if not impossible,
to track the exception back to the source when you are at a breakpoint
in the exception handler.
Then there is dealing with caller boundaries. That is, when a callback
or interface function in the application will return to the operating
system (e.g. when handling a draw request from X11), or another
language such as Python. Also, because different compiler vendors and
versions handle exceptions differently, if you want to support
different compilers (and you have resolved the name mangling
incompatibilities), you need to handle exceptions correctly in these
cases, or risk having major problems that would be impossible to
trace. Not to mention that anywhere new, dynamic_cast and other
language features are used may throw exceptions.
- Reece
^ permalink raw reply
* Re: [PATCH] Supplant the "while case ... break ;; esac" idiom
From: Junio C Hamano @ 2007-09-23 22:20 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85myvdktb3.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> A lot of shell scripts contained stuff starting with
>
> while case "$#" in 0) break ;; esac
>
> and similar. I consider breaking out of the condition instead of the
> body od the loop ugly, and the implied "true" value of the
> non-matching case is not really obvious to humans at first glance. It
> happens not to be obvious to some BSD shells, either, but that's
> because they are not POSIX-compliant. In most cases, this has been
> replaced by a straight condition using "test". "case" has the
> advantage of being faster than "test" on vintage shells where "test"
> is not a builtin. Since none of them is likely to run the git
> scripts, anyway, the added readability should be worth the change.
>
> A few loops have had their termination condition expressed
> differently.
>
> Signed-off-by: David Kastrup <dak@gnu.org>
> ---
>
> Ok, this is not really what we have been talking about except in one
> case, but I think it is actually more of an improvement.
Gaah, didn't I say I do NOT think it is an improvement?
> I consider breaking out of the condition instead of the
> body od the loop ugly,
Well, as we all know that we disagree on this point, stating
what you consider one-sidedly here is quite inappropriate.
> and the implied "true" value of the
> non-matching case is not really obvious to humans at first
> glance.
It is more like "if you do not know shell".
In other words, I am somewhat disgusted with the first part of
your proposed commit log message, although I like what the patch
does ;-).
> -while case "$#" in 0) break ;; esac
> +while test "$#" != 0
> do
> case "$1" in
> -a)
And let's not quote "$#".
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: David Kastrup @ 2007-09-23 21:31 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Linus Torvalds, Marco Costalba, Pierre Habouzit,
Frank Lichtenheld, Alex Unleashed, Kyle Rose, Miles Bader,
Dmitry Kakurin, Git
In-Reply-To: <20070923212239.GA7249@potapov>
Dmitry Potapov <dpotapov@nbs-eng.ru> writes:
> On Sun, Sep 23, 2007 at 09:54:10AM -0700, Linus Torvalds wrote:
>
>> - the stuff C++ *does* have is usually nasty. Implicit
>> initializers and destructors and the magic lifetime rules of
>> objects etc
>
> I am not sure what is wrong with initializers and destructors in
> C++, but certainly there is no magic lifetime rules in C++, as it is
> fully determined by the scope.
It has been some time since I last looked, but the lifetime of objects
constructed in return statements was a moving target through several
standards. The last standard I bothered looking at had the object
survive until the statement with the function call expression ended:
quite a strange synchronization point with regard to language design.
> In fact, other high level languages that use GC have much more
> unpredictable lifetime rules for objects.
Mostly objects are alive as long as you can refer to them. Not really
complicated.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: Dmitry Potapov @ 2007-09-23 21:22 UTC (permalink / raw)
To: Linus Torvalds
Cc: Marco Costalba, Pierre Habouzit, David Kastrup, Frank Lichtenheld,
Alex Unleashed, Kyle Rose, Miles Bader, Dmitry Kakurin, Git
In-Reply-To: <alpine.LFD.0.999.0709230911360.16478@woody.linux-foundation.org>
On Sun, Sep 23, 2007 at 09:54:10AM -0700, Linus Torvalds wrote:
>
> And we do all of this in C. There is no need to go to C++ for any "object
> oriented principles". It really is just a syntactic issue, and in many
> ways the syntax "advantage" of C++ is actually a big *disadvantage*.
Certainly, in this respect, C++ provides only syntactic sugar over C,
and there is a real danger of abuse, which leads to horrible programs.
This is especially likely to happen to those who think that the evil
of C++ is lying in templates, exceptions, or something other feature
of C++, because they start to abuse the only "good" feature they know
and inevitably end up with horrible code.
> struct somestruct __user *p
>
> to explicitly say that it's a pointer to user space - and then having
> every function that takes that pointer have to have that "__user" there is
> a VERY GOOD THING.
user_ptr<somestruct> p;
>
> That's very different from having "accessor functions" and making "p" an
> abstract type, and having the compiler automatically generate the right
> kind of access. That kind of stuff is TOTAL CRAP, and it's an example of
> how C++ has a horrible design, where you carry around _implicit_ knowledge
> instead of making the knowledge explicit and visible locally too.
Whether it will convert to something or not depends entirely on the
definition of user_ptr. So, it can be as explicit as you wish, or
completely implicit. C++ does not impose anything on you here. So,
the problem is not in C++ but in the crappy mentality -- "let's hide
everything behind 'higher' abstraction" or "let's hide this thing too
because we can". Yes, these people end up with total crap. And yes,
those people tend to prefer C++ over C, just because C++ is better at
hiding. But I don't think that C++ forces anyone to do that...
> The same goes for things like memory allocation. Memory allocation issues
> are often some of the *biggest* performance issues, and that means that
> they have to be explicit. I'm actually a big fan of GC, but most languages
> that implement GC do it exactly the wrong way in my opinion: they make it
> a fundamental thing that covers everything, and it all happens implicitly,
> instead of making it explicit.
Stroustrup was not a big fan of GC, so he made the language to be useful
in absence of any GC, and it allows to manage memory and some other
resources though not automatically, but with much less efforts than in C.
Maybe, your idea of more explicit GC is better than what C++ offers. It
is difficult for me to say without trying, but as you said most languages
implement GC in the wrong way in your opinion, so I don't think I will
have a chance to try any language that does it right. As to "caches" in
Git, it works really nicely, but Git is not a programming language.
> But other parts of C++ are just nasty. The whole OO layer seems designed
> to do a lot of things implicitly and in the wrong way.
It could do a lot of things implicitly, but it does not force you,
except calling destructor when the control leaves the scope of
declaration, but I hardly can consider it as implicit.
> I also disagree with exception handling,
Perhaps, you look at it from the kernel point of view. Otherwise, I
would like to hear your arguments against it. In fact, I don't think
it is possible to write generic algorithms without exceptions. Of
course, if you write a program that can print an error to stderr and
exit, there is no much need for them. So, it may depend on the task.
> - the stuff C++ *does* have is usually nasty. Implicit initializers and
> destructors and the magic lifetime rules of objects etc
I am not sure what is wrong with initializers and destructors in C++,
but certainly there is no magic lifetime rules in C++, as it is fully
determined by the scope. In fact, other high level languages that use
GC have much more unpredictable lifetime rules for objects.
Dmitry Potapov
PS Please, do not confuse me with Dmitry Kakurin, who started this
thread, because my position is opposite to his. Though I like C++,
I fully understand most of your consideration in choosing C for Git.
^ permalink raw reply
* The msysGit Herald, issue 2
From: Johannes Schindelin @ 2007-09-23 20:54 UTC (permalink / raw)
To: msysgit, git
Good morning git land!
This lovely afternoon in St Andrews is as good an occasion as any to issue
a new incarnation of the msysGit Herald, the not-quite-biweekly news letter
to keep you informed about msysGit, the effort to bring one of the most
powerful Source Code Management systems to the poor souls stuck with
Windows.
These are the covered topics:
WinGit 0.2
What will be in WinGit 0.3?
We're getting famous in China
Compiling Perl from scratch
Time for a new console?
Interview with Johannes "Mr mingw.git" Sixt
Still no concrete mingw/git.git merge plans yet
WinGit 0.2
==========
By mistake, Perl was not properly installed with version 0.1 of WinGit.
This is the most visible part that was fixed in 0.2.
However, in the meantime we got our "Issue" list (see home page) cut
almost in half. Which means that we are mostly stuck with the hard
problems ;-)
What will be in WinGit 0.3
=========================
What will be in 0.3? We have a proper uninstaller now. Yes, that means
that "Git" will be in the "Add/Remove Software" list.
Also, curl, termcap, the completions, sh-add, and git-gui are actually
installed.
Maybe we'll get to the state where a link to git gui is installed in
addition to the "Git Shell", maybe we'll succeed in merging 1.5.3.2?
Who knows... ;-)
We're getting famous in China
=============================
Apparently, there is a blog talking (amongst other things, like the
unfamous language flame war) about "Git on Windows" in China:
http://blog.csdn.net/turingbook/archive/2007/09/07/1775488.aspx
I am dyslexic when it comes to Chinese, but we got some hits from
there...
Compiling Perl from scratch
===========================
We have an open issue called "Install scripts do not install perl modules
for git-svn" (Issue 42). Unfortunately, it is not really as easy as
that...
The Perl version we have does not come with valid MakeMaker information,
and we are therefore unable to compile modules for Perl (even something
as dirt-simple as Digest::MD5 does not work).
So we tried to compile Perl from scratch -- which opened another can of
worms. It was not a problem at all to compile Perl for _MinGW_. Which
means that the resulting binary does not have any clue about the MSys
environment (think Unix style paths, and (worse!) no shell scripts).
An option would be to not care, and decouple Perl from MSys. Another
option would be to get Perl compiled & linked to msys-1.0.dll.
This issue is not resolved yet.
Time for a new console?
=======================
The first publically available version of msysGit recommended Rxvt, until
I realised that there were strange stderr/stdout issues, which prevented
-- among other things -- the pager and ssh transport from working.
So we reverted back to cmd as the Terminal, which has its own set of
shortcomings (does not do ANSI well, has Control-C issues, and the
multi-line selection being a rectangular box is outright annoying, as
well as the missing Shift+Insert binding to paste the clipboard).
Now, compiling (and possibly fixing) Rxvt seems to be out of reach for the
moment, but Marius Storm-Olsen found the "Console" project:
http://sourceforge.net/projects/console
Unfortunately, this project does not work on Windows 95/98/ME, and I would
have liked to retain backwards compatibility (some developers, yours
truly included, do not have Windows boxen to develop, so they have to
resort to emulated ones -- and 2k is a real hog there, opposed to 95).
However, since we already rely on the NT based family for our installer,
that reason not to use Console seems to fall on the floor.
We would need to work on it, though: ATM it has problems with selections,
and recompiling is made difficult by the ATL dependency.
Interview with Johannes "Mr mingw.git" Sixt
===========================================
Hannes announced an initial official version of the MinGW port of git on
January 19th, 2007:
http://article.gmane.org/gmane.comp.version-control.git/37202
For quite some time, he was the only one working on this port. Most of
the smoothness of the msysGit effort is his fault.
So here, without further ado, the interview:
> 1) How did you get involved with Git?
In our shop, CVS was used for years. I have been working with patch sets
because it did not allow the workflow that I wanted - namely to construct
a series of changes before making them public.
When the news came out that Linus was working on a new VCS, I was
following its development closely. From the discussions I discovered that
git would be the tool that allowed my desired workflow.
In order to get acquainted with git, I used it on my Linux projects
(KDbg, Cinelerra).
> 2) What were the reasons that you started working on Git?
In our shop, which develops software for Windows, the requirement arouse
to have several different, but related versions of the same product -
which is a setup that we would not be able to solve with CVS, but it
would be a breeze with git.
But we needed git on Windows. And since I dislike cygwin (for no good
reason actually), I decided to start the native port of git to Windows
using MSYS ang MinGW.
> 3) What do you like most in Git?
- Easy merging with real merge history
- Massage a series of changes into proper shape before making it public
> 4) What do you hate most in Git?
You're kiddin'!
> 5) What was the most surprising moment when working with Git?
It merged a change I made in an old branch in a file that was moved in
the new branch to a new location. IOW, merge across renames. Really, I
was so surprised - I wanted to start the manual merge when I discovered
that git had done all the work for me.
> 6) What was the most frustrating moment when working with Git?
Just the other day, I wanted to fetch a set of changes from a public
repo into my test repo in order to cherry-pick from them - and it
automatically fetched all the tags. But, the heck, I don't want them tags
here, just the commits. I just can't figure out how to avoid the automatic
fetching of tags.
> 7) In what environment do you work?
Linux (SUSE); Windows 2000, XP.
> 8) What other hobbies do you have?
Cuddling the brats and changing nappies - does that count as a hobby?
> 9) What is your favourite movie?
You think I have time to watch movies?
> 10) What are your visions for Git? (I.e. where do you want it to go?)
Seriously, I'm not a visionair.
On *nix, git will be perfect when it is able to seamlessly serve the KDE
source.
On Windows, git still has too many problems that we don't need a vision, yet.
-- Hannes
Still no concrete mingw/git.git merge plans yet
===============================================
As mentioned in the first issue of this news letter, I sent a rather long
list of relatively small and well contained projects, that in total would
mean a complete merge of the mingw/4msysgit port back into git.git:
http://article.gmane.org/gmane.comp.version-control.git/57163
Unfortunately, there have not been any takers (just a few "would it not
be better to have this in git.git" sayers).
In related news, it seems to be awfully more common for Windows users than
for other people to have the attitude "I am the user. You _have_ to help
me." (Remember that in our case, the users are developers, too, so they
should be able to help themselves.)
Do not let yourself fool into thinking that _all_ Windows users are like
that. Just enough to annoy.
However, nobody stops changing until eaten by the bugs, so all of those who
think "well, I might be able to do a small thing, just to prove that
bastard wrong": follow the above link, read the mail (you can even just
randomly jump around, and only read parts of it), pick a target, and say so
on the msysGit mailing list (msysgit@googlegroups.com).
^ permalink raw reply
* [PATCH] Supplant the "while case ... break ;; esac" idiom
From: David Kastrup @ 2007-09-23 20:42 UTC (permalink / raw)
To: git
In-Reply-To: <853ax5mb1j.fsf@lola.goethe.zz>
A lot of shell scripts contained stuff starting with
while case "$#" in 0) break ;; esac
and similar. I consider breaking out of the condition instead of the
body od the loop ugly, and the implied "true" value of the
non-matching case is not really obvious to humans at first glance. It
happens not to be obvious to some BSD shells, either, but that's
because they are not POSIX-compliant. In most cases, this has been
replaced by a straight condition using "test". "case" has the
advantage of being faster than "test" on vintage shells where "test"
is not a builtin. Since none of them is likely to run the git
scripts, anyway, the added readability should be worth the change.
A few loops have had their termination condition expressed
differently.
Signed-off-by: David Kastrup <dak@gnu.org>
---
Ok, this is not really what we have been talking about except in one
case, but I think it is actually more of an improvement.
contrib/examples/git-gc.sh | 2 +-
contrib/examples/git-reset.sh | 2 +-
contrib/examples/git-tag.sh | 2 +-
contrib/examples/git-verify-tag.sh | 2 +-
git-am.sh | 2 +-
git-clean.sh | 2 +-
git-commit.sh | 2 +-
git-fetch.sh | 2 +-
git-filter-branch.sh | 3 ++-
git-instaweb.sh | 2 +-
git-ls-remote.sh | 2 +-
git-merge.sh | 2 +-
git-mergetool.sh | 2 +-
git-pull.sh | 6 +++---
git-quiltimport.sh | 2 +-
git-rebase--interactive.sh | 2 +-
git-rebase.sh | 5 ++---
git-repack.sh | 2 +-
git-submodule.sh | 2 +-
19 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/contrib/examples/git-gc.sh b/contrib/examples/git-gc.sh
index 2ae235b..1597e9f 100755
--- a/contrib/examples/git-gc.sh
+++ b/contrib/examples/git-gc.sh
@@ -9,7 +9,7 @@ SUBDIRECTORY_OK=Yes
. git-sh-setup
no_prune=:
-while case $# in 0) break ;; esac
+while test $# != 0
do
case "$1" in
--prune)
diff --git a/contrib/examples/git-reset.sh b/contrib/examples/git-reset.sh
index 1dc606f..bafeb52 100755
--- a/contrib/examples/git-reset.sh
+++ b/contrib/examples/git-reset.sh
@@ -11,7 +11,7 @@ require_work_tree
update= reset_type=--mixed
unset rev
-while case $# in 0) break ;; esac
+while test $# != 0
do
case "$1" in
--mixed | --soft | --hard)
diff --git a/contrib/examples/git-tag.sh b/contrib/examples/git-tag.sh
index 5ee3f50..7bb7486 100755
--- a/contrib/examples/git-tag.sh
+++ b/contrib/examples/git-tag.sh
@@ -14,7 +14,7 @@ username=
list=
verify=
LINES=0
-while case "$#" in 0) break ;; esac
+while test "$#" != 0
do
case "$1" in
-a)
diff --git a/contrib/examples/git-verify-tag.sh b/contrib/examples/git-verify-tag.sh
index 37b0023..0902a5c 100755
--- a/contrib/examples/git-verify-tag.sh
+++ b/contrib/examples/git-verify-tag.sh
@@ -5,7 +5,7 @@ SUBDIRECTORY_OK='Yes'
. git-sh-setup
verbose=
-while case $# in 0) break;; esac
+while test $# != 0
do
case "$1" in
-v|--v|--ve|--ver|--verb|--verbo|--verbos|--verbose)
diff --git a/git-am.sh b/git-am.sh
index 6809aa0..d97b528 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -109,7 +109,7 @@ dotest=.dotest sign= utf8=t keep= skip= interactive= resolved= binary=
resolvemsg= resume=
git_apply_opt=
-while case "$#" in 0) break;; esac
+while test "$#" != 0
do
case "$1" in
-d=*|--d=*|--do=*|--dot=*|--dote=*|--dotes=*|--dotest=*)
diff --git a/git-clean.sh b/git-clean.sh
index a5cfd9f..e847ae2 100755
--- a/git-clean.sh
+++ b/git-clean.sh
@@ -26,7 +26,7 @@ rmrf="rm -rf --"
rm_refuse="echo Not removing"
echo1="echo"
-while case "$#" in 0) break ;; esac
+while test "$#" != 0
do
case "$1" in
-d)
diff --git a/git-commit.sh b/git-commit.sh
index 3e46dbb..dcdd49b 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -89,7 +89,7 @@ force_author=
only_include_assumed=
untracked_files=
templatefile="`git config commit.template`"
-while case "$#" in 0) break;; esac
+while test "$#" != 0
do
case "$1" in
-F|--F|-f|--f|--fi|--fil|--file)
diff --git a/git-fetch.sh b/git-fetch.sh
index c3a2001..dc6483f 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -27,7 +27,7 @@ shallow_depth=
no_progress=
test -t 1 || no_progress=--no-progress
quiet=
-while case "$#" in 0) break ;; esac
+while test "$#" != 0
do
case "$1" in
-a|--a|--ap|--app|--appe|--appen|--append)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index a4b6577..b7b2ef7 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -105,8 +105,9 @@ filter_tag_name=
filter_subdir=
orig_namespace=refs/original/
force=
-while case "$#" in 0) usage;; esac
+while :
do
+ test "$#" = 0 && usage
case "$1" in
--)
shift
diff --git a/git-instaweb.sh b/git-instaweb.sh
index b79c6b6..364cf93 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -61,7 +61,7 @@ stop_httpd () {
test -f "$fqgitdir/pid" && kill `cat "$fqgitdir/pid"`
}
-while case "$#" in 0) break ;; esac
+while test "$#" != 0
do
case "$1" in
--stop|stop)
diff --git a/git-ls-remote.sh b/git-ls-remote.sh
index b7e5d04..e6e9760 100755
--- a/git-ls-remote.sh
+++ b/git-ls-remote.sh
@@ -13,7 +13,7 @@ die () {
}
exec=
-while case "$#" in 0) break;; esac
+while test "$#" != 0
do
case "$1" in
-h|--h|--he|--hea|--head|--heads)
diff --git a/git-merge.sh b/git-merge.sh
index 3a01db0..e4116a8 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -122,7 +122,7 @@ merge_name () {
case "$#" in 0) usage ;; esac
have_message=
-while case "$#" in 0) break ;; esac
+while test "$#" != 0
do
case "$1" in
-n|--n|--no|--no-|--no-s|--no-su|--no-sum|--no-summ|\
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 47a8055..a0e44f7 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -268,7 +268,7 @@ merge_file () {
cleanup_temp_files
}
-while case $# in 0) break ;; esac
+while test $# != 0
do
case "$1" in
-t|--tool*)
diff --git a/git-pull.sh b/git-pull.sh
index 5e96d1f..c3f05f5 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -16,7 +16,7 @@ test -z "$(git ls-files -u)" ||
die "You are in the middle of a conflicted merge."
strategy_args= no_summary= no_commit= squash=
-while case "$#,$1" in 0) break ;; *,-*) ;; *) break ;; esac
+while :
do
case "$1" in
-n|--n|--no|--no-|--no-s|--no-su|--no-sum|--no-summ|\
@@ -46,8 +46,8 @@ do
-h|--h|--he|--hel|--help)
usage
;;
- -*)
- # Pass thru anything that is meant for fetch.
+ *)
+ # Pass thru anything that may be meant for fetch.
break
;;
esac
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index 9de54d1..1ad9291 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -5,7 +5,7 @@ SUBDIRECTORY_ON=Yes
dry_run=""
quilt_author=""
-while case "$#" in 0) break;; esac
+while test "$#" != 0
do
case "$1" in
--au=*|--aut=*|--auth=*|--autho=*|--author=*)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index abc2b1c..2fa53fd 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -317,7 +317,7 @@ do_rest () {
done
}
-while case $# in 0) break ;; esac
+while test $# != 0
do
case "$1" in
--continue)
diff --git a/git-rebase.sh b/git-rebase.sh
index c9942f2..9779d34 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -122,15 +122,14 @@ finish_rb_merge () {
is_interactive () {
test -f "$dotest"/interactive ||
- while case $#,"$1" in 0,|*,-i|*,--interactive) break ;; esac
- do
+ while :; do case $#,"$1" in 0,|*,-i|*,--interactive) break ;; esac
shift
done && test -n "$1"
}
is_interactive "$@" && exec git-rebase--interactive "$@"
-while case "$#" in 0) break ;; esac
+while test "$#" != 0
do
case "$1" in
--continue)
diff --git a/git-repack.sh b/git-repack.sh
index 156c5e8..77126cd 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -9,7 +9,7 @@ SUBDIRECTORY_OK='Yes'
no_update_info= all_into_one= remove_redundant=
local= quiet= no_reuse= extra=
-while case "$#" in 0) break ;; esac
+while test "$#" != 0
do
case "$1" in
-n) no_update_info=t ;;
diff --git a/git-submodule.sh b/git-submodule.sh
index 3320998..a7180ad 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -251,7 +251,7 @@ modules_list()
done
}
-while case "$#" in 0) break ;; esac
+while test "$#" != 0
do
case "$1" in
add)
--
1.5.3.1.96.g4568
^ permalink raw reply related
* Re: Uninstalling Git
From: in-call @ 2007-09-23 19:47 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0709232029490.28395@racer.site>
Hello!
Oh! great solution! I didn't know this tool, I'll do that! Thanks a lot!
Johannes Schindelin wrote:
> Hi,
>
> On Sun, 23 Sep 2007, in-call@gmx.net wrote:
>
>> $ make configure
>> $ ./configure --prefix=/usr/local
>> $ make all doc
>> $ sudo make install install-doc
>>
>> First, I'd like to uninstall the thing completely, how do I do that?
>
> I'd use checkinstall to install it (again), and then use the distro's
> regular tools; in case of Ubuntu, that would be dpkg I believe.
>
>> Second, what would be the correct procedure to follow if I would like
>> just to upgrade to a newer version? install over the older perhaps? Is
>> that always safe in the sense that there won't be any dangling piece of
>> bin nor doc?
>
> On Linux this should be safe at all times.
>
> Hth,
> Dscho
>
^ permalink raw reply
* Re: [PATCH] Allow shell scripts to run with non-Bash /bin/sh
From: David Kastrup @ 2007-09-23 19:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eygene Ryabinkin, git
In-Reply-To: <7vy7excho4.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> Independent of that: would you mind a patch replacing that idiom with
>>
>> while : do case xxx) break; esac
>>
>> instead? I find breaking out of the condition rather than the body
>> awkward,...
>
> I do not have any problem with your approach at all.
Too bad sh does... I need to write
while :; do case xxx) break; esac
instead which is slightly uglier concerning visual aesthetics.
> But on one condition, however. If it is done correctly with
> double semi-colons before "esac" ;-)
My feeling about this is that double semi-colons before "esac" are
redundant and similarly ugly as ";" before "end" in Pascal. However,
looking at the existing git scripts it would seem that the redundant
style is ubiquitous anyway, so it would be inconsistent to do this
differently just within the idiom.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH 3/5] git-merge: add support for branch.<name>.mergeoptions
From: Lars Hjemli @ 2007-09-23 19:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6kpchny.fsf@gitster.siamese.dyndns.org>
On 9/23/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Lars Hjemli" <hjemli@gmail.com> writes:
>
> > On 9/23/07, Junio C Hamano <gitster@pobox.com> wrote:
> >> Lars Hjemli <hjemli@gmail.com> writes:
> >> > +branch=$(git-symbolic-ref HEAD | sed -e 's|^refs/heads/||')
> >> > +mergeopts=$(git config "branch.$branch.mergeoptions")
> >> > +parse_config $mergeopts
> >>
> >> What should happen when your head is detached?
> >>
> >
> > My plan was 'nothing', but I should have tested it (it does work, but
> > also prints an ugly "fatal: ref HEAD is not a symbolic ref").
>
> That, and also running "git config branch..mergeoptions" and
> expect it does not change behaviour to issue more strict
> warning, are both not so good. Perhaps the code needs to be
> more defensive like:
>
> if branch=$(git symbolic-ref -q HEAD)
> then
> mergeopts=$(git config "branch.${branch#refs/heads/}.mergeoptions")
> if test -n "$mergeopts"
> then
> parse_config $mergeopts
> fi
> fi
Yes, this is much better (and the ${parameter#word} syntax was nice too).
Thanks.
--
larsh
^ permalink raw reply
* Re: Uninstalling Git
From: Johannes Schindelin @ 2007-09-23 19:31 UTC (permalink / raw)
To: in-call; +Cc: git
In-Reply-To: <46F6B0CC.3040000@gmx.net>
Hi,
On Sun, 23 Sep 2007, in-call@gmx.net wrote:
> $ make configure
> $ ./configure --prefix=/usr/local
> $ make all doc
> $ sudo make install install-doc
>
> First, I'd like to uninstall the thing completely, how do I do that?
I'd use checkinstall to install it (again), and then use the distro's
regular tools; in case of Ubuntu, that would be dpkg I believe.
> Second, what would be the correct procedure to follow if I would like
> just to upgrade to a newer version? install over the older perhaps? Is
> that always safe in the sense that there won't be any dangling piece of
> bin nor doc?
On Linux this should be safe at all times.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 3/5] git-merge: add support for branch.<name>.mergeoptions
From: Junio C Hamano @ 2007-09-23 19:20 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git
In-Reply-To: <8c5c35580709230331h459bd07ay8b17146b5feec212@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
> On 9/23/07, Junio C Hamano <gitster@pobox.com> wrote:
>> Lars Hjemli <hjemli@gmail.com> writes:
>> > +branch=$(git-symbolic-ref HEAD | sed -e 's|^refs/heads/||')
>> > +mergeopts=$(git config "branch.$branch.mergeoptions")
>> > +parse_config $mergeopts
>>
>> What should happen when your head is detached?
>>
>
> My plan was 'nothing', but I should have tested it (it does work, but
> also prints an ugly "fatal: ref HEAD is not a symbolic ref").
That, and also running "git config branch..mergeoptions" and
expect it does not change behaviour to issue more strict
warning, are both not so good. Perhaps the code needs to be
more defensive like:
if branch=$(git symbolic-ref -q HEAD)
then
mergeopts=$(git config "branch.${branch#refs/heads/}.mergeoptions")
if test -n "$mergeopts"
then
parse_config $mergeopts
fi
fi
^ permalink raw reply
* Re: [PATCH] Allow shell scripts to run with non-Bash /bin/sh
From: Junio C Hamano @ 2007-09-23 19:20 UTC (permalink / raw)
To: David Kastrup; +Cc: Eygene Ryabinkin, git
In-Reply-To: <85ir61rc3r.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Independent of that: would you mind a patch replacing that idiom with
>
> while : do case xxx) break; esac
>
> instead? I find breaking out of the condition rather than the body
> awkward,...
I do not have any problem with your approach at all.
While I personally do not think it improves readability much, I
do not think it hurts either. And it is a valid workaround for
FBSD issue, so why not.
But on one condition, however. If it is done correctly with
double semi-colons before "esac" ;-)
Thanks.
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: David Kastrup @ 2007-09-23 19:11 UTC (permalink / raw)
To: Marco Costalba
Cc: Linus Torvalds, Pierre Habouzit, Frank Lichtenheld,
Alex Unleashed, Kyle Rose, Miles Bader, Dmitry Kakurin, Git
In-Reply-To: <e5bfff550709231143m7eb351bx4cf1c60d1247cc3d@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> On 9/23/07, David Kastrup <dak@gnu.org> wrote:
>> "Marco Costalba" <mcostalba@gmail.com> writes:
>>
>> > And BTW
>> >
>> > template <typename T>
>> >
>> > is the thing in C++ that more remembers me of opaque pointers and
>> > their use in C, the difference is that the first is fully type
>> > checked.
>>
>> Not really. The difference is that the first generates new (and
>> optimized) code for every type which is something you can only do
>> using macros in C. Class programming is similar to opaque pointers
>> (in particular concerning the generated code) but templates are really
>> more like macros, as their instantiation generates specialized code,
>> not at all like the handling of opaque pointers.
>
> Probably if I had written like this was more clear:
>
> template <typename T> int some_function(T* p);
Huh? How is this supposed to support your point? There is nothing
like an opaque pointer involved here. The point of opaque pointers is
that they can stand for a variety of types, whereas each template
instantiation can only substitute a single type.
> And regarding 'new' code for each type I would like to remember that
> template instantations of different types can be removed by
> compiler/linker when the instantations are the same (i.e. produce
> the same binary instuctions), this could happen for function
> templates that handle pointers, as example.
Hardly. The type constraints/virtual function tables of any called
function depending on T will be different. And if indeed nothing
depends on T at all inside of the template, it is pointless not to
declare it as void *p in the first place: the type of *p will never be
used then.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Uninstalling Git
From: David Kastrup @ 2007-09-23 19:06 UTC (permalink / raw)
To: in-call; +Cc: git
In-Reply-To: <46F6B0CC.3040000@gmx.net>
in-call@gmx.net writes:
> This must be a stupid-obvious-newbie question but...
>
> Well, the point is that I installed the git version 1.5.2.1 in an
> ubuntu box. That was done following the INSTALL instructions in the
> corresponding tarball. I typed:
>
> $ make configure
> $ ./configure --prefix=/usr/local
> $ make all doc
> $ sudo make install install-doc
>
> First, I'd like to uninstall the thing completely, how do I do that?
Basically, you are screwed. That being said, it might somewhat work
to do the following:
find /usr/local -depth -iname 'git*' -exec rm -rf {} \;
But I think you'll catch more if you apply the following patch, then
do
./configure --prefix=/opt/git
make all doc
sudo make install install-doc install-symlinks
sudo rm -rf /opt/git
sudo find /usr/local -lname '/opt/git/*' -delete
> Second, what would be the correct procedure to follow if I would
> like just to upgrade to a newer version? install over the older
> perhaps? Is that always safe in the sense that there won't be any
> dangling piece of bin nor doc?
There is some software called xstow which is supposed to do something
similar to the "install-symlinks" target of this patch.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
From: David Kastrup <dak@gnu.org>
Date: Wed, 18 Jul 2007 16:45:36 +0200
Subject: [PATCH] Makefile: create an install-symlinks target
[commit text mostly pinched from INSTALL]
An alternative global installation method making it much easier to
uninstall is to use a package-specific prefix like /opt/git, then
create symlinks from /usr/local into that hierarchy. Uninstalling can
then be achieved by
# rm -rf /opt/git; find /usr/local -lname '/opt/git/*' -delete
You can create a setup like that after having used one of the above
install recipes with prefix=/opt/git by writing
# make prefix=/opt/git symlinkprefix=/usr/local install-symlinks
This works by copying the directory hierarchy of $prefix to
$symlinkprefix (not copying or descending to any directories of the
name git* matched case-insensitively), then linking all the rest.
---
INSTALL | 12 ++++++++++++
Makefile | 10 +++++++++-
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/INSTALL b/INSTALL
index 289b046..38d6fdd 100644
--- a/INSTALL
+++ b/INSTALL
@@ -21,6 +21,18 @@ set up install paths (via config.mak.autogen), so you can write instead
$ make all doc ;# as yourself
# make install install-doc ;# as root
+An alternative global installation method making it much easier to
+uninstall is to use a package-specific prefix like /opt/git, then
+create symlinks from /usr/local into that hierarchy. Uninstalling can
+then be achieved by
+
+ # rm -rf /opt/git; find /usr/local -lname '/opt/git/*' -delete
+
+You can create a setup like that after having used one of the above
+install recipes with prefix=/opt/git by writing
+
+ # make prefix=/opt/git symlinkprefix=/usr/local install-symlinks
+
Issues of note:
diff --git a/Makefile b/Makefile
index 0055eef..caea6fb 100644
--- a/Makefile
+++ b/Makefile
@@ -147,6 +147,7 @@ ALL_LDFLAGS = $(LDFLAGS)
STRIP ?= strip
prefix = $(HOME)
+symlinkprefix = /usr/local
bindir = $(prefix)/bin
gitexecdir = $(bindir)
sharedir = $(prefix)/share
@@ -727,6 +728,7 @@ bindir_SQ = $(subst ','\'',$(bindir))
gitexecdir_SQ = $(subst ','\'',$(gitexecdir))
template_dir_SQ = $(subst ','\'',$(template_dir))
prefix_SQ = $(subst ','\'',$(prefix))
+symlinkprefix_SQ = $(subst ','\'',$(symlinkprefix))
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
@@ -1039,7 +1041,13 @@ install-info:
quick-install-doc:
$(MAKE) -C Documentation quick-install
-
+# The somewhat strange looking lines start with an ignored $(MAKE) in
+# order to be executed also in make -n calls.
+install-symlinks:
+ @: $(MAKE) && echo cd '$(prefix_SQ)' && cd '$(prefix_SQ)' && $(FIND) . -type d ! \( -iname 'git*' -prune \) -exec echo $(INSTALL) -m 755 -d '$(symlinkprefix_SQ)/{}' \;
+ @cd '$(prefix_SQ)' && $(FIND) . -type d ! \( -iname 'git*' -prune \) -exec $(INSTALL) -m 755 -d '$(symlinkprefix_SQ)/{}' \;
+ @: $(MAKE) && echo cd '$(prefix_SQ)' && cd '$(prefix_SQ)' && $(FIND) . \( -type d -iname 'git*' -prune -o ! -type d \) -exec echo $(RM) -r '$(symlinkprefix_SQ)/{}' \; -exec echo ln -s '$(prefix_SQ)/{}' '$(symlinkprefix_SQ)/{}' \;
+ @cd '$(prefix_SQ)' && $(FIND) . \( -type d -iname 'git*' -prune -o ! -type d \) -exec $(RM) -r '$(symlinkprefix_SQ)/{}' \; -exec ln -s '$(prefix_SQ)/{}' '$(symlinkprefix_SQ)/{}' \;
### Maintainer's dist rules
--
1.5.3.1.96.g4568
^ permalink raw reply related
* Re: [OT] Re: C++ *for Git*
From: Marco Costalba @ 2007-09-23 18:43 UTC (permalink / raw)
To: David Kastrup
Cc: Linus Torvalds, Pierre Habouzit, Frank Lichtenheld,
Alex Unleashed, Kyle Rose, Miles Bader, Dmitry Kakurin, Git
In-Reply-To: <85hcllmdzb.fsf@lola.goethe.zz>
On 9/23/07, David Kastrup <dak@gnu.org> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > On 9/23/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >>
> >> There are a few features of C++ that I really really like. For example, I
> >> think the C preprocessor is absolutely horrid, and a preprocessor that is
> >> built into the language - and integrates with the syntax - would be
> >> wonderful. And while C++ doesn't improve on that, at least templates are
> >> an example of something like that. Not perfect, but that's the kind of
> >> feature that C really would like.
> >>
> >
> > Yes, I really agree. IMO templates are the thing that more resembles
> > procedural programming, a common way of using them is to split data
> > structures (containers) from functions that operates on them
> > (algorithms). I find them very similar to the struct + functions
> > classical approach of C.
> >
> > And BTW
> >
> > template <typename T>
> >
> > is the thing in C++ that more remembers me of opaque pointers and
> > their use in C, the difference is that the first is fully type
> > checked.
>
> Not really. The difference is that the first generates new (and
> optimized) code for every type which is something you can only do
> using macros in C. Class programming is similar to opaque pointers
> (in particular concerning the generated code) but templates are really
> more like macros, as their instantiation generates specialized code,
> not at all like the handling of opaque pointers.
>
Probably if I had written like this was more clear:
template <typename T> int some_function(T* p);
And regarding 'new' code for each type I would like to remember that
template instantations of different types can be removed by
compiler/linker when the instantations are the same (i.e. produce the
same binary instuctions), this could happen for function templates
that handle pointers, as example.
Marco
^ 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