* 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
* git-repack not removing files from $GIT_DIR/objects/[00-ff]
From: Post, Mark K @ 2006-07-17 0:44 UTC (permalink / raw)
To: git
I'm having a problem that just started occurring with git-repack not
removing the files from $GIT_DIR/objects/*, and therefore not removing
the directories, since they're not empty. The command I'm using (as the
git user) is this:
GIT_DIR=/home/git/pub/scm/linux-2.6.git git-repack -a -d -l
This used to work, but then suddenly stopped working. I ran an strace
-f -F with this same command, and I don't see any attempt being made to
unlink the files in $GIT_DIR/objects/*/, but I do see the rmdir commands
failing because the directories are not empty. All of the files in
those directories are owned by git:git.
I tried upgrading to git 1.4.1, but the same thing happens. The gzipped
strace output is almost 5MB in size, certainly not appropriate to attach
here. I can make it available from the system's web server if anyone
wants to look at it.
Please let me know if there's any other information needed.
Mark Post
^ permalink raw reply
* Re: git-repack not removing files from $GIT_DIR/objects/[00-ff]
From: Shawn Pearce @ 2006-07-17 1:21 UTC (permalink / raw)
To: Post, Mark K; +Cc: git
In-Reply-To: <5A14AF34CFF8AD44A44891F7C9FF410507E43005@usahm236.amer.corp.eds.com>
"Post, Mark K" <mark.post@eds.com> wrote:
> I'm having a problem that just started occurring with git-repack not
> removing the files from $GIT_DIR/objects/*, and therefore not removing
> the directories, since they're not empty. The command I'm using (as the
> git user) is this:
> GIT_DIR=/home/git/pub/scm/linux-2.6.git git-repack -a -d -l
>
> This used to work, but then suddenly stopped working. I ran an strace
> -f -F with this same command, and I don't see any attempt being made to
> unlink the files in $GIT_DIR/objects/*/, but I do see the rmdir commands
> failing because the directories are not empty. All of the files in
> those directories are owned by git:git.
Try running `git-prune-packed` after git-repack. git-repack doesn't
delete the loose objects.
I don't remember git-repack ever doing it either.
--
Shawn.
^ permalink raw reply
* RE: git-repack not removing files from $GIT_DIR/objects/[00-ff]
From: Post, Mark K @ 2006-07-17 1:47 UTC (permalink / raw)
To: spearce; +Cc: git
In-Reply-To: <20060717012154.GA27389@spearce.org>
Thanks for the suggestion, but it didn't help. One reason is that this
is a bare repository. When I ran the command, it aborted with "fatal:
Not a git repository." Most likely because bare repositories don't have
a .git directory in them.
Mark Post
-----Original Message-----
From: spearce@spearce.org [mailto:spearce@spearce.org]
Sent: Sunday, July 16, 2006 9:22 PM
To: Post, Mark K
Cc: git@vger.kernel.org
Subject: Re: git-repack not removing files from $GIT_DIR/objects/[00-ff]
"Post, Mark K" <mark.post@eds.com> wrote:
> I'm having a problem that just started occurring with git-repack not
> removing the files from $GIT_DIR/objects/*, and therefore not removing
> the directories, since they're not empty. The command I'm using (as
the
> git user) is this:
> GIT_DIR=/home/git/pub/scm/linux-2.6.git git-repack -a -d -l
>
> This used to work, but then suddenly stopped working. I ran an strace
> -f -F with this same command, and I don't see any attempt being made
to
> unlink the files in $GIT_DIR/objects/*/, but I do see the rmdir
commands
> failing because the directories are not empty. All of the files in
> those directories are owned by git:git.
Try running `git-prune-packed` after git-repack. git-repack doesn't
delete the loose objects.
I don't remember git-repack ever doing it either.
--
Shawn.
^ permalink raw reply
* Re: git-repack not removing files from $GIT_DIR/objects/[00-ff]
From: Shawn Pearce @ 2006-07-17 1:51 UTC (permalink / raw)
To: Post, Mark K; +Cc: git
In-Reply-To: <5A14AF34CFF8AD44A44891F7C9FF410507E43006@usahm236.amer.corp.eds.com>
So try:
GIT_DIR=/home/git/pub/scm/linux-2.6.git git-prune-packed
On a bare repository you should always set the GIT_DIR environment
variable to the directory of the repository before running the
command.
"Post, Mark K" <mark.post@eds.com> wrote:
> Thanks for the suggestion, but it didn't help. One reason is that this
> is a bare repository. When I ran the command, it aborted with "fatal:
> Not a git repository." Most likely because bare repositories don't have
> a .git directory in them.
>
>
> Mark Post
>
> -----Original Message-----
> From: spearce@spearce.org [mailto:spearce@spearce.org]
> Sent: Sunday, July 16, 2006 9:22 PM
> To: Post, Mark K
> Cc: git@vger.kernel.org
> Subject: Re: git-repack not removing files from $GIT_DIR/objects/[00-ff]
>
> "Post, Mark K" <mark.post@eds.com> wrote:
> > I'm having a problem that just started occurring with git-repack not
> > removing the files from $GIT_DIR/objects/*, and therefore not removing
> > the directories, since they're not empty. The command I'm using (as
> the
> > git user) is this:
> > GIT_DIR=/home/git/pub/scm/linux-2.6.git git-repack -a -d -l
> >
> > This used to work, but then suddenly stopped working. I ran an strace
> > -f -F with this same command, and I don't see any attempt being made
> to
> > unlink the files in $GIT_DIR/objects/*/, but I do see the rmdir
> commands
> > failing because the directories are not empty. All of the files in
> > those directories are owned by git:git.
>
> Try running `git-prune-packed` after git-repack. git-repack doesn't
> delete the loose objects.
>
> I don't remember git-repack ever doing it either.
--
Shawn.
^ permalink raw reply
* Fresh stuff Online Casiino. GGo and Play It
From: Caroline @ 2006-07-17 1:15 UTC (permalink / raw)
To: git
Hi
Onlinne Casino with 85+ games. Play It Now! http://uveltord.com/d1/check/
A cat has nine lives. Lots of people confuse bad management with destiny
^ permalink raw reply
* RE: git-repack not removing files from $GIT_DIR/objects/[00-ff]
From: Post, Mark K @ 2006-07-17 2:48 UTC (permalink / raw)
To: spearce; +Cc: git
In-Reply-To: <20060717015149.GB27389@spearce.org>
That doesn't generate any error messages, but it also doesn't clean up
the files in the object directory.
Mark Post
-----Original Message-----
From: spearce@spearce.org [mailto:spearce@spearce.org]
Sent: Sunday, July 16, 2006 9:52 PM
To: Post, Mark K
Cc: git@vger.kernel.org
Subject: Re: git-repack not removing files from $GIT_DIR/objects/[00-ff]
So try:
GIT_DIR=/home/git/pub/scm/linux-2.6.git git-prune-packed
On a bare repository you should always set the GIT_DIR environment
variable to the directory of the repository before running the
command.
"Post, Mark K" <mark.post@eds.com> wrote:
> Thanks for the suggestion, but it didn't help. One reason is that
this
> is a bare repository. When I ran the command, it aborted with "fatal:
> Not a git repository." Most likely because bare repositories don't
have
> a .git directory in them.
>
>
> Mark Post
>
> -----Original Message-----
> From: spearce@spearce.org [mailto:spearce@spearce.org]
> Sent: Sunday, July 16, 2006 9:22 PM
> To: Post, Mark K
> Cc: git@vger.kernel.org
> Subject: Re: git-repack not removing files from
$GIT_DIR/objects/[00-ff]
>
> "Post, Mark K" <mark.post@eds.com> wrote:
> > I'm having a problem that just started occurring with git-repack not
> > removing the files from $GIT_DIR/objects/*, and therefore not
removing
> > the directories, since they're not empty. The command I'm using (as
> the
> > git user) is this:
> > GIT_DIR=/home/git/pub/scm/linux-2.6.git git-repack -a -d -l
> >
> > This used to work, but then suddenly stopped working. I ran an
strace
> > -f -F with this same command, and I don't see any attempt being made
> to
> > unlink the files in $GIT_DIR/objects/*/, but I do see the rmdir
> commands
> > failing because the directories are not empty. All of the files in
> > those directories are owned by git:git.
>
> Try running `git-prune-packed` after git-repack. git-repack doesn't
> delete the loose objects.
>
> I don't remember git-repack ever doing it either.
--
Shawn.
^ permalink raw reply
* Re: git-repack not removing files from $GIT_DIR/objects/[00-ff]
From: Jeff King @ 2006-07-17 3:26 UTC (permalink / raw)
To: Post, Mark K; +Cc: git
In-Reply-To: <5A14AF34CFF8AD44A44891F7C9FF410507E43005@usahm236.amer.corp.eds.com>
On Sun, Jul 16, 2006 at 08:44:52PM -0400, Post, Mark K wrote:
> I'm having a problem that just started occurring with git-repack not
> removing the files from $GIT_DIR/objects/*, and therefore not removing
> the directories, since they're not empty. The command I'm using (as the
> git user) is this:
> GIT_DIR=/home/git/pub/scm/linux-2.6.git git-repack -a -d -l
git-prune-packed (which, contrary to what Shawn said, is run by
git-repack -d) will only remove objects which are redundant because of
their presence in packs. It will not remove objects which are not
reachable (which is normal if you have, for example, done a rebase in
this repository). Check out git-prune and git-fsck-objects.
-Peff
^ permalink raw reply
* Re: [RFH/RFC] typechange tests for git apply (currently failing)
From: Junio C Hamano @ 2006-07-17 6:21 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <1153046320538-git-send-email-normalperson@yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> I've found that git apply is incapable of handling patches
> involving object type changes to the same path.
It's more of directory vs file conflicts -- and we do not track
directories. Some are pure bugs and relatively simple to fix
(and important), some others I am not sure if they are worth
dealing with.
> +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
> + '
If you look at where it fails closely you would notice this
first fails during git-checkout (without failing, I should
add). Try adding "git diff" immediately after "git checkout".
A fix for read-tree is in this message to fix this, but this has
only been very lightly tested, so please check it thoroughly.
After that is cleared, this and the next one uncover a few bugs
in "git apply".
> +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'
one-way merge used in "git checkout -f" does not remove existing
directory when checking out a file. "git reset --hard" used to
be more careful but recent rewrite made them more or less
equivalent, and now has the same problem. This patch to read-tree
should fix it.
diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index 6df5d7c..122b6f1 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -507,7 +507,7 @@ static int merged_entry(struct cache_ent
}
merge->ce_flags &= ~htons(CE_STAGEMASK);
- add_cache_entry(merge, ADD_CACHE_OK_TO_ADD);
+ add_cache_entry(merge, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE);
return 1;
}
@@ -518,7 +518,7 @@ static int deleted_entry(struct cache_en
else
verify_absent(ce->name, "removed");
ce->ce_mode = 0;
- add_cache_entry(ce, ADD_CACHE_OK_TO_ADD);
+ add_cache_entry(ce, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE);
invalidate_ce_path(ce);
return 1;
}
Then apply, when applying to create a file where a directory
lies, or vice versa, was not careful and did not remove
conflicting one. This patch makes the first few tests to work,
but it is not enough.
Currently, builtin-apply.c::write_out_one_result() says "remove
the old, write the new" for each "struct patch" (which
corresponds to "diff --git" line in your patch file). I think
the loop write_out_results() should be modified to first remove
what we are going to remove in all patches, and then create what
we are going to create.
What causes the fourth test to fail is that you have foo/baz in
the working tree and the index, and the patch creates file foo
and removes file foo/baz. The current loop to deal with one
patch at a time means we try to create file "foo" first, which
would not work without removing directory "foo" first.
diff --git a/builtin-apply.c b/builtin-apply.c
index c903146..9727442 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1732,9 +1732,14 @@ static int check_patch(struct patch *pat
if (check_index && cache_name_pos(new_name, strlen(new_name)) >= 0)
return error("%s: already exists in index", new_name);
if (!cached) {
- if (!lstat(new_name, &st))
- return error("%s: already exists in working directory", new_name);
- if (errno != ENOENT)
+ struct stat nst;
+ if (!lstat(new_name, &nst)) {
+ if (S_ISDIR(nst.st_mode))
+ ; /* ok */
+ else
+ return error("%s: already exists in working directory", new_name);
+ }
+ else if ((errno != ENOENT) && (errno != ENOTDIR))
return error("%s: %s", new_name, strerror(errno));
}
if (!patch->new_mode) {
@@ -2011,6 +2016,16 @@ static void create_one_file(char *path,
}
if (errno == EEXIST) {
+ /* We may be trying to create a file where a directory
+ * used to be.
+ */
+ struct stat st;
+ errno = 0;
+ if (!lstat(path, &st) && S_ISDIR(st.st_mode) && !rmdir(path))
+ errno = EEXIST;
+ }
+
+ if (errno == EEXIST) {
unsigned int nr = getpid();
for (;;) {
^ permalink raw reply related
* Re: comparing file contents in is_exact_match?
From: Florian Weimer @ 2006-07-17 5:25 UTC (permalink / raw)
To: git
In-Reply-To: <20060716223607.GA6023@steel.home>
* Alex Riesen:
> It is not Cygwin really. It's windows. You can't rename or delete an
> open or mmapped file in that thing.
And GIT's workaround is to read the whole file into memory and close
it after that? Uh-oh.
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-07-17 8:29 UTC (permalink / raw)
To: git
Quite a bit of stuff has been merged, and I have tagged the tip
of the master as v1.4.2-rc1, before heading for Ottawa.
Notable changes in the "master" branch includes:
- Merge-base has been improved thanks to a test script by
ALASCM.
- A handful gitweb enhancements and fixes by Alp Toker and
Luben Tuikov.
- git-svn is now out of "contrib/" status.
- Many documentation updates.
- Fixed a performance bug in git-show-branch, which affected
git-merge.
- Fixed a nonsense output from git-fmt-merge-msg when pulling
HEAD from a remote repository, spotted by Linus.
- "git-log --merge" helps the archeology during a conflicted
merge, per request by Linus.
- git-grep boolean expression to allow --and, --or, and --not
is now in "master".
- A few updates to git-daemon by Matthias Lederhofer.
- A handful portability fixes by Pavel Roskin and Shawn Pearce.
- Ref-log updates by Shawn Pearce.
* The 'next' branch, in addition, has these.
- "checkout -f" and "reset --hard" fixes, when the new tree
should have file "foo" and the old tree and/or working tree
has directory there. Earlier we failed to instantiate file
"foo", and did not report an error. Testing is appreciated.
- git-apply fixes that was started by a test script by Eric
Wong. Testing is appreciated on this stuff.
- Perly git by Pasky with help from others.
- Optional autoconf by Jakub Narebski.
- A WIP of merge-recursive by Johannes and Alex Riesen.
- A usability enhancement of format-patch for imap-send users by
Josh Triplett
- A new loose object format support by Linus.
- An update to diff to make --name-only, --name-status,
--check and -s mutually exclusive by Timo Hirvonen.
* The 'pu' branch has an experimental "read-tree --rename" to
teach renames to git-merge-resolve, but currently it fails a
few of its own tests.
I noticed that "git diff" from subdirectories does not seem to
pick up the configuration from $GIT_DIR/config properly. I
suspect that fixing this breakage properly would help us later,
as more and more commands learn to use the configuration
mechanism to store user preferences, and the same fix would be
applicable to them. If somebody can fix this while we are away
this week, that would be wonderful ;-).
^ 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