* Re: [ANNOUNCE] darcs-fast-export
From: zooko @ 2008-11-11 2:39 UTC (permalink / raw)
To: Miklos Vajna; +Cc: bazaar, mercurial, git, darcs-users
In-Reply-To: <20081111015313.GB24201@genesis.frugalware.org>
Hello Miklos Vajna:
Thanks for announcing this project.
I looked at the "alternatives" section, and you wrote:
"tailor is a nice any2any VCS converter, but the end result can
easily differ to the original repo because tailor replays all the
changesets itself, while darcs-fast-export just leaves this task to
darcs."
If you can show an example of the end result differing from the
original repo then that is a bug in tailor, and please report it!
Thanks.
Regards,
Zooko
---
http://allmydata.org -- Tahoe, the Least-Authority Filesystem
http://allmydata.com -- back up all your files for $10/month
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Avery Pennarun @ 2008-11-11 4:04 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Björn Steinbrink, Johannes Schindelin,
David Symonds, git, Stephan Beyer
In-Reply-To: <20081103071420.GD10772@coredump.intra.peff.net>
On Mon, Nov 3, 2008 at 2:14 AM, Jeff King <peff@peff.net> wrote:
> So "git diff --staged", while it makes sense to us (since we are asking
> "what is staged"), is not consistent with the discussed rules. In
> particular:
>
> 1. It operates on just the "stage" and not the working tree, so it
> should be "--staged-only". But the only there is nonsensical.
>
> 2. The default is _already_ operating on the staging area, so you are
> really switching up the working tree for the HEAD in what you are
> diffing. So in that sense, it doesn't convey the change in
> operation very well.
>
> And I am not proposing a change here (except to perhaps "git diff
> --staged" instead of "--cached"). Just pointing out that it does not
> follow the "--staged operates on both, --staged-only operates on just
> the index" rule.
>
> Hrm. For that matter, grep is a bit different, too. Since I would expect
> "git grep --staged" to find only staged things, not things in both the
> working tree and the index. So perhaps there is a difference between
> commands that modify and commands that inspect.
Speaking just for myself, I would find this all a lot less confusing
if "staged" were a refspec of some sort, not an option at all.
git diff HEAD..STAGED
git diff STAGED..WORKTREE
git grep pattern STAGED HEAD sillybranch WORKTREE ^ignorebranch --
path/to/files
git-rev-parse already gives us a nice syntax for including/excluding
particular trees as much as we like; the only problem is you can't
talk about the work tree or index as if they were revisions.
Have fun,
Avery
^ permalink raw reply
* [PATCH] Tell users that git protocol is not for pushing
From: Nathan W. Panike @ 2008-11-11 5:06 UTC (permalink / raw)
To: git; +Cc: Nathan W. Panike
When one attempts to push to a git-protocol repository, one gets the
line:
fatal: The remote end hung up unexpectedly
This seems a bit obscure to me. It is better to inform the user that git://
does not allow pushing.
---
transport.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/transport.c b/transport.c
index 56831c5..2c1577e 100644
--- a/transport.c
+++ b/transport.c
@@ -684,7 +684,9 @@ static int git_transport_push(struct transport *transport, int refspec_nr, const
args.use_thin_pack = data->thin;
args.verbose = !!(flags & TRANSPORT_PUSH_VERBOSE);
args.dry_run = !!(flags & TRANSPORT_PUSH_DRY_RUN);
-
+ if(strncmp(transport->url,"git",3)==0){
+ fprintf(stderr,"git protocol does not support push.\n");
+ }
return send_pack(&args, transport->url, transport->remote, refspec_nr, refspec);
}
--
1.6.0.4
^ permalink raw reply related
* [PATCH 1/9 v4] bisect: add "git bisect replace" subcommand
From: Christian Couder @ 2008-11-11 5:39 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 (v3) are the following:
- move 2 lines of code in patch 1,
- added tests in patch 7,
- added --no-replace option (patches 8 and 9)
I still wonder about the following:
- perhaps "git bisect replace" should have a "NAME" argument
so that the branch names could be like "bisect-replace-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
But I think it's already possible to do many things in the
current state, especially by using "git branch -m" (to rename
branches). For example to give a more explicit name:
$ git branch -m bisect-replace-X bisect-replace-X-explicit-name
and to not replace a branch any more (but keep it in case you may
use it again latter):
$ git branch -m bisect-replace-Y bisect-do-not-replace-Y
...
So as I don't want to over-engineer this and I am a bit lazy too,
I will wait for some comments. Thanks in advance for them!
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 0d0e278..b0139d5 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 ;;
@@ -643,6 +674,8 @@ case "$#" in
bisect_replay "$@" ;;
log)
cat "$GIT_DIR/BISECT_LOG" ;;
+ replace)
+ bisect_replace "$@" ;;
run)
bisect_run "$@" ;;
*)
--
1.6.0.3.614.g0f3b9
^ permalink raw reply related
* [PATCH 2/9 v4] bisect: add test cases for "git bisect replace"
From: Christian Couder @ 2008-11-11 5:39 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.614.g0f3b9
^ permalink raw reply related
* [PATCH 3/9 v4] Documentation: add "git bisect replace" documentation
From: Christian Couder @ 2008-11-11 5:39 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 39034ec..3834a34 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.614.g0f3b9
^ permalink raw reply related
* [PATCH 4/9 v4] rev-list: add "--bisect-replace" to list revisions with fixed up history
From: Christian Couder @ 2008-11-11 5:40 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 68a253f..36253b8 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.614.g0f3b9
^ permalink raw reply related
* [PATCH 5/9 v4] commit: add "bisect_replace_all" prototype to "commit.h"
From: Christian Couder @ 2008-11-11 5:41 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.614.g0f3b9
^ permalink raw reply related
* [PATCH 6/9 v4] merge-base: add "--bisect-replace" option to use fixed up revs
From: Christian Couder @ 2008-11-11 5:42 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.614.g0f3b9
^ permalink raw reply related
* [PATCH 7/9 v4] bisect: use "--bisect-replace" options when checking merge bases
From: Christian Couder @ 2008-11-11 5:45 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 4 ++--
t/t6035-bisect-replace.sh | 10 ++++++++++
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index b0139d5..be37b64 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
diff --git a/t/t6035-bisect-replace.sh b/t/t6035-bisect-replace.sh
index 8fe7cc5..dabf1ae 100755
--- a/t/t6035-bisect-replace.sh
+++ b/t/t6035-bisect-replace.sh
@@ -144,6 +144,16 @@ test_expect_success '"git merge-base --bisect-replace" works' '
test "$hash" = "$HASH1"
'
+test_expect_success 'git bisect works when starting on the replace branch' '
+ git bisect start $HASH7 $HASHFIX3 &&
+ test "$(git rev-parse --verify HEAD)" = "$HASH5" &&
+ git bisect bad &&
+ test "$(git rev-parse --verify HEAD)" = "$HASHFIX4" &&
+ git bisect good > my_bisect_log.txt &&
+ grep "$HASH5 is first bad commit" my_bisect_log.txt &&
+ git bisect reset
+'
+
#
#
test_done
--
1.6.0.3.614.g0f3b9
^ permalink raw reply related
* [PATCH 8/9 v4] rev-list: make it possible to disable replacing using "--no-bisect-replace"
From: Christian Couder @ 2008-11-11 5:45 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-rev-list.txt | 1 +
Documentation/rev-list-options.txt | 10 ++++++++++
builtin-rev-list.c | 20 ++++++++++++++++----
t/t6035-bisect-replace.sh | 10 ++++++++++
4 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 4cc8abf..b466da3 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -42,6 +42,7 @@ SYNOPSIS
[ \--bisect-vars ]
[ \--bisect-all ]
[ \--bisect-replace ]
+ [ \--no-bisect-replace ]
[ \--merge ]
[ \--reverse ]
[ \--walk-reflogs ]
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 36253b8..e207b4f 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -522,6 +522,16 @@ 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.
+
+--no-bisect-replace::
+
+With this option, 'rev-list' will not make use of the
+"bisect-replace-*" branches, even if another `--bisect*` option is
+used.
+
+By default, if any `--bisect*` option is used, 'rev-list' will graft
+"bisect-replace-*" branches into other branches when bisecting, so
+that bisection can be performed on a fixed up history.
endif::git-rev-list[]
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 7cf5f9e..65e59d6 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -48,13 +48,20 @@ static const char rev_list_usage[] =
" --bisect\n"
" --bisect-vars\n"
" --bisect-all\n"
-" --bisect-replace"
+" --bisect-replace\n"
+" --no-bisect-replace"
;
static struct rev_info revs;
+enum {
+ REPLACE_UNSET,
+ REPLACE_DEFAULT,
+ REPLACE_SET
+};
+
static int bisect_list;
-static int bisect_replace_only;
+static int bisect_force_replace = REPLACE_DEFAULT;
static int show_timestamp;
static int hdr_termination;
static const char *header_prefix;
@@ -684,7 +691,11 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
continue;
}
if (!strcmp(arg, "--bisect-replace")) {
- bisect_replace_only = 1;
+ bisect_force_replace = REPLACE_SET;
+ continue;
+ }
+ if (!strcmp(arg, "--no-bisect-replace")) {
+ bisect_force_replace = REPLACE_UNSET;
continue;
}
if (!strcmp(arg, "--stdin")) {
@@ -719,7 +730,8 @@ 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 || bisect_replace_only)
+ if (bisect_force_replace != REPLACE_UNSET &&
+ (bisect_list || bisect_force_replace == REPLACE_SET))
bisect_replace_all();
if (bisect_list)
revs.limited = 1;
diff --git a/t/t6035-bisect-replace.sh b/t/t6035-bisect-replace.sh
index dabf1ae..f22a2e5 100755
--- a/t/t6035-bisect-replace.sh
+++ b/t/t6035-bisect-replace.sh
@@ -154,6 +154,16 @@ test_expect_success 'git bisect works when starting on the replace branch' '
git bisect reset
'
+test_expect_success '"git rev-list --no-bisect-replace" works' '
+ git rev-list --bisect-all --no-bisect-replace $HASH6 > rev_list.txt &&
+ test_must_fail grep $HASHFIX2 rev_list.txt &&
+ test_must_fail grep $HASHFIX3 rev_list.txt &&
+ test_must_fail grep $HASHFIX4 rev_list.txt &&
+ grep $HASH2 rev_list.txt &&
+ grep $HASH3 rev_list.txt &&
+ grep $HASH4 rev_list.txt
+'
+
#
#
test_done
--
1.6.0.3.614.g0f3b9
^ permalink raw reply related
* [PATCH 9/9 v4] bisect: add "--no-replace" option to bisect without using replace branches
From: Christian Couder @ 2008-11-11 5:46 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-bisect.txt | 6 +++++-
git-bisect.sh | 26 ++++++++++++++++++++------
t/t6035-bisect-replace.sh | 10 ++++++++++
3 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 3834a34..ce8d7c1 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -16,7 +16,7 @@ The command takes various subcommands, and different options depending
on the subcommand:
git bisect help
- git bisect start [<bad> [<good>...]] [--] [<paths>...]
+ git bisect start [--no-replace] [<bad> [<good>...]] [--] [<paths>...]
git bisect bad [<rev>]
git bisect good [<rev>...]
git bisect skip [<rev>...]
@@ -247,6 +247,10 @@ 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.
+If you give the `--no-replace` to "git bisect start", then the
+"bisect-replace-*" branches will not be used for the bisection you
+start.
+
Bisect run
~~~~~~~~~~
diff --git a/git-bisect.sh b/git-bisect.sh
index be37b64..5a65ab5 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -3,7 +3,7 @@
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>...]
+git bisect start [--no-replace] [<bad> [<good>...]] [--] [<pathspec>...]
reset bisect state and start bisection.
git bisect bad [<rev>]
mark <rev> a known-bad revision.
@@ -119,6 +119,10 @@ bisect_start() {
shift
break
;;
+ --no-replace)
+ shift
+ touch "$GIT_DIR/BISECT_NO_REPLACE"
+ ;;
*)
rev=$(git rev-parse -q --verify "$arg^{commit}") || {
test $has_double_dash -eq 1 &&
@@ -386,6 +390,16 @@ We continue anyway.
EOF
}
+replace_option() {
+ test -f "$GIT_DIR/BISECT_NO_REPLACE" ||
+ echo "--bisect-replace"
+}
+
+no_replace_option() {
+ test ! -f "$GIT_DIR/BISECT_NO_REPLACE" ||
+ echo "--no-bisect-replace"
+}
+
#
# "check_merge_bases" checks that merge bases are not "bad".
#
@@ -401,7 +415,7 @@ check_merge_bases() {
_bad="$1"
_good="$2"
_skip="$3"
- for _mb in $(git merge-base --all --bisect-replace $_bad $_good)
+ for _mb in $(git merge-base --all $(replace_option) $_bad $_good)
do
if is_among "$_mb" "$_good"; then
continue
@@ -436,7 +450,7 @@ check_good_are_ancestors_of_bad() {
# Bisecting with no good rev is ok
test -z "$_good" && return
- _side=$(git rev-list --bisect-replace $_good ^$_bad)
+ _side=$(git rev-list $(replace_option) $_good ^$_bad)
if test -n "$_side"; then
# Return if a checkout was done
check_merge_bases "$_bad" "$_good" "$_skip" || return
@@ -465,9 +479,8 @@ bisect_next() {
test "$?" -eq "1" && return
# Get bisection information
- BISECT_OPT=''
- test -n "$skip" && BISECT_OPT='--bisect-all'
- eval="git rev-list --bisect-vars $BISECT_OPT $good $bad --" &&
+ BISECT_OPTS="$(no_replace_option) --bisect-vars ${skip:+--bisect-all}"
+ eval="git rev-list $BISECT_OPTS $good $bad --" &&
eval="$eval $(cat "$GIT_DIR/BISECT_NAMES")" &&
eval=$(filter_skipped "$eval" "$skip") &&
eval "$eval" || exit
@@ -534,6 +547,7 @@ bisect_clean_state() {
do
git update-ref -d $ref $hash || exit
done
+ rm -f "$GIT_DIR/BISECT_NO_REPLACE" &&
rm -f "$GIT_DIR/BISECT_EXPECTED_REV" &&
rm -f "$GIT_DIR/BISECT_ANCESTORS_OK" &&
rm -f "$GIT_DIR/BISECT_LOG" &&
diff --git a/t/t6035-bisect-replace.sh b/t/t6035-bisect-replace.sh
index f22a2e5..b9cc739 100755
--- a/t/t6035-bisect-replace.sh
+++ b/t/t6035-bisect-replace.sh
@@ -164,6 +164,16 @@ test_expect_success '"git rev-list --no-bisect-replace" works' '
grep $HASH4 rev_list.txt
'
+test_expect_success 'git bisect works with --no-replace' '
+ git bisect start --no-replace $HASH5 $HASH1 &&
+ test "$(git rev-parse --verify HEAD)" = "$HASH3" &&
+ git bisect good &&
+ test "$(git rev-parse --verify HEAD)" = "$HASH4" &&
+ git bisect bad > my_bisect_log.txt &&
+ grep "$HASH4 is first bad commit" my_bisect_log.txt &&
+ git bisect reset
+'
+
#
#
test_done
--
1.6.0.3.614.g0f3b9
^ permalink raw reply related
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Miles Bader @ 2008-11-11 5:49 UTC (permalink / raw)
To: Avery Pennarun
Cc: Jeff King, Junio C Hamano, Björn Steinbrink,
Johannes Schindelin, David Symonds, git, Stephan Beyer
In-Reply-To: <32541b130811102004n54a47331v48ba8d299039897f@mail.gmail.com>
"Avery Pennarun" <apenwarr@gmail.com> writes:
> Speaking just for myself, I would find this all a lot less confusing
> if "staged" were a refspec of some sort, not an option at all.
>
> git diff HEAD..STAGED
> git diff STAGED..WORKTREE
> git grep pattern STAGED HEAD sillybranch WORKTREE ^ignorebranch --
> path/to/files
Another thing that seems strange to me is that the operation of diffing
HEAD..STAGED is so verbose -- currently it's "git diff --cached", with
no short option.
Surely this is very common operation... I rather often want to see
details of what's staged for commit...
-Miles
--
If you can't beat them, arrange to have them beaten. [George Carlin]
^ permalink raw reply
* Re: [PATCH] Tell users that git protocol is not for pushing
From: Alex Riesen @ 2008-11-11 7:24 UTC (permalink / raw)
To: Nathan W. Panike; +Cc: git
In-Reply-To: <1226379976-5959-1-git-send-email-nathan.panike@gmail.com>
Nathan W. Panike, Tue, Nov 11, 2008 06:06:16 +0100:
> When one attempts to push to a git-protocol repository, one gets the
> line:
>
> fatal: The remote end hung up unexpectedly
>
> This seems a bit obscure to me. It is better to inform the user that git://
> does not allow pushing.
But it does. See git daemon --help, look for receive-pack.
^ permalink raw reply
* Re: JGIT: discuss: diff/patch implementation
From: Rogan Dawes @ 2008-11-11 7:27 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Git Mailing List, Shawn O. Pearce, Robin Rosenberg
In-Reply-To: <200811101522.13558.fg@one2team.net>
Francis Galiegue wrote:
> Hello,
>
> A very nice git feature, without even going as far as merges, is the cherry
> pick feature.
>
> For this to be doable from within the Eclipse Git plugin, a diff/patch
> implementation needs to be found, in a license compatible with the current
> JGit license (3-clause BSD, as far as I can tell). Or a new implementation
> can be rewritten from scratch, of course.
Shouldn't Eclipse already *have* a diff/patch implementation, for its
other "team work" plugins?
Rogan
^ permalink raw reply
* Re: git commit -v does not removes the patch
From: Santi Béjar @ 2008-11-11 7:56 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20081111000706.GA26223@coredump.intra.peff.net>
On Tue, Nov 11, 2008 at 1:07 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Nov 10, 2008 at 03:27:18PM -0800, Junio C Hamano wrote:
>
>> > It is exactly as you described. I'll try in other systems.
>>
>> Guess in the dark... by any chance are you enabling color unconditionally?
>
> I thought I covered that case explicitly...
>
> ...yes, I can't reproduce with color set to "always". And indeed,
> looking at the diff for 4f672ad shows that we always turn off color for
> the message that goes to the editor (since we can't trust our isatty
> setting _anyway_, since we're not going to the tty).
>
> So that's not it.
Almost! I have diff.mnemonicprefix=true, if I unset it everything works.
Santi
^ permalink raw reply
* Re: Install issues
From: H.Merijn Brand @ 2008-11-11 7:59 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20081110175123.GV24201@genesis.frugalware.org>
On Mon, 10 Nov 2008 18:51:23 +0100, Miklos Vajna
<vmiklos@frugalware.org> wrote:
> On Mon, Nov 10, 2008 at 05:31:01PM +0100, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote:
> > --- Makefile.org 2008-11-10 17:29:53.000000000 +0100
> > +++ Makefile 2008-11-10 17:29:39.000000000 +0100
> > @@ -1329,6 +1329,10 @@ check-sha1:: test-sha1$X
> > ./test-sha1.sh
> >
> > check: common-cmds.h
> > + @`sparse </dev/null 2>/dev/null` || (\
> > + echo "The 'sparse' command is not available, so I cannot make the 'check' target" ;\
> > + echo "Did you mean 'make test' instead?" ;\
> > + exit 1 )
> > for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
>
> Please read Documentation/SubmittingPatches, your patch lacks a signoff
> and a commit message.
You're not making things easier for people that do not use git from a
git repo, something that happens quite a lot when you build from a
released tarball.
git-1.6.0.4 $ git format-patch -M
fatal: Not a git repository
Exit 128
I don't like this at all. How much more work is it for you to add the
subject and sign-off yourself, instead of requiring that from people
that like to help?
In the perl development, the only thing we *require* is a diff that
either uses unified (preferred) or context diff.
I did follow the ideal patch flow so far:
--8<---
An ideal patch flow
Here is an ideal patch flow for this project the current maintainer
suggests to the contributors:
(0) You come up with an itch. You code it up.
(1) Send it to the list and cc people who may need to know about
the change.
-->8---
Code speaks louder than words, so I proposed a patch.
This might be my last patch. git is not just another project I want to
loose so much time in.
--8<---
Author: H.Merijn Brand <h.m.brand@xs4all.nl>
Date: Mon, 10 Nov 2008 17:31:01 +0100
Make check needs sparse. If sparse is not available, it might as
well be a user error who really wanted make test.
Signed-off-by: H.Merijn Brand <h.m.brand@xs4all.nl>
---
diff --git a/Makefile.org b/Makefile
index becd008..718ddf2 100644
--- a/Makefile
+++ b/Makefile
@@ -1329,6 +1329,10 @@ check-sha1:: test-sha1$X
./test-sha1.sh
check: common-cmds.h
+ @`sparse </dev/null 2>/dev/null` || (\
+ echo "The 'sparse' command is not available, so I cannot make the 'check' target" ;\
+ echo "Did you mean 'make test' instead?" ;\
+ exit 1 )
for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
remove-dashes:
-->8---
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply related
* Re: [PATCH] git push: Interpret $GIT_DIR/branches in a Cogito compatible way
From: Martin Koegler @ 2008-11-11 8:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqqv410q.fsf@gitster.siamese.dyndns.org>
On Mon, Nov 10, 2008 at 03:25:09PM -0800, Junio C Hamano wrote:
> Martin Koegler <mkoegler@auto.tuwien.ac.at> writes:
> > Current git versions ignore everything after # (called <head> in the
> > following) when pushing. Older versions (before cf818348f1ab57),
> > interpret #<head> as part of the URL, which make git bail out.
> >
> > Ignoring the <head> part for push (fetch respects them) is unlogical.
> > As branches origin from Cogito, it is the best to correct this by
> > using the behaviour of cg-push:
> >
> > push HEAD to remote refs/heads/<head>
> >
> > Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
>
> This message was addressed to me, but is it meant for inclusion?
>
> I do not recall seeing an agreement on what the desired behaviour should
> be from (ex-)Cogito users, if this change of behaviour hurts real world
> usage of existing git users, andr if so how we ease this change in to the
> release.
Nobody else seemd to be interessted in this topic, so its difficult to
start a discussion.
I would suggest to queue it in pu for some time and wait for other
feedback.
> While I'd personally agree matching with whatever cg-push used to do might
> make the most sense in the end, I am not sure changing of behaviour
> abruptly like this is a good idea.
I'm open for any suggestion, how to make this change smoothly. I
think, that doing such a behaviour change should be OK for 1.6.1 or
1.6.2:
Until v1.5.4 (9 month ago), git-push with # was totally broken. Daniel
Barkalow fixed the fetch case in v1.5.4. As a side effect, git-push no
longer fails, but ignores everything after #. So in my option, the
current behaviour was created by chance.
> I am also not so sure url#branch is illogical; I'd suggest dropping that
> line from the commit log message in any case.
OK, I'll drop it in the next version.
> > +git push uses:
> >
> > ------------
> > - refs/heads/<head>:<repository>
> > + HEAD:refs/heads/<head>
> > ------------
>
> Why isn't this "refs/heads/<head>:refs/heads/<head>", by the way?
1) It's Cogito behaviour (cg-push(2)):
| It will push your commits on the current branch (or as specified
| by the -r option) to the remote repository, provided that your
| commits follow the last commit in the remote repository.
2) In my options, it's more flexible
If you want to push to <head>, you must create a local branch called
<head>. If you want to fetch from the remote too, you must choose a
name != <head> for the branches file, as you normaly don't want to
fetch into a local branch. Pushing to <head> in multiple remote
repositories is also more difficult, if they are used for diffent
things, as they are based on one local branch.
=> It's a way to seperate the remote head names from the local ones.
mfg Martin Kögler
^ permalink raw reply
* Re: [PATCH] git push: Interpret $GIT_DIR/branches in a Cogito compatible way
From: Mike Ralphson @ 2008-11-11 8:45 UTC (permalink / raw)
To: Martin Koegler; +Cc: Junio C Hamano, git
In-Reply-To: <1226353631-3716-1-git-send-email-mkoegler@auto.tuwien.ac.at>
2008/11/10 Martin Koegler <mkoegler@auto.tuwien.ac.at>:
> +Depending on the operation, git will use one of the following
> +refsprecs, if you don't provide one on the command line.
s/refsprecs,/refspecs/
^ permalink raw reply
* Re: Install issues
From: Andreas Ericsson @ 2008-11-11 9:17 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Miklos Vajna, git
In-Reply-To: <20081111085923.00213a89@pc09.procura.nl>
H.Merijn Brand wrote:
> On Mon, 10 Nov 2008 18:51:23 +0100, Miklos Vajna
> <vmiklos@frugalware.org> wrote:
>
>> On Mon, Nov 10, 2008 at 05:31:01PM +0100, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote:
>>> --- Makefile.org 2008-11-10 17:29:53.000000000 +0100
>>> +++ Makefile 2008-11-10 17:29:39.000000000 +0100
>>> @@ -1329,6 +1329,10 @@ check-sha1:: test-sha1$X
>>> ./test-sha1.sh
>>>
>>> check: common-cmds.h
>>> + @`sparse </dev/null 2>/dev/null` || (\
>>> + echo "The 'sparse' command is not available, so I cannot make the 'check' target" ;\
>>> + echo "Did you mean 'make test' instead?" ;\
>>> + exit 1 )
>>> for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
>> Please read Documentation/SubmittingPatches, your patch lacks a signoff
>> and a commit message.
>
> You're not making things easier for people that do not use git from a
> git repo, something that happens quite a lot when you build from a
> released tarball.
>
I think it's assumed that most git developers will clone the git repo so
they can send their patches against the very latest code. Usually, that's
part of "how to submit patches" of all projects.
> git-1.6.0.4 $ git format-patch -M
> fatal: Not a git repository
> Exit 128
>
> I don't like this at all. How much more work is it for you to add the
> subject and sign-off yourself, instead of requiring that from people
> that like to help?
>
"Ask not what a bunch of oss devs can do for you, but what you can do
for them. Especially if you want your changes accepted".
The harsh reality is that this is your itch. Noone else cares very
much either way, so if you want your change included, you'll have to
do it the way the project maintainer wants it.
> In the perl development, the only thing we *require* is a diff that
> either uses unified (preferred) or context diff.
>
Nothing's required here, but since nobody else seems to have problems
with the check/test stuff here, noone else will fix it up for you.
Besides that, I'm sure you require a teensy bit more than that. If I
send you a 14k line patch without a reasoning behind it, you won't
just go ahead and apply it, will you? If I send an algorithm for a new
hash that might actually be proprietary code from an anonymous email
address, wouldn't you want some sort of verification that I'm actually
allowed to send that algorithm to you?
In git, those two steps are formalized into "Sign your patches!" and
"Write a proper commit message!". Since they *are* formalized, we
provide handy tools for doing just that. It's up to you if you want to
use them. Dictating the patch submission (or rather, acceptancy policy)
is not. Patches submitted incorrectly will have one of the following
things happen to them:
1. The patch is forgotten entirely, since nobody cares about it enough
to make it a "proper" patch (by git standards).
2. The patch author resubmits it in the proper format.
3. Someone else resubmits it in the proper format.
4. Junio accepts it anyway.
4 is the least likely to happen, and will pretty much only occur if
someone finds some really horrible bug that absolutely and obviously
has to go in the git code. Even in those cases, 3 usually happens
before Junio wakes up.
3 is not very likely to happen unless the feature you're suggesting
is of interest to a lot of people.
Ofcourse, *after* the patch has been submitted in the proper format,
it can still get rejected. Submitting it properly is only the first
step towards getting any kind of review on it (basically).
> I did follow the ideal patch flow so far:
> --8<---
> An ideal patch flow
>
> Here is an ideal patch flow for this project the current maintainer
> suggests to the contributors:
>
> (0) You come up with an itch. You code it up.
>
> (1) Send it to the list and cc people who may need to know about
> the change.
> -->8---
>
> Code speaks louder than words, so I proposed a patch.
> This might be my last patch. git is not just another project I want to
> loose so much time in.
>
That would be sad. We're a tad short on perl folks, although I guess
that's not much of an issue since we're rewriting most of it in C
anyways.
If you should decide to relent though, I seriously suggest using the
tools git provides for sending patches. If you do, you'll be able to
able to send (properly formatted) patches very easily indeed.
Rant aside, thanks for the re-send. I'm sure Junio can sed s/Author/From/
on the mail and have git accept it properly in case he accepts it.
Otherwise, I'll resubmit it, faking you as the author.
> --8<---
> Author: H.Merijn Brand <h.m.brand@xs4all.nl>
> Date: Mon, 10 Nov 2008 17:31:01 +0100
>
> Make check needs sparse. If sparse is not available, it might as
> well be a user error who really wanted make test.
>
> Signed-off-by: H.Merijn Brand <h.m.brand@xs4all.nl>
> ---
>
> diff --git a/Makefile.org b/Makefile
> index becd008..718ddf2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1329,6 +1329,10 @@ check-sha1:: test-sha1$X
> ./test-sha1.sh
>
> check: common-cmds.h
> + @`sparse </dev/null 2>/dev/null` || (\
> + echo "The 'sparse' command is not available, so I cannot make the 'check' target" ;\
> + echo "Did you mean 'make test' instead?" ;\
> + exit 1 )
> for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
>
> remove-dashes:
> -->8---
>
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 2/2] Document "git log --simplify-by-decoration"
From: Nanako Shiraishi @ 2008-11-11 9:47 UTC (permalink / raw)
To: Santi Béjar; +Cc: git, Junio C Hamano
Quoting "Santi Béjar" <santi@agolina.net>:
>> +The '\--simplify-by-decoration' option can be used to treat commits that
>> +are not referenced by tags as TREESAME, and treat commits that are tagged
>> +as !TREESAME (even when they have exactly the same tree as their parents).
>> +This can be used when you are only interested in the big picture of the
>> +topology of the history.
>> +
>> +
>
> I prefer the other way around, first what it does, and then how it
> does it (but it is a general comment about the help in "History
> Simplification", at least when viewing the help for "git log").
Thank you for your comments.
In the earlier part of the description, TREESAME (or !TREESAME) is explained as a prerequisite concept for understanding how the history simplification works. I think my description first talks about what it does using the concept that was already explained (in other words, "which commits are marked as TREESAME"), and then talks about what the consequence of what it does is (in other words, "only shows the big picture").
I can swap them around. Let's see if you like this better:
The '\--simplify-by-decoration' option allows you to view only the
big picture of the topology of the history, by omitting commits
that are not referenced by tags. Commits are marked as !TREESAME
(in other words, kept after history simplification rules described
above) if (1) they are referenced by tags, or (2) they change the
contents of the paths given on the command line. All other
commits are marked as TREESAME (subject to be simplified away).
> And you should rewrite the line 416:
>
> Finally, there is a fourth simplification mode available
>
> as it is no longer "Finally".
Yes, I thought about it, but describing the new option at the end does not change the fact that the fourth simplification mode is the final one.
The new option is not about a "simplification mode". Given a set of commits marked as TREESAME and !TREESAME, simplification modes decide how the history is simplified. The new option does not add any new mode. Instead, it affects which commits are marked as TREESAME/!TREESAME.
For this reason, I also thought about moving the description of the new option before the existing text begins to talk about the simplification modes, but decided against it. This new option is rarely useful for everyday life (useful only once in a release cycle, maybe) and I do not think it deserves to be in the early part of the section. The readers are first taught how the basic concept TREESAME works in the usual case, and after learning that concept, they are shown how that concept is used in the history simplification mechanism. It will only complicate and confuse the readers if we talk about this new option that changes the way TREESAME mark is given to commits before showing how the simplification modes work for basic cases.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: JGIT: discuss: diff/patch implementation
From: Raimund Bauer @ 2008-11-11 10:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: Francis Galiegue, Git Mailing List, Shawn O. Pearce,
Robin Rosenberg
In-Reply-To: <7v63mv5mro.fsf@gitster.siamese.dyndns.org>
On Mon, 2008-11-10 at 12:50 -0800, Junio C Hamano wrote:
> Francis Galiegue <fg@one2team.net> writes:
>
> > A very nice git feature, without even going as far as merges, is the cherry
> > pick feature.
>
> I thought cherry-picking needs to be done in terms of 3-way merge, not
> diff piped to patch, for correctness's sake.
What about http://sourceforge.net/projects/jlibdiff ?
Maybe a bit old, but claims to have diff3 and is under LGPL.
best regards,
Ray
^ permalink raw reply
* Re: git commit -v does not removes the patch
From: Jeff King @ 2008-11-11 10:29 UTC (permalink / raw)
To: Santi Béjar; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <adf1fd3d0811102356u6e671dcfj6491f81cf462ec2e@mail.gmail.com>
On Tue, Nov 11, 2008 at 08:56:34AM +0100, Santi Béjar wrote:
> Almost! I have diff.mnemonicprefix=true, if I unset it everything works.
Ah, indeed. The obvious fix is just loosening our match a little bit:
diff --git a/builtin-commit.c b/builtin-commit.c
index 93ca496..a721990 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -1015,7 +1015,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
}
/* Truncate the message just before the diff, if any. */
- p = strstr(sb.buf, "\ndiff --git a/");
+ p = strstr(sb.buf, "\ndiff --git ");
if (p != NULL)
strbuf_setlen(&sb, p - sb.buf + 1);
But I have to wonder if there is some more robust solution. It seems
like this can have false positives if you include diff output in your
commit message, and a potential false negative if you delete the newline
(e.g., delete everything up to "diff --git", making it the first line).
But I guess we haven't seen a lot of complaints, so maybe those
conditions aren't worth worrying about.
-Peff
^ permalink raw reply related
* importing mercurial patch
From: Ondrej Certik @ 2008-11-11 10:58 UTC (permalink / raw)
To: Git Mailing List
Hi,
I'd like git to be able to import mercurial-exported patches. This
short Python program does it:
-------------------------------------
#! /usr/bin/python
import os
import sys
import re
import tempfile
def run(cmd):
print cmd
os.system(cmd)
patch = sys.argv[1]
p = open(patch).read()
author = re.search("# User (.+)", p).groups()[0]
p = p.split("\n")
while not p[0].startswith("# Parent"):
del p[0]
i = 1
while not p[i].startswith("diff -r "):
i += 1
commit_message = "\n".join(p[1:i])
_, filename = tempfile.mkstemp()
f = open(filename, "w")
f.write(commit_message)
f.close()
run("git apply %s" % patch)
run("git ci -a --author='%s' -F %s" % (author, filename) )
---------------------
How should this be implemented in git? Should I try to extend
"git-am.sh" to handle it?
For better imagination, this is how the patch looks like:
http://paste.debian.net/21210/
Thanks for any feedback,
Ondrej
^ permalink raw reply
* Re: importing mercurial patch
From: Ondrej Certik @ 2008-11-11 10:59 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <85b5c3130811110258h53d389co97a3c33e10667ae8@mail.gmail.com>
On Tue, Nov 11, 2008 at 11:58 AM, Ondrej Certik <ondrej@certik.cz> wrote:
> Hi,
>
> I'd like git to be able to import mercurial-exported patches. This
> short Python program does it:
>
>
> -------------------------------------
> #! /usr/bin/python
>
> import os
> import sys
> import re
> import tempfile
>
> def run(cmd):
> print cmd
> os.system(cmd)
>
> patch = sys.argv[1]
> p = open(patch).read()
> author = re.search("# User (.+)", p).groups()[0]
> p = p.split("\n")
> while not p[0].startswith("# Parent"):
> del p[0]
> i = 1
> while not p[i].startswith("diff -r "):
> i += 1
> commit_message = "\n".join(p[1:i])
> _, filename = tempfile.mkstemp()
> f = open(filename, "w")
> f.write(commit_message)
> f.close()
>
> run("git apply %s" % patch)
> run("git ci -a --author='%s' -F %s" % (author, filename) )
> ---------------------
>
>
> How should this be implemented in git? Should I try to extend
> "git-am.sh" to handle it?
Just to make it clear --- I will of course use sh or C with git, I
only used Python above because that's the language I know the best.
Ondrej
^ 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