[PATCH] RelNotes: fsmonitor: add a pointer to man page and the word itself

[Yasushi SHOJI]

Add a pointer to git-update-index(1) and a bit more detail about
fsmonitor and watchman to help people following up the new feature.
---

Hi Ben and Junio,

Wouldn't it be nice to tell the world a bit more about "file system
monitor" we now support?  I think that "git status" and "watchman"
might not ring the bell for some, but adding a word "file system
monitor" may.

I know most of repos don't need fsmonitor but it's a cool feature to
have it. ;-)

WDYT?


 Documentation/RelNotes/2.16.0.txt | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/RelNotes/2.16.0.txt 
b/Documentation/RelNotes/2.16.0.txt
index 919f3eb3e..0c81c5915 100644
--- a/Documentation/RelNotes/2.16.0.txt
+++ b/Documentation/RelNotes/2.16.0.txt
@@ -62,8 +62,11 @@ UI, Workflows & Features
  * The SubmittingPatches document has been converted to produce an
HTML version via AsciiDoc/Asciidoctor.

- * We learned to talk to watchman to speed up "git status" and other
-   operations that need to see which paths have been modified.
+ * We learned to optionally talk to a file system monitor via new
+   fsmonitor extension to speed up "git status" and other operations
+   that need to see which paths have been modified.  Currently we only
+   support "watchman".  See File System Monitor section of
+   git-update-index(1) for more detail.

  * The "diff" family of commands learned to ignore differences in
carriage return at the end of line.
--
2.15.1

[PATCH] bisect: debug: convert struct object to object_id

[Yasushi SHOJI]

The commit f2fd0760f62e79609fef7bfd7ecebb002e8e4ced converted struct
object to object_id but a debug function show_list(), which is
ifdef'ed to noop, in bisect.c wasn't.

So fix it.

Signed-off-by: Yasushi SHOJI <yasushi.sh...@gmail.com>
---
 bisect.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bisect.c b/bisect.c
