* Re: Gitk strangeness..
From: Paul Mackerras @ 2006-03-28 2:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0603271802030.15714@g5.osdl.org>
Linus Torvalds writes:
> Paul, do this on the current git tree:
>
> gitk b0a3de42..dff86e28
>
> and tell me it doesn't look horrid.
Wow! That's spectacular! :)
> Maybe it's not a new thing, and it's just that the recent pattern of
> merges in the git tree makes any version of gitk do horrible things.
A large part of it is that I took out the stuff where gitk used to
reorder the commits it got from git-rev-list. One of the side-effects
of doing the reordering was that for commits which aren't listed in
the git-rev-list output (i.e. which are drawn with open circles), gitk
was able to draw them immediately after their last child. Now gitk
doesn't discover that they aren't listed until it has drawn all the
commits that are listed, which means we can get a whole pile of
open-circle commits at the bottom of the graph.
I think the best thing to do is to change git-rev-list. One
possibility would be to add an option to make git-rev-list omit
parents that are not in the requested set, which would mean that gitk
would not draw the open-circle commits any more.
The other option would be to make git-rev-list list the open-circle
commits explicitly, with an indication that they are not in the
requested set but are parents of commits in the requested set.
Or I can put the logic back into gitk. I'd rather do it in
git-rev-list though since it will be faster that way.
Do you think that having the open-circle commits in the graph is
useful?
Paul.
^ permalink raw reply
* [PATCH] xdiff: Show function names in hunk headers.
From: Mark Wooding @ 2006-03-28 2:23 UTC (permalink / raw)
To: git; +Cc: Mark Wooding
The speed of the built-in diff generator is nice; but the function names
shown by `diff -p' are /really/ nice. And I hate having to choose. So,
we hack xdiff to find the function names and print them.
xdiff has grown a flag to say whether to dig up the function names. The
builtin_diff function passes this flag unconditionally. I suppose it
could parse GIT_DIFF_OPTS, but it doesn't at the moment. I've also
reintroduced the `function name' into the test suite, from which it was
removed in commit 3ce8f089.
The function names are parsed by a particularly stupid algorithm at the
moment: it just tries to find a line in the `old' file, from before the
start of the hunk, whose first character looks plausible. Still, it's
most definitely a start.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
diff.c | 1 +
t/t4001-diff-rename.sh | 2 +-
xdiff/xdiff.h | 3 +++
xdiff/xemit.c | 41 ++++++++++++++++++++++++++++++++++++++++-
xdiff/xinclude.h | 1 +
xdiff/xutils.c | 15 ++++++++++++---
xdiff/xutils.h | 3 ++-
7 files changed, 60 insertions(+), 6 deletions(-)
746418a20769c003886d7f4bbec6563af7aabd4b
diff --git a/diff.c b/diff.c
index 5eae094..8b37477 100644
--- a/diff.c
+++ b/diff.c
@@ -267,6 +267,7 @@ static void builtin_diff(const char *nam
ecbdata.label_path = lbl;
xpp.flags = XDF_NEED_MINIMAL;
xecfg.ctxlen = 3;
+ xecfg.flags = XDL_EMIT_FUNCNAMES;
if (!diffopts)
;
else if (!strncmp(diffopts, "--unified=", 10))
diff --git a/t/t4001-diff-rename.sh b/t/t4001-diff-rename.sh
index 08c1131..2e3c20d 100755
--- a/t/t4001-diff-rename.sh
+++ b/t/t4001-diff-rename.sh
@@ -49,7 +49,7 @@ rename from path0
rename to path1
--- a/path0
+++ b/path1
-@@ -8,7 +8,7 @@
+@@ -8,7 +8,7 @@ Line 7
Line 8
Line 9
Line 10
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index 71cb939..2540e8a 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -35,6 +35,8 @@ #define XDL_PATCH_REVERSE '+'
#define XDL_PATCH_MODEMASK ((1 << 8) - 1)
#define XDL_PATCH_IGNOREBSPACE (1 << 8)
+#define XDL_EMIT_FUNCNAMES (1 << 0)
+
#define XDL_MMB_READONLY (1 << 0)
#define XDL_MMF_ATOMIC (1 << 0)
@@ -65,6 +67,7 @@ typedef struct s_xdemitcb {
typedef struct s_xdemitconf {
long ctxlen;
+ unsigned long flags;
} xdemitconf_t;
typedef struct s_bdiffparam {
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 2e5d54c..ad5bfb1 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -69,10 +69,43 @@ static xdchange_t *xdl_get_hunk(xdchange
}
+static void xdl_find_func(xdfile_t *xf, long i, char *buf, long sz, long *ll) {
+
+ /*
+ * Be quite stupid about this for now. Find a line in the old file
+ * before the start of the hunk (and context) which starts with a
+ * plausible character.
+ */
+
+ const char *rec;
+ long len;
+
+ *ll = 0;
+ while (i-- > 0) {
+ len = xdl_get_rec(xf, i, &rec);
+ if (len > 0 &&
+ (isalpha((unsigned char)*rec) || /* identifier? */
+ *rec == '_' || /* also identifier? */
+ *rec == '(' || /* lisp defun? */
+ *rec == '#')) { /* #define? */
+ if (len > sz)
+ len = sz;
+ if (len && rec[len - 1] == '\n')
+ len--;
+ memcpy(buf, rec, len);
+ *ll = len;
+ return;
+ }
+ }
+}
+
+
int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
xdemitconf_t const *xecfg) {
long s1, s2, e1, e2, lctx;
xdchange_t *xch, *xche;
+ char funcbuf[40];
+ long funclen = 0;
for (xch = xche = xscr; xch; xch = xche->next) {
xche = xdl_get_hunk(xch, xecfg);
@@ -90,7 +123,13 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange
/*
* Emit current hunk header.
*/
- if (xdl_emit_hunk_hdr(s1 + 1, e1 - s1, s2 + 1, e2 - s2, ecb) < 0)
+
+ if (xecfg->flags & XDL_EMIT_FUNCNAMES) {
+ xdl_find_func(&xe->xdf1, s1, funcbuf,
+ sizeof(funcbuf), &funclen);
+ }
+ if (xdl_emit_hunk_hdr(s1 + 1, e1 - s1, s2 + 1, e2 - s2,
+ funcbuf, funclen, ecb) < 0)
return -1;
/*
diff --git a/xdiff/xinclude.h b/xdiff/xinclude.h
index 9490fc5..04a9da8 100644
--- a/xdiff/xinclude.h
+++ b/xdiff/xinclude.h
@@ -23,6 +23,7 @@
#if !defined(XINCLUDE_H)
#define XINCLUDE_H
+#include <ctype.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index 8221806..afaada1 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -235,7 +235,8 @@ long xdl_atol(char const *str, char cons
}
-int xdl_emit_hunk_hdr(long s1, long c1, long s2, long c2, xdemitcb_t *ecb) {
+int xdl_emit_hunk_hdr(long s1, long c1, long s2, long c2,
+ const char *func, long funclen, xdemitcb_t *ecb) {
int nb = 0;
mmbuffer_t mb;
char buf[128];
@@ -264,8 +265,16 @@ int xdl_emit_hunk_hdr(long s1, long c1,
nb += xdl_num_out(buf + nb, c2);
}
- memcpy(buf + nb, " @@\n", 4);
- nb += 4;
+ memcpy(buf + nb, " @@", 3);
+ nb += 3;
+ if (func && funclen) {
+ buf[nb++] = ' ';
+ if (funclen > sizeof(buf) - nb - 1)
+ funclen = sizeof(buf) - nb - 1;
+ memcpy(buf + nb, func, funclen);
+ nb += funclen;
+ }
+ buf[nb++] = '\n';
mb.ptr = buf;
mb.size = nb;
diff --git a/xdiff/xutils.h b/xdiff/xutils.h
index 428a4bb..55b0d39 100644
--- a/xdiff/xutils.h
+++ b/xdiff/xutils.h
@@ -36,7 +36,8 @@ unsigned long xdl_hash_record(char const
unsigned int xdl_hashbits(unsigned int size);
int xdl_num_out(char *out, long val);
long xdl_atol(char const *str, char const **next);
-int xdl_emit_hunk_hdr(long s1, long c1, long s2, long c2, xdemitcb_t *ecb);
+int xdl_emit_hunk_hdr(long s1, long c1, long s2, long c2,
+ const char *func, long funclen, xdemitcb_t *ecb);
--
1.3.0.rc1.g7464
^ permalink raw reply related
* Re: Gitk strangeness..
From: Junio C Hamano @ 2006-03-28 2:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603271802030.15714@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Maybe it's not a new thing, and it's just that the recent pattern of
> merges in the git tree makes any version of gitk do horrible things.
It is both, but new gitk plays a major part of it.
There are too wide horizontal lines when many merges are
involved. My "next" branch from yesterday (which is essentially
what my "master" branch today) was somewhat more pleasant to
read with older gitk, but only somewhat.
^ permalink raw reply
* Gitk strangeness..
From: Linus Torvalds @ 2006-03-28 2:05 UTC (permalink / raw)
To: Junio C Hamano, Paul Mackerras; +Cc: Git Mailing List
In-Reply-To: <7v64lzo1j7.fsf@assigned-by-dhcp.cox.net>
On Mon, 27 Mar 2006, Junio C Hamano wrote:
>
> GIT 1.3.0-rc1 is pushed out and will be mirrored out soon.
I did
gitk ORIG_HEAD..
with this, and the end result looks horrible. I think it's the new gitk
that does it.
Paul, do this on the current git tree:
gitk b0a3de42..dff86e28
and tell me it doesn't look horrid.
Maybe it's not a new thing, and it's just that the recent pattern of
merges in the git tree makes any version of gitk do horrible things.
Linus
^ permalink raw reply
* Re: [PATCH] Add ALL_LDFLAGS to the git target.
From: Junio C Hamano @ 2006-03-28 1:25 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <13226.1143508524@lotus.CS.Berkeley.EDU>
Jason Riedy <ejr@EECS.Berkeley.EDU> writes:
> For some reason, I need ALL_LDFLAGS in the git target only on
> AIX.
I wonder what the dependency is, since ALL_LDFLAGS is not
modified on AIX, but you are right. That is the only binary
that does not link with ALL_LDFLAGS which can include whatever
user passes via LDFLAGS.
> Once it builds, only one test "fails" on AIX 5.1 with
> 1.3.0.rc1, t5500-fetch-pack.sh, but it looks like it's some
> odd tool problem in the tester + my setup and not a real bug.
Curious and would appreciate more details.
^ permalink raw reply
* [PATCH] Add ALL_LDFLAGS to the git target.
From: Jason Riedy @ 2006-03-28 1:15 UTC (permalink / raw)
To: git
In-Reply-To: <7v64lzo1j7.fsf@assigned-by-dhcp.cox.net>
For some reason, I need ALL_LDFLAGS in the git target only on
AIX. Once it builds, only one test "fails" on AIX 5.1 with
1.3.0.rc1, t5500-fetch-pack.sh, but it looks like it's some
odd tool problem in the tester + my setup and not a real bug.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
diff --git a/Makefile b/Makefile
index 4edb383..d945546 100644
--- a/Makefile
+++ b/Makefile
@@ -455,7 +455,8 @@ strip: $(PROGRAMS) git$X
git$X: git.c common-cmds.h $(LIB_FILE)
$(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
- $(ALL_CFLAGS) -o $@ $(filter %.c,$^) $(LIB_FILE) $(LIBS)
+ $(ALL_CFLAGS) -o $@ $(filter %.c,$^) $(LIB_FILE) \
+ $(ALL_LDFLAGS) $(LIBS)
common-cmds.h: Documentation/git-*.txt
./generate-cmdlist.sh > $@
^ permalink raw reply related
* What's in git.git
From: Junio C Hamano @ 2006-03-28 0:28 UTC (permalink / raw)
To: git
GIT 1.3.0-rc1 is pushed out and will be mirrored out soon.
All of the things that were not in the "master" branch were
either cooked long enough in "next" without causing problems
(e.g. insanely fast rename detector or true built-in diff) or
isolated in a specific subsystem (e.g. tar-tree and svnimport).
So I am clearing the deck to prepare for a 1.3.0. Remaining
wrinkles, if any, will be ironed out in the "master" branch.
------------
Changes since the last announcement:
- updates around git-clone:
. --use-separate-remote
. --reference <repo>
. fetch,parse-remote,fmt-merge-msg: refs/remotes/* support (Eric Wong)
. sha1_name() understands refs/remotes/$foo/HEAD
- sha1_name safety and core.warnambiguousrefs
- git-merge knows some strategies want to skip trivial merges
- insanely fast rename detection (Linus and me)
- tar-tree updates (Rene Scharfe)
- send-email updates (Eric Wong)
- truly built-in diff (Linus with Davide)
- ls-{files,tree} --abbrev (Eric Wong)
- git-svnimport: if a limit is specified, respect it (Anand Kumria)
- documentation (J. Bruce Fields)
- build fix (Johannes Schindelin)
- git-ls-files --others --directory --no-empty-directory (Petr Baudis)
- gitk updates (Martin Mares, Paul Mackerras)
- GIT 1.3.0 rc1 (me)
Currently "next" and "pu" are empty.
^ permalink raw reply
* Re: Problem with git bisect between 2.6.15 and 2.6.16
From: Tony Luck @ 2006-03-28 0:22 UTC (permalink / raw)
To: Greg Lee; +Cc: sean, git
In-Reply-To: <0e7e01c651fc$e30a2860$a100a8c0@casabyte.com>
> No, the problem was fixed in 2.6.16 and I'm trying to figure out what fixed it so that I
> can back-port the fix into a previous kernel version, so 2.6.16 is good and 2.6.15 is bad.
You'll need to invert "good" and bad" for this. I.e. mark 2.6.15 as
good, 2.6.16 as bad, and
then as you test mark kernels with the bug as good, and ones without
as bad. Try not to go
insane while working in this inverted parallel universe :-)
-Tony
^ permalink raw reply
* Re: Selecting the minor revs
From: sean @ 2006-03-28 0:18 UTC (permalink / raw)
To: Greg Lee; +Cc: git
In-Reply-To: <0e7d01c651fb$fa11ceb0$a100a8c0@casabyte.com>
On Mon, 27 Mar 2006 19:10:09 -0500
"Greg Lee" <glee@swspec.com> wrote:
> > If you're interested in the stable-series releases of the
> > kernel, unfortunately they're not in the git repository.
>
> As I feared ... I'm curious, why?
Because the stable-series is maintained by people other than Linus.
They may have their own git tree, i'm not sure. Even if they don't,
you could create a stable-series branch and import the patches
into your git repo if it was something you needed often.
Sean
^ permalink raw reply
* RE: Problem with git bisect between 2.6.15 and 2.6.16
From: Greg Lee @ 2006-03-28 0:16 UTC (permalink / raw)
To: 'sean', git
In-Reply-To: <BAYC1-PASMTP036F0DBE8F7101BCAD5470AED30@CEZ.ICE>
> You need to do the bisect start after you cd into the linux-git
> directory.
Sorry, cut and paste error, I did the cd before the bisect:
[root@Fedora-test git]# git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-git-fresh
[root@Fedora-test git]# cd linux-git-fresh/
[root@Fedora-test linux-git-fresh]# git bisect start
[root@Fedora-test linux-git-fresh]# git bisect bad v2.6.15
[root@Fedora-test linux-git-fresh]# git bisect good v2.6.16
dab47a31f42a23d2b374e1cd7d0b797e8e08b23d was both good and bad
> Also, it appears you have the good and bad reversed,
> presumably the newer (v2.6.16) is bad, and the older (v.2.6.15)
> is good.
No, the problem was fixed in 2.6.16 and I'm trying to figure out what fixed it so that I
can back-port the fix into a previous kernel version, so 2.6.16 is good and 2.6.15 is bad.
Greg
^ permalink raw reply
* RE: Selecting the minor revs
From: Greg Lee @ 2006-03-28 0:10 UTC (permalink / raw)
To: 'sean', git
In-Reply-To: <BAYC1-PASMTP12827905B389678EB07BDAAED30@CEZ.ICE>
> If you're interested in the stable-series releases of the
> kernel, unfortunately they're not in the git repository.
As I feared ... I'm curious, why?
Greg
^ permalink raw reply
* Re: Problem with git bisect between 2.6.15 and 2.6.16
From: sean @ 2006-03-28 0:06 UTC (permalink / raw)
To: Greg Lee; +Cc: git
In-Reply-To: <0e7301c651fa$9e0fd770$a100a8c0@casabyte.com>
On Mon, 27 Mar 2006 19:00:25 -0500
"Greg Lee" <glee@casabyte.com> wrote:
> I get the following when I try to git bisect between 2.6.15 and 2.6.16:
>
> [root@Fedora-test tmp]# git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-git
> [root@Fedora-test linux-git]# git bisect start
> [root@Fedora-test linux-git]# cd linux-git
> [root@Fedora-test linux-git]# git bisect good v2.6.16
> [root@Fedora-test linux-git]# git bisect bad v2.6.15
> dab47a31f42a23d2b374e1cd7d0b797e8e08b23d was both good and bad
>
> What is the proper method to do a bisect between 2.6.15 and 2.6.16?
>
You need to do the bisect start after you cd into the linux-git
directory. Also, it appears you have the good and bad reversed,
presumably the newer (v2.6.16) is bad, and the older (v.2.6.15)
is good.
Sean
^ permalink raw reply
* Re: Selecting the minor revs
From: sean @ 2006-03-28 0:02 UTC (permalink / raw)
To: Greg Lee; +Cc: git
In-Reply-To: <0e6701c651f9$2605aad0$a100a8c0@casabyte.com>
On Mon, 27 Mar 2006 18:49:53 -0500
"Greg Lee" <glee@swspec.com> wrote:
> How do I select one of the "minor" bug fix revs using git? For example I want to do a git
> bisect between 2.6.15.6 and 2.6.16 but I cannot determine what the naming convention is
> for "2.6.15.6". I've tried "v2.6.15.6" and "v2.6.15-6".
>
> Please cc any responses.
If you're interested in the stable-series releases of the kernel, unfortunately they're
not in the git repository. On the otherhand if you're actually talking about the
release candidates that Linus puts out before each new major version, the format is
v2.6.16-rc2, v2.6.15-rc3 etc..
Sean
^ permalink raw reply
* Problem with git bisect between 2.6.15 and 2.6.16
From: Greg Lee @ 2006-03-28 0:00 UTC (permalink / raw)
To: git
I get the following when I try to git bisect between 2.6.15 and 2.6.16:
[root@Fedora-test tmp]# git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-git
[root@Fedora-test linux-git]# git bisect start
[root@Fedora-test linux-git]# cd linux-git
[root@Fedora-test linux-git]# git bisect good v2.6.16
[root@Fedora-test linux-git]# git bisect bad v2.6.15
dab47a31f42a23d2b374e1cd7d0b797e8e08b23d was both good and bad
What is the proper method to do a bisect between 2.6.15 and 2.6.16?
Greg
^ permalink raw reply
* Selecting the minor revs
From: Greg Lee @ 2006-03-27 23:49 UTC (permalink / raw)
To: git
How do I select one of the "minor" bug fix revs using git? For example I want to do a git
bisect between 2.6.15.6 and 2.6.16 but I cannot determine what the naming convention is
for "2.6.15.6". I've tried "v2.6.15.6" and "v2.6.15-6".
Please cc any responses.
Thanks,
Greg Lee
^ permalink raw reply
* Re: Following renames
From: Petr Baudis @ 2006-03-27 21:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ryan Anderson, git
In-Reply-To: <20060326232649.GV18185@pasky.or.cz>
Dear diary, on Mon, Mar 27, 2006 at 01:26:49AM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> To quickly see what it does, you can try it e.g. on the git-log.sh file
> in the Git repository.
By the way, the cg-log in master uses it now to automagically follow
file renames (in case you call it per-file like cg-log FILENAME). If you
hate it, you can prevent it by cg-log --no-renames (cg-log -R).
Looks pretty slick.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* [PATCH] cogito: Push tags over http
From: Dennis Stosberg @ 2006-03-27 19:12 UTC (permalink / raw)
To: git
A trivial patch for cg-push allows to push tags over http.
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---
cg-push | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
e9540d5f524c54102a93570031fb59156cec4188
diff --git a/cg-push b/cg-push
index b6b8954..4332b28 100755
--- a/cg-push
+++ b/cg-push
@@ -70,7 +70,7 @@ sprembranch=":refs/heads/$rembranch"
if [ "${uri#http://}" != "$uri" -o "${uri#https://}" != "$uri" ]; then
# git-http-push doesn't like $sprembranch
- git-http-push "$uri/" "$locbranch:$rembranch"
+ git-http-push "$uri/" "$locbranch:$rembranch" "${tags[@]}"
elif [ "${uri#git+ssh://}" != "$uri" ]; then
send_pack_update "$name" "$(echo "$uri" | sed 's#^git+ssh://\([^/]*\)\(/.*\)$#\1:\2#')" "$locbranch$sprembranch" "${tags[@]}"
elif [ "${uri#rsync://}" != "$uri" ]; then
--
1.2.GIT
^ permalink raw reply related
* Re: [PATCH] Reintroduce svn pools to solve the memory leak.
From: Junio C Hamano @ 2006-03-27 18:16 UTC (permalink / raw)
To: Santi Béjar; +Cc: Jan-Benedict Glaw, git, Karl Hasselström
In-Reply-To: <8aa486160603270326i3a8ddcfau61ca84cdac036ff9@mail.gmail.com>
"Santi Béjar" <sbejar@gmail.com> writes:
> On 3/24/06, Santi Béjar <sbejar@gmail.com> wrote:
>> Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
>>
>> diff-tree 4802426... (from 525c0d7...)
>> Author: Karl Hasselström <kha@treskal.com>
>> Date: Sun Feb 26 06:11:27 2006 +0100
>>
>> svnimport: Convert executable flag
>>
>> Convert the svn:executable property to file mode 755 when converting
>> an SVN repository to GIT.
>>
>> Signed-off-by: Karl Hasselström <kha@treskal.com>
>> Signed-off-by: Junio C Hamano <junkio@cox.net>
>>
>> :100755 100755 ee2940f... 6603b96... M git-svnimport.perl
>
> And this patch fixes my problems.
Jan-Benedict, thanks for pinpointing the regression, and Santi,
thanks for the patch.
I should have looked a bit more closely when applying the patch
-- it is clear that the patch is doing more than what its log
says. My fault.
Karl, were there other reasons you needed to disable the pool
here (maybe to work around a problem with incompatible version
of SVN module)? I see some other uses of SVN::Pool still there
in the code, so I am assuming this was a simple typo, but just
in case...
^ permalink raw reply
* Re: git-svn name
From: Chris Wright @ 2006-03-27 17:48 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Gerrit Pape, Chris Wright
In-Reply-To: <20060326030425.GA6306@hand.yhbt.net>
* Eric Wong (normalperson@yhbt.net) wrote:
> Would distro package maintainers also be willing to add my git-svn
> script to their git-svn binary packages when a new release of git is
> made, too? It's quite different from git-svnimport (see
> contrib/git-svn/git-svn.txt for details).
I think your script name is fine. Best way to handle this is with a
patch to make your git-svn part of the git-svn packaging.
thanks,
-chris
^ permalink raw reply
* Re: Following renames
From: Linus Torvalds @ 2006-03-27 16:52 UTC (permalink / raw)
To: Marco Costalba; +Cc: Jakub Narebski, git
In-Reply-To: <e5bfff550603270319w20796918wc8f8fe30a6c5627@mail.gmail.com>
On Mon, 27 Mar 2006, Marco Costalba wrote:
> >
> > And that's the point. Almost always, we're interested in the _recent_
> > stuff. The fact that it takes longer to get the old history is not very
> > important. You generally don't ask "what changed in this file" for a file
> > that hasn't changed in five years.
>
> We could run git-rev-list with a time range specifier (changes of last
> year as example) by default so to have fast results and run all time
> history _only_ on request.
Yes.
However, what I've been meaning to do (but just haven't had the time and
energy for so far) is to fix "git-rev-list" with a path limiter.
Right now that always causes things to be totally serialized, and the
revision walking will first look up _all_ the history (well, it will prune
out the merges) before starting to output stuff.
So right now in order for "git-whatchanged" to be fast and incremental, it
doesn't do any path limiting with git-rev-list at ALL, and does it all in
git-diff-tree. Which is horrid.
> I still think the problem with annotation is that you don't see
> patches that _remove_ lines of code, you need the whole diff for this.
Well, that's just another reason "annotate" sucks.
If you select a range of lines, my suggested tool _would_ show you lines
that got removed there, and git-whatchanged does it quite well.
I really think "annotate" is _fundamentally_ a broken operation. It's not
what any sane developer actually wants, and it has serious limitations (ie
it depends on whole history, and it cannot show removals well).
Linus
^ permalink raw reply
* Re: Following renames
From: Andreas Ericsson @ 2006-03-27 12:27 UTC (permalink / raw)
To: Marco Costalba; +Cc: Linus Torvalds, Jakub Narebski, git
In-Reply-To: <e5bfff550603270355s4b71c306hb4cb2b96eafd0f6e@mail.gmail.com>
Marco Costalba wrote:
> On 3/27/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>>In contrast, git-whatchanged will start outputting the recent changes
>>immediately.
>>
>
>
> To integrate git-whatchanged like functionality with filter on a
> specific code region, the Linus original request, I am wondering about
> something like this:
>
> A new git-diff-tree option --range=a..b to delimit a region,
> identified by code lines bounduaries.
>
Make it --line-range if you implement this. On a first glance I thought
you meant --commit-range.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Following renames
From: Marco Costalba @ 2006-03-27 11:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0603270005330.15714@g5.osdl.org>
On 3/27/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
> In contrast, git-whatchanged will start outputting the recent changes
> immediately.
>
To integrate git-whatchanged like functionality with filter on a
specific code region, the Linus original request, I am wondering about
something like this:
A new git-diff-tree option --range=a..b to delimit a region,
identified by code lines bounduaries.
As example
git-diff-tree --range=10..15 HEAD -- <path>
Coud give these answers, added to standard git-diff-tree output:
* 10..25 --> modified region new region bounduaries are lines from 10 to 25
15..20 --> region _NOT_ modified but new region bounduaries are
lines from 15 to 20 (perhaps patch added 5 lines _before_ the region)
10..15 ---> region _NOT_ modified and lines, if any, added/removed
_after_ the region
* 10..15 --> modified region with the same boundiaries (as example
removing trailing witespaces)
With this new option of git-diff-tree becames very simple to retrieve
a file history limited to a region, because the region bounduaries in
ouput from one rev are feed as input in parent rev.
Comments?
Marco
^ permalink raw reply
* Re: Following renames
From: Johannes Schindelin @ 2006-03-27 11:30 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550603270319w20796918wc8f8fe30a6c5627@mail.gmail.com>
Hi,
On Mon, 27 Mar 2006, Marco Costalba wrote:
> I still think the problem with annotation is that you don't see
> patches that _remove_ lines of code, you need the whole diff for this.
Interesting. You'd need a "git-emalb" (blame, but reverse), and you'd need
to tell it a range "rev1..rev2" which is *not* to be interpreted as "^rev1
rev2" but as a direct path from rev1 to rev2.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Reintroduce svn pools to solve the memory leak.
From: Santi Béjar @ 2006-03-27 11:26 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git, Junio C Hamano
On 3/24/06, Santi Béjar <sbejar@gmail.com> wrote:
> Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
>
> > On Wed, 2006-03-22 14:33:37 +0100, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> >
> > Since it seems nobody looked at the GCC import run (which means to use
> > the svnimport), I ran it again, under strace control:
> >
> >> GCC
> >> ~~~
> >> $ /home/jbglaw/bin/git svnimport -C gcc -v svn://gcc.gnu.org/svn/gcc
> >
> >> Committed change 3936:/ 1993-03-31 05:44:03)
> >> Commit ID ceff85145f8671fb2a9d826a761cedc2a507bd1e
> >> Writing to refs/heads/origin
> >> DONE: 3936 origin ceff85145f8671fb2a9d826a761cedc2a507bd1e
> >> ... 3937 trunk/gcc/final.c ...
> >> Can't fork at /home/jbglaw/bin/git-svnimport line 379.
> >
>
> I have the same (?) problem with one of my svn repository. It worked
> before (I've redone the import with the -r flag), so I bisected it.
> The problematic commit seems to be:
>
> diff-tree 4802426... (from 525c0d7...)
> Author: Karl Hasselström <kha@treskal.com>
> Date: Sun Feb 26 06:11:27 2006 +0100
>
> svnimport: Convert executable flag
>
> Convert the svn:executable property to file mode 755 when converting
> an SVN repository to GIT.
>
> Signed-off-by: Karl Hasselström <kha@treskal.com>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> :100755 100755 ee2940f... 6603b96... M git-svnimport.perl
>
> I think it has a memory leak, it used up to 140m of memory.
>
> $ git reset --hard 4802426^
> $ time ../git-svnimport.perl file:///path/
> Use of uninitialized value in string eq at ../git-svnimport.perl line 463.
> Use of uninitialized value in substitution (s///) at ../git-svnimport.perl line 466.
> real 0m55.801s
> user 0m30.578s
> sys 0m23.084s
>
> $ git reset --hard 4802426
> $ time ../git-svnimport.perl file:///path/
> Use of uninitialized value in string eq at ../git-svnimport.perl line 463.
> Use of uninitialized value in substitution (s///) at ../git-svnimport.perl line 466.
> Can't fork at /home/santi/usr/src/scm/git/git-svnimport.perl line 331.
> real 6m2.163s
> user 0m20.332s
> sys 0m50.180s
>
> and it didn't finished. Hope it helps.
And this patch fixes my problems.
---
Introduced in 4802426.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
git-svnimport.perl | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 639aa41..f2cf062 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -135,8 +135,10 @@
print "... $rev $path ...\n" if $opt_v;
my (undef, $properties);
+ my $pool = SVN::Pool->new();
eval { (undef, $properties)
- = $self->{'svn'}->get_file($path,$rev,$fh); };
+ = $self->{'svn'}->get_file($path,$rev,$fh,$pool); };
+ $pool->clear;
if($@) {
return undef if $@ =~ /Attempted to get checksum/;
die $@;
^ permalink raw reply related
* Re: Following renames
From: Marco Costalba @ 2006-03-27 11:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0603270005330.15714@g5.osdl.org>
On 3/27/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Mon, 27 Mar 2006, Marco Costalba wrote:
> >
> > Historic Linux test (63428 revisions)
> >
> > File: drivers/net/tg3.c
> > Revisions that modify tg3.c : 292
> >
> > With qgit
> > 15s to retrieve file history (git-rev-list)
> > 19.5s to annotate (git-diff-tree -p, current GNU algorithm, not new faster one)
>
> .. and it does absolutely _nothing_ while it's doing that, does it?
>
yes, it's true.
> > $ time git-whatchanged HEAD drivers/net/tg3.c > /dev/null
> > 98.01user 2.44system 1:46.19elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k
> > 0inputs+0outputs (797major+43033minor)pagefaults 0swaps
>
> In contrast, git-whatchanged will start outputting the recent changes
> immediately.
>
> And that's the point. Almost always, we're interested in the _recent_
> stuff. The fact that it takes longer to get the old history is not very
> important. You generally don't ask "what changed in this file" for a file
> that hasn't changed in five years.
>
We could run git-rev-list with a time range specifier (changes of last
year as example) by default so to have fast results and run all time
history _only_ on request.
This perhaps could solve the fast output for recent revs problem, if
this is the problem.
I still think the problem with annotation is that you don't see
patches that _remove_ lines of code, you need the whole diff for this.
Marco
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox