* Re: [PATCH 3/5] git-merge: add support for branch.<name>.mergeoptions
From: Lars Hjemli @ 2007-09-23 10:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vps0adx0x.fsf@gitster.siamese.dyndns.org>
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").
--
larsh
^ permalink raw reply
* Re: [PATCH 1/5] Add test-script for git-merge porcelain
From: Lars Hjemli @ 2007-09-23 10:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsuidx1a.fsf@gitster.siamese.dyndns.org>
On 9/23/07, Junio C Hamano <gitster@pobox.com> wrote:
> 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" ;-).
Heh, ok
> > + 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.
Good point, I'll change it.
>
> > +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;
Yes, sorry for being lazy ;-) I'll add more thorough verification
>
> 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.
Ok, I'll try to detect it in the test-script and send a proper fix.
Thanks for the review.
--
larsh
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: Marco Costalba @ 2007-09-23 9:50 UTC (permalink / raw)
To: David Kastrup
Cc: Frank Lichtenheld, Alex Unleashed, Kyle Rose, Miles Bader,
Dmitry Kakurin, Git
In-Reply-To: <856421ra3l.fsf@lola.goethe.zz>
On 9/23/07, David Kastrup <dak@gnu.org> wrote:
> >
> > Well, according to your reasoning
>
> Who is "you"? You are replying to a post of mine, yet commenting on
> Alex.
>
Sorry, you are right, I'm not meticolus either ;-)
Marco
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: David Kastrup @ 2007-09-23 9:42 UTC (permalink / raw)
To: Marco Costalba
Cc: Frank Lichtenheld, Alex Unleashed, Kyle Rose, Miles Bader,
Dmitry Kakurin, Git
In-Reply-To: <e5bfff550709230229t79004ce2j5ce8c2ae7744a7f2@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> On 9/23/07, David Kastrup <dak@gnu.org> wrote:
>> David Brown <git@davidb.org> writes:
>>
>> > On Sun, Sep 23, 2007 at 04:09:51AM +0200, Frank Lichtenheld wrote:
>> >>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.
>> >>
>
> Well, according to your reasoning
Who is "you"? You are replying to a post of mine, yet commenting on
Alex.
> assembly should be the gotha of elite programmers, only very
> disciplined and meticulous programmers survive, much more then in C.
I am neither disciplined nor meticulous, yet have designed and
programmed applications and complete systems in assembly language.
Programmers can easily survive assembly language without being
disciplined or meticulous. Their projects can't: they get tied to the
programmers. Porting an assembly language application to a different
processor might be easier than porting it to another programmer.
> Is this a good way to measure a language?
It is a good way to measure programmers, at least concerning some
interesting metrics.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: Marco Costalba @ 2007-09-23 9:29 UTC (permalink / raw)
To: David Kastrup
Cc: Frank Lichtenheld, Alex Unleashed, Kyle Rose, Miles Bader,
Dmitry Kakurin, Git
In-Reply-To: <851wcpsv4z.fsf@lola.goethe.zz>
On 9/23/07, David Kastrup <dak@gnu.org> wrote:
> David Brown <git@davidb.org> writes:
>
> > On Sun, Sep 23, 2007 at 04:09:51AM +0200, Frank Lichtenheld wrote:
> >>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.
> >>
Well, according to your reasoning assembly should be the gotha of
elite programmers, only very disciplined and meticulous programmers
survive, much more then in C.
Is this a good way to measure a language?
>
> C++ is good for creating black boxes.
Object oriented languages creates black boxes: that's the reason why
object oriented exsists and also the reason why Linus hates it ;-)
Difference between C++ and other OO languages is mostly in the size of
the applications written in that language IMHO.
C++ noramlly has the bigger code bases, so problem you mention are
enanched and perhaps seem to depend on the language itself not on the
size of application. IOW a Python (Ruby) app probably does not have
the size of Firefox or Open Office, this _could_ induce the naive idea
that the python app is cleaner or easier to understand just becasue of
Python vc C++.
I really don't think so. I think this could be true for toy problems,
but for real, for big applications is the design of the appllcation,
not the language, that at 90% state the difference between clean and
crap.
>A black box that has been
> fitted into its environment and that has good innards is fine. A
> black box with rotten innards, or not really being well-suited for the
> job at hand, isn't.
I really agree here. The biggset downside of OO is that for it to work
you should have a much deeper knowledge of the problem you want to
handle. OO force you to analyze more and know more because a bad
design normally means throwing everything in the trash can and start
again.
Procedural programming as C is more immune to this 'good problem
analysis' dependency.
Marco
^ permalink raw reply
* Re: [PATCH] Allow shell scripts to run with non-Bash /bin/sh
From: David Kastrup @ 2007-09-23 8:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eygene Ryabinkin, git
In-Reply-To: <7vtzpnf6c9.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Eygene Ryabinkin <rea-git@codelabs.ru> writes:
>
>> OK, you're right. Especially if /bin/sh from Solaris and OpenBSD
>> are working and they are not Bash. But I would not tell that
>> the shell is broken now -- I had not seen the POSIX specification.
>> Does it specifies how the shell should work in this case?
>
> I have always been assuming it to be the case (this construct is
> not my invention but is an old school idiom I just inherited
> from my mentor) and never looked at the spec recently, but I
> re-read it just to make sure. The answer is yes.
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, and I find a non-matching case statement, POSIX or not, quite
unobvious in the place of a true while condition.
It is a bit too much of cleverness for my taste. Never mind that the
current FreeBSD shell does not understand it due to being buggy: I
find that this is not very readable to the human reader either without
a double take.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] Allow shell scripts to run with non-Bash /bin/sh
From: Eygene Ryabinkin @ 2007-09-23 8:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzpnf6c9.fsf@gitster.siamese.dyndns.org>
Junio, *, good day.
Sat, Sep 22, 2007 at 01:32:38AM -0700, Junio C Hamano wrote:
> > OK, you're right. Especially if /bin/sh from Solaris and OpenBSD
> > are working and they are not Bash. But I would not tell that
> > the shell is broken now -- I had not seen the POSIX specification.
> > Does it specifies how the shell should work in this case?
>
> I have always been assuming it to be the case (this construct is
> not my invention but is an old school idiom I just inherited
> from my mentor) and never looked at the spec recently, but I
> re-read it just to make sure. The answer is yes.
>
> Visit http://www.opengroup.org/onlinepubs/000095399/ and follow
> "Shell and Utilities volume (XCU)" and then "Case conditional
> construct".
Yes, thanks for the pointer.
> So, as David suggests, if
>
> false
> case Ultra in
> Super) false ;;
> Hyper) true ;;
> esac && echo case returned ok
>
> does not say "case returned ok", then the shell has a bit of
> problem.
Correct: the current /bin/sh for FreeBSD does not set zero exit
code if no case patterns were matched. So, I apologize for my quick
decision on the non-brokenness of the /bin/sh -- it is broken.
I had fixed the shell and filed the problem report. May be the
change will be incorporated into the future release of FreeBSD.
Meanwhile, I had added workarounds to the other places Junio mentioned
in his follow-up and will try to push this patch to the FreeBSD
port of Git. The explanation had been changed too ;))
Thanks to all people who helped me to realize what is wrong and where!
--
Eygene
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: David Kastrup @ 2007-09-23 7:23 UTC (permalink / raw)
To: Frank Lichtenheld
Cc: Alex Unleashed, Kyle Rose, Miles Bader, Dmitry Kakurin, Git
In-Reply-To: <20070923062527.GA8979@old.davidb.org>
David Brown <git@davidb.org> writes:
> On Sun, Sep 23, 2007 at 04:09:51AM +0200, Frank Lichtenheld wrote:
>>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...
>
> I work with plenty of them :-) It's all C. All of the same things
> happen, with management looking for magic bullets to solve problems
> caused by bad programmers.
C++ is good for creating black boxes. A black box that has been
fitted into its environment and that has good innards is fine. A
black box with rotten innards, or not really being well-suited for the
job at hand, isn't. For a project where people come and go, black
boxes might hide a lot about bad design and implementation.
In particular, changing an algorithm to require different black boxes
is something that is very unpleasant to do.
Having everything in the open is an advantage as long as the
complexity to be managed is at a reasonable level.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [OT] Re: C++ *for Git*
From: David Brown @ 2007-09-23 6:25 UTC (permalink / raw)
To: Frank Lichtenheld
Cc: Alex Unleashed, Kyle Rose, Miles Bader, Dmitry Kakurin, Git
In-Reply-To: <20070923020951.GF24423@planck.djpig.de>
On Sun, Sep 23, 2007 at 04:09:51AM +0200, Frank Lichtenheld wrote:
>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...
I work with plenty of them :-) It's all C. All of the same things happen,
with management looking for magic bullets to solve problems caused by bad
programmers.
Dave
^ permalink raw reply
* 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
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