index 3756f127b..0dd0f289a 100644
--- a/bisect.c
+++ b/bisect.c
@@ -132,7 +132,7 @@ static void show_list(const char *debug, int counted, int 
nr,
unsigned flags = commit->object.flags;
enum object_type type;
unsigned long size;
-   char *buf = read_sha1_file(commit->object.sha1, , );
+   char *buf = read_sha1_file(commit->object.oid.hash, , 
);
const char *subject_start;
int subject_len;
 
@@ -144,10 +144,10 @@ static void show_list(const char *debug, int counted, int 
nr,
fprintf(stderr, "%3d", weight(p));
else
fprintf(stderr, "---");
-   fprintf(stderr, " %.*s", 8, sha1_to_hex(commit->object.sha1));
+   fprintf(stderr, " %.*s", 8, 
sha1_to_hex(commit->object.oid.hash));
for (pp = commit->parents; pp; pp = pp->next)
fprintf(stderr, " %.*s", 8,
-   sha1_to_hex(pp->item->object.sha1));
+   sha1_to_hex(pp->item->object.oid.hash));
 
subject_len = find_commit_subject(buf, _start);
if (subject_len)
-- 
2.15.1

Re: [BUG] v2.16.0-rc0 seg faults when git bisect skip

[Yasushi SHOJI]

Hi,

On Tue, Jan 9, 2018 at 12:09 AM, Christian Couder
 wrote:
> ... "i == cnt" is always false above. I think it should be "i == cnt - 1".

uga.  Thanks.  That's stupid of me.

> And with your code one can wonder why the cleanup is part of the loop.

OK.  I have nothing to offer, then.  Thank you for taking care of this!

>> I also found a bug in show_list().  I'm attaching a patch as well.
>
> Could you send it inline as explained in Documentation/SubmittingPatches?

Done that.

Thanks,
-- 
  yashi

Re: [BUG] v2.16.0-rc0 seg faults when git bisect skip

[Yasushi SHOJI]

Hi all,

Thank you guys for insightful help.  I just read the code and now I understand
what you guys are saying.  Yeah, I can say the fix is "spot on".

But, to be honest, it's hard to see why you need "if (p)" at  the first glance.
So, how about this fix, instead?

I also found a bug in show_list().  I'm attaching a patch as well.
-- 
   yashi
From d149a1348e94ea0246a10181751ce3bf9ba48198 Mon Sep 17 00:00:00 2001
From: Yasushi SHOJI <ya...@atmark-techno.com>
Date: Mon, 8 Jan 2018 22:31:10 +0900
Subject: [PATCH 1/2] bisect: debug: convert struct object to object_id

The commit f2fd0760f62e79609fef7bfd7ecebb002e8e4ced converted struct
object to object_id but a debug function show_list(), which is
ifdef'ed to noop, in bisect.c wasn't.

So fix it.
---
 bisect.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bisect.c b/bisect.c
index 0fca17c02..fb3e44903 100644
--- a/bisect.c
+++ b/bisect.c
@@ -132,7 +132,7 @@ static void show_list(const char *debug, int counted, int nr,
 		unsigned flags = commit->object.flags;
 		enum object_type type;
 		unsigned long size;
-		char *buf = read_sha1_file(commit->object.sha1, , );
+		char *buf = read_sha1_file(commit->object.oid.hash, , );
 		const char *subject_start;
 		int subject_len;
 
@@ -144,10 +144,10 @@ static void show_list(const char *debug, int counted, int nr,
 			fprintf(stderr, "%3d", weight(p));
 		else
 			fprintf(stderr, "---");
-		fprintf(stderr, " %.*s", 8, sha1_to_hex(commit->object.sha1));
+		fprintf(stderr, " %.*s", 8, sha1_to_hex(commit->object.oid.hash));
 		for (pp = commit->parents; pp; pp = pp->next)
 			fprintf(stderr, " %.*s", 8,
-sha1_to_hex(pp->item->object.sha1));
+sha1_to_hex(pp->item->object.oid.hash));
 
 		subject_len = find_commit_subject(buf, _start);
 		if (subject_len)
-- 
2.15.1

From 2ec8823de3bd0ca8253ddbd07f58b66afcfabe96 Mon Sep 17 00:00:00 2001
From: Yasushi SHOJI <ya...@atmark-techno.com>
Date: Mon, 8 Jan 2018 22:35:12 +0900
Subject: [PATCH 2/2] bisect: handle empty list in best_bisection_sorted()

In 7c117184d7 ("bisect: fix off-by-one error in
`best_bisection_sorted()`", 2017-11-05) the more careful logic dealing
with freeing p->next in 50e62a8e70 ("rev-list: implement
--bisect-all", 2007-10-22) was removed.

This function, and also all other functions below find_bisection() to
be complete, will be called with an empty commit list if all commits
are _uninteresting_.  So the functions must be prepared for it.

This commit, instead of restoring the check, moves the clean-up code
into the loop.  To do that this commit changes the non-last-case
branch in the loop to a last-case branch, and clean-up unused trailing
elements there.

We could, on the other hand, do a big "if list" condition at the very
beginning.  But, that doesn't sound right for the current code base.
No other functions does that but all blocks in the functions are
tolerant to an empty list.

By the way, as you can tell from the non-last-case branch we had in
the loop, this fix shouldn't cause a pipeline stall on every iteration
on modern processors with a branch predictor.

Signed-off-by: Yasushi ShOJI <yasushi.sh...@gmail.com>
---
 bisect.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/bisect.c b/bisect.c
index fb3e44903..cec4a537f 100644
--- a/bisect.c
+++ b/bisect.c
@@ -218,7 +218,7 @@ static struct commit_list *best_bisection_sorted(struct commit_list *list, int n
 		cnt++;
 	}
 	QSORT(array, cnt, compare_commit_dist);
-	for (p = list, i = 0; i < cnt; i++) {
+	for (p = list, i = 0; i < cnt; i++, p = p->next) {
 		struct object *obj = &(array[i].commit->object);
 
 		strbuf_reset();
@@ -226,11 +226,13 @@ static struct commit_list *best_bisection_sorted(struct commit_list *list, int n
 		add_name_decoration(DECORATION_NONE, buf.buf, obj);
 
 		p->item = array[i].commit;
-		if (i < cnt - 1)
-			p = p->next;
+
+		if (i == cnt) {
+			/* clean-up unused elements if any */
+			free_commit_list(p->next);
+			p->next = NULL;
+		}
 	}
-	free_commit_list(p->next);
-	p->next = NULL;
 	strbuf_release();
 	free(array);
 	return list;
-- 
2.15.1

Re: [BUG] v2.16.0-rc0 seg faults when git bisect skip

[Yasushi SHOJI]

Hi Martin,

Thank you for your comment.
I haven't have time to read the code carefully so bare with me.

On Sat, Jan 6, 2018 at 5:21 PM, Martin Ågren <martin.ag...@gmail.com> wrote:
>> On Fri, Jan 5, 2018 at 11:45 AM, Yasushi SHOJI <yasushi.sh...@gmail.com> 
>> wrote:
>>> When does the list allowed to contain NULLs?
>
> Short answer: there are no commits left to test.
>
> The list is built in the for-loop in `find_bisection()`. So the
> technical answer is: if all commits in the initial list `commit_list`
> are UNINTERESTING (including if `commit_list` is empty to begin with).
>
> It's also helpful to study where we should end up from there. We should
> take the `if (!revs.commits)` branch in `bisect_next_all()`. That is, we
> should print either "There are only 'skip'ped commits left to test. The
> first bad commit could be any of:" or " was both good and bad".

best_bisection_sorted() seems to do

 - get the commit list along with the number of elements in the list
 - walk the list one by one to check whether a element have TREESAME or not
 - if TREESAME, skip
 - if not, add it to array
 - sort the array by distance
 - put elements back to the list

so, if you find TREESAME, you get less elements than given, right?
Also, if you sort, the last commit, which has NULL in the ->next,
might get in the middle of the array??

# BTW, is it really fast to use QSORT even if you have to convert to
# an array from list?

>>> Since nobody noticed it since 7c117184d7, it must be a rare case, right?
>
> Right, you marked a commit both good and bad. That's probably not very
> common. But it obviously happens. :-)
>
> On 5 January 2018 at 06:28, Yasushi SHOJI <yasushi.sh...@gmail.com> wrote:
>> OK, here is the step to reproduce on git.git
>
> Thank you for providing a script for reproducing this. It helped me come
> up with the attached patch. The patch is based on ma/bisect-leakfix,
> which includes Ævar's patch.
>
> I think this patch could be useful, either as a final "let's test
> something previously non-tested; this would have caught the segfault",
> or simply squashed into Ævar's patch as a "let's add a test that would
> have caught this, and which also tests a previously non-tested code
> path."

Do we really need that?  What is a practical use of a commit having
both good and bad?

Regards,
-- 
yashi

Re: [BUG] v2.16.0-rc0 seg faults when git bisect skip

[Yasushi SHOJI]

Hi,

On Fri, Jan 5, 2018 at 11:45 AM, Yasushi SHOJI <yasushi.sh...@gmail.com> wrote:
> So that I can make a test case.

OK, here is the step to reproduce on git.git

$ git bisect start
$ git bisect bad v2.16.0-rc0
$ git bisect good 0433d533f13671f4313c31e34707f0f5281a18e0
$ git bisect good
$ git bisect bad
$ git bisect bad
$ git bisect skip #=> works with error
$ git bisect good #=> Segmentation fault
$ git bisect skip #=> Segmentation fault

The following is with full outputs, just in case you need it.

$ git describe
v2.16.0-rc0

$ git bisect start
$ git bisect bad v2.16.0-rc0

$ git bisect good 0433d533f13671f4313c31e34707f0f5281a18e0
Bisecting: 4 revisions left to test after this (roughly 2 steps)
[c87b653c46c4455561642b14efc8920a0b3e44b9] builtin/describe.c: rename
`oid` to avoid variable shadowing

$ git bisect good
Bisecting: 2 revisions left to test after this (roughly 1 step)
[4dbc59a4cce418ff8428a9d2ecd67c34ca50db56] builtin/describe.c: factor
out describe_commit

$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[cdaed0cf023a47cae327671fae11c10d88100ee7] builtin/describe.c: print
debug statements earlier

$ git bisect bad
cdaed0cf023a47cae327671fae11c10d88100ee7 is the first bad commit
commit cdaed0cf023a47cae327671fae11c10d88100ee7
Author: Stefan Beller <sbel...@google.com>
Date:   Wed Nov 15 18:00:37 2017 -0800

builtin/describe.c: print debug statements earlier

When debugging, print the received argument at the start of the
function instead of in the middle. This ensures that the received
argument is printed in all code paths, and also allows a subsequent
refactoring to not need to move the "arg" parameter.

Signed-off-by: Stefan Beller <sbel...@google.com>
Signed-off-by: Junio C Hamano <gits...@pobox.com>

:04 04 beb1f2c4d9ee7584e54e0489c7e85e348cbf9fc7
b9882eea0772e3025690d3513cea5a940567668e M builtin

$ git bisect skip
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
cdaed0cf023a47cae327671fae11c10d88100ee7
We cannot bisect more!

$ git bisect good
Segmentation fault

$ git bisect skip
Segmentation fault
-- 
   yashi

Re: [BUG] v2.16.0-rc0 seg faults when git bisect skip

[Yasushi SHOJI]

Hi,

On Thu, Jan 4, 2018 at 3:26 AM, Martin Ågren <martin.ag...@gmail.com> wrote:
> On 3 January 2018 at 15:21, Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote:
>>
>> On Wed, Jan 03 2018, Yasushi SHOJI jotted:
>>
>>> Hi,
>>>
>>> git version 2.16.0.rc0 seg faults on my machine when I
>>> [...]
>>> Program terminated with signal SIGSEGV, Segmentation fault.
>>> #0  0x55a73107f900 in best_bisection_sorted (list=0x0, nr=0) at 
>>> bisect.c:232
>>> 232 free_commit_list(p->next);
>>> (gdb) bt
>>> #0  0x55a73107f900 in best_bisection_sorted (list=0x0, nr=0) at 
>>> bisect.c:232
>>> #1  0x55a73107fc0f in do_find_bisection (list=0x0, nr=0,
>>> weights=0x55a731b6ffd0, find_all=1) at bisect.c:361
>>> #2  0x55a73107fcf4 in find_bisection (commit_list=0x7ffe8750d4d0,
>>> reaches=0x7ffe8750d4c4, all=0x7ffe8750d4c0, find_all=1) at
>>> bisect.c:400
>>> #3  0x55a73108128d in bisect_next_all (prefix=0x0, no_checkout=0)
>>> at bisect.c:969
>>> #4  0x55a730fd5238 in cmd_bisect__helper (argc=0,
>>> argv=0x7ffe8750e230, prefix=0x0) at builtin/bisect--helper.c:140
>>> #5  0x55a730fcbc76 in run_builtin (p=0x55a73145c778
>>> <commands+120>, argc=2, argv=0x7ffe8750e230) at git.c:346
>>> #6  0x55a730fcbf40 in handle_builtin (argc=2, argv=0x7ffe8750e230)
>>> at git.c:554
>>> #7  0x55a730fcc0e8 in run_argv (argcp=0x7ffe8750e0ec,
>>> argv=0x7ffe8750e0e0) at git.c:606
>>> #8  0x55a730fcc29b in cmd_main (argc=2, argv=0x7ffe8750e230) at 
>>> git.c:683
>>> #9  0x55a731068d9e in main (argc=3, argv=0x7ffe8750e228) at 
>>> common-main.c:43
>>> (gdb) p p
>>> $1 = (struct commit_list *) 0x0
>>>
>>> As you can see, the code dereferences to the 'next' while 'p' is NULL.
>>>
>>> I'm sure I did 'git bisect good' after git _found_ bad commit.  Then I
>>> typed 'git bisect skip' on the commit 726804874 of guile repository.
>>> If that matters at all.
>>>
>>> I haven't touched guile repo to preserve the current state.
>>
>> I can't reproduce this myself, but looking at the backtrace it seems
>> pretty obvious that 7c117184d7 ("bisect: fix off-by-one error in
>> `best_bisection_sorted()`", 2017-11-05) is the culprit.
>>
>> That changed more careful code added by Christian in 50e62a8e70
>> ("rev-list: implement --bisect-all", 2007-10-22) to free a pointer which
>> as you can see can be NULL.
>>
>> If you can test a patch to see if it works this should fix it:
>>
>> diff --git a/bisect.c b/bisect.c
>> index 0fca17c02b..2f3008b078 100644
>> --- a/bisect.c
>> +++ b/bisect.c
>> @@ -229,8 +229,10 @@ static struct commit_list *best_bisection_sorted(struct 
>> commit_list *list, int n
>> if (i < cnt - 1)
>> p = p->next;
>> }
>> -   free_commit_list(p->next);
>> -   p->next = NULL;
>> +   if (p) {
>> +   free_commit_list(p->next);
>> +   p->next = NULL;
>> +   }
>> strbuf_release();
>> free(array);
>> return list;
>>
>> But given the commit message by Martin maybe there's some deeper bug here.
>
> I haven't tried to reproduce, or tested the patch, but from the looks of
> it, your analysis and fix are both spot on. The special case that yashi
> has hit is that `list` is NULL. The old code handled that very well, the
> code after my patch ... not so well. The loop-sort-loop pattern reduces
> to a no-op, both before and after my patch. But what I failed to realize
> was that `list` could be NULL.

The patch (actually, I've tested the one in pu, 2e9fdc795cb27) avoids
the seg fault for sure, but the question is:

When does the list allowed to contain NULLs?

Since nobody noticed it since 7c117184d7, it must be a rare case, right?

Would you guys elaborate a bit?  I don't have any insight how
best_bisection_sorted() should work and what the list should contain.
So that I can make a test case.

Thanks,
-- 
   yashi

[BUG] v2.16.0-rc0 seg faults when git bisect skip

[Yasushi SHOJI]

Hi,

git version 2.16.0.rc0 seg faults on my machine when I

git bisect skip

Here is a back trace:

$ /opt/mygit/bin/git --version
git version 2.16.0.rc0

$ /opt/mygit/bin/git bisect skip
Segmentation fault (core dumped)

$ gdb /opt/mygit/bin/git core
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /opt/mygit/bin/git...done.
[New LWP 5211]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `git bisect--helper --next-all'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x55a73107f900 in best_bisection_sorted (list=0x0, nr=0) at bisect.c:232
232 free_commit_list(p->next);
(gdb) bt
#0  0x55a73107f900 in best_bisection_sorted (list=0x0, nr=0) at bisect.c:232
#1  0x55a73107fc0f in do_find_bisection (list=0x0, nr=0,
weights=0x55a731b6ffd0, find_all=1) at bisect.c:361
#2  0x55a73107fcf4 in find_bisection (commit_list=0x7ffe8750d4d0,
reaches=0x7ffe8750d4c4, all=0x7ffe8750d4c0, find_all=1) at
bisect.c:400
#3  0x55a73108128d in bisect_next_all (prefix=0x0, no_checkout=0)
at bisect.c:969
#4  0x55a730fd5238 in cmd_bisect__helper (argc=0,
argv=0x7ffe8750e230, prefix=0x0) at builtin/bisect--helper.c:140
#5  0x55a730fcbc76 in run_builtin (p=0x55a73145c778
, argc=2, argv=0x7ffe8750e230) at git.c:346
#6  0x55a730fcbf40 in handle_builtin (argc=2, argv=0x7ffe8750e230)
at git.c:554
#7  0x55a730fcc0e8 in run_argv (argcp=0x7ffe8750e0ec,
argv=0x7ffe8750e0e0) at git.c:606
#8  0x55a730fcc29b in cmd_main (argc=2, argv=0x7ffe8750e230) at git.c:683
#9  0x55a731068d9e in main (argc=3, argv=0x7ffe8750e228) at common-main.c:43
(gdb) p p
$1 = (struct commit_list *) 0x0

As you can see, the code dereferences to the 'next' while 'p' is NULL.

I'm sure I did 'git bisect good' after git _found_ bad commit.  Then I
typed 'git bisect skip' on the commit 726804874 of guile repository.
If that matters at all.

I haven't touched guile repo to preserve the current state.

Let me know if you need any other info.
-- 
  yashi

Re: [PATCH] Introduce reset type flag to git reset

[Yasushi SHOJI]

At Tue, 23 Aug 2005 15:08:44 -0700,
Junio C Hamano wrote:
 
 Sam Ravnborg [EMAIL PROTECTED] writes:
 
  But --soft, --hard looks rather confusing to me.
 
  Something like --force or --prune may be a bit more intuitive, and let
  default behaviour be the one you name --soft for now.
 
 I do not have objections to removing --mixed, but I do not find
 --force/--prune any less confusing than --soft/--hard.  Its just
 a terminology so once people get used to it anything would do.
 But I agree that we need to come up with a good name for them.
 I do not think --force/--prune is it, though.

I think the point is what is the target?.

I believe git reset is targeting at the index file and only the
index file and nothing more. it's that simple.

what we want instead is a command to sync/reset/revert both index and
tree to know working point.  so this isn't core plumbing but as a user
of git, i'm sure it's very handy to have it.

--soft one is simple to think, so i'm starting with this one. let's
assume that, as you described in the original post, this one is
intended to be used to rework on the work _you_ have before.  that
means that _you_ know exactly what you are doing.

there might be a case, and this happned to me quite some time when I
was working with quilt, which you don't want to automatically add all
the files you added on the privious commit. ie. moving defines from
header to .c, splitting a work to two commits.

so in this case, it's ideal to just use git reset if the command
lists files removed from the index.

for --hard option, what you want to do is to completely revert the
current state of your index file and work tree to known point.

for that, how about git-revert-script?  can we add --force option to
that command so that even if your working tree is dirty it reverts to
the specified point?
--
  yashi
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch] possible memory leak in diff.c::diff_free_filepair()

[Yasushi SHOJI]

At Mon, 15 Aug 2005 21:32:12 -0700,
Junio C Hamano wrote:
 
 Yasushi SHOJI [EMAIL PROTECTED] writes:
 
  parepare_temp_file() and diff_populate_filespec() has a lot in
  similarity. so it'd be nice to refactor some. and re-introduce
  diff_free_filespec_data() and call right after prep_temp_blob() in
  prepare_temp_file().
 
 Another thing that may (or may not) help would be to move that
 prepare_temp_file() and stuff to happen in the forked child
 process instead of the parent, so that we do not have to worry
 about freeing the buffer; it has been some time since I worked
 on that part of the code so this may not be an option to make
 things easier.

well, I couldn't figure out how to do it in child.  because the parent
need to know temp files in order to delete after child used it.

anyway, here is a patch to fix the problem in the simplest way.

regards,
--
  yashi

---
Make diff_flush a bit more system friendly.

This seems to be the simplest way to fix the peak time
high memory usage in diff_flush.  Don't wait all iteration
to free each filepair.

Signed-off-by: Yasushi SHOJI [EMAIL PROTECTED]


---

 diff.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

e0f7f97ddc29a9172c2f6c1221eca936aa80835c
diff --git a/diff.c b/diff.c
--- a/diff.c
+++ b/diff.c
@@ -1010,9 +1010,8 @@ void diff_flush(int diff_output_style, i
diff_flush_name(p, line_termination);
break;
}
-   }
-   for (i = 0; i  q-nr; i++)
diff_free_filepair(q-queue[i]);
+   }
free(q-queue);
q-queue = NULL;
q-nr = q-alloc = 0;
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] gitweb - Use description instead of content:encoded.

[Yasushi SHOJI]

Use description instead of content:encoded.

RSS 2.0 Specification doesn't have content:encoded.
see http://blogs.law.harvard.edu/tech/rss

I've tested this with Mozilla Thunderbird version 1.0.6 (20050802),
and seems to be working well.

Signed-off-by: Yasushi SHOJI [EMAIL PROTECTED]
---

 gitweb.cgi |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

8a489f354a5412e44ddaf7443aaecb47a81167f8
diff --git a/gitweb.cgi b/gitweb.cgi
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -1426,8 +1426,7 @@ sub git_rss {
  /title\n .
  pubDate$cd{'rfc2822'}/pubDate\n .
  link . 
escapeHTML($my_url?p=$project;a=commit;h=$commit) . /link\n .
- description . escapeHTML($co{'title'}) . 
/description\n .
- content:encoded .
+ description .
  ![CDATA[\n;
my $comment = $co{'comment'};
foreach my $line (@$comment) {
@@ -1442,7 +1441,7 @@ sub git_rss {
print $filebr/\n;
}
print ]]\n .
- /content:encoded\n .
+ /description\n .
  /item\n;
}
print /channel/rss;
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] gitweb - Add author and guid.

[Yasushi SHOJI]

Hi all,

with this patch and the privious one I just sent, you can run a pretty
neat blog site with rss feed for geeks ;)

one missing feature is the picture tag Junio asked a while ago ;P

 yashi

Add author and guid.

From http://blogs.law.harvard.edu/tech/rss
  author - Email address of the author of the item.
  guid   - A string that uniquely identifies the item.

Signed-off-by: Yasushi SHOJI [EMAIL PROTECTED]
---

 gitweb.cgi |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

0a477312bf2975cf3240d3cf107ff7ac2e32049a
diff --git a/gitweb.cgi b/gitweb.cgi
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -1424,7 +1424,9 @@ sub git_rss {
  title .
  sprintf(%d %s %02d:%02d, $cd{'mday'}, $cd{'month'}, 
$cd{'hour'}, $cd{'minute'}) .  -  . escapeHTML($co{'title'}) .
  /title\n .
+ author . escapeHTML($co{'author'}) . /author\n .
  pubDate$cd{'rfc2822'}/pubDate\n .
+ guid isPermaLink=\true\ . 
escapeHTML($my_url?p=$project;a=commit;h=$commit) . /guid\n .
  link . 
escapeHTML($my_url?p=$project;a=commit;h=$commit) . /link\n .
  description .
  ![CDATA[\n;
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitweb - Use description instead of content:encoded.

[Yasushi SHOJI]

At Thu, 18 Aug 2005 18:01:09 +0200,
Kay Sievers wrote:
 
 On Thu, Aug 18, 2005 at 11:30:41PM +0900, Yasushi SHOJI wrote:
  Use description instead of content:encoded.
  
  RSS 2.0 Specification doesn't have content:encoded.
  see http://blogs.law.harvard.edu/tech/rss
 
 See here:
   http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ
 
   The description element is designed to contain plain text ONLY. When
   the content of your items contains anything other than plain text i.e.
   HTML or XHTML the content:encoded element should be used.
 
 Hmm, there was a request to change it to encoded and the mentioned page
 sounded reasonable to me. I will happily change it to the correct
 format, if you provide _authoritative_ information that we can trust.

hmm... I'm not an rss guy.  so not sure for anything.

at least, the link you gave me points to the rss 2.0 spec site I put
in the log as RSS v2.0.  that can be seen as more trust'able

also, in the rss 2.0 spec site, you can find 2.0 sample under Sapmple
files, which contain _escaped tag_ in description.

that's all I can say :  can any one help?

 It works in XY-reader does not count. :)

agreed.
--
 yashi
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gitweb - Use description instead of content:encoded.

[Yasushi SHOJI]

At Thu, 18 Aug 2005 17:36:07 +0200,
Sven Verdoolaege wrote:
 
 On Thu, Aug 18, 2005 at 11:30:41PM +0900, Yasushi SHOJI wrote:
  Use description instead of content:encoded.
  
 
 Hmm in snownews this gets displayed as Use  instead of ..
 (http://www.liacs.nl/~sverdool/gitweb.cgi?p=gitweb.git;a=rss)
 
 Is that a problem with snownews or with gitweb ?

we are not sure.  As Kay said, we need to find out _authoritative_
information for this.

regards,
--
yashi
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] Add support for figuring out where in the git archive we are

[Yasushi SHOJI]

At Tue, 16 Aug 2005 15:45:35 -0700 (PDT),
Linus Torvalds wrote:
 
 This is really partly a serious patch, but also just a query whether 
 people would want git to work in subdirectories, not just the top-level 
 directory.
 
 So you can be in linux/drivers, and if you do a
 
   git-diff-files -p char
 
 then it will automatically be turned into the full pathname, and do the
 right thing (ie do a diff of drivers/char only).

I've had missed this feature a lot, since quilt has been working this
way.  now I can close just-for-git terminal.(tm)

regards,
--
  yashi
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitweb - option to disable rename detection

[Yasushi SHOJI]

At Mon, 15 Aug 2005 15:43:26 -0700 (PDT),
Linus Torvalds wrote:
 
 On Tue, 16 Aug 2005, Yasushi SHOJI wrote:
 
   Instead of disabling it entirely, how about just having some limit on it?
  
  ah, that's a good idea.  here is a quick and dirty patch.
 
 This makes it somewhat more expensive.

yes.  but much cheaper than OOM ;P

- I was thinking about disabling it 
 in git-diff-tree, since the rename logic already knows how many 
 new/deleted files there are.

I'll leave this feature for homework.  I'll work on
prepare_temp_file() first since it seems to fix my problem.

regards,
--
 yashi

-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch] possible memory leak in diff.c::diff_free_filepair()

[Yasushi SHOJI]

Hi all,

When I run git-diff-tree on big change, it seems the command eats so
much memory.  so I just put git under valgrind to see what's going on.

here is the output:

==26475== 63816 bytes in 766 blocks are definitely lost in loss record 7 of 7
==26475==at 0x1B8FF896: malloc (vg_replace_malloc.c:149)
==26475==by 0x805203B: alloc_filespec (diff.c:214)
==26475==by 0x80528C5: diff_addremove (diff.c:1141)
==26475==by 0x8049C7A: show_file (diff-tree.c:97)
==26475==by 0x8049D63: show_file (diff-tree.c:206)
==26475==by 0x8049D63: show_file (diff-tree.c:206)
==26475==by 0x8049D63: show_file (diff-tree.c:206)
==26475==by 0x8049EB3: diff_tree (diff-tree.c:118)
==26475==by 0x804A12E: diff_tree_sha1 (diff-tree.c:260)
==26475==by 0x804A06E: diff_tree (diff-tree.c:139)
==26475==by 0x804A12E: diff_tree_sha1 (diff-tree.c:260)
==26475==by 0x804A06E: diff_tree (diff-tree.c:139)
==26475== 
==26475== LEAK SUMMARY:
==26475==definitely lost: 63816 bytes in 766 blocks.
==26475==  possibly lost: 0 bytes in 0 blocks.
==26475==still reachable: 351 bytes in 6 blocks.
==26475== suppressed: 0 bytes in 0 blocks.

diff_free_filespec_data() doesn't free diff_filespec itself.  is this
because in merge_broken() filespec itself is used but fliespec data
need to be freed?

so I've put one more function, diff_free_filespec(), between
diff_free_filepare() and diff_free_filespec_data() call-chain.

result is:

==27983== LEAK SUMMARY:
==27983==definitely lost: 0 bytes in 0 blocks.
==27983==  possibly lost: 0 bytes in 0 blocks.
==27983==still reachable: 276 bytes in 6 blocks.
==27983== suppressed: 0 bytes in 0 blocks.

Signed-off-by: Yasushi SHOJI [EMAIL PROTECTED]

---
diff --git a/diff.c b/diff.c
--- a/diff.c
+++ b/diff.c
@@ -767,10 +767,16 @@ struct diff_filepair *diff_queue(struct 
return dp;
 }
 
+void diff_free_filespec(struct diff_filespec *s)
+{
+   diff_free_filespec_data(s);
+free(s);
+}
+
 void diff_free_filepair(struct diff_filepair *p)
 {
-   diff_free_filespec_data(p-one);
-   diff_free_filespec_data(p-two);
+   diff_free_filespec(p-one);
+   diff_free_filespec(p-two);
free(p);
 }
 
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch] possible memory leak in diff.c::diff_free_filepair()

[Yasushi SHOJI]

At Sat, 13 Aug 2005 12:30:59 -0700,
Junio C Hamano wrote:
 
 Yasushi SHOJI [EMAIL PROTECTED] writes:
 
  When I run git-diff-tree on big change, it seems the command eats so
  much memory.  so I just put git under valgrind to see what's going on.
 
  diff_free_filespec_data() doesn't free diff_filespec itself.  is this
  because in merge_broken() filespec itself is used but fliespec data
  need to be freed?
 
 Thanks for the patch.  I am wondering if the same leak exists in
 diff_free_filepair(), which frees the filespec data without
 freeing filespec itself for both sides.  If this is something
 you can trap easily with valgrind I would really appreciate it.

oops.  probably my english wasn't clear. my patch fixes
diff_free_filepair().

the reason I asked about merge_broken() was that those two functions
are the only functions calling diff_free_filespec_data(). it's first
time reading git source code and still learning ;)
--
  yashi
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html