* Re: [PATCH 1/2] diffcore-rename: support rename cache
From: Yann Dirson @ 2008-11-08 9:24 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <fcaeb9bf0811072001o6df7ae00k1b1bffaadf75d3a1@mail.gmail.com>
On Sat, Nov 08, 2008 at 11:01:20AM +0700, Nguyen Thai Ngoc Duy wrote:
> On 11/8/08, Junio C Hamano <gitster@pobox.com> wrote:
> > Yann Dirson <ydirson@altern.org> writes:
> >
> > > On Fri, Nov 07, 2008 at 09:35:32PM +0700, Nguy???n Thái Ng???c Duy wrote:
> > >> This patch teaches diffcore_rename() to look into
> > >> $GIT_DIR/rename-cache and make use of it to recreate diff_filepair.
> > >> With proper cache, there should be no available entry for estimation
> > >> after exact matching.
> > >
> > > This is something I have thought about in the past, good to see that
> > > implemented :)
> > >
> > >> Rename caching is per commit. I don't think abitrary tree-tree caching
> > >> is worth it.
> > >
> > > That could be a nice complement to my directory-rename patch.
> >
> >
> > Has anybody thought about interaction between that caching and pathspec
> > limited operation?
> >
>
> I didn't. But I think all out-of-pathspec diff pairs are removed
> before it reaches diffcore_rename() so the cache has nothing to do
> with it (except it still loads full cache for a commit).
Well, it could be that an out-of-pathspec pair would have a better
score than an in-pathspec one. Maybe cache recording should be turned
off when doing pathspec limitation ?
^ permalink raw reply
* Re: [PATCH 2/2] Cached the git configuration, which is now noticibly faster on windows.
From: Arafangion @ 2008-11-08 6:52 UTC (permalink / raw)
To: David Symonds; +Cc: git
In-Reply-To: <ee77f5c20811072119y65738f54o7e6792fb405c142c@mail.gmail.com>
On Fri, 2008-11-07 at 21:19 -0800, David Symonds wrote:
<snip>
> _gitConfig = None
> def gitConfig(key):
> if _gitConfig is None:
> lines = read_pipe("git config -l", ignore_error=True).readlines():
> _gitConfig = dict([l.strip().split('=', 1) for l in lines])
> return _gitConfig.get(key, None)
That certainly is better, if one can assume that git's configuration is
small. (And relative to the memory usage of the script, it will
definetly be small).
I shall give that a go, although the change won't make it even faster -
I suspect that much of the performance penalty in windows is the
pathetic fork() performance, particularly as the memory usage of the
script increases. (If subprocess does fork() and exec() in order to open
another process, in cygwin).
Thankyou.
^ permalink raw reply
* [PATCH 7/7 v3] bisect: use "--bisect-replace" options when checking merge bases
From: Christian Couder @ 2008-11-08 7:52 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 1daa81c..87e186f 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -401,7 +401,7 @@ check_merge_bases() {
_bad="$1"
_good="$2"
_skip="$3"
- for _mb in $(git merge-base --all $_bad $_good)
+ for _mb in $(git merge-base --all --bisect-replace $_bad $_good)
do
if is_among "$_mb" "$_good"; then
continue
@@ -436,7 +436,7 @@ check_good_are_ancestors_of_bad() {
# Bisecting with no good rev is ok
test -z "$_good" && return
- _side=$(git rev-list $_good ^$_bad)
+ _side=$(git rev-list --bisect-replace $_good ^$_bad)
if test -n "$_side"; then
# Return if a checkout was done
check_merge_bases "$_bad" "$_good" "$_skip" || return
--
1.6.0.3.619.g9a6a
^ permalink raw reply related
* [PATCH 6/7 v3] merge-base: add "--bisect-replace" option to use fixed up revs
From: Christian Couder @ 2008-11-08 7:51 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-merge-base.txt | 6 +++++-
builtin-merge-base.c | 8 +++++++-
t/t6035-bisect-replace.sh | 7 +++++++
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt
index 2f0c525..af174f7 100644
--- a/Documentation/git-merge-base.txt
+++ b/Documentation/git-merge-base.txt
@@ -8,7 +8,7 @@ git-merge-base - Find as good common ancestors as possible for a merge
SYNOPSIS
--------
-'git merge-base' [--all] <commit> <commit>...
+'git merge-base' [--all] [--bisect-replace] <commit> <commit>...
DESCRIPTION
-----------
@@ -32,6 +32,10 @@ OPTIONS
--all::
Output all merge bases for the commits, instead of just one.
+--bisect-replace::
+ Use fixed up history from "bisect-replace-*" branches when
+ computing merge bases.
+
DISCUSSION
----------
diff --git a/builtin-merge-base.c b/builtin-merge-base.c
index 03fc1c2..31c0015 100644
--- a/builtin-merge-base.c
+++ b/builtin-merge-base.c
@@ -46,9 +46,13 @@ int cmd_merge_base(int argc, const char **argv, const char *prefix)
struct commit **rev;
int rev_nr = 0;
int show_all = 0;
+ int bisect_replace = 0;
struct option options[] = {
- OPT_BOOLEAN('a', "all", &show_all, "outputs all common ancestors"),
+ OPT_BOOLEAN('a', "all", &show_all,
+ "outputs all common ancestors"),
+ OPT_BOOLEAN(0, "bisect-replace", &bisect_replace,
+ "use revs from 'bisect-replace-*' branches"),
OPT_END()
};
@@ -56,6 +60,8 @@ int cmd_merge_base(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, options, merge_base_usage, 0);
if (argc < 2)
usage_with_options(merge_base_usage, options);
+ if (bisect_replace)
+ bisect_replace_all();
rev = xmalloc(argc * sizeof(*rev));
while (argc-- > 0)
rev[rev_nr++] = get_commit_reference(*argv++);
diff --git a/t/t6035-bisect-replace.sh b/t/t6035-bisect-replace.sh
index bc07206..8fe7cc5 100755
--- a/t/t6035-bisect-replace.sh
+++ b/t/t6035-bisect-replace.sh
@@ -137,6 +137,13 @@ test_expect_success '"git rev-list --bisect-replace" works' '
test_cmp rev_list.expect rev_list.output
'
+test_expect_success '"git merge-base --bisect-replace" works' '
+ hash=$(git merge-base --all --bisect-replace $HASH7 $HASHFIX3) &&
+ test "$hash" = "$HASHFIX3" &&
+ hash=$(git merge-base --all --bisect-replace $HASH7 $HASH3) &&
+ test "$hash" = "$HASH1"
+'
+
#
#
test_done
--
1.6.0.3.619.g9a6a
^ permalink raw reply related
* [PATCH 5/7 v3] commit: add "bisect_replace_all" prototype to "commit.h"
From: Christian Couder @ 2008-11-08 7:50 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-rev-list.c | 2 +-
commit.h | 2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 75cc1fc..7cf5f9e 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -637,7 +637,7 @@ static int bisect_replace(const char *refname, const unsigned char *sha1,
return 0;
}
-static void bisect_replace_all(void)
+void bisect_replace_all(void)
{
for_each_branch_ref(bisect_replace, NULL);
}
diff --git a/commit.h b/commit.h
index 3a7b06a..a0ec2a0 100644
--- a/commit.h
+++ b/commit.h
@@ -144,4 +144,6 @@ static inline int single_parent(struct commit *commit)
struct commit_list *reduce_heads(struct commit_list *heads);
+void bisect_replace_all(void);
+
#endif /* COMMIT_H */
--
1.6.0.3.619.g9a6a
^ permalink raw reply related
* [PATCH 4/7 v3] rev-list: add "--bisect-replace" to list revisions with fixed up history
From: Christian Couder @ 2008-11-08 7:49 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git
This should help both human and scripts deal better with
"bisect-replace-*" branches.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-rev-list.txt | 1 +
Documentation/rev-list-options.txt | 15 +++++++++++++++
builtin-rev-list.c | 12 +++++++++---
t/t6035-bisect-replace.sh | 12 ++++++++++++
4 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 1c9cc28..4cc8abf 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -41,6 +41,7 @@ SYNOPSIS
[ \--bisect ]
[ \--bisect-vars ]
[ \--bisect-all ]
+ [ \--bisect-replace ]
[ \--merge ]
[ \--reverse ]
[ \--walk-reflogs ]
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 966276b..85ee03e 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -507,6 +507,21 @@ may not compile for example).
This option can be used along with `--bisect-vars`, in this case,
after all the sorted commit objects, there will be the same text as if
`--bisect-vars` had been used alone.
+
+--bisect-replace::
+
+This option will make use of the "bisect-replace-*" branches if any,
+but will not perform other bisection calculation.
+
+The purpose of the "bisect-replace-*" branches is to be grafted into
+other branches when bisecting, so that bisection can be performed on
+a fixed up history.
+
+The other `--bisect*` options use the "bisect-replace-*" branches by
+default when they perform their bisection calculations. With the
+"--bisect-replace" option, you can see what is the result of using the
+"bisect-replace-*" branches without the effects of other bisection
+calculations.
endif::git-rev-list[]
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index c0717f6..75cc1fc 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -47,12 +47,14 @@ static const char rev_list_usage[] =
" special purpose:\n"
" --bisect\n"
" --bisect-vars\n"
-" --bisect-all"
+" --bisect-all\n"
+" --bisect-replace"
;
static struct rev_info revs;
static int bisect_list;
+static int bisect_replace_only;
static int show_timestamp;
static int hdr_termination;
static const char *header_prefix;
@@ -681,6 +683,10 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
bisect_show_vars = 1;
continue;
}
+ if (!strcmp(arg, "--bisect-replace")) {
+ bisect_replace_only = 1;
+ continue;
+ }
if (!strcmp(arg, "--stdin")) {
if (read_from_stdin++)
die("--stdin given twice?");
@@ -713,10 +719,10 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
save_commit_buffer = revs.verbose_header ||
revs.grep_filter.pattern_list;
- if (bisect_list) {
+ if (bisect_list || bisect_replace_only)
bisect_replace_all();
+ if (bisect_list)
revs.limited = 1;
- }
if (prepare_revision_walk(&revs))
die("revision walk setup failed");
diff --git a/t/t6035-bisect-replace.sh b/t/t6035-bisect-replace.sh
index 6ab3667..bc07206 100755
--- a/t/t6035-bisect-replace.sh
+++ b/t/t6035-bisect-replace.sh
@@ -125,6 +125,18 @@ test_expect_success 'standard bisect works' '
git bisect reset
'
+test_expect_success '"git rev-list --bisect-replace" works' '
+ echo "$HASH7" >> rev_list.expect &&
+ echo "$HASH6" >> rev_list.expect &&
+ echo "$HASH5" >> rev_list.expect &&
+ echo "$HASHFIX4" >> rev_list.expect &&
+ echo "$HASHFIX3" >> rev_list.expect &&
+ echo "$HASHFIX2" >> rev_list.expect &&
+ echo "$HASH1" >> rev_list.expect &&
+ git rev-list --bisect-replace $HASH7 > rev_list.output &&
+ test_cmp rev_list.expect rev_list.output
+'
+
#
#
test_done
--
1.6.0.3.619.g9a6a
^ permalink raw reply related
* [PATCH 3/7 v3] Documentation: add "git bisect replace" documentation
From: Christian Couder @ 2008-11-08 7:49 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-bisect.txt | 61 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index c7981ef..5d5bdf7 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -24,6 +24,7 @@ on the subcommand:
git bisect visualize
git bisect replay <logfile>
git bisect log
+ git bisect replace <rev> [<rev>]
git bisect run <cmd>...
This command uses 'git-rev-list --bisect' to help drive the
@@ -186,6 +187,66 @@ $ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 --
# v2.6.20-rc4 and v2.6.20-rc1 are good
------------
+Bisect replace
+~~~~~~~~~~~~~~
+
+This subcommand should be used when you have a branch or a part of a
+branch that isn't easily bisectable because of a bug that has been
+fixed latter.
+
+We suppose that a bug as been introduced at some point, say A, and
+that it has been fixed latter at another point, say B, but that
+between these points the code is not easily testable because of the
+bug, so it's not easy to bisect between these points.
+
+In this case you can create a branch starting at the parent of A, say
+O, that has a fixed history. In this fixed history for example, there
+could be first a commit C that is the result of squashing A and B
+together and then all the commits between A and B that have been cherry
+picked.
+
+For example, let's say the commits between A and B are X1, X2, ... Xn
+and they have been cherry picked after C as Y1, Y2, ... Yn:
+
+------------
+ C--Y1--Y2--...--Yn
+ /
+...--O--A--X1--X2--...--Xn--B--...
+------------
+
+By design, the last cherry picked commit (Yn) should point to the same
+tree as commit B.
+
+So in this case you can say:
+
+------------
+$ git bisect replace B Yn
+------------
+
+and a branch will be created that points to commit Yn and that has a
+special name like: "bisect-replace-B"
+
+When bisecting, the branch names will be scanned and each branch named
+"bisect-replace-X" and pointing to commit Y will be grafted so that X
+will only have Y as parent.
+
+In the example above, that means that instead of the above graph, the
+following graph will be bisected:
+
+------------
+ C--Y1--Y2--...--Yn
+ / \
+...--O B--...
+------------
+
+This means that the bisections on this branch may be much easier
+because the bug introduced by commit A and fixed by commit B will not
+annoy you anymore.
+
+As the branches created by "git bisect replace" can be shared between
+developers, this feature might be especially usefull on big projects
+where many people often bisect the same code base.
+
Bisect run
~~~~~~~~~~
--
1.6.0.3.619.g9a6a
^ permalink raw reply related
* [PATCH 2/7 v3] bisect: add test cases for "git bisect replace"
From: Christian Couder @ 2008-11-08 7:48 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t6035-bisect-replace.sh | 130 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 130 insertions(+), 0 deletions(-)
create mode 100755 t/t6035-bisect-replace.sh
diff --git a/t/t6035-bisect-replace.sh b/t/t6035-bisect-replace.sh
new file mode 100755
index 0000000..6ab3667
--- /dev/null
+++ b/t/t6035-bisect-replace.sh
@@ -0,0 +1,130 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Christian Couder
+#
+test_description='Test git bisect replace functionality'
+
+exec </dev/null
+
+. ./test-lib.sh
+
+add_and_commit_file()
+{
+ _file="$1"
+ _msg="$2"
+
+ git add $_file || return $?
+ test_tick || return $?
+ git commit --quiet -m "$_file: $_msg"
+}
+
+HASH1=
+HASH2=
+HASH3=
+HASH4=
+HASH5=
+HASH6=
+HASH7=
+
+test_expect_success 'set up buggy branch' '
+ echo "line 1" >> hello &&
+ echo "line 2" >> hello &&
+ echo "line 3" >> hello &&
+ echo "line 4" >> hello &&
+ add_and_commit_file hello "4 lines" &&
+ HASH1=$(git rev-parse --verify HEAD) &&
+ echo "line BUG" >> hello &&
+ echo "line 6" >> hello &&
+ echo "line 7" >> hello &&
+ echo "line 8" >> hello &&
+ add_and_commit_file hello "4 more lines with a BUG" &&
+ HASH2=$(git rev-parse --verify HEAD) &&
+ echo "line 9" >> hello &&
+ echo "line 10" >> hello &&
+ add_and_commit_file hello "2 more lines" &&
+ HASH3=$(git rev-parse --verify HEAD) &&
+ echo "line 11" >> hello &&
+ add_and_commit_file hello "1 more line" &&
+ HASH4=$(git rev-parse --verify HEAD) &&
+ sed -e "s/BUG/5/" hello > hello.new &&
+ mv hello.new hello &&
+ add_and_commit_file hello "BUG fixed" &&
+ HASH5=$(git rev-parse --verify HEAD) &&
+ echo "line 12" >> hello &&
+ echo "line 13" >> hello &&
+ add_and_commit_file hello "2 more lines" &&
+ HASH6=$(git rev-parse --verify HEAD)
+ echo "line 14" >> hello &&
+ echo "line 15" >> hello &&
+ echo "line 16" >> hello &&
+ add_and_commit_file hello "again 3 more lines" &&
+ HASH7=$(git rev-parse --verify HEAD)
+'
+
+HASHFIX2=
+HASHFIX3=
+HASHFIX4=
+
+test_expect_success 'set up fixed branch' '
+ git checkout $HASH1 &&
+ echo "line 5" >> hello &&
+ echo "line 6" >> hello &&
+ echo "line 7" >> hello &&
+ echo "line 8" >> hello &&
+ add_and_commit_file hello "4 more lines with no BUG" &&
+ HASHFIX2=$(git rev-parse --verify HEAD) &&
+ git cherry-pick $HASH3 &&
+ HASHFIX3=$(git rev-parse --verify HEAD) &&
+ git cherry-pick $HASH4 &&
+ HASHFIX4=$(git rev-parse --verify HEAD)
+'
+
+test_expect_success '"git bisect replace" buggy branch with fixed one' '
+ git bisect replace $HASH5 HEAD
+'
+
+test_expect_success 'replace works when bisecting with a later bad commit' '
+ git rev-list --bisect-all $HASH7 > rev_list.txt &&
+ grep $HASHFIX2 rev_list.txt &&
+ grep $HASHFIX3 rev_list.txt &&
+ grep $HASHFIX4 rev_list.txt &&
+ test_must_fail grep $HASH2 rev_list.txt &&
+ test_must_fail grep $HASH3 rev_list.txt &&
+ test_must_fail grep $HASH4 rev_list.txt
+'
+
+test_expect_success 'replace works starting just after replaced commit' '
+ git rev-list --bisect-all $HASH6 > rev_list.txt &&
+ grep $HASHFIX2 rev_list.txt &&
+ grep $HASHFIX3 rev_list.txt &&
+ grep $HASHFIX4 rev_list.txt &&
+ test_must_fail grep $HASH2 rev_list.txt &&
+ test_must_fail grep $HASH3 rev_list.txt &&
+ test_must_fail grep $HASH4 rev_list.txt
+'
+
+test_expect_success 'replace works starting from replaced commit' '
+ git rev-list --bisect-all $HASH5 > rev_list.txt &&
+ grep $HASHFIX2 rev_list.txt &&
+ grep $HASHFIX3 rev_list.txt &&
+ grep $HASHFIX4 rev_list.txt &&
+ test_must_fail grep $HASH2 rev_list.txt &&
+ test_must_fail grep $HASH3 rev_list.txt &&
+ test_must_fail grep $HASH4 rev_list.txt
+'
+
+test_expect_success 'standard bisect works' '
+ git bisect start $HASH6 $HASH1 &&
+ test "$(git rev-parse --verify HEAD)" = "$HASHFIX3" &&
+ git bisect good &&
+ test "$(git rev-parse --verify HEAD)" = "$HASH5" &&
+ git bisect bad &&
+ test "$(git rev-parse --verify HEAD)" = "$HASHFIX4" &&
+ git bisect bad > my_bisect_log.txt &&
+ grep "$HASHFIX4 is first bad commit" my_bisect_log.txt &&
+ git bisect reset
+'
+
+#
+#
+test_done
--
1.6.0.3.619.g9a6a
^ permalink raw reply related
* [PATCH 1/7 v3] bisect: add "git bisect replace" subcommand
From: Christian Couder @ 2008-11-08 7:48 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git
This subcommand should be used when you have a branch or a part of a
branch that isn't easily bisectable because of a bug that has been
fixed latter.
We suppose that a bug as been introduced at some point, say A, and
that it has been fixed latter at another point, say B, but that
between these points the code is not easily testable because of the
bug, so it's not easy to bisect between these points.
In this case you can create a branch starting at the parent of A, say
O, that has a fixed history. In this fixed history for example, there
could be first a commit C that is the result of squashing A and B
together and then all the commits between A and B that have been
cherry picked.
For example, let's say the commits between A and B are X1, X2, ... Xn
and they have been cherry picked after C as Y1, Y2, ... Yn:
C--Y1--Y2--...--Yn
/
...--O--A--X1--X2--...--Xn--B--...
By design, the last cherry picked commit (Yn) should point to the same
tree as commit B.
So in this case you can say:
$ git bisect replace B Yn
and a branch will be created that points to commit Yn and that has a
special name like: "bisect-replace-B"
When bisecting, the branch names will be scanned and each branch named
"bisect-replace-X" and pointing to commit Y will be grafted so that
X will only have Y as parent.
In the example above, that means that instead of the above graph, the
following graph will be bisected:
C--Y1--Y2--...--Yn
/ \
...--O B--...
This means that the bisections on this branch will be much easier
because the bug introduced by commit A and fixed by commit B will not
annoy you anymore.
As the branches created by "git bisect replace" can be shared between
developers, this feature might be especially usefull on big projects
where many people often bisect the same code base.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-rev-list.c | 71 +++++++++++++++++++++++++++++++++++++++++++++++++++-
git-bisect.sh | 37 +++++++++++++++++++++++++-
2 files changed, 105 insertions(+), 3 deletions(-)
Changes since the previous series are the following:
- don't create a tag anymore and use the "bisect-replace-*"
branch to replace to detect grafts that should be created,
- tried to move "replace" subcommand before "run" subcommand,
- added patches from 4 to 7
Perhaps a few more tests are needed for latter patches
especially patch 7.
I wonder about the following:
- perhaps "git bisect replace" should have a "NAME" argument
so that the branch names could be like "bisect-rename-X-NAME"
which could be more descriptive,
- maybe a way to check that the replace branches all point to
existing commits would be useful,
- perhaps bisect log/replay could be improved to handle
replace branches
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 06cdeb7..c0717f6 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -574,6 +574,72 @@ static struct commit_list *find_bisection(struct commit_list *list,
return best;
}
+static void replace_parents(struct commit *commit,
+ const char *refname,
+ const unsigned char *sha1)
+{
+ struct commit *new_parent = lookup_commit(sha1);
+ if (!new_parent) {
+ warning("branch '%s' points to unknown commit '%s'",
+ refname, sha1_to_hex(sha1));
+ return;
+ }
+
+ free_commit_list(commit->parents);
+ commit->parents = NULL;
+ commit_list_insert(new_parent, &commit->parents);
+}
+
+static int bisect_replace(const char *refname, const unsigned char *sha1,
+ int flag, void *cb_data)
+{
+ unsigned char child[20];
+ struct object *obj;
+ struct commit_graft *graft;
+
+ if (prefixcmp(refname, "bisect-replace-"))
+ return 0;
+
+ if (get_sha1_hex(refname + 15, child)) {
+ warning("bad sha1 in branch name '%s'", refname);
+ return 0;
+ }
+
+ /* Check if child commit exist and is already parsed */
+
+ obj = lookup_object(child);
+ if (obj) {
+ struct commit *commit;
+ if (obj->type != OBJ_COMMIT) {
+ warning("branch name '%s' refers to non commit '%s'",
+ refname, refname + 15);
+ return 0;
+ }
+ commit = (struct commit *) obj;
+ if (commit->object.parsed) {
+ replace_parents(commit, refname, sha1);
+ return 0;
+ }
+ }
+
+ /* Create a graft to replace child commit parents */
+
+ graft = xmalloc(sizeof(*graft) + 20);
+
+ hashcpy(graft->sha1, child);
+ graft->nr_parent = 1;
+ hashcpy(graft->parent[0], sha1);
+
+ register_commit_graft(graft, 1);
+
+ return 0;
+}
+
+static void bisect_replace_all(void)
+{
+ for_each_branch_ref(bisect_replace, NULL);
+}
+
int cmd_rev_list(int argc, const char **argv, const char *prefix)
{
struct commit_list *list;
@@ -646,8 +712,11 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
save_commit_buffer = revs.verbose_header ||
revs.grep_filter.pattern_list;
- if (bisect_list)
+
+ if (bisect_list) {
+ bisect_replace_all();
revs.limited = 1;
+ }
if (prepare_revision_walk(&revs))
die("revision walk setup failed");
diff --git a/git-bisect.sh b/git-bisect.sh
index 79de701..1daa81c 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run]'
+USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|replace|run]'
LONG_USAGE='git bisect help
print this long help message.
git bisect start [<bad> [<good>...]] [--] [<pathspec>...]
@@ -21,6 +21,8 @@ git bisect replay <logfile>
replay bisection log.
git bisect log
show bisect log.
+git bisect replace <rev> [<rev>]
+ use another branch for bisection.
git bisect run <cmd>...
use <cmd>... to automatically bisect.
@@ -566,6 +568,36 @@ bisect_replay () {
bisect_auto_next
}
+bisect_replace() {
+ test "$#" -ge 1 -a "$#" -le 2 ||
+ die "'git bisect replace' accept one or two arguments"
+
+ source="$1"
+ target="${2:-HEAD}"
+
+ # Check arguments
+ src_commit=$(git rev-parse --verify "$source^{commit}") ||
+ die "Bad rev input: $source"
+ tgt_commit=$(git rev-parse --verify "$target^{commit}") ||
+ die "Bad rev input: $target"
+
+ test "$src_commit" != "tgt_commit" ||
+ die "source and target should be different commits"
+
+ # Check that trees from source and target are identical
+ src_tree=$(git rev-parse --verify "$src_commit^{tree}") ||
+ die "Could not get tree for source: $source"
+ tgt_tree=$(git rev-parse --verify "$tgt_commit^{tree}") ||
+ die "Could not get tree for target: $target"
+
+ test "$src_tree" = "$tgt_tree" ||
+ die "source and target should point to the same tree"
+
+ # Create branch for the target commit
+ tgt_branch="bisect-replace-$src_commit"
+ git branch "$tgt_branch" "$tgt_commit"
+}
+
bisect_run () {
bisect_next_check fail
@@ -618,7 +650,6 @@ bisect_run () {
done
}
-
case "$#" in
0)
usage ;;
@@ -645,6 +676,8 @@ case "$#" in
cat "$GIT_DIR/BISECT_LOG" ;;
run)
bisect_run "$@" ;;
+ replace)
+ bisect_replace "$@" ;;
*)
usage ;;
esac
--
1.6.0.3.619.g9a6a
^ permalink raw reply related
* Re: absurdly slow git-diff
From: Junio C Hamano @ 2008-11-08 5:30 UTC (permalink / raw)
To: Davide Libenzi
Cc: Linus Torvalds, Abhijit Menon-Sen, Pierre Habouzit,
Git Mailing List
In-Reply-To: <alpine.DEB.1.10.0811071547080.8736@alien.or.mcafeemobile.com>
Davide Libenzi <davidel@xmailserver.org> writes:
> Yeah, similar. Mine is below. There's one less branch in the for loops.
Thanks, will apply like this, but I am not sure if you meant windowN or
just window...
-- >8 --
From: Davide Libenzi <davidel@xmailserver.org>
Date: Fri, 7 Nov 2008 21:24:33 -0800
Subject: [PATCH] xdiff: give up scanning similar lines early
In a corner case of large files whose lines do not match uniquely, the
loop to eliminate a line that matches multiple locations adjacent to a run
of lines that do not uniquely match wasted too much cycles. Fix this by
giving up early after scanning 100 lines in both direction.
---
xdiff/xprepare.c | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/xdiff/xprepare.c b/xdiff/xprepare.c
index e87ab57..6a70cdf 100644
--- a/xdiff/xprepare.c
+++ b/xdiff/xprepare.c
@@ -23,10 +23,9 @@
#include "xinclude.h"
-
#define XDL_KPDIS_RUN 4
#define XDL_MAX_EQLIMIT 1024
-
+#define XDL_SIMSCAN_WINDOWN 100
typedef struct s_xdlclass {
@@ -313,6 +312,18 @@ static int xdl_clean_mmatch(char const *dis, long i, long s, long e) {
long r, rdis0, rpdis0, rdis1, rpdis1;
/*
+ * Limits the window the is examined during the similar-lines
+ * scan. The loops below stops when dis[i - r] == 1 (line that
+ * has no match), but there are corner cases where the loop
+ * proceed all the way to the extremities by causing huge
+ * performance penalties in case of big files.
+ */
+ if (i - s > XDL_SIMSCAN_WINDOWN)
+ s = i - XDL_SIMSCAN_WINDOWN;
+ if (e - i > XDL_SIMSCAN_WINDOWN)
+ e = i + XDL_SIMSCAN_WINDOWN;
+
+ /*
* Scans the lines before 'i' to find a run of lines that either
* have no match (dis[j] == 0) or have multiple matches (dis[j] > 1).
* Note that we always call this function with dis[i] > 1, so the
--
1.6.0.3.674.gdf99f
^ permalink raw reply related
* Re: [PATCH 2/2] Cached the git configuration, which is now noticibly faster on windows.
From: David Symonds @ 2008-11-08 5:19 UTC (permalink / raw)
To: John Chapman; +Cc: git
In-Reply-To: <1226114569-8506-2-git-send-email-thestar@fussycoder.id.au>
On Fri, Nov 7, 2008 at 7:22 PM, John Chapman <thestar@fussycoder.id.au> wrote:
> +_gitConfig = {}
> def gitConfig(key):
> - return read_pipe("git config %s" % key, ignore_error=True).strip()
> + if not _gitConfig.has_key(key):
> + _gitConfig[key] = read_pipe("git config %s" % key, ignore_error=True).strip()
> + return _gitConfig[key]
If this is truly a noticeable bottleneck on Windows, something like
the following might be even better: (completely untested!)
_gitConfig = None
def gitConfig(key):
if _gitConfig is None:
lines = read_pipe("git config -l", ignore_error=True).readlines():
_gitConfig = dict([l.strip().split('=', 1) for l in lines])
return _gitConfig.get(key, None)
Dave.
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: David Symonds @ 2008-11-08 5:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200811080254.53202.jnareb@gmail.com>
On Fri, Nov 7, 2008 at 5:54 PM, Jakub Narebski <jnareb@gmail.com> wrote:
Here's my thoughts on some of these talks.
> Mon, Oct 27, 2008
> -----------------
> * Dscho: Contributing with Git
> http://www.youtube.com/watch?v=j45cs5_nY2k
It was a good intro, but I was expecting a few more non-GitTogether
people. We had quite a large room, but there was only about a dozen
other people who came along. I don't know whether that was the fault
of the timing, lack of advertising, or a lack of interest.
> * Junio: Git Chronicle
>
> blog: Junio went though a sort of statistical history of the Git project
> that was fascinating (turns out there are still about 220 lines of code
> still around from Linus original first commit).
This was really interesting. It would be great to put this on a
general web page instead of in a PDF.
> * Petr: Renames Again and Again and Again
>
> IRC: detection of wholesame renames of directories (WIP) and '--follow'
> limitation were mentioned, but outcome is unclear; pasky plans to hack
> together some patch implementing explicit renames hinting
One thing I didn't get around to bringing up: one of the benefits of
diff-time rename detection that is often touted is that algorithms can
improve over time. Do folk here know whether that has actually
happened recently, in a general way? Do people actually expect major
improvements in the future?
> * Tom: GitHub
>
> IRC: a tour, some history, and insight into how it works; some nice
> gimmicks, such as "gist" (a git backed pastebin), or like network graphs
> (look graphically at forks of a repository).
>
> blog: Tom got to demonstrate GitHub and Gist to the group, most of whom
> are very command line oriented and had not used either before.
The demo of iGitHub (an iPhone app that can act as a clone/push
target) looked really cool, if it can get further development. It
could potentially be really handy for travellers who could push to
their iPhone, and then push from there to an internet server.
> * Scott: Linkable Library
>
> blog: got to talk about the need for a linkable git library
>
> http://thread.gmane.org/gmane.comp.version-control.git/99608
It's good to see this starting to get wider traction. I think we
discussed that there could be benefits to git itself, beyond just
helping other programs access git repositories faster than fork/exec.
> * Sam: perl.git
>
> blog: Sam demonstrated the work he went through to import 20 years of Perl
> history into the git repository that the Perl team is just now finishing
> transitioning to from Perforce.
>
> http://utsl.gen.nz/talks/perl-history/slides/
It was very cool to see old-school email addresses like <isis!aburt>
in git, handled just fine.
> * Tim: Git as a Media Repository
> http://www.thousandparsec.net/~tim/media+git.pdf
This has kicked off some mailing list discussion; I think this can be
a major weak point for git, since checking out only a subtree (and
only the latest revision) is the common SVN way, which copes with
media repositories and the like just fine.
> * JH: $$$ discussion
>
> IRC: It was about the Google Summer of Code 2008 mentor money. It was
> decided (given most of the mentors were there) to use it to help a few
> folks cover their travel expenses to the GitTogether. Most folks actually
> had their costs covered by their employer (yay for some big companies!)
> but a few paid out of pocket, so we are helping them defray it a bit. and
> the rest is being used to order and distribute some git t-shirts.
Yes, how are the t-shirts going? I seem to remember JH had volunteered
to do the logistics there.
Dave.
^ permalink raw reply
* [PATCH 2/2] Cached the git configuration, which is now noticibly faster on windows.
From: John Chapman @ 2008-11-08 3:22 UTC (permalink / raw)
To: git; +Cc: John Chapman
In-Reply-To: <1226114569-8506-1-git-send-email-thestar@fussycoder.id.au>
Signed-off-by: John Chapman <thestar@fussycoder.id.au>
---
contrib/fast-import/git-p4 | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 38d1a17..9f0a5f9 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -316,8 +316,11 @@ def gitBranchExists(branch):
stderr=subprocess.PIPE, stdout=subprocess.PIPE);
return proc.wait() == 0;
+_gitConfig = {}
def gitConfig(key):
- return read_pipe("git config %s" % key, ignore_error=True).strip()
+ if not _gitConfig.has_key(key):
+ _gitConfig[key] = read_pipe("git config %s" % key, ignore_error=True).strip()
+ return _gitConfig[key]
def p4BranchesInGit(branchesAreInRemotes = True):
branches = {}
--
1.6.0.3.643.g233db
^ permalink raw reply related
* [PATCH 1/2] Added support for purged files and also optimised memory usage.
From: John Chapman @ 2008-11-08 3:22 UTC (permalink / raw)
To: git; +Cc: John Chapman
Purged files are handled as if they are merely deleted, which is not
entirely optimal, but I don't know of any other way to handle them.
File data is deleted from memory as early as they can, and they are more
efficiently handled, at (significant) cost to CPU usage.
Still need to handle p4 branches with spaces in their names.
Still need to make git-p4 clone more reliable.
- Perhaps with a --continue option. (Sometimes the p4 server kills
the connection)
Signed-off-by: John Chapman <thestar@fussycoder.id.au>
---
contrib/fast-import/git-p4 | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 2216cac..38d1a17 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -946,7 +946,7 @@ class P4Sync(Command):
if includeFile:
filesForCommit.append(f)
- if f['action'] != 'delete':
+ if f['action'] not in ('delete', 'purge'):
filesToRead.append(f)
filedata = []
@@ -965,11 +965,11 @@ class P4Sync(Command):
while j < len(filedata):
stat = filedata[j]
j += 1
- text = [];
+ text = ''
while j < len(filedata) and filedata[j]['code'] in ('text', 'unicode', 'binary'):
- text.append(filedata[j]['data'])
+ text += filedata[j]['data']
+ del filedata[j]['data']
j += 1
- text = ''.join(text)
if not stat.has_key('depotFile'):
sys.stderr.write("p4 print fails with: %s\n" % repr(stat))
@@ -1038,7 +1038,7 @@ class P4Sync(Command):
continue
relPath = self.stripRepoPath(file['path'], branchPrefixes)
- if file["action"] == "delete":
+ if file["action"] in ("delete", "purge"):
self.gitStream.write("D %s\n" % relPath)
else:
data = file['data']
@@ -1077,7 +1077,7 @@ class P4Sync(Command):
cleanedFiles = {}
for info in files:
- if info["action"] == "delete":
+ if info["action"] in ("delete", "purge"):
continue
cleanedFiles[info["depotFile"]] = info["rev"]
@@ -1400,7 +1400,7 @@ class P4Sync(Command):
if change > newestRevision:
newestRevision = change
- if info["action"] == "delete":
+ if info["action"] in ("delete", "purge"):
# don't increase the file cnt, otherwise details["depotFile123"] will have gaps!
#fileCnt = fileCnt + 1
continue
--
1.6.0.3.643.g233db
^ permalink raw reply related
* Re: absurdly slow git-diff
From: Abhijit Menon-Sen @ 2008-11-08 4:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Davide Libenzi, Junio C Hamano, Pierre Habouzit, git
In-Reply-To: <alpine.LFD.2.00.0811071554590.3468@nehalem.linux-foundation.org>
At 2008-11-07 15:57:23 -0800, torvalds@linux-foundation.org wrote:
>
> > Yeah, similar. Mine is below. There's one less branch in the for
> > loops.
>
> ..and has a comment and made the magic constant be named.
It works fine for me (the time went from 5m17s to 1.8s).
(By the way, my test case is certainly very odd, but it is a real file
from my test suite, albeit with the content x'ed away; and the change
was to adjust the expected output for all the items. I wasn't looking
for bugs. :-)
Thanks for the explanation and the patch.
-- ams
^ permalink raw reply
* Re: [PATCH 1/2] Introduce rename factorization in diffcore.
From: Nguyen Thai Ngoc Duy @ 2008-11-08 4:32 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <fcaeb9bf0811072030u272a6732g2450e1854b96ca18@mail.gmail.com>
On 11/8/08, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> Hmm.. how about turn on a special flag for these rename_dst items?
> Otherwise --group-renames and --find-copies-harder combination would
> become hell: you have to compare all src with all dst. It could exceed
> rename_limit, therefore no rename detection will be done.
Nevermind. I read an old version.
--
Duy
^ permalink raw reply
* Re: [PATCH 1/2] Introduce rename factorization in diffcore.
From: Nguyen Thai Ngoc Duy @ 2008-11-08 4:30 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20081030221645.3325.78288.stgit@gandelf.nowhere.earth>
On 10/31/08, Yann Dirson <ydirson@altern.org> wrote:
> - else if (detect_rename == DIFF_DETECT_COPY) {
> - /*
> - * Increment the "rename_used" score by
> - * one, to indicate ourselves as a user.
> - */
> - p->one->rename_used++;
> - register_rename_src(p->one, p->score);
> + else {
> + if (detect_rename == DIFF_DETECT_COPY) {
> + /*
> + * Increment the "rename_used" score by
> + * one, to indicate ourselves as a user.
> + */
> + p->one->rename_used++;
> + register_rename_src(p->one, p->score);
> + }
> + if (DIFF_OPT_TST(options, FACTORIZE_RENAMES)) {
> + /* similarly, rename factorization needs to
> + * see all files from second tree
> + */
> + //p->two->rename_used++; // FIXME: would we need that ?
> + locate_rename_dst(p->two, 1);
> + }
> }
> }
Hmm.. how about turn on a special flag for these rename_dst items?
Otherwise --group-renames and --find-copies-harder combination would
become hell: you have to compare all src with all dst. It could exceed
rename_limit, therefore no rename detection will be done.
--
Duy
^ permalink raw reply
* Re: [PATCH 1/2] diffcore-rename: support rename cache
From: Nguyen Thai Ngoc Duy @ 2008-11-08 4:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Yann Dirson, git
In-Reply-To: <7vy6zvdt25.fsf@gitster.siamese.dyndns.org>
On 11/8/08, Junio C Hamano <gitster@pobox.com> wrote:
> Yann Dirson <ydirson@altern.org> writes:
>
> > On Fri, Nov 07, 2008 at 09:35:32PM +0700, Nguy???n Thái Ng???c Duy wrote:
> >> This patch teaches diffcore_rename() to look into
> >> $GIT_DIR/rename-cache and make use of it to recreate diff_filepair.
> >> With proper cache, there should be no available entry for estimation
> >> after exact matching.
> >
> > This is something I have thought about in the past, good to see that
> > implemented :)
> >
> >> Rename caching is per commit. I don't think abitrary tree-tree caching
> >> is worth it.
> >
> > That could be a nice complement to my directory-rename patch.
>
>
> Has anybody thought about interaction between that caching and pathspec
> limited operation?
>
I didn't. But I think all out-of-pathspec diff pairs are removed
before it reaches diffcore_rename() so the cache has nothing to do
with it (except it still loads full cache for a commit).
--
Duy
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Johan Herland @ 2008-11-08 3:41 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Jeff King
In-Reply-To: <200811080254.53202.jnareb@gmail.com>
On Saturday 08 November 2008, Jakub Narebski wrote:
> GitTogether 2008, which took place October 27(Mon)-29(Wed), has ended
> more than week ago. Therefore I'd like to ask you impressions (while it
> is still fresh) from GitTogether, describe talks which are not described
> below, correct wrong information in below, etc.
Thanks for providing this summary to those of us that didn't attend.
> * Discussion on notes
Can someone elaborate on this? AFAIK, notes have popped up on this list
often enough that I'm convinced it would be a _really_ useful feature. The
only drawback I was aware of, was the lack of an efficient implementation,
but then Jeff comes out of the blue and posts some interesting numbers [1]
a week or so ago. Does this mean there are no remaining obstacles?
[1]: http://article.gmane.org/gmane.comp.version-control.git/99415
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* How it was at GitTogether'08 ?
From: Jakub Narebski @ 2008-11-08 1:54 UTC (permalink / raw)
To: git
GitTogether 2008, which took place October 27(Mon)-29(Wed), has ended more
than week ago. Therefore I'd like to ask you impressions (while it is still
fresh) from GitTogether, describe talks which are not described below,
correct wrong information in below, etc.
Please reply to this email while GitTogether is on front of your mind...
Talks at GitTogether 2008
=========================
Mon, Oct 27, 2008
-----------------
* Dscho: Contributing with Git
http://www.youtube.com/watch?v=j45cs5_nY2k
* Junio: Git Chronicle
blog: Junio went though a sort of statistical history of the Git project
that was fascinating (turns out there are still about 220 lines of code
still around from Linus original first commit).
http://userweb.kernel.org/~junio/200810-Chron.pdf
* Jeff: Helping new contributors join
* Petr: Renames Again and Again and Again
IRC: detection of wholesame renames of directories (WIP) and '--follow'
limitation were mentioned, but outcome is unclear; pasky plans to hack
together some patch implementing explicit renames hinting
* Sam: GitTorrent
IRC: briefly the history if GitTorrent: way underannounced, not completely
finished, GTP/0.1 was "published" long ago. There was a GSoC project this
year, mentored by mugwump. Unfortunately, the student turned out to be a
procrastinator or something, and this project was mainly pushed forward by
the mentor. Now after the summer, mugwump took a step back and analyzed
the protocol with all the experience won from implementing a large part of
it. Turns out that a lot of the stuff was not really necessary, but copied
because the BitTorrent protocol had it all. So, plan is to really strip
down GTP. And not have a separate protocol for GitTorrent, but rather
have it as part of git-daemon. [...] Turns out that warthog9 had a few
really important things to say that should end up (at least in the 2nd
version) in having a more robust discovery/exchange.
http://utsl.gen.nz/talks/gittorrent/start.html
* Tom: GitHub
IRC: a tour, some history, and insight into how it works; some nice
gimmicks, such as "gist" (a git backed pastebin), or like network graphs
(look graphically at forks of a repository).
blog: Tom got to demonstrate GitHub and Gist to the group, most of whom
are very command line oriented and had not used either before.
* Shawn: JGit
* Scott: Linkable Library
blog: got to talk about the need for a linkable git library
http://thread.gmane.org/gmane.comp.version-control.git/99608
* Sam: perl.git
blog: Sam demonstrated the work he went through to import 20 years of Perl
history into the git repository that the Perl team is just now finishing
transitioning to from Perforce.
http://utsl.gen.nz/talks/perl-history/slides/
Tue, Oct 28, 2008
-----------------
* Shawn: Pack v4
IRC: Shawn gave a pretty good summary of packv4, and he said what are the
major blocks: we need a refactoring of the tree walker first, and then it
would add a pretty complex heap of code to make use of the packv4 format
for tree walking. Main concern was _not_ the size of pack (for spearce at
least), but the speed of rev-list parsing with path delimiters [...] The
tree walking needs a different interface. (Path-delimiting must be a part
of it, not an afterthought. Mode filtering must be a part of it, not an
afterthought.) Estimations for packv4: 10% decrease in size, 25% increase
in speed. [...] reworking packv4 to do it for OBJ_BLOB too (and the
obvious path to speed-optimize git grep -w) has not been touched at all.
* Jeff: What needs refactoring?
* David Brown: Life with Git
http://www.davidb.org/git/git-corp.pdf
* Lighting Round Talks
- Scott: iGitHub - git daemon and repository browser on the iPhone
- Jeff: Portability autobuilders
- Petr: Quick TopGit introduction, problems, future plans
IRC: iGitHub - its a tiny app you run on your iphone to make your iphone
act as a git server/client. since apple doesn't let you tether your laptop
through your iphone to get wireless internet you can instead push a
repository to the iphone via the laptop, then push from there to the
world, or fetch from the world to the iphone, then from the iphone to the
laptop. it also has a small history browser and stuff built in.
* Jeffrey Altman: Discussion with OpenAFS
IRC: was about them trying to convert their franken-CVS repo to
Git. Basically, they use CVS, but have a layer on top of it that logically
combines two related commits into a single "delta", and they want to
preseve those as single git commits to the extent possible (sometimes it
is not possible because of conflicts). They are looking for ways to script
the conversion.
The OpenAFS guys were also interested in helping with libgit and windows
TortoiseGit work (separate conversation).
* Tim: Git as a Media Repository
http://www.thousandparsec.net/~tim/media+git.pdf
* Petr: Git UI
IRC: pasky talked a little bit about what he still misses in git.git CLI:
commit -m piping through fmt; the "reset and checkout" vs "switch, reset
and restore" paradigm; add vs stage; a bit about submodules [...] and
spent most of the time in a bikeshed argument about
add/rm/stage/unstage/staged/revert/restore/switch/. [...] Basically, reset
and checkout sucks and has chaotic behaviour with various switches and
argument combinations (files given vs not given etc.) So in ideal world,
reset and checkout might've been deprecated and instead, switch, restore
and unstage would be introduced... but that's not gonna happen.
blog: The other important, highly visual thing that was discussed, and
even a few patches are already in for, is for little improvements to the
UI. The full planning document is on Gist, but already things like making
use of the term 'stage' for things that happen in the index (such as using
"git diff --staged" instead of "git diff --cached") is being worked
on. I'm excited that staging files may soon be done via "git stage"
rather-than/in-addition-to "git add". This is nice for new users who often
have a hard time seeing why you have to keep "git add"ing to stage your
changes.
http://pasky.or.cz/~pasky/cp/gittogether-ui.sxi
http://gist.github.com/20818
http://thread.gmane.org/gmane.comp.version-control.git/99572
http://thread.gmane.org/gmane.comp.version-control.git/99541
* Steven: Life with git-svn
Wed, Oct 29, 2008
-----------------
* Shawn: Bundle Project
IRC: Gerrit is issue tracker / code review tool, which takes full bundles
and moves them around, and only when it was reviewed, it is actually
applied.
http://android.git.kernel.org/?p=tools/gerrit.git
* Discussion on notes
* Petr: introduce the secret pickaxe project
http://repo.or.cz/w/giddy.git
* Petr: Git in Pharma Corp
http://pasky.or.cz/~pasky/cp/gittogether-novartis.sxi
http://pasky.or.cz/g/gitweb.cgi?p=templatedemo.git;a=summary
* Tim: Large media in Git (Repeat)
IRC: Large = 100M and more (e.g. audio or video assets for a game). the
idea was that you would have shallow _and_ lazy clones. There was not much
discussion about implementation details, though; except that there should
be a mode where blobs are _not_ fetched, and that every non-blob has to be
local.
IRC: Tim Ansell (mithro) of Thousand Parsec still uses SVN for this
because he can checkout just one file, edit it, and push it
back. Basically he wants to clone the metadata (commits and trees and
small blobs) and have large blobs (e.g. >25 MB or some limit) kept on the
origin, lazily fetched over a git transport on demand. Tim started to work
up a prototype using HTTP. folks thought the idea showed promise, but we
need to see code and the impacts it has and where it breaks down to really
understand if it is worth doing or not.
blog: Tim talked about something that I think will be one of the next huge
(highly visible) changes in Git you\u2019re likely to see in the next year
\u2013 handling large meda well, and being able to do narrow and sparse
clones, (and shallow clones better). This means being able to clone part
of a Git repository, such as just the last revision (shallow), just the
\u2018lib\u2019 directory (narrow) or just a single file
(sparse). Importantly, you would be able to see the history of everything
still (it would download the commit and tree objects, which are generally
small, but not the larger blobs), and you would be able to do pushes back
(which shallow clones can\u2019t currently do).
http://www.thousandparsec.net/~tim/media+git.pdf
* JH: $$$ discussion
IRC: It was about the Google Summer of Code 2008 mentor money. It was
decided (given most of the mentors were there) to use it to help a few
folks cover their travel expenses to the GitTogether. Most folks actually
had their costs covered by their employer (yay for some big companies!)
but a few paid out of pocket, so we are helping them defray it a bit. and
the rest is being used to order and distribute some git t-shirts.
* Sam: Git as a DB Backend
IRC: mugwump had this idea of running a sql sort of database in git, using
the git logs as a way to implement an ACID complaint database. to be
honest i was busy reading email or something and didn't pay much attention
to his talk, but folks seemed to think it was an abuse of git
* Petr: GUI Even a Designer Uses
IRC: it was rather short and ambiguous; mostly arguing whether to and in
what language/toolkit to reimplement git-gui
Sources:
========
* http://git.or.cz/gitwiki/GitTogether
* http://google-opensource.blogspot.com/2008/11/gittogether-08.html
* http://github.com/blog/196-gittogether-2008
* Calendar ID: amj5rbmljs66k9rtibs34kc2c8@group.calendar.google.com
* http://colabti.org/irclogger/irclogger_log_search/git
#git channel on irc.freenode.org
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH 2/3] Introduce rename factorization in diffcore.
From: Yann Dirson @ 2008-11-08 0:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4h7dowd.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 07, 2008 at 04:47:46PM -0800, Junio C Hamano wrote:
> Yann Dirson <ydirson@altern.org> writes:
>
> > ... Commands
> > for saving/mailing patches could issue a bold warning if the user
> > specifies the for-human-viewing flag.
>
> If it is a warning to the user who produces the patch, and not but a
> warning in the patch text for the user who receives it, it is not useful.
OK to get everyone warned :)
^ permalink raw reply
* Re: [PATCH 2/3] Introduce rename factorization in diffcore.
From: Junio C Hamano @ 2008-11-08 0:47 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20081108002952.GC4030@nan92-1-81-57-214-146.fbx.proxad.net>
Yann Dirson <ydirson@altern.org> writes:
> ... Commands
> for saving/mailing patches could issue a bold warning if the user
> specifies the for-human-viewing flag.
If it is a warning to the user who produces the patch, and not but a
warning in the patch text for the user who receives it, it is not useful.
> I was talking about exchanging patches with the non-git part of the
> world.
Renaming patch needs manual massaging if you want to use GNU patch and
that is not a new issue. People know that.
The problem is in your example output were that it would break _existing
git tools_ with a backward incompatible change, when you did not have to.
That's the difference.
^ permalink raw reply
* Re: [PATCH 2/3] Introduce rename factorization in diffcore.
From: Yann Dirson @ 2008-11-08 0:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhc6jdrvs.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 07, 2008 at 03:43:19PM -0800, Junio C Hamano wrote:
> Yann Dirson <ydirson@altern.org> writes:
>
> > I hope I just miss your point. Letting unaware tools handle such a
> > patch "the right way" would imply just adding the information "dir foo
> > moved to bar", and not removing the individual file moves, which goes
> > in the way of the exact reason why I have started to work on this.
>
> If your change is to move a/{1,2,3} to b/{1,2,3} and without content
> change to a/{1,2} to b/{1,2}, then do you want to say "a/ moved to b/
> and by the way here is the content change from a/3 to b/3" without saying
> anything about a/{1,2} and b/{1,2}?
>
> Two points.
>
> * I do not think it is a good idea to begin with. If you are to apply
> such a patch (with git-apply that is updated with your patch to
> understand that notation) to the exact tree that has only {1,2,3} under
> a/, you would get an expected result. But if the recipient of your
> patch has a/4 (or lacks a/2), there is no cue in the patch that
> automatically moving a/4 to b/4 may or may not be what is sane (or the
> patch is unapplicable in general).
Sure in theory. But in practice I do not remember one time when, if
all files from one dir are moved in one branch, the files added on
another in the same dir were not bound to be moved as well.
Anway, if we feel git-apply should not decide without the user
knowing, we can make it refuse by default, with options to do either
way, and one option to ask for each doubtful file instead.
> * If you give at least the names of paths that were moved without any
> content changes as I suggested, at least the recipient of your patch
> can catch the case where his tree is structurally different from what
> you used to prepare the patch for by noticing the a/2 in the patch that
> he does not have.
Right.
> In addition, if you keep the movements for the paths whose contents did
> not change, existing tools are perfectly capable of applying (or showing)
> the output. I seriously doubt that keeping 4 lines per perfectly moved
> paths is too much a price to pay to keep backward compatibility.
OK, so I realize we need 2 things here: one format for diff-exporting
with complete info, and one for human viewing (which is, again, the
primary reason why I needed this feature, so I'm not very keen on
letting all this work finally not being useful for me :). Commands
for saving/mailing patches could issue a bold warning if the user
specifies the for-human-viewing flag.
> > Compare this to the addition of the "file rename" feature (correct me
> > if I'm wrong): it was added without bothering whether plain old
> > "patch" can deal with it,...
>
> Sorry, but that's an old history whie git-diff output format was rapidly
> being developed, when we did not have that many users, and when we did not
> have an old version of git-apply that did not understand the new feature
> in majority of user's hands.
>
> We do not have that kind of luxury anymore. git is much more widespread
> now and the majority of people use pre-1.6.1 git now (including me ;-)).
I was talking about exchanging patches with the non-git part of the
world. The point is that eg. GNU patch still happily accepts
git-generated files but produces nonsense using some, exactly because
it ignores meaningful data which (by design ?) appear to it to be
legal to ignore.
^ permalink raw reply
* Re: absurdly slow git-diff
From: Pierre Habouzit @ 2008-11-08 0:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Abhijit Menon-Sen, Davide Libenzi, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811071335010.3468@nehalem.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]
On Fri, Nov 07, 2008 at 09:37:29PM +0000, Linus Torvalds wrote:
>
> On Sat, 8 Nov 2008, Abhijit Menon-Sen wrote:
> >
> > If anyone's interested, the files are http://toroid.org/misc/1 and
> > http://toroid.org/misc/2
> I'm also adding Pierre, since he was talking about trying to implement
> another diff algorithm (although I'm not at all sure that the patience
> diff really would help this case at all).
FWIW Patience diff wouldn't help at all here. Patience diff is just a
matter of preseeding your preferred diff algorithm with better (wrt
human readability) candidate for the invariant lines. IOW it helps
dividing the problem into smaller bits, but requires *unique lines* to
start with. If you haven't any, then basically, Patience diff does
nothing and calls your usual diff algorithm on the whole files.
It does so in a pseudo linear complexity, hence should not make overall
time really worse, but will not help for the ending time usually either.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: absurdly slow git-diff
From: Linus Torvalds @ 2008-11-07 23:57 UTC (permalink / raw)
To: Davide Libenzi, Junio C Hamano
Cc: Abhijit Menon-Sen, Pierre Habouzit, Git Mailing List
In-Reply-To: <alpine.DEB.1.10.0811071547080.8736@alien.or.mcafeemobile.com>
On Fri, 7 Nov 2008, Davide Libenzi wrote:
>
> Yeah, similar. Mine is below. There's one less branch in the for loops.
..and has a comment and made the magic constant be named.
Junio, the time difference is quite big for Abhijit's admittedly odd
test-case:
- Before:
[torvalds@nehalem slow-diff]$ time git diff 1 2 > out.old
real 2m19.912s
user 2m19.885s
sys 0m0.024s
- After:
[torvalds@nehalem slow-diff]$ time ~/git/git diff 1 2 > out
real 0m0.841s
user 0m0.816s
sys 0m0.024s
with no difference in output.
Linus
^ 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