* 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: 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: 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: 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: [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: [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
* [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
* [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 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 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 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 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 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 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 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] 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
* 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
* 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: why not TortoiseGit
From: Li Frank @ 2008-11-11 1:51 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Scott Chacon, Andreas Ericsson, Ian Hilt, git
In-Reply-To: <320075ff0811030200q606b76a8i16496cf7b8b1b7d2@mail.gmail.com>
Nigel Magnay:
I create a tortoisegit project at repo.or.cz.
http://repo.or.cz/w/TortoiseGit.git
It is coming from TortoiseSVN. It is very early stage. The context menu
have worked. TortoiseGitProc.exe help command have been worked.
Welcome contribute.
Best regards
Frank Li
-----Original Message-----
From: Nigel Magnay [mailto:nigel.magnay@gmail.com]
Sent: Monday, November 03, 2008 6:00 PM
To: Li Frank-B20596
Cc: Scott Chacon; Andreas Ericsson; Ian Hilt; git@vger.kernel.org
Subject: Re: why not TortoiseGit
> I read some code of TortoiseSVN and TortoiseHg Code.
> At beginning, TortoiseGit can git command to get information like
Qgit.
> After linkable library ready, replace "git command".
>
> I think TortoiseGit can start base on below way.
>
> 1. Base on TortoiseHg, It is python Script. Replace below hg
> operator with Git.
> 2. Base on TortoiseSVN, It is developed with C++. Need VS2008.
> ToritoiseSVN provide some built in diff and merge tools.
> 3. Base on Qgit, which provide some basic UI, such comment dialogbox,
> history view and file annotate.
>
>
TortoiseSVN is a good place to start because it separates out the
windows icon decorators into a separate DLL (shared with TortoiseCVS).
This is significant, as these are a finite resource in the windows
shell, and so having a TortoiseSVN + TortoiseGIT on one machine and you
might run out, and I'd imagine lots of people wanting both.
On the minus side, building (Tortoise)SVN requires a lot of environment
setup just to get it to build - most of which can be immediately thrown
away as it's specific to SVN.
But it doesn't look like a hard project to me, just requires stripping
out a lot of junk and re-patching callouts to a git executable (which
could be the standard git tools) and a minimal git library that knows if
files are dirty.
^ permalink raw reply
* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Tait @ 2008-11-11 1:49 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811091344480.20499@sys-0.hiltweb.site>
> > > + if ($c_file =~ /^To:\s*+(.+)\s*\nCc:/ism) {
> >
> > Greedy operators are only supported with perl 5.10 or more... I think it's a
> > bad idea to use them...
>
> The problem here was that a space should follow the field, but it may
> not. The user may unwarily backup over it. "\s*" would match this
> case.
>
> But if there is a space, it is included in the "(.+)".
Not in any version of Perl to which I have access.
Why doesn't
/^To:\s*(.+)\s*\nCc:/ism
work?
^ permalink raw reply
* [ANNOUNCE] darcs-fast-export
From: Miklos Vajna @ 2008-11-11 1:53 UTC (permalink / raw)
To: git; +Cc: bazaar, mercurial, darcs-users
[-- Attachment #1.1: Type: text/plain, Size: 886 bytes --]
Hi,
I'm happy to announce a small project I recently stated to work on. It's
a darcs backend for fast importers.
This means that it allows you to export patches/commits from a darcs
repo and import to any version control system where a fast importer is
implemented.
Current features:
- According to its name, it tries to be really fast, even for large
repos.
- Independent. It has been tested with git fast-import, hg fastimport
and bzr fast-import. (Let me know if you know other fast-importers!)
- It supports both (darcs1 and darcs2) darcs repo formats.
- It supports incremental conversions.
More info on the homepage:
http://vmiklos.hu/project/darcs-fast-export/
Including a list of alternatives, where I try to compare them to
darcs-fast-export.
Any feedback or comment is appreciated.
I'm not on the bazaar and the mercurial list, so there please CC me.
Thanks.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #2: Type: text/plain, Size: 148 bytes --]
_______________________________________________
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Jeff King @ 2008-11-11 1:22 UTC (permalink / raw)
To: Junio C Hamano
Cc: David Symonds, Björn Steinbrink, Johannes Schindelin, git,
Stephan Beyer
In-Reply-To: <7vljvr2hjn.fsf@gitster.siamese.dyndns.org>
On Mon, Nov 10, 2008 at 05:11:08PM -0800, Junio C Hamano wrote:
> I doubt "Is there any further discussion on THIS ONE ALONE?" is a valid
> question to ask. What are the other command options we are introducing
> synonyms for? There is no need for two variants of staged for "diff" (you
> don't have --staged-too option but instead you give a committish argument,
> e.g. HEAD), so --staged-only can be abbreviated to --staged without
> risking any ambiguity. But at least a fully-spelled-out --staged-only
> should also be accepted, shouldn't it?
I'm not sure that "staged-only" really makes sense here. In modification
commands like "apply", it is about "do this one thing to the working
tree, to both the index and the working tree, or to just the index".
But here, you are selecting two points for comparison. So while it is
tempting to say "the default for diff just happens to work on the index
and the working tree, so we don't need --staged-too", I don't think that
is right. Doing "--staged-only" is _not_ about saying "do the thing we
would have done to the working tree and the index to just the index." It
is about "use HEAD as one of the points instead of the working tree
(and reverse the order of points :) )".
To me, what is really being asked with "git diff --staged" (or "git
diff --cached" for that matter), is "what is staged?" That is, diff is
not about an operation on a data location (like HEAD, index, or working
tree), but rather an operatoin on a data _relationship_. So you ask for
"what is not staged" (the relationship between index and working tree),
"what is staged" (the relationship between HEAD and index), "what is
different between the working tree and HEAD", or "what is different
between these two trees".
-Peff
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Junio C Hamano @ 2008-11-11 1:11 UTC (permalink / raw)
To: David Symonds
Cc: Jeff King, Junio C Hamano, Björn Steinbrink,
Johannes Schindelin, git, Stephan Beyer
In-Reply-To: <ee77f5c20811101537u6061e5b4w420e9692e0cefad3@mail.gmail.com>
"David Symonds" <dsymonds@gmail.com> writes:
> On Mon, Nov 3, 2008 at 6:14 PM, Jeff King <peff@peff.net> wrote:
>
>> 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.
>
> So apart from the wider discussion, I think this patch by itself is a
> nice step forward towards improving the UI of this part of git. Is
> there any further discussion on this one alone?
I do not think anybody is fundamentally opposed to introduce a consistent
set of new synonyms. I do not think anybody disagrees that the word
"stage" will be involved in that set, either.
I however have a suspicion that people would regret having applied this
"diff --staged" patch, after they realize that other commands need two
options "--staged-only" and "--staged-too", and would wish this patch were
to introduce a synonym "diff --staged-only", not "diff --staged", for
uniformity's sake.
I doubt "Is there any further discussion on THIS ONE ALONE?" is a valid
question to ask. What are the other command options we are introducing
synonyms for? There is no need for two variants of staged for "diff" (you
don't have --staged-too option but instead you give a committish argument,
e.g. HEAD), so --staged-only can be abbreviated to --staged without
risking any ambiguity. But at least a fully-spelled-out --staged-only
should also be accepted, shouldn't it?
^ permalink raw reply
* Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas
From: Jeff King @ 2008-11-11 0:31 UTC (permalink / raw)
To: Thomas Harning; +Cc: Johannes Schindelin, git
In-Reply-To: <74EBEC20-FC39-444E-8B96-31E5B36894B8@gmail.com>
On Mon, Nov 10, 2008 at 03:26:52PM -0500, Thomas Harning wrote:
> What I intended is that if notes are attached to 'A', A` (after a
> rebase) will have the exact same note.
I think that may have been brought up at the GitTogether. It would be
very easy, when rebasing A to A', to copy any notes for A to A'
(retroactively applying notes for A' to A (or vice versa) is much
harder, since we don't maintain any mapping between the two).
_But_ that is not necessarily a good idea in all cases, because your
notes may say certain things about A like "I tested this on system X".
But you _haven't_ tested A', and it might not pass your test. Leaving
aside editing the commits with "rebase -i", there might just be a bad
interaction with the commit you rebased onto.
So I think it would probably make sense to add a "--copy-notes" option
to rebase for those times when the user knows it makes sense, but doing
so by default is probably a mistake.
-Peff
^ permalink raw reply
* Re: [PATCH] 3-way merge with file move fails when diff.renames = copies
From: Junio C Hamano @ 2008-11-11 0:15 UTC (permalink / raw)
To: David D. Kilzer; +Cc: git, Johannes Schindelin
In-Reply-To: <7v63mv3zww.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "David D. Kilzer" <ddkilzer@kilzer.net> writes:
>
>> With diff.renames = copies, a 3-way merge (e.g. "git rebase") would
>> fail with the following error:
By the way, I think the real issue with this one is that we currently do
not disable diff.renames configuration while rebase internally runs
"format-patch" to feed "am -3".
The end user configuration for "diff" should not affect the result
produced by the higher level command that is related to "diff" only
because internally it is implemented in terms of it.
For that matter, I have a feeling that format-patch should not even look
at diff.renames, but we seem to have been doing this for a long time so
there is no easy way to fix this thinko.
In any case, here is a much straightforward fix for "rebase".
Running "am -3" on a copying patch would still need a patch to the
index-info codepath, and my earlier comment on it still stands, but it is
irrelevant/orthogonal to your particular test script.
git-rebase.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git c/git-rebase.sh w/git-rebase.sh
index 023a6dc..159ccb3 100755
--- c/git-rebase.sh
+++ w/git-rebase.sh
@@ -429,7 +429,7 @@ fi
if test -z "$do_merge"
then
git format-patch -k --stdout --full-index --ignore-if-in-upstream \
- "$upstream..$orig_head" |
+ --no-renames "$upstream..$orig_head" |
git am $git_am_opt --rebasing --resolvemsg="$RESOLVEMSG" &&
move_to_original_branch
ret=$?
^ permalink raw reply related
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