* Re: C++ *for Git*
From: Dmitry Kakurin @ 2007-09-23 4:54 UTC (permalink / raw)
To: Marco Costalba; +Cc: Johannes Schindelin, Git
In-Reply-To: <e5bfff550709220823p241d04d1n370bda4fa0ef2733@mail.gmail.com>
On 9/22/07, Marco Costalba <mcostalba@gmail.com> wrote:
> On 9/22/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > We don't want C++. Why is that so hard to accept?
> >
>
> Dmitry, I think what Johannes says in the above line is 100% the core
> point of this (sad) discussion.
Actually after a couple of responses to this thread I had a BFO
(Blinding Flash of Obvious). I cannot believe I was so naive :-). Now
I have my answer.
P.S. Mysteries like this could drive me crazy. Now I'm much happier.
--
- Dmitry
^ permalink raw reply
* History over-simplification
From: Shawn O. Pearce @ 2007-09-23 4:46 UTC (permalink / raw)
To: Linus Torvalds, Junio C Hamano; +Cc: git
This is an interesting problem for me. We had a bad merge in the
repository that produced this particular gitk graph:
http://www.spearce.org/2007/07/ugly-gitk.gif
The project maintainer tried to locate the commits that altered
a given file with `gitk -- path` and found only one commit
(the introduction of the path) but expected to at least find
a modification from a side branch. What he was looking for
specifically was the merge (or revert) that threw away that
side branch's change as the change wasn't supposed to have been
reverted/lost.
He knew what the commit from the side branch was (the author of
it still had a branch pointing at the commit). But try finding
the proper child commit in gitk without a path limiter in that
graph I link to above. If you don't remember what a mess it is,
click through briefly to refresh your memory. The path limiter is
really required here to boil the graph down to something a human
can reason with.
Adding in --full-history *almost* gave us the data he needed.
It did find the modification on the side branch but it couldn't
point to the child commit which reverted the path. It turns
out the bad change was an octopus merge commit done incorrectly.
Yes, really. Don't bother telling me how bad octopus merges are.
This problem happens in a two parent merge as well.
Below is a test which shows the problem. Without the associated
patch to revision.c we cannot find the ours merge that trashed the
side branch's change. In this toy repository its no big deal to
find the ours merge and figure out what happened. In the production
repository we were looking at above its impossible without support
from Git.
I don't really like the patch to revision.c because it winds up
showing trivial merges too. What I really want is to have the
"--full-history" option include a merge if either of the following
is true:
a) The resulting path does not match _any_ of the parents. We
already handle this case correctly in revision.c and correctly
show the "evil" merge.
b) The resulting path matches one of the parents but not one of
the others. In such a case the merge should still be output if
a 3-way read-tree would not have chosen this result by default.
The problem is computing b) from within the revision walker.
You can't compute the merge bases while inside the inner loop of the
revision walker itself, its already busy and the flags are already
in-use on all objects. Worse commit parents are being rewritten
in ways that may break merge base computation. Oh, and lets not
even talk about how expensive that merge base computation is if we
were to perform it on every merge. :-\
Thoughts?
diff --git a/revision.c b/revision.c
index 33d092c..aca62a6 100644
--- a/revision.c
+++ b/revision.c
@@ -365,7 +365,7 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
}
die("bad tree compare for commit %s", sha1_to_hex(commit->object.sha1));
}
- if (tree_changed && !tree_same)
+ if (tree_changed && (!tree_same || !revs->simplify_history))
commit->object.flags |= TREECHANGE;
}
diff --git a/t/t6008-rev-list-toosimple.sh b/t/t6008-rev-list-toosimple.sh
new file mode 100755
index 0000000..696b057
--- /dev/null
+++ b/t/t6008-rev-list-toosimple.sh
@@ -0,0 +1,41 @@
+#!/bin/sh
+
+test_description='test git-rev-list history over simplification'
+. ./test-lib.sh
+
+test_expect_success setup '
+ echo BASE >content &&
+ git add content &&
+ git commit -m BASE &&
+ base=$(git rev-parse --verify HEAD) &&
+
+ test_tick &&
+ git checkout -b side &&
+ echo SIDE >content &&
+ git commit -m SIDE content &&
+ side=$(git rev-parse --verify HEAD) &&
+
+ test_tick &&
+ git checkout master &&
+ echo OTHER >other &&
+ git add other &&
+ git commit -m OTHER &&
+
+ test_tick &&
+ git merge -s ours side &&
+ keep=$(git rev-parse --verify HEAD) &&
+ test OTHER = $(git cat-file blob HEAD:other) &&
+ test BASE = $(git cat-file blob HEAD:content)
+'
+
+cat >expect <<EOF
+$keep
+$base
+$side
+EOF
+test_expect_success 'revert merge in history' '
+ git rev-list --full-history HEAD -- content >actual &&
+ git diff expect actual
+'
+
+test_done
--
Shawn.
^ permalink raw reply related
* Re: [OT] Re: C++ *for Git*
From: Frank Lichtenheld @ 2007-09-23 2:09 UTC (permalink / raw)
To: Alex Unleashed; +Cc: Kyle Rose, Miles Bader, Dmitry Kakurin, Git
In-Reply-To: <5e4707340709221550o6d0a6062qd51c16a278727c29@mail.gmail.com>
On Sun, Sep 23, 2007 at 12:50:00AM +0200, Alex Unleashed wrote:
> I'd say being forced to be explicit is a good thing here, so that the
> programmer at least has some sort of good understanding of what is
> going on, and chances are that if he doesn't really know, things just
> won't work out (quite unlike a lot of other languages where this
> programmer might actually end up with something half-assed that
> "mostly" works).
> For some reason it seems to me a lot harder to find bad programmers
> surviving using C than a lot of the other languages.
Idiot-proofness-by-complexity is a myth IMHO. Idiots can be quite
persistent...
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH 4/5] git-merge: add support for --commit
From: Junio C Hamano @ 2007-09-23 0:51 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <1190421186-21784-5-git-send-email-hjemli@gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> This option can be used to override --no-commit and --squash. The change
> also introduces slightly different behavior for --no-commit: when specified,
> it explicitly overrides --squash.
Makes me wonder if --no-squash also make sense to override a --squash.
Is this really needed? IOW, does it ever make sense to have --no-commit
in the configuration?
^ permalink raw reply
* Re: [PATCH 3/5] git-merge: add support for branch.<name>.mergeoptions
From: Junio C Hamano @ 2007-09-23 0:51 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <1190421186-21784-4-git-send-email-hjemli@gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> 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.
I think this is a sensible thing to do in general.
> +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?
^ permalink raw reply
* Re: [PATCH 1/5] Add test-script for git-merge porcelain
From: Junio C Hamano @ 2007-09-23 0:51 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <1190421186-21784-2-git-send-email-hjemli@gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> This test-script tries to excercise the porcelainish aspects of git-merge.
It does exercise; no need for "tries to" ;-).
> +test_expect_success 'verify merge result' '
> + echo "
> +1 X
> +2
> +3
> +4
> +5
> +6
> +7
> +8
> +9
> +" > result.1 &&
> + cmp -s file result.1
> +'
Unless there is a compelling reason otherwise, I'd prefer tests
with a test vector like this to be spelled like this:
diff -u result.1 file
That is, compare to show the difference actual output might have
from the expected result. It's easier to spot the difference
when you later break things this way.
> +test_expect_success 'merge c1 with c2' '
> + git reset --hard c1 &&
> + git merge c2 &&
> + test "$c1" = "$(git rev-parse HEAD^1)" &&
> + test "$c2" = "$(git rev-parse HEAD^2)"
> +'
We might also want to test:
- the index is merged;
- the working tree matches the index;
- the merge message (e.g. "git show -s --pretty=format:%s
HEAD") is as expected;
Otherwise I think it is a good idea to add these tests.
By the way, I think squash_message() leaves a wrong message
template for an Octopus, which might be worth fixing.
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: Alex Unleashed @ 2007-09-22 22:50 UTC (permalink / raw)
To: Kyle Rose; +Cc: Miles Bader, Dmitry Kakurin, Git
In-Reply-To: <46F55E03.2040404@krose.org>
On 9/22/07, Kyle Rose <krose@krose.org> wrote:
> C++ is in the same category as Perl IMO: too easy to produce unreadable
> code. I contend that C is pretty much just as bad, though in a
> different way: while C lacks C++'s ability to bury code in multiple
> layers of opaque abstractions, C makes up for it by providing absolutely
> no GC-type structures (i.e., I do this now, you clean it up later when
> I'm no longer interested in it). C is all explicit, which is nice when
> you have a good handle on everything that is going on *or* an explicit
> system for remembering to do those types of cleanup tasks that is
> well-understood by all developers involved.
I'd say being forced to be explicit is a good thing here, so that the
programmer at least has some sort of good understanding of what is
going on, and chances are that if he doesn't really know, things just
won't work out (quite unlike a lot of other languages where this
programmer might actually end up with something half-assed that
"mostly" works).
For some reason it seems to me a lot harder to find bad programmers
surviving using C than a lot of the other languages.
Alex
^ permalink raw reply
* Re: C++ *for Git*
From: Martin Langhoff @ 2007-09-22 22:24 UTC (permalink / raw)
To: Kyle Rose; +Cc: Dmitry Kakurin, Git
In-Reply-To: <46F5318A.4030103@krose.org>
On 9/23/07, Kyle Rose <krose@krose.org> wrote:
> But that's irrelevant: git is written in C. That's the way it is, and
> you should accept that or fork.
Or - as Marco's done - write complementary bits to git. I'm a
Perl-head, and I've ended up writing bits of Perl for git, some of
them have been reimplemented in C, some have stayed in Perl.
Arguing is a waste of time -- code! Help Marco, or write something new
and glorious. Make it useful for people who don't care what it's
written in, and beautiful so that the infidels are enlightened with
how elegant C++ can be.
Codefest > Flamefest
cheers,
m
^ permalink raw reply
* Re: [PATCH] Allow shell scripts to run with non-Bash /bin/sh
From: Adam Flott @ 2007-09-22 21:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhclngpgd.fsf@gitster.siamese.dyndns.org>
On Fri, 21 Sep 2007, Junio C Hamano wrote:
> I vaguely recall somebody else had exactly this issue and he
> concluded that the shell was busted. I do not recall the
> details of the story but interestingly, if he did something that
> accesses "$#" before the problematic "while case $# in ..." the
> shell behaved for him in his experiments.
That is what I did notice, just accessing $# fixed later uses of it.
> Also by my comment about "/bin/sh and bash not being the only
> shells available on FreeBSD", I did not mean that you should
> change your /bin/sh. You can build git with SHELL_PATH make
> varilable pointing at a non-broken shell, which does not have to
> be installed as /bin/sh.
If one's installing from the ports tree, then the port should depend on a
non-broken shell and set SHELL_PATH. And as for installing by hand, just print
out a warning that SHELL_PATH points to a broken shell and be done with it.
This is a FreeBSD bug, not a git one.
I had been meaning to write up a bug about this using a small test case, but I
couldn't reproduce it.
Adam
^ permalink raw reply
* [PATCH] git-submodule - allow a relative path as the subproject url
From: Mark Levedahl @ 2007-09-22 20:40 UTC (permalink / raw)
To: git; +Cc: Mark Levedahl
This allows a subproject's location to be specified and stored as relative
to the parent project's location (e.g., ./foo, or ../foo). This url is
stored in .gitmodules as given. It is resolved into an absolute url be
appending it to the parent project's url when the information is written
to .git/config (i.e., during submodule add for the originator, and
submodule init for a downstream recipient). This allows cloning of the
project to work "as expected" if the project is hosted on a different
server than when the subprojects were added.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
---
Documentation/git-submodule.txt | 3 +++
git-submodule.sh | 34 ++++++++++++++++++++++++++++++----
2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 2c48936..d421677 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -21,6 +21,9 @@ add::
repository is cloned at the specified path, added to the
changeset and registered in .gitmodules. If no path is
specified, the path is deduced from the repository specification.
+ If the repository url begins with ./ or ../, it is stored as
+ given but resolved as a relative path from the main project's
+ url when cloning.
status::
Show the status of the submodules. This will print the SHA-1 of the
diff --git a/git-submodule.sh b/git-submodule.sh
index 3320998..c553e14 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -39,6 +39,19 @@ get_repo_base() {
) 2>/dev/null
}
+# Get parent project's url
+get_parent_url ()
+{
+ # need to append this on parent project's url
+ branch="$(git branch --no-color | sed -ne 's/^\* //p')"
+ test -n "$branch" || die "I do not know what branch you are on: $branch"
+ upstream="$(git config branch.$branch.remote)"
+ test -n "$upstream" || die "Cannot find upstream repo for branch $branch"
+ uprepo="$(git config remote.$upstream.url)"
+ test -n "$upstream" || die "Cannot find url for repo $uprepo"
+ echo "$uprepo"
+}
+
#
# Map submodule path to submodule name
#
@@ -105,9 +118,16 @@ module_add()
# Turn the source into an absolute path if
# it is local
- if base=$(get_repo_base "$repo"); then
- repo="$base"
- fi
+ case $repo in
+ .*)
+ realrepo="$(get_parent_url)/$repo" ;;
+ *)
+ if base=$(get_repo_base "$repo"); then
+ repo="$base"
+ realrepo=$repo
+ fi
+ ;;
+ esac
# Guess path from repo if not specified or strip trailing slashes
if test -z "$path"; then
@@ -122,7 +142,7 @@ module_add()
git ls-files --error-unmatch "$path" > /dev/null 2>&1 &&
die "'$path' already exists in the index"
- module_clone "$path" "$repo" || exit
+ module_clone "$path" "$realrepo" || exit
(unset GIT_DIR && cd "$path" && git checkout -q ${branch:+-b "$branch" "origin/$branch"}) ||
die "Unable to checkout submodule '$path'"
git add "$path" ||
@@ -153,6 +173,12 @@ modules_init()
test -z "$url" &&
die "No url found for submodule path '$path' in .gitmodules"
+ # Possibly a url relative to parent
+ case $url in
+ .*)
+ url="$(get_parent_url)/$url";;
+ esac
+
git config submodule."$name".url "$url" ||
die "Failed to register url for submodule path '$path'"
--
1.5.3.1.36.gf01e8
^ permalink raw reply related
* [PATCH] new test from the submodule chapter of the user manual
From: Miklos Vajna @ 2007-09-22 20:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, J. Bruce Fields
In-Reply-To: <7v1wcrki96.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Fri, Sep 21, 2007 at 11:04:05AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> That's horrible. Please do not depend on object SHA1's to stay
> the same. If somebody makes a fix to the test to add a new file
> in a sample subproject it would break all the rest. Also please
> do not depend on the progress output.
okay, here is the third try. now checking for the result using diff-tree and
ls-files. hopefully i did what you expected :)
t/t3060-subprojects-tutorial.sh | 95 +++++++++++++++++++++++++++++++++++++++
1 files changed, 95 insertions(+), 0 deletions(-)
create mode 100755 t/t3060-subprojects-tutorial.sh
diff --git a/t/t3060-subprojects-tutorial.sh b/t/t3060-subprojects-tutorial.sh
new file mode 100755
index 0000000..d46dded
--- /dev/null
+++ b/t/t3060-subprojects-tutorial.sh
@@ -0,0 +1,95 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Miklos Vajna
+#
+
+test_description='A simple subprojects tutorial in the form of a test case'
+
+. ./test-lib.sh
+
+test_expect_success "create the submodules" '
+ for i in a b c d
+ do
+ mkdir $i &&
+ cd $i &&
+ git init &&
+ echo "module $i" > $i.txt &&
+ git add $i.txt &&
+ git commit -m "Initial commit, submodule $i" &&
+ cd ..
+ done
+'
+
+mkdir super
+cd super
+cat >expected << EOF
+:000000 100644 00000... A .gitmodules
+:000000 160000 00000... A a
+:000000 160000 00000... A b
+:000000 160000 00000... A c
+:000000 160000 00000... A d
+EOF
+
+test_expect_success "create the superproject" '
+ git init &&
+ echo super > super.txt &&
+ git add super.txt &&
+ git commit -m "initial" &&
+ for i in a b c d
+ do
+ git submodule add '`pwd`'/../$i
+ done &&
+ git commit -m "Add submodules a, b, c and d." &&
+ git diff-tree --abbrev=5 HEAD^ HEAD |cut -d" " -f-3,5- >current &&
+ cmp expected current
+'
+
+test_expect_success "checking if the correct commit is stored in the superproject" '
+ for i in a b c d
+ do
+ git ls-files -s $i|cut -d " " -f 2 > $i.actual &&
+ (cd $i && git-rev-parse HEAD) > $i.expected &&
+ cmp $i.actual $i.expected
+ done &&
+ cd ..
+'
+
+test_expect_success "clone the superproject" '
+ git clone super cloned &&
+ cd cloned
+'
+
+test_expect_success "submodule init" '
+ git submodule init
+'
+
+test_expect_success "submodule update" '
+ git submodule update
+'
+
+test_expect_success "checking the result of the commit in the cloned project" '
+ for i in a b c d
+ do
+ git ls-files -s $i|cut -d " " -f 2 > $i.actual &&
+ (cd $i && git-rev-parse HEAD) > $i.expected &&
+ cmp $i.actual $i.expected
+ done
+'
+
+test_expect_success "update the submodule from within the superproject" '
+ cd a &&
+ echo "adding a line again" >> a.txt &&
+ git commit -a -m "Updated the submodule from within the superproject." &&
+ git push &&
+ cd .. &&
+ git add a &&
+ git commit -m "Updated submodule a." &&
+ git push
+'
+
+test_expect_success "checking the result of the commit in the updated cloned project" '
+ git ls-files -s a|cut -d " " -f 2 > a.actual &&
+ (cd a && git-rev-parse HEAD) > a.expected &&
+ cmp a.actual a.expected
+'
+test_done
--
1.5.3.2.80.g077d6f-dirty
^ permalink raw reply related
* Re: [OT] Re: C++ *for Git*
From: David Kastrup @ 2007-09-22 19:11 UTC (permalink / raw)
To: Kyle Rose; +Cc: Miles Bader, Dmitry Kakurin, Git
In-Reply-To: <46F55E03.2040404@krose.org>
Kyle Rose <krose@krose.org> writes:
> Miles Bader wrote:
>> Of course, some of the most horrid unreadable source code I've ever seen
>> is in one of git's competitors -- written in python....
>
> Indeed. :-)
>
> At the office, people constantly badmouth Perl, which has some
> admittedly evil syntax (especially around exception handling).
Since Perl has agglomerated pretty much _every_ syntax, it is not
surprising that evil syntax is included.
> C++ is in the same category as Perl IMO: too easy to produce
> unreadable code.
Not quite. Perl gives you a hundred illegible ways to _say_ the same
thing, C++ gives you a hundred illegible ways to _achieve_ the same
thing, but using different means.
> I like Ruby, except for the performance problems. Once they have
> those worked out, Ruby will be "Perl done right." ;-)
Ruby again is in the "throw every syntactical idiom I can think of
together" ballpark. I find that a design mistake in Perl, a design
mistake in Ruby, and even in C++ (Ada syntax for templates was just
stupid, but at least there is no alternative syntax for it).
That's one of the things I like about Lua: its syntax fits on one page
in the reference manual. And the reference manual has a paper size of
about A5. While the syntax for Lisp would probably fit in the margin,
it does so at a cost in legibility.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: C++ *for Git*
From: Miles Bader @ 2007-09-22 18:08 UTC (permalink / raw)
To: Kyle Rose; +Cc: Dmitry Kakurin, Git
In-Reply-To: <46F5318A.4030103@krose.org>
Kyle Rose <krose@krose.org> writes:
> I think the exception handling, garbage collection, and implicit
> object destruction provided by those languages (and by C++, as
> overwrought as it is) makes any codebase easier to understand and
> maintain.
Of course, some of the most horrid unreadable source code I've ever seen
is in one of git's competitors -- written in python....
-Miles
--
=====
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.
^ permalink raw reply
* [OT] Re: C++ *for Git*
From: Kyle Rose @ 2007-09-22 18:25 UTC (permalink / raw)
To: Miles Bader; +Cc: Dmitry Kakurin, Git
In-Reply-To: <877imishdp.fsf@catnip.gol.com>
Miles Bader wrote:
> Of course, some of the most horrid unreadable source code I've ever seen
> is in one of git's competitors -- written in python....
Indeed. :-)
At the office, people constantly badmouth Perl, which has some
admittedly evil syntax (especially around exception handling). My view
is that good Perl programmers can produce good, readable, maintainable
Perl programs, while bad Perl programmers can produce spaghetti the
likes of which can't be found outside Italy.
OTOH, I think it is much harder to hang one's self with Python, though
admittedly possible, as it is when you combine a bad coder with *any*
language. Still, typical bad programmer + Perl is much worse than
typical bad programmer + Python.
C++ is in the same category as Perl IMO: too easy to produce unreadable
code. I contend that C is pretty much just as bad, though in a
different way: while C lacks C++'s ability to bury code in multiple
layers of opaque abstractions, C makes up for it by providing absolutely
no GC-type structures (i.e., I do this now, you clean it up later when
I'm no longer interested in it). C is all explicit, which is nice when
you have a good handle on everything that is going on *or* an explicit
system for remembering to do those types of cleanup tasks that is
well-understood by all developers involved.
I like Ruby, except for the performance problems. Once they have those
worked out, Ruby will be "Perl done right." ;-)
Kyle
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Steven Burns @ 2007-09-22 16:52 UTC (permalink / raw)
To: git
In-Reply-To: <fbr2iv$ugg$1@sea.gmane.org>
Another reason GC is sometimes surprisingly faster is not only you end up
allocating less times like you mention, but because some GC are compacting
garbage collectors and that simplyfies allocations dramatically because
allocating memory is just increasing a pointer. Compare that to the way most
C++ heaps get implemented.
I don't know if that's the case with D's GC though.
I completely understand what you say about the strings and who owns it, I've
ran into the same situation a hundred times, not only with strings but with
vectors, matrixes, lists, etc.
After reading your post, I think I will have to revisit D sometime.
I read about it a few years ago and I got the impression some syntax
decisions had been made to ease the writing of the compiler as opposed to
favoring the end user/programmer, but it's been a while and maybe I was too
quick to judge.
Steven
"Walter Bright" <boost@digitalmars.com> wrote in message
news:fbr2iv$ugg$1@sea.gmane.org...
> Wincent Colaiuta wrote:
>> Git is all about speed, and C is the best choice for speed, especially in
>> context of Git's workload.
>
> I can appreciate that. I originally got into writing compilers because my
> game (Empire) ran too slowly and I thought the existing compilers could be
> dramatically improved.
>
> And technically, yes, you can write code in C that is >= the speed of any
> other language (other than asm). But practically, this isn't necessarily
> so, for the following reasons:
>
> 1) You wind up having to implement the complex, dirty details of things
> yourself. The consequences of this are:
>
> a) you pick a simpler algorithm (which is likely less efficient - I run
> across bubble sorts all the time in code)
>
> b) once you implement, tune, and squeeze all the bugs out of those
> complex, dirty details, you're reluctant to change it. You're reluctant to
> try a different algorithm to see if it's faster. I've seen this effect a
> lot in my own code. (I translated a large body of my own C++ code that I'd
> spent months tuning to D, and quickly managed to get significantly more
> speed out of it, because it was much simpler to try out different
> algorithms/data structures.)
>
> 2) Garbage collection has an interesting and counterintuitive consequence.
> If you compare n malloc/free's with n gcnew/collections, the malloc/free
> will come out faster, and you conclude that gc is slow. But that misses
> one huge speed advantage of gc - you can do FAR fewer allocations! For
> example, I've done a lot of string manipulating programs in C. The basic
> problem is keeping track of who owns each string. This is done by, when in
> doubt, make a copy of the string.
>
> But if you have gc, you don't worry about who owns the string. You just
> make another pointer to it. D takes this a step further with the concept
> of array slicing, where one creates windows on existing arrays, or windows
> on windows on windows, and no allocations are ever done. It's just pointer
> fiddling.
>
> ------
> Walter Bright
> http://www.digitalmars.com C, C++, D programming language compilers
> http://www.astoriaseminar.com Extraordinary C++
>
^ permalink raw reply
* Re: C++ *for Git*
From: Marco Costalba @ 2007-09-22 15:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Kakurin, Git
In-Reply-To: <Pine.LNX.4.64.0709221348180.28395@racer.site>
On 9/22/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> We don't want C++. Why is that so hard to accept?
>
Dmitry, I think what Johannes says in the above line is 100% the core
point of this (sad) discussion.
You cannot force/convince someone to use something he hates. That's
it. And there's no point in trying to do this.
git developers were also kind enough to give explanations on 'why' C++
is not a good language for them. Do you don't agree? do you find the
arguments not totally satisfying for you? That's not their problem.
I like C++ (a my little git related GUI tool called qgit is done in
C++) and at the same time I understand also much of the concerns that
where expressed in the list.
Your position will never be successful for a number of reasons, some
clear expressed other less clear but at the same time, perhaps more
important. So I really don't understand why you insist.
Thanks
Marco
P.S: The example you show is a pity for C++, it's like to advertise a
1000cc 200Hp motorbike saying "...and you will no have problems in
parking in your box."
^ permalink raw reply
* Re: C++ *for Git*
From: Kyle Rose @ 2007-09-22 15:15 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Git
In-Reply-To: <ABE0ABE82AE84593A2B71B0281F4C814@ntdev.corp.microsoft.com>
You know, git *is* free software. Feel free to fork it and add all the
C++ code you want.
FWIW, I am of the opinion that Python or Ruby (or god forbid, Perl)
would have been a better choice for something like git that does lots of
text processing... furthermore, I think the exception handling, garbage
collection, and implicit object destruction provided by those languages
(and by C++, as overwrought as it is) makes any codebase easier to
understand and maintain.
But that's irrelevant: git is written in C. That's the way it is, and
you should accept that or fork.
Kyle
Dmitry Kakurin wrote:
> We've had this theoretical (and IMHO pointless) discussion C vs. C++ *in
> general*.
> In no way I want to restart it.
^ permalink raw reply
* Re: fromcvs installation [was: cvsimport bug on branches [was: conversion to git]]
From: Simon 'corecode' Schubert @ 2007-09-22 15:08 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Robin Rosenberg, Johannes Schindelin, Git Mailing List
In-Reply-To: <86B33DFE-65E6-4F8D-8483-509ACA4FA2F8@zib.de>
Steffen Prohaska wrote:
> Nonetheless a more detailed description how to install fromcvs
> would be helpful. I remember it was not obvious to me.
[..]
> I think a step by step explanation how to proceed would have helped me.
Could you write down what you had to do and where the problems are as an
extension to the current README?
Thanks,
simon
^ permalink raw reply
* Re: C++ *for Git*
From: Johannes Schindelin @ 2007-09-22 12:48 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Git
In-Reply-To: <ABE0ABE82AE84593A2B71B0281F4C814@ntdev.corp.microsoft.com>
Hi,
On Sat, 22 Sep 2007, Dmitry Kakurin wrote:
> We've had this theoretical (and IMHO pointless) discussion C vs. C++ *in
> general*.
I think "pointless" is more to the point.
We don't want C++. Why is that so hard to accept?
Ciao,
Dscho
^ permalink raw reply
* Re: Git as a filesystem
From: Johannes Schindelin @ 2007-09-22 12:06 UTC (permalink / raw)
To: Eric Wong; +Cc: Nicolas Pitre, Peter Stahlir, git
In-Reply-To: <20070922020632.GB8327@muzzle>
Hi,
On Fri, 21 Sep 2007, Eric Wong wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Fri, 21 Sep 2007, Eric Wong wrote:
> > >
> > > On a similar note, has anybody experimented with using git to store
> > > maildirs or news spools? I'd imagine the quoted portions of most
> > > message threads could be delta-compressed quite efficiently.
> >
> > I store all my mail in a git repository. Works beautifully. Except
> > that the buffers on my laptop are constantly full :-( So a simple
> > commit takes some waiting.
> >
> > Should be no issue on normal (desktop) machines.
>
> D'oh. I already have maildir performance problems on my laptop.
Umm. Regular operation is not affected, since I (add and) commit only
when I weeded out all those spams and other unwanted mail.
> I wonder how well only having an index and no commits (no versioning),
> and manual packing with pack-objects would work. Packing could be
> optimized to order objects based on the Message-Id, References, and
> In-Reply-To headers, too.
The most efficient way would be to have a mailer backend accessing the
database, and then not have a working directory, methinks (especially with
these amounts of mail I am juggling ATM).
Time forbids working on this, though.
Ciao,
Dscho
^ permalink raw reply
* Re: C++ *for Git*
From: David Kastrup @ 2007-09-22 11:11 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Git
In-Reply-To: <ABE0ABE82AE84593A2B71B0281F4C814@ntdev.corp.microsoft.com>
Dmitry Kakurin <dmitry.kakurin@gmail.com> writes:
> We've had this theoretical (and IMHO pointless) discussion C vs. C++
> *in general*.
> In no way I want to restart it.
Then don't.
> Just a very straight-forward usage of only 3 C++ features:
> 1. Constructors
> 2. Destructors
> 3. Better syntax (ext_header.append_ext_header
> vs. strbuf_append_ext_header(&ext_header, )
>
> The generated code will be exactly the same.
It won't. It will _do_ exactly the same (modulo the tenfold
likelihood of compiler bugs) but hardly using the same code.
> Yet the source code becomes more readable and MUCH less error
> prone. How is this not a win?
Because it is just your claim that this is more readable.
> One (sensible) argument that I've heard in the previous discussion
> was: you let a little bit of C++ in and then it gets more and more
> complex and the code quality decreases.
> This problem is solved by having "quality gates".
> Again, *for Git* these quality gates already exist: only few people
> have "commit access".
> If/when somebody tries to be too fancy, what stops Junio from replying
> "we don't use Library-X/C++-feature-Y in Git, please change your code
> and resubmit" and throwing that fix away? Nothing.
Well, what stops him from replying "we don't use C++ in Git, please
change your code and resubmit"?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] Allow shell scripts to run with non-Bash /bin/sh
From: David Kastrup @ 2007-09-22 11:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4wbgp9t.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> Eygene Ryabinkin <rea-git@codelabs.ru> writes:
>>
>>>> That is, what does the shell say if you do this?
>>>>
>>>> case Ultra in
>>>> Super)
>>>> false ;;
>>>> Hyper)
>>>> true ;;
>>>> esac &&
>>>> echo case returned ok
>>>
>>> It says 'case returned ok', so I will try to understand why it
>>> works here and does not work in the 'while' construct.
>>
>> What you actually need to do is
>>
>> false
>> case Ultra in
>> Super)
>> false ;;
>> Hyper)
>> true ;;
>> esac && echo case returned ok
>
> AHHHHHH.
>
> Is "case" supposed to be transparent?
Not that I would know. It is basically a revival of the
false
if false then : ; fi || echo "this fails!?!"
bug that probably has been fixed by now. For obvious reasons,
conditionals without a taken branch are considered to have an exit
code of 0.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* C++ *for Git*
From: Dmitry Kakurin @ 2007-09-22 10:42 UTC (permalink / raw)
To: Git
We've had this theoretical (and IMHO pointless) discussion C vs. C++ *in
general*.
In no way I want to restart it. But *very specifically*, and *for Git*:
We already have strbuf "class" to do string/buffer manipulations.
Kudos to Pierre Habouzit for doing the refactoring work!
Now, what I fail to understand is how this:
static void write_global_extended_header(const unsigned char *sha1)
{
struct strbuf ext_header;
strbuf_init(&ext_header, 0);
strbuf_append_ext_header(&ext_header, "comment", sha1_to_hex(sha1), 40);
write_entry(NULL, NULL, 0, ext_header.buf, ext_header.len);
strbuf_release(&ext_header);
}
is better than this:
static void write_global_extended_header(const unsigned char *sha1)
{
strbuf ext_header;
ext_header.append_ext_header("comment", sha1_to_hex(sha1), 40);
write_entry(NULL, NULL, 0, ext_header.buf, ext_header.len);
}
?
Note, there is no Boost/multiple inheritance/template
metaprogramming/std::string/whatever-else-scares-you-in-C++ in the second
piece of code.
Just a very straight-forward usage of only 3 C++ features:
1. Constructors
2. Destructors
3. Better syntax (ext_header.append_ext_header vs.
strbuf_append_ext_header(&ext_header, )
The generated code will be exactly the same.
Yet the source code becomes more readable and MUCH less error prone. How is
this not a win?
One (sensible) argument that I've heard in the previous discussion was: you
let a little bit of C++ in and then it gets more and more complex and the
code quality decreases.
This problem is solved by having "quality gates".
Again, *for Git* these quality gates already exist: only few people have
"commit access".
If/when somebody tries to be too fancy, what stops Junio from replying "we
don't use Library-X/C++-feature-Y in Git, please change your code and
resubmit" and throwing that fix away? Nothing.
- Dmitry
^ permalink raw reply
* Re: [PATCH] git-svn: handle changed svn command-line syntax
From: Karl Hasselström @ 2007-09-22 9:06 UTC (permalink / raw)
To: Eric Wong; +Cc: Sam Vilain, git
In-Reply-To: <20070921082348.GA5152@mayonaise>
On 2007-09-21 01:23:48 -0700, Eric Wong wrote:
> The @REV and -rREV distinction/ambiguity has always confused me in svn,
> too. It always seems that it needed to be one way sometimes, the other
> way at other times, and even _both_ at other times...
-rREV specifies the operative revision, and @REV specifies the peg
revision. See the clear but dreadfully long explanation here:
http://svnbook.red-bean.com/en/1.4/svn.advanced.pegrevs.html
In short, it's a way to manage the complexity that comes from
considering files (and directories!) to have an identity that is
preserved across copies and renames.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Use "" instead of "<unknown>" for placeholders
From: Michal Vitecek @ 2007-09-22 8:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vk5qjixqy.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>>>>>> I made it because I want to use my own pretty format which currently
>>>>>> only allows '%s' for subject and '%b' for body. But '%b' is
>>>>>> substituted with <undefined> if the body is "missing" which I
>>>>>> obviously don't like :)
>>>>> Then you should fix %b not to show "<undefined>".
>>>> I'll do it if it is okay. Shall I do the same for the other
>>>> placeholders as well?
>>> Yeah. Don't know why I did it that way.
>> Here comes the big patch :)
>
> Now, this breaks t6006 which needs this patch.
Oops - I'm sorry about that. I ran the test suite (1.5.3.1) but it
failed in 2 tests before the patch and in 2 tests after it so I
considered it okay.
> Looking at this patch, I am not sure if your change is really a
> desirable one --- shouldn't it be removing the line itself, not
> just <unknown> token?
This sounds as the best solution. I'll look into it. Thanks for your time.
--
fuf (fuf@mageo.cz)
^ 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