* Re: [PATCH 00/40] test whitespace - perform trivial whitespace clean ups of test scripts.
From: Jeff King @ 2011-08-06 9:20 UTC (permalink / raw)
To: Jon Seymour; +Cc: git
In-Reply-To: <1312620119-18369-1-git-send-email-jon.seymour@gmail.com>
On Sat, Aug 06, 2011 at 06:41:59PM +1000, Jon Seymour wrote:
> The series applies cleanly to both master and pu.
>
> The first patch contains a script, t/test-cleaner.sh, that can
> automate whitespace cleanup of tests.
Hmm. Can't we do something similar using git itself, and clean up all
sorts of whitespace errors?
I tried:
rm t/t1006-cat-file.sh
git diff -R | git apply --whitespace=fix
and ended up with the same blob as your script.
In theory you could do the whole tree:
git ls-files -z | xargs -0 rm
git diff -R --binary | git apply --whitespace=fix
though it reports 604 whitespace errors, but only 489 lines fixed. And
t1006 is not among the modified files. So I wonder if this is a bug in
git-apply, or am I missing something.
-Peff
^ permalink raw reply
* [PATCH replacement for 01/40] test-cleaner: automate whitespace cleaning of test scripts
From: Jon Seymour @ 2011-08-06 9:26 UTC (permalink / raw)
To: git; +Cc: Jon Seymour
In-Reply-To: <1312620119-18369-1-git-send-email-jon.seymour@gmail.com>
This script allows the automated cleaning of test scripts.
Any whitespace fixups of a test script that do not effect the
exit status or output of the test are assumed to be safe
and are automatically committed.
To check the tests for whitespace issues, change into git's
test directory and run:
test-cleaner.sh check-whitespace t*.sh
This will:
* write one line of the form:
AUTO<tab><filename>
for each file that can be fixed automatically.
* write one line of the form:
MANUAL<tab><filename>
for each file that will require manual intervention to fix.
To fix all the automatically correctable errors, run:
./test-cleaner.sh fix-whitespace-auto t[0-9]*.sh
To generate commits for all the errors that require manual correction, run:
./test-cleaner.sh fix-whitespace-manual t[0-9]*.sh
To clean a file without running tests or generating commits, run:
./test-cleaner.sh clean-whitespace foobar.sh
clean-whitespace can be used with files that are not tests.
If no arguments are supplied, file arguments are read from stdin.
The filter itself can be run with:
./test-cleaner.sh whitespace-filter < file > some-other-file
The resulting series of commits should rebased on both the git master
and pu branches. Commits that cause merge conflicts should be purged
from the series.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
t/test-cleaner.sh | 185 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 185 insertions(+), 0 deletions(-)
create mode 100755 t/test-cleaner.sh
diff --git a/t/test-cleaner.sh b/t/test-cleaner.sh
new file mode 100755
index 0000000..b6a1781
--- /dev/null
+++ b/t/test-cleaner.sh
@@ -0,0 +1,185 @@
+#!/bin/sh
+
+USAGE="test-cleaner.sh
+ check-whitespace [<test-file> ...] - report on test files that need cleaning
+ fix_whitespace [<test-file> ...] - generate commits for files that need white space cleaning
+ fix-whitespace-auto [<test-file> ...] - generate commits for files that can be automatically cleaned
+ fix-whitespace-manual [<test-file> ...] - generate commits for files that need manual cleaning
+ clean-whitespace [<file> ...] - applying the cleaner to the specified file without running tests or generating commits
+"
+SUBDIRECTORY_OK=t
+. "$(git --exec-path)/git-sh-setup"
+require_clean_work_tree
+
+cleaner()
+{
+ expand -i | unexpand --first-only | sed "s/ *\$//"
+}
+
+clean_whitespace()
+{
+ rc=0
+ list_files "$@" | while read file
+ do
+ cleaner <"$file" >$$.tmp &&
+ cat $$.tmp >"$file" || rc=1
+ rm -f $$.tmp
+ test $rc = 0
+ done || exit $?
+}
+
+list_files()
+{
+ if test $# -gt 0
+ then
+ for arg in "$@"; do
+ echo $arg
+ done
+ else
+ cat
+ fi
+}
+
+fix_whitespace_auto()
+{
+ check_whitespace "$@" 2>/dev/null | grep "^AUTO" | cut -f2 | fix_whitespace
+}
+
+fix_whitespace_manual()
+{
+ check_whitespace "$@" 2>/dev/null | grep "^MANUAL" | cut -f2 | fix_whitespace
+}
+
+fix_whitespace()
+{
+ rc=0
+ check_whitespace "$@" 2>/dev/null | while read status file
+ do
+ case "$status" in
+ AUTO)
+ if clean_whitespace "$file" &&
+ git diff --exit-code -w -- "$file" >/dev/null
+ git add "$file" &&
+ git diff --exit-code -w HEAD -- "$file" >/dev/null
+ then
+ git commit -F - 1>&2 <<EOF
+whitespace: remediate $file
+
+This file was edited by applying:
+
+ expand -i | unexpand --first-only | sed "s/ *\$//"
+
+to the file.
+
+No change to test outputs or status code was observed.
+
+Signed-off-by: $(git config user.name) <$(git config user.email)>
+EOF
+ echo "$status $file"
+ else
+ rc=1
+ fi
+ rm -f $$.tmp
+ ;;
+ MANUAL)
+ CLEANER_PREFIX=fixer.
+ check_whitespace "$file" >/dev/null 2>$$.err
+ if clean_whitespace "$file" &&
+ git diff --exit-code -w -- "$file" >/dev/null
+ git add "$file" &&
+ git diff --exit-code -w HEAD -- "$file" >/dev/null
+ then
+ git commit -F - 1>&2 <<EOF
+FAILED: whitespace: remediate $file
+
+This file was edited by applying:
+
+ expand -i | unexpand --first-only | sed "s/ *\$//"
+
+to the file.
+
+The following errors were observed:
+
+$(cat $$.err | sed "s/^/ /")
+
+These errors should be fixed before submitting this patch upstream.
+
+Signed-off-by: $(git config user.name) <$(git config user.email)>
+EOF
+ echo "$status $file"
+ else
+ rc=1
+ fi
+ rm -f $$.tmp $$.err
+ ;;
+ *)
+ die "fix-whitespace failed on $file with unexpected output"
+ ;;
+ esac
+ test "$rc" = 0
+ done || rc=$?
+ test "$rc" = 0
+}
+
+check_whitespace()
+{
+ list_files "$@" | while read file
+ do
+ cleaner <"$file" >$$.${CLEANER_PREFIX}edited &&
+ cmp "$file" $$.${CLEANER_PREFIX}edited 1>/dev/null
+ rc=$?
+ if test $rc != 0
+ then
+ sh $file >$$.${CLEANER_PREFIX}before.output 2>$$.${CLEANER_PREFIX}before.error </dev/null
+ echo $? > $$.${CLEANER_PREFIX}before.exit
+ sh ./$$.${CLEANER_PREFIX}edited >$$.${CLEANER_PREFIX}after.output 2>$$.${CLEANER_PREFIX}after.error </dev/null
+ echo $? > $$.${CLEANER_PREFIX}after.exit
+
+ if cmp $$.${CLEANER_PREFIX}before.output $$.${CLEANER_PREFIX}after.output 1>/dev/null &&
+ cmp $$.${CLEANER_PREFIX}before.error $$.${CLEANER_PREFIX}after.error 1>/dev/null &&
+ cmp $$.${CLEANER_PREFIX}before.exit $$.${CLEANER_PREFIX}after.exit 1>/dev/null
+ then
+ echo "AUTO $file"
+ else
+ echo "MANUAL $file"
+ diff -u $$.${CLEANER_PREFIX}before.output $$.${CLEANER_PREFIX}after.output 1>&2
+ diff -u $$.${CLEANER_PREFIX}before.error $$.${CLEANER_PREFIX}after.error 1>&2
+ diff -u $$.${CLEANER_PREFIX}before.exit $$.${CLEANER_PREFIX}after.exit 1>&2
+ fi
+ looprc=1
+ fi
+ rm -f $$.${CLEANER_PREFIX}edited $$.${CLEANER_PREFIX}after.* $$.${CLEANER_PREFIX}before.*
+ test "$looprc" = 0
+ done
+}
+
+case $# in
+0)
+ usage ;;
+*)
+ cmd=$1
+ shift
+ case "$cmd" in
+ check-whitespace)
+ check_whitespace "$@"
+ ;;
+ fix-whitespace)
+ fix_whitespace "$@"
+ ;;
+ fix-whitespace-auto)
+ fix_whitespace_auto "$@"
+ ;;
+ fix-whitespace-manual)
+ fix_whitespace_manual "$@"
+ ;;
+ clean-whitespace)
+ clean_whitespace "$@"
+ ;;
+ whitespace-filter)
+ cleaner
+ ;;
+ *)
+ usage
+ ;;
+ esac
+esac
--
1.7.6.362.gf0e6
^ permalink raw reply related
* Re: [PATCH 03/40] whitespace: remediate t1006-cat-file.sh
From: Jeff King @ 2011-08-06 9:28 UTC (permalink / raw)
To: Jon Seymour; +Cc: git
In-Reply-To: <1312620294-18616-3-git-send-email-jon.seymour@gmail.com>
On Sat, Aug 06, 2011 at 06:44:17PM +1000, Jon Seymour wrote:
> diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh
> index d8b7f2f..c78bf87 100755
> --- a/t/t1006-cat-file.sh
> +++ b/t/t1006-cat-file.sh
> @@ -14,7 +14,7 @@ strlen () {
>
> maybe_remove_timestamp () {
> if test -z "$2"; then
> - echo_without_newline "$1"
> + echo_without_newline "$1"
Yes, this indent with spaces violates our coding style policy. However,
the 4-space indentation does, too (and the space between function name
and parentheses). The "right" way is according to our policy is:
maybe_remove_timestamp() {
if test -z "$2"; then
echo_without_newline "$1"
So I have to wonder if this automated indentation is really worthwhile.
The result still doesn't meet our whitespace criteria (and I am slightly
dubious that it is possible to write an accurate general-purpose
indenter for shell code).
I suppose you could argue that even taking it partway towards right is
better than nothing. But I get the feeling that nobody is really looking
at this code; if they were, they would fix the style while they were
there. And if not, then who cares if it's 10% right or 30% right?
I dunno. I'm not against a one-time cleanup, but I think making the
cleanup script a part of the repo is kind of silly. Between git's
whitespace warnings (which I suspect post-date most of these changes)
and code review (which we need to catch non-automated style violations,
in addition to regular bugs, of course), it seems like we already have
a better solution in place. It's just that nobody has bothered to clean
up the old code.
-Peff
^ permalink raw reply
* Re: [PATCH 00/40] test whitespace - perform trivial whitespace clean ups of test scripts.
From: Jon Seymour @ 2011-08-06 9:36 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20110806092029.GA7645@sigill.intra.peff.net>
On Sat, Aug 6, 2011 at 7:20 PM, Jeff King <peff@peff.net> wrote:
> On Sat, Aug 06, 2011 at 06:41:59PM +1000, Jon Seymour wrote:
>
>> The series applies cleanly to both master and pu.
>>
>> The first patch contains a script, t/test-cleaner.sh, that can
>> automate whitespace cleanup of tests.
>
> Hmm. Can't we do something similar using git itself, and clean up all
> sorts of whitespace errors?
>
Right. That's probably a better way to implement the test and cleanup,
since it ensures the desired heuristic is used.
I will revise accordingly.
I guess the additional advantage of test-cleaner.sh is that it
automates the testing and creation of patches, at least for tests.
As mentioned in another note, it would probably be useful to
generalize this to files other than tests but one would have to use a
more complicated discovery procedure in that case (in order to make it
efficient - one doesn't want to have to run the full test suite to
test every single edit).
> I tried:
>
> rm t/t1006-cat-file.sh
> git diff -R | git apply --whitespace=fix
>
> and ended up with the same blob as your script.
>
> In theory you could do the whole tree:
>
> git ls-files -z | xargs -0 rm
> git diff -R --binary | git apply --whitespace=fix
>
> though it reports 604 whitespace errors, but only 489 lines fixed. And
> t1006 is not among the modified files. So I wonder if this is a bug in
> git-apply, or am I missing something.
>
Not sure - I'll dig into it.
jon.
^ permalink raw reply
* Re: [PATCH v2 4/4] upload-archive: use start_command instead of fork
From: René Scharfe @ 2011-08-06 9:40 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jeff King, Erik Faye-Lund, Junio C Hamano, git
In-Reply-To: <4E388A55.6080606@kdbg.org>
Am 03.08.2011 01:37, schrieb Johannes Sixt:
> Am 02.08.2011 20:13, schrieb Jeff King:
>> Hmm. So it's not _just_ the pipe vs file thing. What's different about
>> calling it from the shell, versus the way we call it from git-archive?
>
> When the parent process of an MSYS process is itself an MSYS process,
> such as bash, then the child does not do its own
> binary-mode-vs.-text-mode detection, but just uses whatever it is told
> by the parent. This is achieved by MSYS's fork emulation.
>
> But if the parent is a regular Windows program, such as git(-archive),
> then the autodection happens and file descriptors pointing to files are
> put into text mode.
So here's an ugly patch to implement an internal passthrough filter to
avoid newline conversions. It makes the tar filter command (gzip etc.)
write to a pipe instead of directly to a file.
The patch does this unconditionally, which is a waste on all unaffected
systems, of course. We could #ifdef it out, but is there perhaps a nice
way to integrate this functionality into run_command/finish_command?
René
---
archive-tar.c | 31 +++++++++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/archive-tar.c b/archive-tar.c
index 20af005..22d52c5 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -314,6 +314,25 @@ static int write_tar_archive(const struct archiver *ar,
return err;
}
+static int cat_fn(int in, int out, void *data)
+{
+ for (;;) {
+ char buf[16 * 1024];
+ ssize_t got = xread(in, buf, sizeof(buf));
+ if (got == 0)
+ break;
+ if (got < 0) {
+ if (errno == EPIPE)
+ break;
+ die_errno("read errror");
+ }
+ write_or_die(out, buf, got);
+ }
+ close(in);
+ close(out);
+ return 0;
+}
+
static int write_tar_filter_archive(const struct archiver *ar,
struct archiver_args *args)
{
@@ -321,6 +340,14 @@ static int write_tar_filter_archive(const struct archiver *ar,
struct child_process filter;
const char *argv[2];
int r;
+ struct async cat;
+
+ memset(&cat, 0, sizeof(cat));
+ cat.proc = cat_fn;
+ cat.in = -1;
+ cat.out = dup(1);
+ if (start_async(&cat))
+ die("unable to start passthrough filter");
if (!ar->data)
die("BUG: tar-filter archiver called with no filter defined");
@@ -335,6 +362,7 @@ static int write_tar_filter_archive(const struct archiver *ar,
filter.argv = argv;
filter.use_shell = 1;
filter.in = -1;
+ filter.out = cat.in;
if (start_command(&filter) < 0)
die_errno("unable to start '%s' filter", argv[0]);
@@ -349,6 +377,9 @@ static int write_tar_filter_archive(const struct archiver *ar,
if (finish_command(&filter) != 0)
die("'%s' filter reported error", argv[0]);
+ if (finish_async(&cat))
+ die("passthrough filter reported error");
+
strbuf_release(&cmd);
return r;
}
^ permalink raw reply related
* Re: [PATCH 03/40] whitespace: remediate t1006-cat-file.sh
From: Jon Seymour @ 2011-08-06 9:47 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20110806092856.GB7645@sigill.intra.peff.net>
On Sat, Aug 6, 2011 at 7:28 PM, Jeff King <peff@peff.net> wrote:
> On Sat, Aug 06, 2011 at 06:44:17PM +1000, Jon Seymour wrote:
>
>> diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh
>> index d8b7f2f..c78bf87 100755
>> --- a/t/t1006-cat-file.sh
>> +++ b/t/t1006-cat-file.sh
>> @@ -14,7 +14,7 @@ strlen () {
>>
>> maybe_remove_timestamp () {
>> if test -z "$2"; then
>> - echo_without_newline "$1"
>> + echo_without_newline "$1"
>
> Yes, this indent with spaces violates our coding style policy. However,
> the 4-space indentation does, too (and the space between function name
> and parentheses). The "right" way is according to our policy is:
>
Sure, but I not claiming the fix up is complete.
> maybe_remove_timestamp() {
> if test -z "$2"; then
> echo_without_newline "$1"
>
> So I have to wonder if this automated indentation is really worthwhile.
> The result still doesn't meet our whitespace criteria (and I am slightly
> dubious that it is possible to write an accurate general-purpose
> indenter for shell code).
Or that complete automation is possible...
>
> I suppose you could argue that even taking it partway towards right is
> better than nothing. But I get the feeling that nobody is really looking
> at this code; if they were, they would fix the style while they were
> there. And if not, then who cares if it's 10% right or 30% right?
>
> I dunno. I'm not against a one-time cleanup, but I think making the
> cleanup script a part of the repo is kind of silly. Between git's
> whitespace warnings (which I suspect post-date most of these changes)
> and code review (which we need to catch non-automated style violations,
> in addition to regular bugs, of course), it seems like we already have
> a better solution in place. It's just that nobody has bothered to clean
> up the old code.
Well, the battle against white space errors in an ongoing one. This is
just one more tool that might help.
As mentioned elsewhere, It would be more useful, I think to generalise
test-cleaner so that it could be used with files other than just tests
and, indeed, for edits other than just whitespace cleanup.
I think there is value is ensuring that the slavish application of an
automated cleanup doesn't introduce test breaks.
jon.
^ permalink raw reply
* Re: [RFC] gettext: add gettextln, eval_gettextln to encode common idiom
From: Ævar Arnfjörð Bjarmason @ 2011-08-06 11:53 UTC (permalink / raw)
To: Jon Seymour; +Cc: git
In-Reply-To: <1312604164-19980-1-git-send-email-jon.seymour@gmail.com>
On Sat, Aug 6, 2011 at 06:16, Jon Seymour <jon.seymour@gmail.com> wrote:
> This patch introduces two new helper functions, gettextln and eval_gettextln
> which append a trailing newline to the gettext output.
I like this, I would have done this myself but didn't have time.
Acked-by me
^ permalink raw reply
* I suggest that git commit support -A option, just like hg does.thanks.
From: jelly @ 2011-08-06 14:32 UTC (permalink / raw)
To: git
$ hg help commit
hg commit [OPTION]... [FILE]...
-A --addremove mark new/missing files as added/removed before committing
^ permalink raw reply
* Re: I suggest that git commit support -A option, just like hg does.thanks.
From: Magnus Bäck @ 2011-08-06 15:02 UTC (permalink / raw)
To: jelly; +Cc: git
In-Reply-To: <35a2b515.12f42.1319f82c79d.Coremail.sinojelly@163.com>
On Saturday, August 06, 2011 at 16:32 CEST,
jelly <sinojelly@163.com> wrote:
> $ hg help commit
> hg commit [OPTION]... [FILE]...
> -A --addremove mark new/missing files as added/removed before committing
It seems like you're looking for the -A option to "git add".
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
^ permalink raw reply
* [PATCH] whitespace: additional whitespace clean ups.
From: Jon Seymour @ 2011-08-06 15:48 UTC (permalink / raw)
To: git; +Cc: Jon Seymour
In-Reply-To: <1312620294-18616-1-git-send-email-jon.seymour@gmail.com>
After replacing the whitespace test with a test and fix based on
git apply's --whitespace=fix option, a few additional cleanups were
identified.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
t/t0100-previous.sh | 1 -
t/t1008-read-tree-overlay.sh | 1 -
t/t1009-read-tree-new-index.sh | 1 -
t/t1505-rev-parse-last.sh | 2 --
t/t2009-checkout-statinfo.sh | 1 -
t/t2203-add-intent.sh | 1 -
t/t6011-rev-list-with-bad-commit.sh | 1 -
t/t7700-repack.sh | 1 -
t/t9121-git-svn-fetch-renamed-dir.sh | 1 -
t/t9122-git-svn-author.sh | 2 +-
t/t9123-git-svn-rebuild-with-rewriteroot.sh | 1 -
11 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/t/t0100-previous.sh b/t/t0100-previous.sh
index 315b9b3..fbdc124 100755
--- a/t/t0100-previous.sh
+++ b/t/t0100-previous.sh
@@ -46,4 +46,3 @@ test_expect_success 'merge @{-1} when there is not enough switches yet' '
'
test_done
-
diff --git a/t/t1008-read-tree-overlay.sh b/t/t1008-read-tree-overlay.sh
index 4c50ed9..bce158b 100755
--- a/t/t1008-read-tree-overlay.sh
+++ b/t/t1008-read-tree-overlay.sh
@@ -29,4 +29,3 @@ test_expect_success 'multi-read' '
'
test_done
-
diff --git a/t/t1009-read-tree-new-index.sh b/t/t1009-read-tree-new-index.sh
index 59b3aa4..6fd4827 100755
--- a/t/t1009-read-tree-new-index.sh
+++ b/t/t1009-read-tree-new-index.sh
@@ -22,4 +22,3 @@ test_expect_success 'empty index file' '
'
test_done
-
diff --git a/t/t1505-rev-parse-last.sh b/t/t1505-rev-parse-last.sh
index d709ecf..caef359 100755
--- a/t/t1505-rev-parse-last.sh
+++ b/t/t1505-rev-parse-last.sh
@@ -65,5 +65,3 @@ test_expect_success '@{-3} fails' '
'
test_done
-
-
diff --git a/t/t2009-checkout-statinfo.sh b/t/t2009-checkout-statinfo.sh
index f3c2152..8688cf6 100755
--- a/t/t2009-checkout-statinfo.sh
+++ b/t/t2009-checkout-statinfo.sh
@@ -49,4 +49,3 @@ test_expect_success 'path checkout' '
'
test_done
-
diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
index 58a3299..2c849a9 100755
--- a/t/t2203-add-intent.sh
+++ b/t/t2203-add-intent.sh
@@ -61,4 +61,3 @@ test_expect_success 'can "commit -a" with an i-t-a entry' '
'
test_done
-
diff --git a/t/t6011-rev-list-with-bad-commit.sh b/t/t6011-rev-list-with-bad-commit.sh
index e51eb41..fdbfb9a 100755
--- a/t/t6011-rev-list-with-bad-commit.sh
+++ b/t/t6011-rev-list-with-bad-commit.sh
@@ -57,4 +57,3 @@ test_expect_success 'first commit is still available' \
'
test_done
-
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
index d954b84..0e3f8d5 100755
--- a/t/t7700-repack.sh
+++ b/t/t7700-repack.sh
@@ -165,4 +165,3 @@ test_expect_success 'objects made unreachable by grafts only are kept' '
'
test_done
-
diff --git a/t/t9121-git-svn-fetch-renamed-dir.sh b/t/t9121-git-svn-fetch-renamed-dir.sh
index 000cad3..ff3af03 100755
--- a/t/t9121-git-svn-fetch-renamed-dir.sh
+++ b/t/t9121-git-svn-fetch-renamed-dir.sh
@@ -17,4 +17,3 @@ test_expect_success 'init and fetch repository' '
'
test_done
-
diff --git a/t/t9122-git-svn-author.sh b/t/t9122-git-svn-author.sh
index 30013b7..002c62f 100755
--- a/t/t9122-git-svn-author.sh
+++ b/t/t9122-git-svn-author.sh
@@ -75,7 +75,7 @@ test_expect_success 'interact with it via git svn' '
(
cd work.svn &&
svn_cmd up &&
-
+
test $(svn_cmd log -r2:2 | wc -l) = 5 &&
test $(svn_cmd log -r4:4 | wc -l) = 7
)
diff --git a/t/t9123-git-svn-rebuild-with-rewriteroot.sh b/t/t9123-git-svn-rebuild-with-rewriteroot.sh
index fd81847..b535ca1 100755
--- a/t/t9123-git-svn-rebuild-with-rewriteroot.sh
+++ b/t/t9123-git-svn-rebuild-with-rewriteroot.sh
@@ -29,4 +29,3 @@ test_expect_success 'rebuild rev_map' '
'
test_done
-
--
1.7.6.411.gf4ef
^ permalink raw reply related
* Re:Re: I suggest that git commit support -A option, just like hg does.thanks.
From: jelly @ 2011-08-06 16:17 UTC (permalink / raw)
To: Magnus Bäck; +Cc: git
In-Reply-To: <20110806150246.GA20650@jpl.local>
>It seems like you're looking for the -A option to "git add".
I don't want to run "git add -A" before commit,
I want to use "git commit -A -m 'msg' " instead.
^ permalink raw reply
* Re: Why do some commits not appear in "git log"?
From: Dov Grobgeld @ 2011-08-06 17:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Witten, git
In-Reply-To: <CA++fsGG1xHm2ubXB-EL56L6xSau9AQX=o8fvmZb_7zNFkqdW2w@mail.gmail.com>
Ok, now I grok it. Indeed these "substantial changes" by mistake
undid another large change. So the net result was zero, which git was
smart enough to figure out, and therefore these two changes +D and -D
cancelled one another and none of them were shown.
Thanks a lot!
Dov
On Wed, Aug 3, 2011 at 21:57, Junio C Hamano <gitster@pobox.com> wrote:
>
> Dov Grobgeld <dov.grobgeld@gmail.com> writes:
>
> > --full-history indeed made the missing commits show up! So why was the
> > commit pruned? It contains some substantial source changes...
>
> I suspect that these "substantial changes" did not make any contribution
> to the end result. Read
>
> http://thread.gmane.org/gmane.comp.version-control.git/89400/focus=90659
>
> These days, the --post-simplify option implemented in that discussion
> thread is called --simplify-merges or something, I think.
^ permalink raw reply
* Re: [PATCH 03/40] whitespace: remediate t1006-cat-file.sh
From: Junio C Hamano @ 2011-08-06 17:56 UTC (permalink / raw)
To: Jeff King; +Cc: Jon Seymour, git
In-Reply-To: <20110806092856.GB7645@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Yes, this indent with spaces violates our coding style policy. However,
> the 4-space indentation does, too (and the space between function name
> and parentheses). The "right" way is according to our policy is:
>
> maybe_remove_timestamp() {
> if test -z "$2"; then
> echo_without_newline "$1"
Hmm, I have always thought that our shell scripts preferred the above to
be spelled this way instead:
maybe_remove_timestamp () {
if test -z "$2"
then
echo_without_newline "$1"
> So I have to wonder if this automated indentation is really worthwhile.
That I agree with.
> I dunno. I'm not against a one-time cleanup,...
I actually am slightly against it. One-time whole-tree clean-up can never
happen without downside as _some_ parts of the tree always have patches to
conflict with it in flight. One-time decision to clearly spell out the
rules and cleaning the tree over time, fixing parts that are not actively
touched one at a time, is probably feasible, though.
^ permalink raw reply
* Re: git-archive's wrong documentation: really write pax rather than tar
From: René Scharfe @ 2011-08-06 18:57 UTC (permalink / raw)
To: htl10; +Cc: Jeff King, git
In-Reply-To: <1312482802.68635.YahooMailClassic@web29518.mail.ird.yahoo.com>
Am 04.08.2011 20:33, schrieb Hin-Tak Leung:
> --- On Thu, 4/8/11, René Scharfe <rene.scharfe@lsrfire.ath.cx>
> wrote:
>
>> From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
> <snipped>
>> Ah, here it is:
>>
>> https://svn.r-project.org/R/trunk/src/library/utils/R/tar.R
>>
>> It's the ctype handling in function untar2 that rejects unknown
>> entry types.
>>
>> For reference, the documentation of the pax format including a
>> suggestion to treat unknown types like regular files can be found
>> here (search for "typename"):
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html
>>
>>> I think I tried the tree example and the R code also
>> didn't like it
>>> much... may be I'll give it another try.
>>
>> Did you try adding a ":" to the tree argument, e.g. this:
>>
>> $ git archive HEAD:
>>
>> instead of this?
>>
>> $ git archive HEAD
>>
>> René
>
> That's better! With a HEAD: , that code does a lot of:
>
> Warning in untar2(tarfile, files, list, exdir) : checksum error for
> entry 'file...'
>
> for each file it tries to extract, but at least it is extracting the
> files.
That doesn't sound good. Looking at the R source, however, I can see
that they use a two different algorithms to compute the checksum than
the one specified by POSIX (even though I don't fully understand what it
actually is their doing, since I don't know R). So worry too much about
the warning; as long e.g. "tar tf <file>" doesn't complain your archive
should be intact.
> I wasn't entirely sure about the notation used in the man page
> - is "v1.4.0^{tree}" same as "v1.4.0:" ? "HEAD:" is clearer, as most
> people has a HEAD...
They're a bit different in principle, but point to the same target in
this particular case. "<ref>:<path>" gets you an object (blob or tree)
of a commit; with an empty <path> you get the root tree.
"<ref>^{<type>}" gives you the requested object of <type> (tag, commit
or tree) behind the <ref>; with "tree" you get the root tree of the commit.
René
^ permalink raw reply
* Re:Re: I suggest that git commit support -A option, just like hg does.thanks.
From: Marc Weber @ 2011-08-06 19:35 UTC (permalink / raw)
To: git
In-Reply-To: <4d88745.134ea.1319fe29f01.Coremail.sinojelly@163.com>
Excerpts from jelly's message of Sat Aug 06 18:17:34 +0200 2011:
> >It seems like you're looking for the -A option to "git add".
>
> I don't want to run "git add -A" before commit,Â
> I want to use "git commit -A -m 'msg' " instead.
if you need it that often add to your .bashrc:
gcA(){ git add -A && git commit -m "$@"; }
which is even faster.
Marc Weber
^ permalink raw reply
* Re: [PATCH 00/48] Handling more corner cases in merge-recursive.c
From: Elijah Newren @ 2011-08-06 20:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, jgfouca
In-Reply-To: <7vr54z15dn.fsf@alter.siamese.dyndns.org>
On Fri, Aug 5, 2011 at 11:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
> But why do you care about the original index (i.e. the starting state of
> our side) in the first place? If your algorithm depends on the original
> index, wouldn't that mean you would screw up the same merge if the user
> merged branches in the opposite direction?
No, it does not mess up the same merge in the opposite direction. The
code in question (with some local modifications) is
if (mfi.clean && !df_conflict_remains &&
sha_eq(mfi.sha, a_sha) && mfi.mode == a_mode) {
output(o, 3, "Skipped %s (merged same as existing)", path);
/*
* The content merge resulted in the same file contents we
* already had. We can return early if those file contents
* are recorded at the correct path (which may not be true
* if the merge involves a rename).
*/
if (was_tracked(&o->original_index, path)) {
add_cacheinfo(mfi.mode, mfi.sha, path,
0 /*stage*/, 1 /*refresh*/, 0 /*options*/)
return mfi.clean;
}
} else
output(o, 2, "Auto-merging %s", path);
And the merge is:
BASE: original-path: v1
HEAD: original-path: v2
SIDE: renamed-path: v1
So, HEAD did have the correct contents that we wanted, as checked in
the first if. However, we cannot bail early because those contents
were recorded at the wrong path. Repeating the merge in the other
direction would simply show that we don't have the right contents
(a_sha != mfi.sha). Only if we have both the right contents and have
it at the right path should we exit early.
If we use "&the_index" instead of "&o->original_index", which is what
my previous series essentially did, then we get the wrong answer about
whether the contents are recorded at the necessary path, i.e.
was_tracked() lies to us.
Now, your gut feel and question here does turn out to be
important...in a different case. You'll note that I'm passing an
index to was_tracked(); that's because there is one case (the call to
was_tracked() from would_lose_untracked()) where it is important that
we use the index as modified by unpack_trees rather than the original
index and not doing so causes a bug depending on the direction things
are merged. I added a big comment in the code about that one.
> I think the fact you have a path "two" at stage 0, combined with the two
> diffs you ran for rename detection between the common ancestor and two
> branches, should be enough to decide if one branch added the path or moved
> it from elsewhere (in which case the common ancestor would not have that
> path), or it kept the path at the original place (with or without content
> change), no?
You are correct. I just need to reorder the patch series somewhat
(other patches added the passing of the relevant diff_filepair
information to merge_content, which is needed to do these checks you
suggest), and then I can change the was_tracked() call to instead
compare pathnames.
^ permalink raw reply
* Re: [RFC] helping smart-http/stateless-rpc fetch race
From: Shawn Pearce @ 2011-08-06 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbow337gx.fsf@alter.siamese.dyndns.org>
On Fri, Aug 5, 2011 at 13:54, Junio C Hamano <gitster@pobox.com> wrote:
> A request to fetch from a client over smart HTTP protocol is served in
> multiple steps. In the first round, the server side shows the set of refs
> it has and their values, and the client picks from them and sends "I want
> to fetch the history leading to these commits".
>
> When the server tries to respond to this second request, its refs may have
> progressed by a push from elsewhere. By design, we do not allow fetching
> objects that are not at the tip of an advertised ref, and the server
> rejects such a request. The client needs to try again, which is not ideal
> especially for a busy server.
>
> Teach --allow-non-tip option to upload-pack (which is the workhorse driven
> by git-daemon and smart http server interface) that lets it server commits
> that are not at the tip of any advertised ref, as long as they are
> reachable from advertised refs.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> * I'll leave it to interested parties who are more qualified than I am to
> update remote-curl nor http-backend to actually ask upload-pack to use
> this new logic ;-)
Why a new --allow-non-tip flag? Why not always do this with the
existing --stateless-rpc flag? I think the only time it is reasonable
to allow a non-tip want line is during the smart HTTP usage where the
request has spanned processes and the references may have moved in the
interm. Over a git:// or SSH where its the same server process and the
refs were cached at startup (and thus cannot move), it isn't
reasonable to allow a non-tip want.
Otherwise the patch looks good to me. This should fix some issues with
very busy repositories being fetched over smart HTTP.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 03/40] whitespace: remediate t1006-cat-file.sh
From: Jon Seymour @ 2011-08-06 22:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vmxfm1l1r.fsf@alter.siamese.dyndns.org>
On Sun, Aug 7, 2011 at 3:56 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
> I actually am slightly against it. One-time whole-tree clean-up can never
> happen without downside as _some_ parts of the tree always have patches to
> conflict with it in flight. One-time decision to clearly spell out the
> rules and cleaning the tree over time, fixing parts that are not actively
> touched one at a time, is probably feasible, though.
>
I certainly agree that whole tree cleanup is disruptive when there is
a lot of other stuff going on since it causes lots of merge conflicts.
In my day job, I sometimes have to defer otherwise sensible
refactorings because of the carnage they would cause for the daily
integration.
That's what I think is nice about having an easy way to automate the
cleanup+test, especially if it can be applied to arbitrary
refactorings. Having earlier invested the effort in creating some
refactoring heuristic, you can later easily apply the heuristic
completely and consistently to a file as part of some other
maintenance activity.
jon.
^ permalink raw reply
* Re: Cleaning up history with git rebase
From: Michael Witten @ 2011-08-06 23:59 UTC (permalink / raw)
To: Patricia Egeland; +Cc: Ricky Egeland, git
In-Reply-To: <ad9fe99851b7a4650e739e2e13b6a7c9@linea.gov.br>
On Fri, 05 Aug 2011 18:26:27 -0300, Patricia Egeland wrote:
>> On Thu, 04 Aug 2011 14:35:19 -0000, Michael Witten wrote:
>>
>> [Put your reply text below the quoted text.]
>>
>> On Wed, 03 Aug 2011 17:58:26 -0300, Patricia Egeland wrote:
>>
>>> On Mon, 01 Aug 2011 01:07:33 -0000, Michael Witten wrote:
>>>
>>>> Michael Witten wrote:
>>>>
>>>>> On Sun, 31 Jul 2011 18:44:43 -0300, Ricky, Egeland wrote:
>>>>>
>>>>>> On Jul 31, 2011, at 6:33 PM, Michael Witten wrote:
>>>>>>
>>>>>>> On Sun, Jul 31, 2011 at 20:21, Michael Witten
>>>>>>> <mfwitten@gmail.com>
>>>>>>> wrote:
>>>>>>>> Why are there conflicts anyway?
>>>>>>>
>>>>>>> Oh...
>>>>>>>
>>>>>>> I guess there were conflicts when the merge commit was made in
>>>>>>> the original repository, and these conflicts were resolved by
>>>>>>> the merge commit itself. Hence, when rebase tries to split up
>>>>>>> a merge by dealing with just the non-merge parents, you end up
>>>>>>> having to deal with the conflict again.
>>>>>>
>>>>>> Yes, I thought it was something like this going on, too. In the
>>>>>> pre-rebase history, when there is a commit with "Conflict:" and
>>>>>> listing file which is in the sub-repository history, this is a
>>>>>> point where rebase stops with a conflict.
>>>>>>
>>>>>>> Shouldn't rebase take this into account?
>>>>>>
>>>>>> Not sure. Seems that it does not, it makes me resolve the
>>>>>> conflict
>>>>>> =
>>>>>> again.
>>>>>
>>>>> I think git rebase should take this into account is what I'm
>>>>> saying.
>>>>>
>>>>> The following implements what I think `git rebase' should be
>>>>> doing;
>>>>> run it instead of `git rebase' in your repo:
>>>>>
>>>>> git branch saved
>>>>> git rev-list HEAD --reverse --first-parent --parents |
>>>>> {
>>>>> read root
>>>>> git reset --hard $root
>>>>> rebase_head=$root
>>>>>
>>>>> while read commit first_parent other_parents; do
>>>>>
>>>>> if [ -z "$other_parents" ]; then
>>>>>
>>>>> git cherry-pick $commit
>>>>> rebase_head=$commit
>>>>>
>>>>> else
>>>>>
>>>>> for parent in $other_parents; do
>>>>>
>>>>> if ! git cherry-pick $parent; then
>>>>>
>>>>> git reset --hard $rebase_head
>>>>> git merge $other_parents
>>>>> git rm -rf .
>>>>> git checkout -- $commit
>>>>> git commit -aC $commit
>>>>> break
>>>>>
>>>>> fi
>>>>>
>>>>> done
>>>>>
>>>>> rebase_head=$(git rev-parse HEAD)
>>>>>
>>>>> fi
>>>>>
>>>>> done
>>>>> }
>>>>
>>>> Woops!
>>>>
>>>> This line:
>>>>
>>>> git checkout -- $commit
>>>>
>>>> should be:
>>>>
>>>> git checkout $commit -- .
>>>
>>> I tried to run the script in my repo. However, seems like the
>>> 'git
>>> merge $other_parents' process fails. In the script output I see some
>>> lines saying that files were not able to be merged, ie:
>>>
>>> warning: Cannot merge binary files:
>>> scienceportal/images/tabs/tabs-gray.png (HEAD vs.
>>> 84f6fc283861aa7c5798f58769789dd0b91a5e9d)
>>> warning: Cannot merge binary files: scienceportal/images/waiting.gif
>>> (HEAD vs. e033cbbf1e9d24b66cb55a04701c059dc945c1c3)
>>>
>>> Do you have some suggestion?
>>
>> That's probably as expected; the script is coming across the
>> conflict, but
>> it should be taking care of the conflict automatically.
>>
>> Unfortunately, though, the results probably end up being almost
>> completely
>> similar to the original un-rebased branch because the original script
>> actually has ANOTHER mistake (sorry!). See the updated version here
>> (or
>> in your inbox):
>>
>> http://marc.info/?l=git&m=131246773005168&w=2
>> Message-ID: <d62225a3cc5740cda7cb163a94d55892-mfwitten@gmail.com>
>
>
> Thanks for taking a look at it again.
> I tried to run the script with that update, but in the end I got more
> merge messages than I had originally. (71 additional merges. From those
> 71, I got 53 "Merge commit" messages. While in the saved repo I have 1
> "Merge commit".). Do you see what may be causing that?
>
> Another thing I noticed is that the auto-merging is still failing:
>
> fatal: Commit b0596fce207735081b8aa9afdd9686b7d412f5d8 is a merge but
> no -m option was given.
> HEAD is now at ac5eaa2 *Continue Last Commit*
> Auto-merging scienceportal/css/myprofile.css
> CONFLICT (content): Merge conflict in scienceportal/css/myprofile.css
> Auto-merging scienceportal/css/qc.css
> Automatic merge failed; fix conflicts and then commit the result.
> scienceportal/css/myprofile.css: needs merge
> rm 'scienceportal/css/des.css'
>
> Looking at this thread:
> http://www.mail-archive.com/git-users@googlegroups.com/msg01046.html
> I thought that the attempt of removing the files was the step first
> facing the conflicts as the one shown above. So that, I tried to iterate
> through the files and in case the removal of any file failed, I added
> the steps as suggested in the thread:
> git checkout --theirs $file
> git add $file
> git commit -m 'Fixing conflict during rebase'
>
> But that didn't work either.
>
> I'd be greatly appreciated if you are still willing to help.
Those error messages are expected, but my original script is
incredibly naive (to the point of being incorrect).
Fortunately, I've thought a bit more about it, and I have a much
better solution in the works, so please hold on just a bit longer
while I work out the kinks.
^ permalink raw reply
* When i run git difftool, git did not use difftool.bc3.cmd,why?
From: jelly @ 2011-08-07 1:48 UTC (permalink / raw)
To: Git讨论组(无须订阅)
Even i write a wrong exe file name bcomp1.exe, git still use bcompare.
[diff]
tool = bc3
[difftool "bc3"]
cmd = "/cygdrive/c/program files/beyond compare 3/bcomp1.exe" "$(cygpath -w $LOCAL)" "$REMOTE"
$ git difftool/usr/lib/git-core/git-mergetool--lib: line 124: bcompare: command not found
^ permalink raw reply
* Re:When i run git difftool, git did not use difftool.bc3.cmd,why?
From: jelly @ 2011-08-07 2:03 UTC (permalink / raw)
To: Git讨论组(无须订阅)
In-Reply-To: <24cad567.da0.131a1ed237b.Coremail.sinojelly@163.com>
>When i run git difftool, git did not use difftool.bc3.cmd,why?>Even i write a wrong exe file name bcomp1.exe, git still use bcompare.
I found the reason.
because bc3 is a special name, git call bcompare internal.change the name bc3, it works fine.
^ permalink raw reply
* [PATCH] filter-branch: Export variable `workdir' for --commit-filter
From: Michael Witten @ 2011-08-07 2:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
According to `git help filter-branch':
--commit-filter <command>
...
You can use the _map_ convenience function in this filter,
and other convenience functions, too...
...
However, it turns out that `map' hasn't been usable because it depends
on the variable `workdir', which is not propogated to the environment
of the shell that runs the commit-filter <command> because the
shell is created via a simple-command rather than a compound-command
subshell:
@SHELL_PATH@ -c "$filter_commit" "git commit-tree" \
$(git write-tree) $parentstr < ../message > ../map/$commit ||
die "could not write rewritten commit"
One solution is simply to export `workdir'. However, it seems rather
heavy-handed to export `workdir' to the environments of all commands,
so instead this commit exports `workdir' for only the duration of the
shell command in question:
workdir=$workdir @SHELL_PATH@ -c "$filter_commit" "git commit-tree" \
$(git write-tree) $parentstr < ../message > ../map/$commit ||
die "could not write rewritten commit"
Signed-off-by: Michael Witten <mfwitten@gmail.com>
---
git-filter-branch.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 962a93b..6b5f225 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -363,7 +363,7 @@ while read commit parents; do
sed -e '1,/^$/d' <../commit | \
eval "$filter_msg" > ../message ||
die "msg filter failed: $filter_msg"
- @SHELL_PATH@ -c "$filter_commit" "git commit-tree" \
+ workdir=$workdir @SHELL_PATH@ -c "$filter_commit" "git commit-tree" \
$(git write-tree) $parentstr < ../message > ../map/$commit ||
die "could not write rewritten commit"
done <../revs
--
1.7.6.134.gcf13f6
^ permalink raw reply related
* Re: [RFC 4/6] git-check-attr: Normalize paths
From: Michael Haggerty @ 2011-08-07 4:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaabn52bb.fsf@alter.siamese.dyndns.org>
On 08/05/2011 05:02 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> If I understand you correctly, the use of some API routines requires a
>> chdir by the caller (i.e., the surrounding application) *before* calling
>> into the routine. This is certainly a bit cleaner than the library
>> chdiring itself, but it is still unusable in a multithreaded context.
>
> Why?
>
> Presumably you know what your threads are doing, so if you take input from
> the end user after you started the environment, you will be doing the
> prefix discovery and pathspec prefixing on the entry and prefix stripping
> upon output but do not have to (and should not be doing) chdir at all.
I must have misunderstood your earlier message. Indeed, if none of the
git functions that one would want to libify require that CWD==project
root, then all is OK.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH 0/3] bisect: add support for bisecting bare repositories
From: Jon Seymour @ 2011-08-07 10:50 UTC (permalink / raw)
To: git; +Cc: gitster, chriscool, j6t, jnareb, jrnieder, Jon Seymour
This extension to js/bisect-no-checkout (currently in pu) adds support for bisecting bare repositories.
It does this by relaxing the requirement that git bisect is invoked in a repository with a working tree and by
defaulting to --no-checkout in the case of a bare repository.
Two tests are included to demonstrate this behaviour.
Jon Seymour (3):
bisect: relax requirement for a working tree.
bisect: add tests for bisection on bare repositories
bisect: document that --no-checkout is the default for bare
repositories
Documentation/git-bisect.txt | 2 ++
git-bisect.sh | 8 ++++++--
git.c | 2 +-
t/t6030-bisect-porcelain.sh | 28 ++++++++++++++++++++++++++++
4 files changed, 37 insertions(+), 3 deletions(-)
--
1.7.6.363.g9b380.dirty
^ permalink raw reply
* [PATCH 1/3] bisect: relax requirement for a working tree.
From: Jon Seymour @ 2011-08-07 10:50 UTC (permalink / raw)
To: git; +Cc: gitster, chriscool, j6t, jnareb, jrnieder, Jon Seymour
In-Reply-To: <1312714240-23647-1-git-send-email-jon.seymour@gmail.com>
Now that bisection does not require checkout, it can work
on bare repositories too.
In this case, we default the checkout mode to --no-checkout,
thereby forcing the creation of BISECT_HEAD on either a manual
or automatic start.
The require_work_tree check in git-bisect.sh and the NEED_WORK_TREE
check in git.c are relaxed.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
git-bisect.sh | 8 ++++++--
git.c | 2 +-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 22c4da5..436cc07 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -29,7 +29,6 @@ Please use "git help bisect" to get the full man page.'
OPTIONS_SPEC=
. git-sh-setup
. git-sh-i18n
-require_work_tree
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
@@ -79,7 +78,12 @@ bisect_start() {
orig_args=$(git rev-parse --sq-quote "$@")
bad_seen=0
eval=''
- mode=''
+ if test "z$(git rev-parse --is-bare-repository)" != "zfalse"
+ then
+ mode='--no-checkout'
+ else
+ mode=''
+ fi
while [ $# -gt 0 ]; do
arg="$1"
case "$arg" in
diff --git a/git.c b/git.c
index 8828c18..7fdcab2 100644
--- a/git.c
+++ b/git.c
@@ -320,7 +320,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "annotate", cmd_annotate, RUN_SETUP },
{ "apply", cmd_apply, RUN_SETUP_GENTLY },
{ "archive", cmd_archive },
- { "bisect--helper", cmd_bisect__helper, RUN_SETUP | NEED_WORK_TREE },
+ { "bisect--helper", cmd_bisect__helper, RUN_SETUP },
{ "blame", cmd_blame, RUN_SETUP },
{ "branch", cmd_branch, RUN_SETUP },
{ "bundle", cmd_bundle, RUN_SETUP_GENTLY },
--
1.7.6.363.g9b380.dirty
^ 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