* [PATCH] array index mixup
From: Matthias Lederhofer @ 2006-07-15 12:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <e9aff7$nk1$1@sea.gmane.org>
---
Jakub Narebski <jnareb@gmail.com> wrote:
> git diff output for files specified by revision is somewhat unexpected.
>
> $ git diff <revision_1>:<file> <revision_2>:<file>
>
> outputs the following diff metainfo
>
> diff --git a/<revision_2>:<file> b/<revision_2>:<file>
> index 5eabe06..2e87de4 100644
> --- a/<revision_2>:<file>
> +++ b/<revision_2>:<file>
>
> Is it intended, or is it a bug? Looks like a bug to me...
I dunno if this is really an index mixup or was intended. If this is
intended please add a comment what it's for. (Without this you get
rename information, perhaps this is the reason.)
---
builtin-diff.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-diff.c b/builtin-diff.c
index cb38f44..4d43a5c 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -136,7 +136,7 @@ static int builtin_diff_blobs(struct rev
stuff_change(&revs->diffopt,
mode, mode,
blob[1].sha1, blob[0].sha1,
- blob[0].name, blob[0].name);
+ blob[1].name, blob[0].name);
diffcore_std(&revs->diffopt);
diff_flush(&revs->diffopt);
return 0;
--
1.4.1.ga3e6
^ permalink raw reply related
* :), Pan-slavonism
From: Elliott Gagnon @ 2006-07-15 18:26 UTC (permalink / raw)
To: git-commits-head-owner
Even if you have no erectin problems SOFT CIAGLIS
would help you to make BETTER SE6X MORE OFTEN!
and to bring unimagnable plesure to her.
Just disolve half a pil under your tongue
and get ready for action in 15 minutes.
The tests showed that the majority of men
after taking this medic ation were able to have
PERFECT ER3ECTION during 36 hours!
VISIT US, AND GET OUR SPECIAL 70% DISCPOUNT OFER!
http://1XUV88ehdhvqwlejr881dq81v88q.snowkdj.com/
==========
the fishing boats were specks in the flat blue water, Breakfast Flock was
"Well, I don't either. That's true. But now for the First time we know
science fiction called swords-and-sorcery. And among its highest virtues is
five hours to a stalker? A snap. How about twelve? Or how about two days? If
When they could see again, Chiang was gone.
He didn't answer. The water was making a lot of noise.
He spoke of very simple things - that it is right for a guil to fly,
windows weren't broken. Only they were so dirty that they looked blind. At
^ permalink raw reply
* [PATCH] git-svn: don't check for migrations/upgrades on commit-diff
From: Eric Wong @ 2006-07-15 14:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
Unlike other git-svn commands, commit-diff is intended to
operate without needing any additional metadata inside .git
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 4530ffe..89ad840 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -147,7 +147,7 @@ init_vars();
load_authors() if $_authors;
load_all_refs() if $_branch_all_refs;
svn_compat_check() unless $_use_lib;
-migration_check() unless $cmd =~ /^(?:init|rebuild|multi-init)$/;
+migration_check() unless $cmd =~ /^(?:init|rebuild|multi-init|commit-diff)$/;
$cmd{$cmd}->[0]->(@ARGV);
exit 0;
--
1.4.1.gb805
^ permalink raw reply related
* The newest Every man wishes it. Revel in
From: Kurt @ 2006-07-15 18:24 UTC (permalink / raw)
To: gord
Yo!
Have you ever wanted to impress your girl?
But some of us think it’s impossible
Take this and your woman will be speechless
Come in: http://lingvert.com/gall/
The prices are really low and the quality it truly very high!
^ permalink raw reply
* Re: disable the compile-flags-changed check
From: Matthias Lederhofer @ 2006-07-15 19:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j2gsotv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Matthias Lederhofer <matled@gmx.net> writes:
>
> > Is there any way to disable the "the compile flags have changed,
> > recompile everything" check? I want to built with another prefix than
> > installing to create a tarball I copy to other machines. Is there any
> > way to do this?
>
> Perhaps
>
> DESTDIR=/var/tmp/ make prefix=/usr install
>
> is what you are looking for?
Thanks, this works.
^ permalink raw reply
* Re: disable the compile-flags-changed check
From: Junio C Hamano @ 2006-07-15 21:48 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1G1qAS-0005gv-P7@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> Matthias Lederhofer <matled@gmx.net> writes:
>>
>> > Is there any way to disable the "the compile flags have changed,
>> > recompile everything" check? I want to built with another prefix than
>> > installing to create a tarball I copy to other machines. Is there any
>> > way to do this?
>>
>> Perhaps
>>
>> DESTDIR=/var/tmp/ make prefix=/usr install
>>
>> is what you are looking for?
>
> Thanks, this works.
By the way, in older days before binary distributions have
become _the_ way for the end users to get programs, "install
into a saparate place for tarring up" needed to be custom job
per package, because Makefiles of many packages were not set up
to easily allow it (like DESTDIR= stuff). These days, allowing
it is almost a requirement in order to make binary distros'
lives easier, so if a program is packaged for some binary
distros (say, RPM or deb), often the easiest way to figure out
the answer to your question is to see how they build their
packages out of the source.
^ permalink raw reply
* git merge performance problem..
From: Linus Torvalds @ 2006-07-15 21:48 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Junio, I think there is something wrong with git-merge. It sometimes takes
up to ten seconds, and it's stuck at the
git-show-branch --independent "$head" "$@"
call.
I don't know quite what that thing is even meant to do (we do already know
the parents, why do we do something special here?) but even apart from
that, the whole thing must be doing something seriously wrong, since it
takes so long. Does it check the whole commit history?
Linus
^ permalink raw reply
* * LIVE DEALERS & Fast Downloads
From: Basil @ 2006-07-16 2:35 UTC (permalink / raw)
To: git
Halo!
Hi Rolelr is the best in the industry because we offer:
* 24-hour support
* LIVE DEALERS & Fast Downloads
* Hi Roller Cassino is one of the oldest and most established online cassino.
* Several options that allow you to control the playing environment
Give us a try! Remember, Free $88.800 is ON THE HOUSE!
How can you possibly turn that down?
Start Winning Now!
http://uveltord.com/d1/check/
It nah good to shove yuh foot in every stocking. Moon ah run till daylight ketch am. A celebrity is someone who works hard all his life to become known and then wears dark glasses to avoid being recognized. Half a loaf is better than no bread Lookers on see most of the game
^ permalink raw reply
* Re: git merge performance problem..
From: Junio C Hamano @ 2006-07-16 3:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607151445270.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Junio, I think there is something wrong with git-merge. It sometimes takes
> up to ten seconds, and it's stuck at the
>
> git-show-branch --independent "$head" "$@"
>
> call.
>
> I don't know quite what that thing is even meant to do (we do already know
> the parents, why do we do something special here?) but even apart from
> that, the whole thing must be doing something seriously wrong, since it
> takes so long. Does it check the whole commit history?
The code is to cull redundant parents primarily in octopus and
is not strictly necessary. Can I have the $head and $@ (the
other merge parents, but in your case you never do an octopus so
that would be the other branch head) to see what is going on
please? It should not descend down the history all the way but
with the recent changes to the object marking/unmarking code it
is possible we might have broken something.
^ permalink raw reply
* Enjoy the newest Onlline Casino. Go and Play It
From: Erica @ 2006-07-16 3:19 UTC (permalink / raw)
To: git
Hi
Online Casino wwith 85+ games. Play It Now! http://wegast.com/d1/ace/
Wisdom crieth without; she uttereth her voice in the streets. Empty sacks will never stand upright
^ permalink raw reply
* Re: git merge performance problem..
From: Junio C Hamano @ 2006-07-16 4:24 UTC (permalink / raw)
To: git
In-Reply-To: <7v7j2eme3u.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> Junio, I think there is something wrong with git-merge. It sometimes takes
>> up to ten seconds, and it's stuck at the
>>
>> git-show-branch --independent "$head" "$@"
>>
>> call.
>>
>> I don't know quite what that thing is even meant to do (we do already know
>> the parents, why do we do something special here?) but even apart from
>> that, the whole thing must be doing something seriously wrong, since it
>> takes so long. Does it check the whole commit history?
>
> The code is to cull redundant parents primarily in octopus and
> is not strictly necessary.
Wrong. The commit log says it was to remove redundant parents;
I think this as a reaction after seeing a few incorrectly made
merge commits in the kernel archive.
> ..., but in your case you never do an octopus so
> that would be the other branch head) to see what is going on
> please?
Disregard this request please. I see a few commits that this
step takes a long time to process in the kernel archive. The
last merge before you left to Ottawa was one of them.
b5032a5 48ce8b0
I do not think we need to do the --independent check there
especially for two-head cases because we have already done
fast-forward and up-to-date tests when we get there, so let's
revert that part from commit 6ea2334.
-- >8 --
diff --git a/git-merge.sh b/git-merge.sh
index 24e3b50..ee41077 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -314,7 +314,11 @@ # If we have a resulting tree, that mean
# auto resolved the merge cleanly.
if test '' != "$result_tree"
then
- parents=$(git-show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
+ parents="-p $head"
+ for remote
+ do
+ parents="$parents -p $remote"
+ done
result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree $parents) || exit
finish "$result_commit" "Merge $result_commit, made by $wt_strategy."
dropsave
^ permalink raw reply related
* Re: git merge performance problem..
From: Linus Torvalds @ 2006-07-16 4:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v7j2eme3u.fsf@assigned-by-dhcp.cox.net>
On Sat, 15 Jul 2006, Junio C Hamano wrote:
>
> The code is to cull redundant parents primarily in octopus and
> is not strictly necessary. Can I have the $head and $@ (the
> other merge parents, but in your case you never do an octopus so
> that would be the other branch head) to see what is going on
> please?
I think it was commit b20e481 that I reacted to this time, merging b5032a5
and 48ce8b0.
Ie, lookie here:
[torvalds@evo linux]$ time git merge-base --all b5032a5 48ce8b0
672c6108a51bf559d19595d9f8193dfd81f0f752
real 0m1.426s
user 0m1.404s
sys 0m0.016s
so it can find a merge-base in 1.4 seconds, which should certainly
guarantee that they are independent. Then:
[torvalds@evo linux]$ time git-show-branch --independent b5032a5 48ce8b0
b5032a50aea76b6230db74b1d171a7f56b204bb7
48ce8b056c88920c8ac187781048f5dae33c81b9
real 0m30.657s
user 0m30.414s
sys 0m0.076s
Whee. Half a minute. Ok, so this is on my laptop (I'm oat the airport
right now), so it was probably twice as fast on my desktop, but that is
still not acceptable.
I really don't know what it's doing, because
[torvalds@evo linux]$ time git-rev-list b5032a5 48ce8b0 > /dev/null
real 0m3.248s
user 0m2.588s
sys 0m0.036s
so it's really doing something very expensive - more so than just parsing
the commits.
Linus
^ permalink raw reply
* Re: git merge performance problem..
From: Linus Torvalds @ 2006-07-16 4:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkqukwhb.fsf@assigned-by-dhcp.cox.net>
On Sat, 15 Jul 2006, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
> >
> > The code is to cull redundant parents primarily in octopus and
> > is not strictly necessary.
>
> Wrong. The commit log says it was to remove redundant parents;
> I think this as a reaction after seeing a few incorrectly made
> merge commits in the kernel archive.
Arguing with yourself? ;)
But that should already have been handled by the fact that we did the
merge-base improvements. So I don't really see why we'd need the extremely
heavy git-show-branch.
I think the problems we had with rmk generating patches that had two
parents but really were _meant_ to be regular patches were due to an
independent problem, namely that we'd commit with a stale MERGE_HEAD from
a previous (failed) merge that was never done.
I think. It's a long time ago.
> Disregard this request please. I see a few commits that this
> step takes a long time to process in the kernel archive. The
> last merge before you left to Ottawa was one of them.
>
> b5032a5 48ce8b0
Yup.
And your patch will obviously fix it (by not calling git-show-branch at
all), but I'm still left wondering why git-show-branch took that long in
the first place. Half a minute when traversing the whole commit history
only takes three seconds (as per my previous email)?
Now, as long as nothing I use actually ends up using git-show-branch, I
won't care, but maybe a sign that something else can be improved?
Traditionally, what has made things _that_ slow has almost always been
logic that traverses all sides of a merge, without having the logic to
ignore already-seen commits (so each merge basically doubles the number of
commits we will traverse, and the problem size goes from O(n+m) to O(m^2)
where 'n' is number of commits, and 'm' is number of merges.
Or is git-show-branch doing something else really expensive?
Linus
^ permalink raw reply
* Re: git merge performance problem..
From: Junio C Hamano @ 2006-07-16 6:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607152136010.2438@evo.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sat, 15 Jul 2006, Junio C Hamano wrote:
>> Junio C Hamano <junkio@cox.net> writes:
>> >
>> > The code is to cull redundant parents primarily in octopus and
>> > is not strictly necessary.
>>
>> Wrong. The commit log says it was to remove redundant parents;
>> I think this as a reaction after seeing a few incorrectly made
>> merge commits in the kernel archive.
>
> Arguing with yourself? ;)
Yes, I was kind of tired ;-)
> And your patch will obviously fix it (by not calling git-show-branch at
> all), but I'm still left wondering why git-show-branch took that long in
> the first place. Half a minute when traversing the whole commit history
> only takes three seconds (as per my previous email)?
>
> Now, as long as nothing I use actually ends up using git-show-branch, I
> won't care, but maybe a sign that something else can be improved?
I instrumented builtin-show-branch.c::join_revs() and
commit.c::merge-bases(), and run another problematic case
between commits 1d3737 and 7f2857. They traverse exactly the
same commits in the same order. After all in two head case they
are essentially the same algorithm, modulo that the heuristics
with horizon effect has not been removed from join_revs() yet.
Similarly, "merge-base --all" vs "show-branch --merge-base"
between these commits has the same issue. Although they
traverse exactly the same set of commits, the former takes 10x
longer for some reason.
And (drumroll please), thanks to gprof, the guilty party turns
out to be insert_by_date() in mark_seen().
I think this will fix both problems.
-- >8 --
show-branch: fix performance problem.
The core function used in show-branch, join_revs(), was supposed
to be exactly the same algorithm as merge_bases(), except that
it was a version enhanced for use with more than two heads.
However, it needed to mark and keep a list of all the commits it
has seen, because it needed them for its semi-graphical output.
The function to implement this list, mark_seen(), stupidly used
insert_by_date(), when it did not need to keep the list sorted
during its processing. This made "show-branch --merge-base"
more than 20x slower compared to "merge-base --all" in some
cases (e.g. between b5032a5 and 48ce8b0 in the Linux 2.6 kernel
archive). The performance of "show-branch --independent"
suffered from the same reason.
This patch sorts the resulting list after the list traversal
just once to fix these problems.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/builtin-show-branch.c b/builtin-show-branch.c
index 260cb22..3d240ca 100644
--- a/builtin-show-branch.c
+++ b/builtin-show-branch.c
@@ -172,7 +172,7 @@ static void name_commits(struct commit_l
static int mark_seen(struct commit *commit, struct commit_list **seen_p)
{
if (!commit->object.flags) {
- insert_by_date(commit, seen_p);
+ commit_list_insert(commit, seen_p);
return 1;
}
return 0;
@@ -218,9 +218,8 @@ static void join_revs(struct commit_list
* Postprocess to complete well-poisoning.
*
* At this point we have all the commits we have seen in
- * seen_p list (which happens to be sorted chronologically but
- * it does not really matter). Mark anything that can be
- * reached from uninteresting commits not interesting.
+ * seen_p list. Mark anything that can be reached from
+ * uninteresting commits not interesting.
*/
for (;;) {
int changed = 0;
@@ -701,6 +700,8 @@ int cmd_show_branch(int ac, const char *
if (0 <= extra)
join_revs(&list, &seen, num_rev, extra);
+ sort_by_date(&seen);
+
if (merge_base)
return show_merge_base(seen, num_rev);
^ permalink raw reply related
* Re: [PATCH] array index mixup
From: Junio C Hamano @ 2006-07-16 8:50 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git, Jakub Narebski
In-Reply-To: <E1G1jje-0007ey-OA@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> I dunno if this is really an index mixup or was intended. If this is
> intended please add a comment what it's for. (Without this you get
> rename information, perhaps this is the reason.)
That is exactly the reason -- it was a temporary workaround
which nobody noticed so far.
The right fix would involve updating diff_resolve_rename_copy so
that it does not rely on the comparison of path names (that
means DIFF_PAIR_RENAME() macro needs to change), and instead
mark the pairs synthesized in diffcore-rename as such, and use
that to tell if a pair is a result of rename/copy [*1*].
Your other patch (not the one to change the index of the array
used for labels, but the one that extracts the pathname out of
the syntax to name a blob by path in an arbitrary tree object)
could be safely applied when that happens.
[Footnote]
*1* If somebody wants to do this, one thing to watch out for is
matching up of broken pairs. If a pair originally broken by
diffcore-break (because they were dissimilar enough according to
the option given to -B flag) are merged into one by
diffcore-rename (because they were similar enough according to
the option given to -M flag), we should _not_ say the resulting
pair is renamed. In general, the threashold for breaking should
be lower than diffcore-rename to merge them for a sane use, so
this might be a non-issue in practice, though.
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Florian Weimer @ 2006-07-16 9:05 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0607080450100.29667@wbgn013.biozentrum.uni-wuerzburg.de>
* Johannes Schindelin:
> Hi,
>
> On Fri, 7 Jul 2006, Florian Weimer wrote:
>
>> - s->data = mmap(NULL, s->size, PROT_READ, MAP_PRIVATE, fd, 0);
>> + s->data = mmap(NULL, s->size, PROT_READ, MAP_SHARED, fd, 0);
>
> Be advised that this breaks setups with NO_MMAP, in particular most (all)
> cygwin setups I know of.
Are these Cygwin setups running on top of the Windows 95 code base by
chance?
^ permalink raw reply
* [RFH/RFC] typechange tests for git apply (currently failing)
From: Eric Wong @ 2006-07-16 10:38 UTC (permalink / raw)
To: git; +Cc: Eric Wong
I've found that git apply is incapable of handling patches
involving object type changes to the same path.
Of course git itself is perfectly capable of making commits that
generate these changes, as it only tracks trees states. It's
just that the diffs between them are less useful if they can't
be applied.
Some of these are rare, but I've hit one of them (file becoming
a symlink) recently in real-world usage, and was inspired to
find more potential breakages :)
I'm not sure when I'll have time to fix these myself and I'm not
very familiar with the apply code. So if someone could get
some or all of these cases working, they would be my hero :)
Some of these are what I would refer to as corner-cases from
hell. Most (if not all) other systems fail some of these. In
fact, they aren't even capable of representing most of these
changes in their histories; much less being able to handle
patches to that effect.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t4114-apply-typechange.sh | 105 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 105 insertions(+), 0 deletions(-)
diff --git a/t/t4114-apply-typechange.sh b/t/t4114-apply-typechange.sh
new file mode 100755
index 0000000..ca81d72
--- /dev/null
+++ b/t/t4114-apply-typechange.sh
@@ -0,0 +1,105 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Eric Wong
+#
+
+test_description='git-apply should not get confused with type changes.
+
+'
+
+. ./test-lib.sh
+
+test_expect_success 'setup repository and commits' '
+ echo "hello world" > foo &&
+ echo "hi planet" > bar &&
+ git update-index --add foo bar &&
+ git commit -m initial &&
+ git branch initial &&
+ rm -f foo &&
+ ln -s bar foo &&
+ git update-index foo &&
+ git commit -m "foo symlinked to bar" &&
+ git branch foo-symlinked-to-bar &&
+ rm -f foo &&
+ echo "how far is the sun?" > foo &&
+ git update-index foo &&
+ git commit -m "foo back to file" &&
+ git branch foo-back-to-file &&
+ rm -f foo &&
+ git update-index --remove foo &&
+ mkdir foo &&
+ echo "if only I knew" > foo/baz &&
+ git update-index --add foo/baz &&
+ git commit -m "foo becomes a directory" &&
+ git branch "foo-becomes-a-directory" &&
+ echo "hello world" > foo/baz &&
+ git update-index foo/baz &&
+ git commit -m "foo/baz is the original foo" &&
+ git branch foo-baz-renamed-from-foo
+ '
+
+test_expect_success 'file renamed from foo to foo/baz' '
+ git checkout -f initial &&
+ git diff-tree -M -p HEAD foo-baz-renamed-from-foo > patch &&
+ git apply --index < patch
+ '
+test_debug 'cat patch'
+
+
+test_expect_success 'file renamed from foo/baz to foo' '
+ git checkout -f foo-baz-renamed-from-foo &&
+ git diff-tree -M -p HEAD initial > patch &&
+ git apply --index < patch
+ '
+test_debug 'cat patch'
+
+
+test_expect_success 'directory becomes file' '
+ git checkout -f foo-becomes-a-directory &&
+ git diff-tree -p HEAD initial > patch &&
+ git apply --index < patch
+ '
+test_debug 'cat patch'
+
+
+test_expect_success 'file becomes directory' '
+ git checkout -f initial &&
+ git diff-tree -p HEAD foo-becomes-a-directory > patch &&
+ git apply --index < patch
+ '
+test_debug 'cat patch'
+
+
+test_expect_success 'file becomes symlink' '
+ git checkout -f initial &&
+ git diff-tree -p HEAD foo-symlinked-to-bar > patch &&
+ git apply --index < patch
+ '
+test_debug 'cat patch'
+
+
+test_expect_success 'symlink becomes file' '
+ git checkout -f foo-symlinked-to-bar &&
+ git diff-tree -p HEAD foo-back-to-file > patch &&
+ git apply --index < patch
+ '
+test_debug 'cat patch'
+
+
+test_expect_success 'symlink becomes directory' '
+ git checkout -f foo-symlinked-to-bar &&
+ git diff-tree -p HEAD foo-becomes-a-directory > patch &&
+ git apply --index < patch
+ '
+test_debug 'cat patch'
+
+
+test_expect_success 'directory becomes symlink' '
+ git checkout -f foo-becomes-a-directory &&
+ git diff-tree -p HEAD foo-symlinked-to-bar > patch &&
+ git apply --index < patch
+ '
+test_debug 'cat patch'
+
+
+test_done
--
1.4.1.g9d8f
^ permalink raw reply related
* :), oat kiln
From: Jean Santana @ 2006-07-16 12:29 UTC (permalink / raw)
To: git-commits-head-owner
Even if you have no erectin problems SOFT CIADLIS
would help you to make BETTER SETX MORE OFTEN!
and to bring unimagnable plesure to her.
Just disolve half a pil under your tongue
and get ready for action in 15 minutes.
The tests showed that the majority of men
after taking this medic ation were able to have
PERFECT ERHECTION during 36 hours!
VISIT US, AND GET OUR SPECIAL 70% DISC4OUNT OFER!
http://FW1X2oouftftoujuz76ozt6ohb666.gogglekm.com/
==========
the wind was a solid beating wall of sound against which he could move no
He wants to go up. And what if something gets you at twenty yards?
day practicing flight, testing advanced aeronautics.
I thought the whole thing through and even felt a sense of relief that
Elder had noticed.
"What do you think about the Visitation?"
Livingston Seagull fired directly through the center of Breakfast Flock,
"Hold it," I said. "Don't move an inch."
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Johannes Schindelin @ 2006-07-16 14:00 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87fyh1ncm0.fsf@mid.deneb.enyo.de>
Hi,
On Sun, 16 Jul 2006, Florian Weimer wrote:
> * Johannes Schindelin:
>
> > Hi,
> >
> > On Fri, 7 Jul 2006, Florian Weimer wrote:
> >
> >> - s->data = mmap(NULL, s->size, PROT_READ, MAP_PRIVATE, fd, 0);
> >> + s->data = mmap(NULL, s->size, PROT_READ, MAP_SHARED, fd, 0);
> >
> > Be advised that this breaks setups with NO_MMAP, in particular most (all)
> > cygwin setups I know of.
>
> Are these Cygwin setups running on top of the Windows 95 code base by
> chance?
No. One is Windows2000, the other WindowsXP, and both need the NO_MMAP
set. For obvious reasons, NO_MMAP does not support MAP_SHARED...
Ciao,
Dscho
^ permalink raw reply
* Re: comparing file contents in is_exact_match?
From: Yakov Lerner @ 2006-07-16 15:03 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87fyh1ncm0.fsf@mid.deneb.enyo.de>
On 7/16/06, Florian Weimer <fw@deneb.enyo.de> wrote:
> * Johannes Schindelin:
>
> > Hi,
> >
> > On Fri, 7 Jul 2006, Florian Weimer wrote:
> >
> >> - s->data = mmap(NULL, s->size, PROT_READ, MAP_PRIVATE, fd, 0);
> >> + s->data = mmap(NULL, s->size, PROT_READ, MAP_SHARED, fd, 0);
> >
> > Be advised that this breaks setups with NO_MMAP, in particular most (all)
> > cygwin setups I know of.
>
> Are these Cygwin setups running on top of the Windows 95 code base by
> chance?
Cygwin has mmap. But cygwin's mmap() not good enough for git.
What happens is that git does rename() when target file has active mmap().
In cygwin, this makes rename() to fail. This is what makes cygwin's
mmap unusable for git. (BTW for read-only git access, mmap() will work
on cygwin, for what I saw. But attempts to modify index will break).
Yakov
^ permalink raw reply
* [RTLWS8-CFP] Eighth Real-Time Linux Workshop 2nd CFP
From: mcguire @ 2006-07-16 17:22 UTC (permalink / raw)
To: grig76, alina12004, mail, mail, market, market, sales01, sales01,
git, david, git, rsync-bugs, vas-agu, vas-agu, igor, lena, web
We apologize for multiple receipts.
--------------------------------------------------------------------------------
Eighth Real-Time Linux Workshop
October 12-15, 2006
Lanzhou University - SISE
Tianshui South Road 222
Lanzhou, Gansu 730000
P.R.China
General
Following the meetings of developers and users at the previous 7
successful real-time Linux workshops held in Vienna, Orlando, Milano,
Boston, and Valencia, Singapore, Lille, the Real-Time Linux Workshop
for 2006 will come back to Asia again, to be held at the School for
Information Science and Engineering, Lanzhou University, in Lanzhou
China.
Embedded and real-time Linux is rapidly gaining traction in the Asia
Pacific region. Embedded systems in both automation/control and
entertainment moving to 32/64bit systems, opening the door for the use
of full featured OS like GNU/Linux on COTS based systems. With
real-time capabilities being a common demand for embedded systems the
soft and hard real-time variants are an important extension to the
versatile GNU/Linux GPOS.
Authors are invited to submit original work dealing with general
topics related to real-time Linux research, experiments and case
studies, as well as issues of integration of real-time and embedded
Linux. A special focus will be on industrial case studies. Topics of
interest include, but are not limited to:
* Modifications and variants of the GNU/Linux operating system
extending its real-time capabilities,
* Contributions to real-time Linux variants, drivers and extensions,
* User-mode real-time concepts, implementation and experience,
* Real-time Linux applications, in academia, research and industry,
* Work in progress reports, covering recent developments,
* Educational material on real-time Linux,
* Tools for embedding Linux or real-time Linux and embedded
real-time Linux applications,
* RTOS core concepts, RT-safe synchronization mechanisms,
* RT-safe interaction of RT and non RT components,
* IPC mechanisms in RTOS,
* Analysis and Benchmarking methods and results of
real-time GNU/Linux variants,
* Debugging techniques and tools, both for code and temporal
debugging of core RTOS components, drivers and real-time
applications,
* Real-time related extensions to development environments.
Further information:
EN: http://www.realtimelinuxfoundation.org/events/rtlws-2006/ws.html
CN: http://dslab.lzu.edu.cn/rtlws8/index.html
Awarded papers
The Programme Committee will award a best paper in the category Real-
Time Systems Theory. This best paper will be invited for publication
to the Real-Time Systems Journal, RTSJ.
The Programme Committee will award a best paper in the category Real-
Time Systems Application. This best paper will be invited for publication
to the Dr Dobbs Journal. Moreover, the publication of the other papers in
a special issue of Dr Dobbs Journal is in discussion.
Abstract submission
In order register an abstract, please go to:
http://www.realtimelinuxfoundation.org/rtlf/register-abstract.html
Venue
Lanzhou University Information Building, School of Information Science
and Engineering, Laznhou University, http://www.lzu.edu.cn/.
Registration
In order to participate to the workshop, please register on the
registration page at:
http://www.realtimelinuxfoundation.org/rtlf/register-participant.html
Accommodation
Please refer to the Lanzhou hotel page for accomodation at
http://dslab.lzu.edu.cn/rtlws8/hotels/hotels.htm
Travel information
For travel information and directions how to get to Lanzhou from an
international airport in China please refer to:
http://www.realtimelinuxfoundation.org/events/rtlws-2006/
Important dates
August 28: Abstract submission
September 15: Notification of acceptance
September 29: Final paper
Pannel Participants:
o Roberto Bucher - Scuola Universitaria Professionale della Svizzera
Italiana, Switzerland, RTAI/ADEOS/RTAI-Lab.
o Alfons Crespo Lorente - University of Valenica, Spain,Departament
d'Informtica de Sistemes i Computadors, XtratuM.
o Herman Haertig - Technical University Dresden, Germany,Institute for
System Architecture, L4/Fiasco/L4Linux.
o Nicholas Mc Guire - Lanzhou University, P.R. China, Distributed and
Embedded Systems Lab, RTLinux/GPL.
o Douglas Niehaus - University of Kansas, USA, Information and
Telecommunication Technology Center, RT-preempt.
Organization committee:
* Prof. Li LIAN (Co-Chair), (SISE, Lanzhou University, CHINA)
* Xiaoping ZHANG, LZU, CHINA
* Jiming WANG, PKU, CHINA
* Zhibing LI, ECNU, China
* Prof. Nicholas MCGUIRE (Co-Chair), Real Time Linux Foundation
(RTLF)
* Dr. Peter WURMSDOBLER, Real Time Linux Foundation (RTLF)
* Dr. Qingguo ZHOU, (Distributed and Embedded Systems Lab, Lanzhou
University, CHINA)
Program committee:
* Prof. Li Xing (Co-Chair), (Tsinghua University, CHINA)
* Dr. Zhang Yunquan, (Institute of Software, Chinese Academy of
Science, CHINA)
* Dr. Chen Yu, (Tsinghua University, CHINA)
* Dr. Chen Maoke, (Tsinghua University, CHINA)
* Dr. Yu Guanghui, (Dalian University of Techonolgy, CHINA)
* Prof. Dr. Paolo Mantegazza, (Dipartimento di Ingegneria
Aerospaziale, ITALY)
* Prof. Dr. Bernhard Zagar, (Johannes Kepler Universitt Linz,
AUSTRIA)
* Prof. Dr. Hermann Hrtig, (Technische Universitt Dresden,
Fakultt Informatik, GERMANY)
* Prof. Tei-Wei Kuo, (National Taiwan University, Department of
Computer Science and Information Engineering,TAIWAN)
* Anthony Skjellum, (Mississippi State University, USA)
* Ing. Pavel Pisa, (Czech Technical University, CZECH REPUBLIC)
* Prof. Alfons Crespo, (Universidad Politcnica de Valencia, SPAIN)
* Dr. Qingguo Zhou, (Lanzhou University, CHINA)
* PhD. Jaesoon Choi, (National Cancer Center, KOREA)
* Prof. Douglas Niehaus, (Kansas University, USA)
* Dr. Michael Hohmuth, (Technische Universitt Dresden, GERMANY)
* Prof. Thambipillai Srikanthan, (Nanyang Technological University,
SINGAPORE)
* Zhengting He, (University of Texas, USA)
* Martin Terbuc, (Universitz of Maribor, SLOVENIA)
* Yoshinori Sato, (the H8/300 project, JAPAN)
* Yuqing Lan, (China Standard SoftwareCo.,LTD, CHINA)
* Dr. Peter Wurmsdobler, (Real Time Linux Foundation, USA)
* Prof. Nicholas Mc Guire (Co-Chair), (Lanzhou University, CHINA)
Workshop organizers:
* School for Information Science and Engineering (SISE) , Lanzhou
University , CHINA
* IBM China, Xi'an Branch , China
* Haag Embedded Systems, Austira
Peter Wurmsdobler <peter@wurmsdobler.org>
Nicholas Mc Guire <mcguire@lzu.edu.cn>
Zhou Qingguo <zhouqg@lzu.edu.cn>
^ permalink raw reply
* Re: [PATCH] array index mixup
From: linux @ 2006-07-16 18:12 UTC (permalink / raw)
To: git, junkio
> *1* If somebody wants to do this, one thing to watch out for is
> matching up of broken pairs. If a pair originally broken by
> diffcore-break (because they were dissimilar enough according to
> the option given to -B flag) are merged into one by
> diffcore-rename (because they were similar enough according to
> the option given to -M flag), we should _not_ say the resulting
> pair is renamed. In general, the threashold for breaking should
> be lower than diffcore-rename to merge them for a sane use, so
> this might be a non-issue in practice, though.
Er... no. You want to be fairly aggressive when doing both things.
That is, you want to break aggressively so you can look for a better
match elsewhere, but once you've found the best match, you don't want to
be shy about accepting it.
Pulling numbers out of thin air, say break if 1/3 of a file has
changed (66% common), and merge if you have 33% common. Or maybe
even less. The point of break then merge is to give you a chance
to find the 90% common file that has a new name.
I always understood that the reason for having two thresholds
is exactly so they can have this relationship, not the opposite
one as you suggest.
^ permalink raw reply
* [PATCH 2/2] use git quote in git-bisect
From: Alex Riesen @ 2006-07-16 22:28 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
The echo after git quote is just to match the behaviour of the
previous script exactly (yes, it is needed - it's bisect log output).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
git-bisect.sh | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 06a8d26..8407960 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -13,13 +13,8 @@ git bisect log show bisect log.'
. git-sh-setup
sq() {
- @@PERL@@ -e '
- for (@ARGV) {
- s/'\''/'\'\\\\\'\''/g;
- print " '\''$_'\''";
- }
- print "\n";
- ' "$@"
+ git quote -- "$@"
+ echo
}
bisect_autostart() {
--
1.4.1.gb944
^ permalink raw reply related
* [PATCH 1/2] add git-quote: shell and C quoting tool
From: Alex Riesen @ 2006-07-16 22:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
As git-stripspace, it may ne useful for something. As an example, the
next patch converts git-bisect.sh to use of this tool.
In case anyone asks why isn't it a standalone tool nor is it put into
git-stripspace: I don't know. Maybe it should be.
Makefile | 3 +-
builtin-quote.c | 102 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
builtin.h | 2 +
git.c | 1 +
4 files changed, 107 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 01fb9cf..9fcbf3b 100644
--- a/Makefile
+++ b/Makefile
@@ -234,7 +234,8 @@ BUILTIN_OBJS = \
builtin-apply.o builtin-show-branch.o builtin-diff-files.o \
builtin-diff-index.o builtin-diff-stages.o builtin-diff-tree.o \
builtin-cat-file.o builtin-mailsplit.o builtin-stripspace.o \
- builtin-update-ref.o builtin-fmt-merge-msg.o builtin-prune.o
+ builtin-update-ref.o builtin-fmt-merge-msg.o builtin-prune.o \
+ builtin-quote.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
LIBS = $(GITLIBS) -lz
diff --git a/builtin-quote.c b/builtin-quote.c
new file mode 100644
index 0000000..cbd822d
--- /dev/null
+++ b/builtin-quote.c
@@ -0,0 +1,102 @@
+/*
+ * "git quote" builtin command
+ *
+ * DOES NOT QUOTE \0 (truncates lines at it)
+ */
+#include "cache.h"
+#include "builtin.h"
+#include "quote.h"
+
+enum {SHELL_QUOTE, C_QUOTE};
+static int style = SHELL_QUOTE,
+ use_stdin = 0;
+static const char *separator = NULL; /* default is space */
+static unsigned sep_len = 0;
+
+static const char builtin_quote_usage[] =
+"git-quote [--c] [--sep=<c-quoted> | -z] ( [--stdin] | [--] ... )";
+
+static void print_quoted(const char *text)
+{
+ switch (style)
+ {
+ case SHELL_QUOTE:
+ sq_quote_print(stdout, text);
+ break;
+ case C_QUOTE:
+ quote_c_style(text, NULL, stdout, 0);
+ break;
+ }
+ fwrite(separator, 1, sep_len, stdout);
+}
+
+int cmd_quote(int argc, const char **argv, char **envp)
+{
+ int i;
+ for (i = 1; i < argc; i++) {
+ const char *arg = argv[i];
+
+ if (arg[0] != '-')
+ break;
+ if (!strcmp(arg, "--")) {
+ i++;
+ break;
+ }
+ if (!strcmp(arg, "--stdin")) {
+ use_stdin = 1;
+ if ( !separator ) {
+ separator = "\n";
+ sep_len = 1;
+ }
+ break;
+ }
+ if (!strcmp(arg, "--c")) {
+ style = C_QUOTE;
+ continue;
+ }
+ if (!strcmp(arg, "-z")) {
+ separator = "";
+ sep_len = 1;
+ continue;
+ }
+ if (!strncmp(arg, "--sep=", 6)) {
+ const char *end;
+ char *tmp;
+ arg += 6;
+ if ('"' == *arg)
+ tmp = strdup(arg);
+ else {
+ size_t l = strlen(arg);
+ tmp = malloc(l + 3);
+ sprintf(tmp, "\"%s\"", arg);
+ }
+ separator = unquote_c_style(tmp, &end);
+ sep_len = strlen(separator);
+ /* this will leak if multiple --sep= given */
+ continue;
+ }
+ die(builtin_quote_usage);
+ }
+ if (!separator) {
+ sep_len = 1;
+ separator = "\x20";
+ }
+ if (use_stdin) {
+ size_t size = BUFSIZ;
+ char *buf = xmalloc(size);
+ int ch, pos = 0;
+ while (EOF != (ch = fgetc(stdin))) {
+ if (pos == size)
+ buf = xrealloc(buf, size <<= 1);
+ buf[pos++] = ch;
+ if ('\n' == ch) {
+ buf[--pos] = '\0';
+ pos = 0;
+ print_quoted(buf);
+ }
+ }
+ } else
+ for (; argv[i]; ++i)
+ print_quoted(argv[i]);
+ return 0;
+}
diff --git a/builtin.h b/builtin.h
index 5339d86..9bd522e 100644
--- a/builtin.h
+++ b/builtin.h
@@ -64,4 +64,6 @@ extern int mailinfo(FILE *in, FILE *out,
extern int cmd_stripspace(int argc, const char **argv, char **envp);
extern void stripspace(FILE *in, FILE *out);
+
+extern int cmd_quote(int argc, const char **argv, char **envp);
#endif
diff --git a/git.c b/git.c
index ee5a0e8..f94d25a 100644
--- a/git.c
+++ b/git.c
@@ -202,6 +202,7 @@ static void handle_internal_command(int
{ "update-ref", cmd_update_ref },
{ "fmt-merge-msg", cmd_fmt_merge_msg },
{ "prune", cmd_prune },
+ { "quote", cmd_quote },
};
int i;
--
1.4.1.gb944
^ permalink raw reply related
* Re: comparing file contents in is_exact_match?
From: Alex Riesen @ 2006-07-16 22:36 UTC (permalink / raw)
To: Yakov Lerner; +Cc: Florian Weimer, git
In-Reply-To: <f36b08ee0607160803s27dac6a6k476e3dd7742346fc@mail.gmail.com>
Yakov Lerner, Sun, Jul 16, 2006 17:03:49 +0200:
> Cygwin has mmap. But cygwin's mmap() not good enough for git.
> What happens is that git does rename() when target file has active mmap().
> In cygwin, this makes rename() to fail. This is what makes cygwin's
> mmap unusable for git. (BTW for read-only git access, mmap() will work
> on cygwin, for what I saw. But attempts to modify index will break).
It is not Cygwin really. It's windows. You can't rename or delete an
open or mmapped file in that thing.
^ 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