* [PATCH 01/15] t1013 (loose-object-format): fix && chaining
From: Ramkumar Ramachandra @ 2011-12-07 19:36 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, Git List
In-Reply-To: <1323286611-4806-1-git-send-email-artagnon@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
t/t1013-loose-object-format.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t1013-loose-object-format.sh b/t/t1013-loose-object-format.sh
index 0a9cedd..fbf5f2f 100755
--- a/t/t1013-loose-object-format.sh
+++ b/t/t1013-loose-object-format.sh
@@ -34,7 +34,7 @@ assert_blob_equals() {
}
test_expect_success setup '
- cp -R "$TEST_DIRECTORY/t1013/objects" .git/
+ cp -R "$TEST_DIRECTORY/t1013/objects" .git/ &&
git --version
'
--
1.7.7.3
^ permalink raw reply related
* Re: &&-chaining tester
From: Ramkumar Ramachandra @ 2011-12-07 19:36 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, Git List
In-Reply-To: <20111207100858.GB13374@elie.hsd1.il.comcast.net>
Hi,
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> Missing the chaining '&&' seems to be quite a common
>> error: I vaguely remember seeing a patch to detect this sometime ago.
>> Jonathan?
>
> [...]
> - fix all cases of broken &&-chaining. For extra bonus points,
> send out those patches, respond to reviews, and gently usher
> them into Junio's tree
Hm, involves a huge amount of janitorial work. Anyway, thanks for
pointing me in the right direction- here's a small start.
[What I used; for reference]
--
t/test-lib.sh | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index bdd9513..3bf75ac 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -472,7 +472,17 @@ test_eval_ () {
eval >&3 2>&4 "$*"
}
+check_command_chaining_ () {
+ eval >&3 2>&4 "(exit 189) && $1"
+ eval_chain_ret=$?
+ if test "$eval_chain_ret" != 189
+ then
+ echo '[CHAIN_BUG] in the test script: missing "&&" in test commands'
+ fi
+}
+
test_run_ () {
+ check_command_chaining_ "$1"
test_cleanup=:
expecting_failure=$2
test_eval_ "$1"
--
Thanks.
-- Ram
Ramkumar Ramachandra (15):
t1013 (loose-object-format): fix && chaining
t1300 (repo-config): fix && chaining
t1412 (reflog-loop): fix && chaining
t1007 (hash-object): fix && chaining
t1510 (repo-setup): fix && chaining
t1511 (rev-parse-caret): fix && chaining
t1510 (worktree): fix && chaining
t3200 (branch): fix && chaining
t3418 (rebase-continue): fix && chaining
t3400 (rebase): fix && chaining
t3310 (notes-merge-manual-resolve): fix && chaining
t3419 (rebase-patch-id): fix && chaining
t3030 (merge-recursive): use test_expect_code
t1006 (cat-file): use test_cmp
t3040 (subprojects-basic): modernize style
t/t1006-cat-file.sh | 53 +++---------
t/t1007-hash-object.sh | 16 ++--
t/t1013-loose-object-format.sh | 2 +-
t/t1300-repo-config.sh | 2 +-
t/t1412-reflog-loop.sh | 2 +-
t/t1501-worktree.sh | 6 +-
t/t1510-repo-setup.sh | 4 +-
t/t1511-rev-parse-caret.sh | 2 +-
t/t3030-merge-recursive.sh | 72 ++---------------
t/t3040-subprojects-basic.sh | 144 ++++++++++++++++----------------
t/t3200-branch.sh | 4 +-
t/t3310-notes-merge-manual-resolve.sh | 10 +-
t/t3400-rebase.sh | 4 +-
t/t3418-rebase-continue.sh | 4 +-
t/t3419-rebase-patch-id.sh | 2 +-
15 files changed, 119 insertions(+), 208 deletions(-)
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH 4/2] grep: turn off threading for non-worktree
From: Jeff King @ 2011-12-07 18:28 UTC (permalink / raw)
To: René Scharfe; +Cc: Thomas Rast, git, Eric Herman, Junio C Hamano
In-Reply-To: <4EDF9E53.7090702@lsrfire.ath.cx>
On Wed, Dec 07, 2011 at 06:11:47PM +0100, René Scharfe wrote:
> > $ time git grep --threads=8 'a.*b' HEAD >/dev/null
> > real 0m8.655s
> > user 0m23.817s
> > sys 0m0.480s
> [...]
>
> Ugh, right, Turbo Boost complicates matters.
>
> I don't understand the multiplied user time in the threaded case,
> though. Is it caused by busy-waiting? Thomas reported similar numbers
> earlier.
I think it's mostly the clock speed. This processor runs at 1.86GHz but
boosts to 3.2GHz. So we'd expect just the actual work to take close to
twice as long. Plus it's a quad-core with hyperthreading, so 8 threads
is going to mean two threads sharing each core, including cache (i.e.,
hyperthreading a core does not let you double performance, even though
it presents itself as an extra core).
And then you have context switching and lock overhead. So I can believe
that it takes 3x the CPU time to accomplish the task. In an ideal world,
it would be mitigated by having 8x the threads, but in this case, lock
contention brings us down to less than 3x, and it's a slight net loss.
-Peff
^ permalink raw reply
* Re: Odd issue - The Diffs That WILL NOT DIE.
From: Chris Patti @ 2011-12-07 18:16 UTC (permalink / raw)
To: Philippe Vaucher; +Cc: Carlos Martín Nieto, git
In-Reply-To: <CAGK7Mr7z6hqoda=pr3syzC5mO1+ZExMeD7sReeyRaYL5OMhemw@mail.gmail.com>
On Wed, Dec 7, 2011 at 12:20 PM, Philippe Vaucher
<philippe.vaucher@gmail.com> wrote:
>> 11:35][admin@Hiram-Abiff-2:~/src]$ rm -rf framework/
>> [11:44][admin@Hiram-Abiff-2:~/src]$ git clone
> ...snip...
>> [11:51][admin@Hiram-Abiff-2:~/src]$ cd framework/
>> [11:51][admin@Hiram-Abiff-2:~/src/framework(master)]$ git diff
> ...snip...
>
> Can you paste the output of "git status" right after the "cd framework"?
>
> Looks like you have some external process that goes and touches your
> file after the git clone, or that git fails to check out the files
> after cloning but isn't able to work out it failed to checkout those
> files.
>
> Philippe
FYI this behavior persists across reboots so this rogue process is
also restarting itself :)
Thanks,
-Chris
--
Christopher Patti - Geek At Large | GTalk: cpatti@gmail.com | AIM:
chrisfeohpatti | P: (260) 54PATTI
"Technology challenges art, art inspires technology." - John Lasseter, Pixar
^ permalink raw reply
* Re: [PATCH v2 3/3] grep: disable threading in all but worktree case
From: Jeff King @ 2011-12-07 18:10 UTC (permalink / raw)
To: René Scharfe; +Cc: git, Eric Herman, Junio C Hamano
In-Reply-To: <4EDF99BA.3040006@lsrfire.ath.cx>
On Wed, Dec 07, 2011 at 05:52:10PM +0100, René Scharfe wrote:
> > As a user, I would do:
> >
> > git grep --threads=1 ...
> >
> > if I wanted a single-threaded process. Instead, we actually spawn a
> > sub-thread and do all of the locking, which has a measurable cost:
>
> Yes, the difference is measurable, and that's exactly how I like it to
> be. :) A user can turn off threading with --threads=0 or (more
> intuitively) --no-threads. And we can quantify the overhead.
That seems acceptable to me if --threads is for speed-testing, but a
horrible interface if it is meant for end users who just want git to be
fast.
-Peff
^ permalink raw reply
* Re: Odd issue - The Diffs That WILL NOT DIE.
From: Chris Patti @ 2011-12-07 18:05 UTC (permalink / raw)
To: Philippe Vaucher; +Cc: Carlos Martín Nieto, git
In-Reply-To: <CAGK7Mr7z6hqoda=pr3syzC5mO1+ZExMeD7sReeyRaYL5OMhemw@mail.gmail.com>
On Wed, Dec 7, 2011 at 12:20 PM, Philippe Vaucher
<philippe.vaucher@gmail.com> wrote:
>> 11:35][admin@Hiram-Abiff-2:~/src]$ rm -rf framework/
>> [11:44][admin@Hiram-Abiff-2:~/src]$ git clone
> ...snip...
>> [11:51][admin@Hiram-Abiff-2:~/src]$ cd framework/
>> [11:51][admin@Hiram-Abiff-2:~/src/framework(master)]$ git diff
> ...snip...
>
> Can you paste the output of "git status" right after the "cd framework"?
>
> Looks like you have some external process that goes and touches your
> file after the git clone, or that git fails to check out the files
> after cloning but isn't able to work out it failed to checkout those
> files.
>
> Philippe
Sure.
--
[13:04][admin@Hiram-Abiff-2:~/src/framework(master)]$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: app/modules/Core/controllers/CloudSponge.php
#
no changes added to commit (use "git add" and/or "git commit -a")
[13:04][admin@Hiram-Abiff-2:~/src/framework(master)]$
I'll try rebooting the Mac to see if there's some rogue process afoot :)
-Chris
--
Christopher Patti - Geek At Large | GTalk: cpatti@gmail.com | AIM:
chrisfeohpatti | P: (260) 54PATTI
"Technology challenges art, art inspires technology." - John Lasseter, Pixar
^ permalink raw reply
* [PATCH] index-pack: eliminate unlimited recursion in get_delta_base()
From: Nguyễn Thái Ngọc Duy @ 2011-12-07 17:50 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <7vvcpthh97.fsf@alter.siamese.dyndns.org>
Revert the order of delta applying so that by the time a delta is
applied, its base is either non-delta or already inflated.
get_delta_base() is still recursive, but because base's data is always
ready, the inner get_delta_base() call never has any chance to call
itself again.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/index-pack.c | 30 +++++++++++++++++++++---------
1 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 0945adb..103e19c 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -508,10 +508,25 @@ static void *get_base_data(struct base_data *c)
{
if (!c->data) {
struct object_entry *obj = c->obj;
+ struct base_data **delta = NULL;
+ int delta_nr = 0, delta_alloc = 0;
- if (is_delta_type(obj->type)) {
- void *base = get_base_data(c->base);
- void *raw = get_data_from_pack(obj);
+ for (; is_delta_type(c->obj->type); c = c->base) {
+ ALLOC_GROW(delta, delta_nr + 1, delta_alloc);
+ delta[delta_nr++] = c;
+ }
+ if (!delta_nr) {
+ c->data = get_data_from_pack(obj);
+ c->size = obj->size;
+ base_cache_used += c->size;
+ prune_base_data(c);
+ }
+ for (; delta_nr > 0; delta_nr--) {
+ void *base, *raw;
+ c = delta[delta_nr - 1];
+ obj = c->obj;
+ base = get_base_data(c->base);
+ raw = get_data_from_pack(obj);
c->data = patch_delta(
base, c->base->size,
raw, obj->size,
@@ -519,13 +534,10 @@ static void *get_base_data(struct base_data *c)
free(raw);
if (!c->data)
bad_object(obj->idx.offset, "failed to apply delta");
- } else {
- c->data = get_data_from_pack(obj);
- c->size = obj->size;
+ base_cache_used += c->size;
+ prune_base_data(c);
}
-
- base_cache_used += c->size;
- prune_base_data(c);
+ free(delta);
}
return c->data;
}
--
1.7.8.36.g69ee2
^ permalink raw reply related
* Re: Odd issue - The Diffs That WILL NOT DIE.
From: Philippe Vaucher @ 2011-12-07 17:20 UTC (permalink / raw)
To: Chris Patti; +Cc: Carlos Martín Nieto, git
In-Reply-To: <CAJ8P3RCPt9Kwi1F7_TEkZQhkm1mwR_TFKhYszS5LL50kXU8oNQ@mail.gmail.com>
> 11:35][admin@Hiram-Abiff-2:~/src]$ rm -rf framework/
> [11:44][admin@Hiram-Abiff-2:~/src]$ git clone
...snip...
> [11:51][admin@Hiram-Abiff-2:~/src]$ cd framework/
> [11:51][admin@Hiram-Abiff-2:~/src/framework(master)]$ git diff
...snip...
Can you paste the output of "git status" right after the "cd framework"?
Looks like you have some external process that goes and touches your
file after the git clone, or that git fails to check out the files
after cloning but isn't able to work out it failed to checkout those
files.
Philippe
^ permalink raw reply
* Re: [PATCH 4/2] grep: turn off threading for non-worktree
From: René Scharfe @ 2011-12-07 17:11 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Rast, git, Eric Herman, Junio C Hamano
In-Reply-To: <20111207044242.GB10765@sigill.intra.peff.net>
Am 07.12.2011 05:42, schrieb Jeff King:
> On Wed, Dec 07, 2011 at 12:01:37AM +0100, René Scharfe wrote:
>
>> Reading of git objects needs to be protected by an exclusive lock
>> and cannot be parallelized. Searching the read buffers can be done
>> in parallel, but for simple expressions threading is a net loss due
>> to its overhead, as measured by Thomas. Turn it off unless we're
>> searching in the worktree.
>
> Based on my earlier numbers, I was going to complain that we should
> also be checking the "simple expressions" assumption here, as time spent
> in the actual regex might be important.
>
> However, after trying to repeat my experiment, I think the numbers I
> posted earlier were misleading. For example, using my "more complex"
> regex of 'a.*b':
>
> $ time git grep --threads=8 'a.*b' HEAD >/dev/null
> real 0m8.655s
> user 0m23.817s
> sys 0m0.480s
>
> Look at that sweet, sweet parallelism. It's a quad-core with
> hyperthreading, so we're not getting the 8x speedup we might hope for
> (presumably due to lock contention on extracting blobs), but hey, 3x
> isn't bad. Except, wait:
>
> $ time git grep --threads=0 'a.*b' HEAD >/dev/null
> real 0m7.651s
> user 0m7.600s
> sys 0m0.048s
>
> We can get 1x on a single core, but the total time is lower! This
> processor is an i7 with "turbo boost", which means it clocks higher in
> single-core mode than when multiple cores are active. So the numbers I
> posted earlier were misleading. Yes, we got parallelism, but at the cost
> of knocking the clock speed down for a net loss.
Ugh, right, Turbo Boost complicates matters.
I don't understand the multiplied user time in the threaded case,
though. Is it caused by busy-waiting? Thomas reported similar numbers
earlier.
> The sweet spot for me seems to be:
>
> $ time git grep --threads=2 'a.*b' HEAD >/dev/null
> real 0m6.303s
> user 0m11.129s
> sys 0m0.220s
>
> I'd be curious to see results from somebody with a quad-core (or more)
> without turbo boost; I suspect that threading may have more benefit
> there, even though we have some lock contention for blobs.
It would be nice if we could come up with simple rules to calculate
defaults for the number of threads on a given run. Users shouldn't have
to specify this option normally. And it would be good if these rules
didn't require a list of all CPUs known to git. :)
>> --- a/builtin/grep.c
>> +++ b/builtin/grep.c
>> @@ -1048,7 +1048,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
>> nr_threads = 0;
>> #else
>> if (nr_threads == -1)
>> - nr_threads = (online_cpus() > 1) ? THREADS : 0;
>> + nr_threads = (online_cpus() > 1 && !list.nr) ? THREADS : 0;
>>
>> if (nr_threads > 0) {
>> opt.use_threads = 1;
>
> This doesn't kick in for "--cached", which has the same performance
> characteristics as grepping a tree. I think you want to add "&& !cached" to
> the conditional.
Oh, yes.
René
^ permalink raw reply
* Re: [PATCH 4/2] grep: turn off threading for non-worktree
From: René Scharfe @ 2011-12-07 17:00 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Eric Herman, Junio C Hamano
In-Reply-To: <201112070912.54766.trast@student.ethz.ch>
Am 07.12.2011 09:12, schrieb Thomas Rast:
> René Scharfe wrote:
>> diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
>> index 47ac188..e981a9b 100644
>> --- a/Documentation/git-grep.txt
>> +++ b/Documentation/git-grep.txt
>> @@ -228,8 +228,9 @@ OPTIONS
>> there is a match and with non-zero status when there isn't.
>>
>> --threads <n>::
>> + Run <n> search threads in parallel. Default is 8 when searching
>> + the worktree and 0 otherwise. This option is ignored if git was
>> + built without support for POSIX threads.
> [...]
>> - nr_threads = (online_cpus() > 1) ? THREADS : 0;
>> + nr_threads = (online_cpus() > 1 && !list.nr) ? THREADS : 0;
>
> It would be more consistent to stick to the pack.threads convention
> where 0 means "all of my cores", so to disable threading the user
> would set the number of threads to 1. Or were you trying to measure
> the contention between the worker thread and the add_work() thread?
Yes, indeed, the cost for the threading overhead does interest me. The
documentation should perhaps mention --no-threads explicitly to avoid
confusion.
Currently there is no way to specify "as many threads as there are
cores" here. Previous measurements indicated that it wasn't too useful,
however, because I/O parallelism was beneficial even for machines with
less than eight cores and more threads didn't pay off.
René
^ permalink raw reply
* Re: [PATCH v2 3/3] grep: disable threading in all but worktree case
From: René Scharfe @ 2011-12-07 16:54 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Eric Herman, Junio C Hamano
In-Reply-To: <201112070911.08079.trast@student.ethz.ch>
Am 07.12.2011 09:11, schrieb Thomas Rast:
> René Scharfe wrote:
>> Am 02.12.2011 17:15, schrieb René Scharfe:
>>> How about adding a parameter to control the number of threads
>>> (--threads?) instead that defaults to eight (or five) for the worktree
>>> and one for the rest? That would also make benchmarking easier.
>>
>> Like this:
>>
>> -- >8 --
>> Subject: grep: add parameter --threads
>>
>> Allow the number of threads to be specified by the user. This makes
>> benchmarking the performance impact of different numbers of threads
>> much easier.
>
> Sounds good, though in the end we would also want to have a config
> variable for the poor OS X users who have to tune their threads
> *down*... :-)
We could set different defaults for different platforms..
René
^ permalink raw reply
* Re: Odd issue - The Diffs That WILL NOT DIE.
From: Chris Patti @ 2011-12-07 16:54 UTC (permalink / raw)
To: Carlos Martín Nieto, Chris Patti, git
In-Reply-To: <20111206215102.GA3654@centaur.lab.cmartin.tk>
On Tue, Dec 6, 2011 at 4:51 PM, Carlos Martín Nieto <cmn@elego.de> wrote:
> On Tue, Dec 06, 2011 at 04:43:50PM -0500, Chris Patti wrote:
>> I have a Homebrew installed version if Git 1.7.8 running on OSX Lion.
>>
>> I'm seeing a very odd issue where these diffs I didn't create keep
>> recurring in a particular repository.
>
> Which diffs? You haven't given us any? What files does this happen
> with? Do they have any peculiarities?
>
> If these are files with non-ASCII filenames, then you're hitting a
> misfeature of the HFS+ filesystem (it lies when git asks it about
> files).
>
>>
>> I've tried:
>>
>> * Nuking the repo and re-cloning, cloning into a totally different
>> containing directory
>> * git reset --hard, git checkout -- of the offending file supposedly
>> containing the diffs
>>
>> Is there some sort of uber persistent local cache that's bound to the
>> remote repository?
>
> The remote repository shouldn't have anything to do with this.
>
> cmn
OK. Let me give you a very specific series of commands, sorry about
the poor question / report (Not convinced it's a bug, probably pilot
error?)
If my understanding of the way Git works is correct, there should be
NO pending diffs in a freshly cloned repository, yes?
Note that I tried git diff and git diff -w below with identical results:
---
11:35][admin@Hiram-Abiff-2:~/src]$ rm -rf framework/
[11:37][admin@Hiram-Abiff-2:~/src]$
[11:44][admin@Hiram-Abiff-2:~/src]$ git clone
ssh://git.bluestatedigital.com/home/git/framework.git
Cloning into 'framework'...
remote: Counting objects: 378540, done.
remote: Compressing objects: 100% (100469/100469), done.
remote: Total 378540 (delta 261046), reused 374685 (delta 258447)
Receiving objects: 100% (378540/378540), 148.33 MiB | 2.08 MiB/s, done.
Resolving deltas: 100% (261046/261046), done.
[11:51][admin@Hiram-Abiff-2:~/src]$ cd framework/
[11:51][admin@Hiram-Abiff-2:~/src/framework(master)]$ git diff
diff --git a/app/modules/Core/controllers/CloudSponge.php b/app/modules/Core/con
index 615a7b3..911d456 100644
--- a/app/modules/Core/controllers/CloudSponge.php
+++ b/app/modules/Core/controllers/CloudSponge.php
@@ -1,229 +1,71 @@
-<?php
-
-require_once "utils/blue_mailer/queue_mailer.class.php";
-
-class Core_CloudSponge_Controller extends Core_PageBase_Controller
-{
- private $_config;
- private $_tsFactory;
- private $_emailValidator;
- private $_formFactory;
- private $_rowBuilderFactory;
-
- public function __construct
- (
- Blue_Config $config,
- Blue_SecureTimestamp_Factory $tsFactory,
- Blue_Email_Validator $emailValidator,
- Framework_Ui_Form_Factory $formFactory,
[11:51][admin@Hiram-Abiff-2:~/src/framework(master)]$ git diff -w
diff --git a/app/modules/Core/controllers/CloudSponge.php b/app/modules/Core/con
index 615a7b3..911d456 100644
--- a/app/modules/Core/controllers/CloudSponge.php
+++ b/app/modules/Core/controllers/CloudSponge.php
@@ -1,229 +1,71 @@
-<?php
-
-require_once "utils/blue_mailer/queue_mailer.class.php";
-
-class Core_CloudSponge_Controller extends Core_PageBase_Controller
-{
- private $_config;
- private $_tsFactory;
- private $_emailValidator;
- private $_formFactory;
- private $_rowBuilderFactory;
-
- public function __construct
- (
- Blue_Config $config,
- Blue_SecureTimestamp_Factory $tsFactory,
- Blue_Email_Validator $emailValidator,
- Framework_Ui_Form_Factory $formFactory,
[11:52][admin@Hiram-Abiff-2:~/src/framework(master)]$
--
Christopher Patti - Geek At Large | GTalk: cpatti@gmail.com | AIM:
chrisfeohpatti | P: (260) 54PATTI
"Technology challenges art, art inspires technology." - John Lasseter, Pixar
^ permalink raw reply related
* Re: [PATCH v2 3/3] grep: disable threading in all but worktree case
From: René Scharfe @ 2011-12-07 16:52 UTC (permalink / raw)
To: Jeff King; +Cc: git, Eric Herman, Junio C Hamano
In-Reply-To: <20111207042431.GA10765@sigill.intra.peff.net>
Am 07.12.2011 05:24, schrieb Jeff King:
> On Tue, Dec 06, 2011 at 11:48:26PM +0100, René Scharfe wrote:
>
>> #ifndef NO_PTHREADS
>> - if (use_threads) {
>> + if (nr_threads > 0) {
>> grep_sha1_async(opt, name, sha1);
>> return 0;
>> } else
>
> Should this be "if (nr_threads > 1)"?
>
> As a user, I would do:
>
> git grep --threads=1 ...
>
> if I wanted a single-threaded process. Instead, we actually spawn a
> sub-thread and do all of the locking, which has a measurable cost:
Yes, the difference is measurable, and that's exactly how I like it to
be. :) A user can turn off threading with --threads=0 or (more
intuitively) --no-threads. And we can quantify the overhead.
> $ time git grep --threads=0 SIMPLE HEAD >/dev/null
> real 0m2.994s
> user 0m2.932s
> sys 0m0.060s
>
> $ time git grep --threads=1 SIMPLE HEAD >/dev/null
> real 0m3.407s
> user 0m3.392s
> sys 0m0.140s
>
> Should --threads=1 be equivalent to --threads=0?
We can do that if there's another way to calculate this difference, or
if it is not useful to know. I find your results interesting at least,
though. :)
René
^ permalink raw reply
* Re: Undo a commit that is already pushed to central server and merged to several branches
From: Johan Herland @ 2011-12-07 16:01 UTC (permalink / raw)
To: Matthias Fechner; +Cc: Ramkumar Ramachandra, Git Mailing List
In-Reply-To: <4EDF87A6.4000703@fechner.net>
On Wed, Dec 7, 2011 at 16:35, Matthias Fechner <idefix@fechner.net> wrote:
> Am 07.12.11 15:42, schrieb Ramkumar Ramachandra:
>>
>> Assuming that you actually want to rewrite the history, the situation
>> calls for a git-reset(1). Just "git reset --hard HEAD~1" on each of
>> your branches (Caution: first understand what it does!) and you'll
>
>
> that will not work, because in the master branch I already have around 15
> commits after the bogus commit and I want to keep these commits.
>
> And in some other branches there are tons of commits (over 100) after the
> bogus commit with the merge and I only want to remove that bogus commit but
> keep all other commits after the bogus commit (all commits are not related
> to the bogus one, they are all in different files).
>
> It is even fine if I could remove the bogus commit from all branches.
Use "git revert $commit" to undo the effects of the given $commit.
This must be applied to all affected branches (either by reverting in
the master branch and remerging master to the other branches, or by
using "git revert" in each individual branch).
Note that the "git revert" command will NOT remove the original bogus
commit. Instead, it will create a new commit that undoes the changes
introduced by the bogus commit. If the same lines/files have been
touched by other commits in the meantime, you might get conflicts that
you'll have to resolve, just like a regular merge.
If you'd rather want the bogus commit to disappear entirely (i.e.
rewrite the history so that it looks like the bogus comit never
happened in the first place), then things get more complicated. You
will need to recreate the history of your master branch, skipping the
bogus commit, and then recreate all the other branches in a similar
manner. The "git rebase" tool will be helpful here, but I recommend
that you understand and get used to how it works before applying it to
this problem. Note that rewriting history is only a good idea when you
haven't shared the history with anyone else. If other people are
already using any of the branches with the bogus commit, then
rewriting the history is a BIG NO-NO. In that case, "git revert" is
the only sane approach.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Undo a commit that is already pushed to central server and merged to several branches
From: Ramkumar Ramachandra @ 2011-12-07 16:01 UTC (permalink / raw)
To: Matthias Fechner; +Cc: Git Mailing List
In-Reply-To: <4EDF87A6.4000703@fechner.net>
Hi Matthias,
Matthias Fechner wrote:
> Am 07.12.11 15:42, schrieb Ramkumar Ramachandra:
>
>> Assuming that you actually want to rewrite the history, the situation
>> calls for a git-reset(1). Just "git reset --hard HEAD~1" on each of
>> your branches (Caution: first understand what it does!) and you'll
>
>
> that will not work, because in the master branch I already have around 15
> commits after the bogus commit and I want to keep these commits.
>
> And in some other branches there are tons of commits (over 100) after the
> bogus commit with the merge and I only want to remove that bogus commit but
> keep all other commits after the bogus commit (all commits are not related
> to the bogus one, they are all in different files).
I see. I won't attempt to repeat what Junio and Linus have explained
in this document then [1].
Cheers.
[1]: http://schacon.github.com/git/howto/revert-a-faulty-merge.txt
-- Ram
^ permalink raw reply
* Re: Yo dawg, I heard you like trees...
From: Sebastian Morr @ 2011-12-07 15:54 UTC (permalink / raw)
To: Phil Hord; +Cc: git
In-Reply-To: <CABURp0rBkGtGfU=od2XeuhD6otUWUfL2ASqo1XBckra18WKy7w@mail.gmail.com>
> Git uses a DAG. The A stands for "acyclic". Loops are not allowed.
I'm aware of that. It's acyclic by design, but is this actually enforced
by the code? Or does it simply trust that no loops will ever occur,
because it's so improbable?
After Andrew's response I investigated a bit, and it seems I
overvalued the attempts to "break" SHA-1. Wikipedia quotes a 2008
attack, that can create a collision with 2^51 hash function calls.
Which, of course, is still way to much. Good for you! :-)
^ permalink raw reply
* [PATCH] git symbolic-ref: documentation fix
From: mhagger @ 2011-12-07 15:20 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Michael Haggerty
From: Michael Haggerty <mhagger@alum.mit.edu>
The old "git symbolic-ref" manpage seemed to imply in one place that
symlinks are still the default way to represent symbolic references
and in another that symlinks are deprecated. Fix the text and shorten
the justification for the change of implementation.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
Documentation/git-symbolic-ref.txt | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-symbolic-ref.txt b/Documentation/git-symbolic-ref.txt
index 75b1ae5..a45d4c4 100644
--- a/Documentation/git-symbolic-ref.txt
+++ b/Documentation/git-symbolic-ref.txt
@@ -43,12 +43,9 @@ In the past, `.git/HEAD` was a symbolic link pointing at
`refs/heads/master`. When we wanted to switch to another branch,
we did `ln -sf refs/heads/newbranch .git/HEAD`, and when we wanted
to find out which branch we are on, we did `readlink .git/HEAD`.
-This was fine, and internally that is what still happens by
-default, but on platforms that do not have working symlinks,
-or that do not have the `readlink(1)` command, this was a bit
-cumbersome. On some platforms, `ln -sf` does not even work as
-advertised (horrors). Therefore symbolic links are now deprecated
-and symbolic refs are used by default.
+But symbolic links are not entirely portable, so they are now
+deprecated and symbolic refs (as described above) are used by
+default.
'git symbolic-ref' will exit with status 0 if the contents of the
symbolic ref were printed correctly, with status 1 if the requested
--
1.7.8
^ permalink raw reply related
* Re: [PATCH] git-gui: Set both 16x16 and 32x32 icons on X to pacify Xming.
From: Pat Thoyts @ 2011-12-07 14:36 UTC (permalink / raw)
To: Samuel Bronson; +Cc: git, Shawn O. Pearce
In-Reply-To: <CAJYzjmcsGQ8xxmOEvDCZGyT5e=gKkjC7fDxdcbNg4FZRddERpw@mail.gmail.com>
Samuel Bronson <naesten@gmail.com> writes:
>
>Hmm. Nothing seems to have happened with this patch yet. Any
>suggestions on how to bring it to the attention of the git-gui people?
I got around to checking this with xmingw and it makes sense so it's
committed now.
Thanks.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: [RFC PATCH] git-p4: introduce asciidoc documentation
From: Pete Wyckoff @ 2011-12-07 15:36 UTC (permalink / raw)
To: Luke Diamand; +Cc: git
In-Reply-To: <4EDF3611.3000902@diamand.org>
luke@diamand.org wrote on Wed, 07 Dec 2011 09:46 +0000:
> On 03/12/11 23:53, Pete Wyckoff wrote:
> >Add proper documentation for git-p4. Delete the old .txt
> >documentation from contrib/fast-import.
> >---
> >+------------
> >+$ cd project
> >+$ vi foo.h
>
> I think it works with other editors as well, although I've not tried
> it myself. Obviously with reduced functionality :-)
Quite. :)
> >+git-p4.allowSubmit::
> >+ By default, any branch can be used as the source for a 'git p4
> >+ submit' operation. This configuration variable , if set, permits only
>
> Spacing around comma in "variable , if set"
Thanks, queued up.
I've got 8 more patches to the docs and code, adding unit tests
as I figure out quirks of all the existing options for
sync/clone. I'll continue with the submit options next then
send them all out for review.
-- Pete
^ permalink raw reply
* Re: Undo a commit that is already pushed to central server and merged to several branches
From: Matthias Fechner @ 2011-12-07 15:35 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git Mailing List
In-Reply-To: <CALkWK0k46HnWTHx3iYuWFUegTgZhAMShx9MT2E83QCmxrvZOxg@mail.gmail.com>
Am 07.12.11 15:42, schrieb Ramkumar Ramachandra:
> Assuming that you actually want to rewrite the history, the situation
> calls for a git-reset(1). Just "git reset --hard HEAD~1" on each of
> your branches (Caution: first understand what it does!) and you'll
that will not work, because in the master branch I already have around
15 commits after the bogus commit and I want to keep these commits.
And in some other branches there are tons of commits (over 100) after
the bogus commit with the merge and I only want to remove that bogus
commit but keep all other commits after the bogus commit (all commits
are not related to the bogus one, they are all in different files).
It is even fine if I could remove the bogus commit from all branches.
Bye
Matthias
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook
^ permalink raw reply
* Re: Query on git commit amend
From: Vijay Lakshminarayanan @ 2011-12-07 15:06 UTC (permalink / raw)
To: Viresh Kumar
Cc: Björn Steinbrink, Junio C Hamano, git@vger.kernel.org,
Shiraz HASHIM, Vipin KUMAR
In-Reply-To: <4EDEFD66.4020404@st.com>
Viresh Kumar <viresh.kumar@st.com> writes:
[snip]
> Now, whats the benefit of
>
> GIT_EDITOR=cat git commit --amend
>
> over
>
> git commit --amend -C HEAD
>
> ?
The latter preserves the original timestamp of the commit and other
environment variables like GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL
whereas GIT_EDITOR=cat (or true or :) are equivalent to opening up the
commit in an editor and so consider these variables during execution.
For instance, you could say
$ GIT_EDITOR=cat GIT_COMMITTER_EMAIL=foo@bar.baz git commit --amend
and the commiter email would be set to foo@bar.baz
--
Cheers
~vijay
Gnus should be more complicated.
^ permalink raw reply
* [PATCH 4/4] test: commit --amend should honor --no-edit
From: Jonathan Nieder @ 2011-12-07 14:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Vijay Lakshminarayanan, Viresh Kumar, Shiraz HASHIM
In-Reply-To: <20111207144217.GA30157@elie.hsd1.il.comcast.net>
A quick test to make sure git doesn't lose the functionality added by
the recent patch "commit: honor --no-edit", plus another test to check
the classical --edit use case (use with "-m").
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
t/t7501-commit.sh | 40 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index bf025df6..c462bf3b 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -94,6 +94,46 @@ test_expect_success 'amend commit' '
EDITOR=./editor git commit --amend
'
+test_expect_success 'set up editor' '
+ cat >editor <<-\EOF &&
+ #!/bin/sh
+ sed -e "s/unamended/amended/g" <"$1" >"$1-"
+ mv "$1-" "$1"
+ EOF
+ chmod 755 editor
+'
+
+test_expect_success 'amend without launching editor' '
+ echo unamended >expect &&
+ git commit --allow-empty -m "unamended" &&
+ echo needs more bongo >file &&
+ git add file &&
+ EDITOR=./editor git commit --no-edit --amend &&
+ git diff --exit-code HEAD -- file &&
+ git diff-tree -s --format=%s HEAD >msg &&
+ test_cmp expect msg
+'
+
+test_expect_success '--amend --edit' '
+ echo amended >expect &&
+ git commit --allow-empty -m "unamended" &&
+ echo bongo again >file &&
+ git add file &&
+ EDITOR=./editor git commit --edit --amend &&
+ git diff-tree -s --format=%s HEAD >msg &&
+ test_cmp expect msg
+'
+
+test_expect_success '-m --edit' '
+ echo amended >expect &&
+ git commit --allow-empty -m buffer &&
+ echo bongo bongo >file &&
+ git add file &&
+ EDITOR=./editor git commit -m unamended --edit &&
+ git diff-tree -s --format=%s HEAD >msg &&
+ test_cmp expect msg
+'
+
test_expect_success '-m and -F do not mix' '
echo enough with the bongos >file &&
test_must_fail git commit -F msg -m amending .
--
1.7.8.rc3
^ permalink raw reply related
* [PATCH 3/4] t7501 (commit): modernize style
From: Jonathan Nieder @ 2011-12-07 14:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Vijay Lakshminarayanan, Viresh Kumar, Shiraz HASHIM
In-Reply-To: <20111207144217.GA30157@elie.hsd1.il.comcast.net>
Put the opening quote starting each test on the same line as the
test_expect_* invocation. While at it:
- guard commands that prepare test input for individual tests in
the same test_expect_success, so their scope is clearer and
errors at that stage can be caught;
- use the compare_diff_patch helper function when comparing patches;
- use single-quotes in preference to double-quotes and <<\EOF in
preference to <<EOF, to save readers the trouble of looking for
variable interpolations;
- lift the setting of the $author variable used throughout the
test script to the top of the test script;
- include "setup" in the titles of test assertions that prepare for
later ones to make it more obvious which tests can be skipped;
- use test_must_fail instead of "if ...; then:; else false; fi",
for clarity and to catch segfaults when they happen;
- break up some pipelines into separate commands that read and write
to ordinary files, and test the exit status at each stage;
- chain commands with &&. Breaks in a test assertion's && chain can
potentially hide failures from earlier commands in the chain;
- combine two initial tests that do not make as much sense alone.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Miscellaneous cleanups.
t/t7501-commit.sh | 278 ++++++++++++++++++++++++++---------------------------
1 files changed, 136 insertions(+), 142 deletions(-)
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 9c507b08..bf025df6 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -8,39 +8,39 @@
test_description='git commit'
. ./test-lib.sh
+. "$TEST_DIRECTORY/diff-lib.sh"
+
+author='The Real Author <someguy@his.email.org>'
test_tick
-test_expect_success \
- "initial status" \
- "echo 'bongo bongo' >file &&
- git add file"
-
-test_expect_success "Constructing initial commit" '
+test_expect_success 'initial status' '
+ echo bongo bongo >file &&
+ git add file &&
git status >actual &&
test_i18ngrep "Initial commit" actual
'
-test_expect_success \
- "fail initial amend" \
- "test_must_fail git commit --amend"
+test_expect_success 'fail initial amend' '
+ test_must_fail git commit --amend
+'
-test_expect_success \
- "initial commit" \
- "git commit -m initial"
+test_expect_success 'setup: initial commit' '
+ git commit -m initial
+'
-test_expect_success \
- "invalid options 1" \
- "test_must_fail git commit -m foo -m bar -F file"
+test_expect_success '-m and -F do not mix' '
+ test_must_fail git commit -m foo -m bar -F file
+'
-test_expect_success \
- "invalid options 2" \
- "test_must_fail git commit -C HEAD -m illegal"
+test_expect_success '-m and -C do not mix' '
+ test_must_fail git commit -C HEAD -m illegal
+'
-test_expect_success \
- "using paths with -a" \
- "echo King of the bongo >file &&
- test_must_fail git commit -m foo -a file"
+test_expect_success 'paths and -a do not mix' '
+ echo King of the bongo >file &&
+ test_must_fail git commit -m foo -a file
+'
test_expect_success PERL 'can use paths with --interactive' '
echo bong-o-bong >file &&
@@ -50,120 +50,123 @@ test_expect_success PERL 'can use paths with --interactive' '
git reset --hard HEAD^
'
-test_expect_success \
- "using invalid commit with -C" \
- "test_must_fail git commit -C bogus"
-
-test_expect_success \
- "testing nothing to commit" \
- "test_must_fail git commit -m initial"
-
-test_expect_success \
- "next commit" \
- "echo 'bongo bongo bongo' >file && \
- git commit -m next -a"
-
-test_expect_success \
- "commit message from non-existing file" \
- "echo 'more bongo: bongo bongo bongo bongo' >file && \
- test_must_fail git commit -F gah -a"
-
-# Empty except stray tabs and spaces on a few lines.
-sed -e 's/@$//' >msg <<EOF
- @
-
- @
-Signed-off-by: hula
-EOF
-test_expect_success \
- "empty commit message" \
- "test_must_fail git commit -F msg -a"
-
-test_expect_success \
- "commit message from file" \
- "echo 'this is the commit message, coming from a file' >msg && \
- git commit -F msg -a"
-
-cat >editor <<\EOF
-#!/bin/sh
-sed -e "s/a file/an amend commit/g" < "$1" > "$1-"
-mv "$1-" "$1"
-EOF
-chmod 755 editor
-
-test_expect_success \
- "amend commit" \
- "EDITOR=./editor git commit --amend"
-
-test_expect_success \
- "passing -m and -F" \
- "echo 'enough with the bongos' >file && \
- test_must_fail git commit -F msg -m amending ."
-
-test_expect_success \
- "using message from other commit" \
- "git commit -C HEAD^ ."
-
-cat >editor <<\EOF
-#!/bin/sh
-sed -e "s/amend/older/g" < "$1" > "$1-"
-mv "$1-" "$1"
-EOF
-chmod 755 editor
-
-test_expect_success \
- "editing message from other commit" \
- "echo 'hula hula' >file && \
- EDITOR=./editor git commit -c HEAD^ -a"
-
-test_expect_success \
- "message from stdin" \
- "echo 'silly new contents' >file && \
- echo commit message from stdin | git commit -F - -a"
-
-test_expect_success \
- "overriding author from command line" \
- "echo 'gak' >file && \
- git commit -m 'author' --author 'Rubber Duck <rduck@convoy.org>' -a >output 2>&1"
-
-test_expect_success \
- "commit --author output mentions author" \
- "grep Rubber.Duck output"
-
-test_expect_success PERL \
- "interactive add" \
- "echo 7 | git commit --interactive | grep 'What now'"
-
-test_expect_success PERL \
- "commit --interactive doesn't change index if editor aborts" \
- "echo zoo >file &&
+test_expect_success 'using invalid commit with -C' '
+ test_must_fail git commit -C bogus
+'
+
+test_expect_success 'nothing to commit' '
+ test_must_fail git commit -m initial
+'
+
+test_expect_success 'setup: non-initial commit' '
+ echo bongo bongo bongo >file &&
+ git commit -m next -a
+'
+
+test_expect_success 'commit message from non-existing file' '
+ echo more bongo: bongo bongo bongo bongo >file &&
+ test_must_fail git commit -F gah -a
+'
+
+test_expect_success 'empty commit message' '
+ # Empty except stray tabs and spaces on a few lines.
+ sed -e "s/@//g" >msg <<-\EOF &&
+ @ @
+ @@
+ @ @
+ @Signed-off-by: hula@
+ EOF
+ test_must_fail git commit -F msg -a
+'
+
+test_expect_success 'setup: commit message from file' '
+ echo this is the commit message, coming from a file >msg &&
+ git commit -F msg -a
+'
+
+test_expect_success 'amend commit' '
+ cat >editor <<-\EOF &&
+ #!/bin/sh
+ sed -e "s/a file/an amend commit/g" < "$1" > "$1-"
+ mv "$1-" "$1"
+ EOF
+ chmod 755 editor &&
+ EDITOR=./editor git commit --amend
+'
+
+test_expect_success '-m and -F do not mix' '
+ echo enough with the bongos >file &&
+ test_must_fail git commit -F msg -m amending .
+'
+
+test_expect_success 'using message from other commit' '
+ git commit -C HEAD^ .
+'
+
+test_expect_success 'editing message from other commit' '
+ cat >editor <<-\EOF &&
+ #!/bin/sh
+ sed -e "s/amend/older/g" < "$1" > "$1-"
+ mv "$1-" "$1"
+ EOF
+ chmod 755 editor &&
+ echo hula hula >file &&
+ EDITOR=./editor git commit -c HEAD^ -a
+'
+
+test_expect_success 'message from stdin' '
+ echo silly new contents >file &&
+ echo commit message from stdin |
+ git commit -F - -a
+'
+
+test_expect_success 'overriding author from command line' '
+ echo gak >file &&
+ git commit -m author \
+ --author "Rubber Duck <rduck@convoy.org>" -a >output 2>&1 &&
+ grep Rubber.Duck output
+'
+
+test_expect_success PERL 'interactive add' '
+ echo 7 |
+ git commit --interactive |
+ grep "What now"
+'
+
+test_expect_success PERL "commit --interactive doesn't change index if editor aborts" '
+ echo zoo >file &&
test_must_fail git diff --exit-code >diff1 &&
- (echo u ; echo '*' ; echo q) |
- (EDITOR=: && export EDITOR &&
- test_must_fail git commit --interactive) &&
+ (echo u ; echo "*" ; echo q) |
+ (
+ EDITOR=: &&
+ export EDITOR &&
+ test_must_fail git commit --interactive
+ ) &&
git diff >diff2 &&
- test_cmp diff1 diff2"
+ compare_diff_patch diff1 diff2
+'
-cat >editor <<\EOF
-#!/bin/sh
-sed -e "s/good/bad/g" < "$1" > "$1-"
-mv "$1-" "$1"
-EOF
-chmod 755 editor
+test_expect_success 'editor not invoked if -F is given' '
+ cat >editor <<-\EOF &&
+ #!/bin/sh
+ sed -e s/good/bad/g <"$1" >"$1-"
+ mv "$1-" "$1"
+ EOF
+ chmod 755 editor &&
-cat >msg <<EOF
-A good commit message.
-EOF
+ echo A good commit message. >msg &&
+ echo moo >file &&
-test_expect_success \
- 'editor not invoked if -F is given' '
- echo "moo" >file &&
- EDITOR=./editor git commit -a -F msg &&
- git show -s --pretty=format:"%s" | grep -q good &&
- echo "quack" >file &&
- echo "Another good message." | EDITOR=./editor git commit -a -F - &&
- git show -s --pretty=format:"%s" | grep -q good
- '
+ EDITOR=./editor git commit -a -F msg &&
+ git show -s --pretty=format:%s >subject &&
+ grep -q good subject &&
+
+ echo quack >file &&
+ echo Another good message. |
+ EDITOR=./editor git commit -a -F - &&
+ git show -s --pretty=format:%s >subject &&
+ grep -q good subject
+'
test_expect_success 'partial commit that involves removal (1)' '
@@ -197,7 +200,6 @@ test_expect_success 'partial commit that involves removal (3)' '
'
-author="The Real Author <someguy@his.email.org>"
test_expect_success 'amend commit to fix author' '
oldtick=$GIT_AUTHOR_DATE &&
@@ -326,7 +328,6 @@ test_expect_success 'multiple -m' '
'
-author="The Real Author <someguy@his.email.org>"
test_expect_success 'amend commit to fix author' '
oldtick=$GIT_AUTHOR_DATE &&
@@ -353,15 +354,8 @@ test_expect_success 'git commit <file> with dirty index' '
test_expect_success 'same tree (single parent)' '
- git reset --hard
-
- if git commit -m empty
- then
- echo oops -- should have complained
- false
- else
- : happy
- fi
+ git reset --hard &&
+ test_must_fail git commit -m empty
'
--
1.7.8.rc3
^ permalink raw reply related
* [PATCH 2/4] test: remove a porcelain test that hard-codes commit names
From: Jonathan Nieder @ 2011-12-07 14:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Vijay Lakshminarayanan, Viresh Kumar, Shiraz HASHIM
In-Reply-To: <20111207144217.GA30157@elie.hsd1.il.comcast.net>
The rev-list output in this test depends on the details of test_tick's
dummy dates and the choice of hash function. Worse, it depends on the
order and nature of commits made in the earlier tests, so adding new
tests or rearranging existing ones breaks it.
It would be nice to check that "git commit" and commit-tree name
objects consistently and that commit objects' text is as documented,
but this particular test checks everything at once and hence is not a
robust test for that. Remove it.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Hence the odd hunk in the previous patch.
Maybe this doesn't belong in this series, but it's the kind of thing
that drives me batty when writing new tests.
t/t7501-commit.sh | 20 --------------------
1 files changed, 0 insertions(+), 20 deletions(-)
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index da75abc1..9c507b08 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -144,10 +144,6 @@ test_expect_success PERL \
git diff >diff2 &&
test_cmp diff1 diff2"
-test_expect_success \
- "showing committed revisions" \
- "git rev-list HEAD >current"
-
cat >editor <<\EOF
#!/bin/sh
sed -e "s/good/bad/g" < "$1" > "$1-"
@@ -168,22 +164,6 @@ test_expect_success \
echo "Another good message." | EDITOR=./editor git commit -a -F - &&
git show -s --pretty=format:"%s" | grep -q good
'
-# We could just check the head sha1, but checking each commit makes it
-# easier to isolate bugs.
-
-cat >expected <<\EOF
-285fcf7ec0d61b14249dfdb4c1e1fe03eaf15ee0
-0b8148b9afce917b87d71199b900466dc8ea8b6e
-43fb8826314939ce79a856face7953557fdca3d1
-eaa04bc3ae0f0b003f7f1d86bf869ec5d73eaf3e
-ee1963b250ee0f02a3fe37be0e4a02bb5af6a1ad
-b49f306003c627361a0304d151a6b4c8b26af6a1
-402702b49136e7587daa9280e91e4bb7cb2179f7
-EOF
-
-test_expect_success \
- 'validate git rev-list output.' \
- 'test_cmp expected current'
test_expect_success 'partial commit that involves removal (1)' '
--
1.7.8.rc3
^ permalink raw reply related
* [PATCH 1/4] test: add missing "&&" after echo command
From: Jonathan Nieder @ 2011-12-07 14:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Vijay Lakshminarayanan, Viresh Kumar, Shiraz HASHIM
In-Reply-To: <20111207144217.GA30157@elie.hsd1.il.comcast.net>
This test wants to modify a file and commit the change, but because of
a missing separator between commands it is parsed as a single "echo"
command.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
t/t7501-commit.sh | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 3ad04363..da75abc1 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -60,7 +60,7 @@ test_expect_success \
test_expect_success \
"next commit" \
- "echo 'bongo bongo bongo' >file \
+ "echo 'bongo bongo bongo' >file && \
git commit -m next -a"
test_expect_success \
@@ -172,11 +172,12 @@ test_expect_success \
# easier to isolate bugs.
cat >expected <<\EOF
-72c0dc9855b0c9dadcbfd5a31cab072e0cb774ca
-9b88fc14ce6b32e3d9ee021531a54f18a5cf38a2
-3536bbb352c3a1ef9a420f5b4242d48578b92aa7
-d381ac431806e53f3dd7ac2f1ae0534f36d738b9
-4fd44095ad6334f3ef72e4c5ec8ddf108174b54a
+285fcf7ec0d61b14249dfdb4c1e1fe03eaf15ee0
+0b8148b9afce917b87d71199b900466dc8ea8b6e
+43fb8826314939ce79a856face7953557fdca3d1
+eaa04bc3ae0f0b003f7f1d86bf869ec5d73eaf3e
+ee1963b250ee0f02a3fe37be0e4a02bb5af6a1ad
+b49f306003c627361a0304d151a6b4c8b26af6a1
402702b49136e7587daa9280e91e4bb7cb2179f7
EOF
--
1.7.8.rc3
^ 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