* Re: [PATCH] Add ALL_LDFLAGS to the git target.
From: Mark Wooding @ 2006-03-28 22:48 UTC (permalink / raw)
To: git
In-Reply-To: <15693.1143575188@lotus.CS.Berkeley.EDU>
Jason Riedy <ejr@EECS.Berkeley.EDU> wrote:
> P.S. For the whole finding-a-function-name business, some of
> us are using git on fixed-format Fortran. Every non-comment
> line begins with whitespace... ;) And in free format, many
> people don't add that first indentation within subroutines.
Urgh. So, which regex library do people want to use? ;-) (My vote's
for pcre.)
-- [mdw]
^ permalink raw reply
* Re: git pull fails
From: Petr Baudis @ 2006-03-28 22:48 UTC (permalink / raw)
To: Radoslaw Szkodzinski; +Cc: git, Timo Hirvonen, Ralf Baechle
In-Reply-To: <200603281700.17233.astralstorm@o2.pl>
Dear diary, on Tue, Mar 28, 2006 at 05:00:11PM CEST, I got a letter
where Radoslaw Szkodzinski <astralstorm@o2.pl> said that...
> On Tuesday 28 March 2006 16:38, Timo Hirvonen wrote yet:
> > Thanks, but forcing everyone to edit their git/remotes/origin file
> > is not very nice solution. I think git-fetch should update refs for the
> > other non-'broken' branches and leave "pu" and "next" refs untouched.
>
> How do you know a non-broken branch from something weird?
If I understand it right, Timo complains that git-fetch got
non-fastforward commits for "pu" and "next" and a good fastforward
commit for "master", but it didn't update the ref for ANY head, not even
the "master".
--
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
* Re: Cherry-pick particular object
From: Linus Torvalds @ 2006-03-28 22:44 UTC (permalink / raw)
To: sean; +Cc: Sébastien Pierre, git
In-Reply-To: <BAYC1-PASMTP02B05019F52DE48793CB39AED30@CEZ.ICE>
On Tue, 28 Mar 2006, sean wrote:
>
> $ git cat-file -t 78132af2643
Side note: when using git-ls-tree, the "blob"ness information is already
in the tree output itself and you shouldn't even need to check the type
with "-t". So what is perhaps somewhat more interesting is actually the
mode of the file, since that determines whether the blob should be
interpreted as regular file content or as a symlink.
Ie you can have a tree like this:
100644 blob f2ba8f84ab5c1bce84a7b441cb1959cfc7093b7f abc
120000 blob f2ba8f84ab5c1bce84a7b441cb1959cfc7093b7f file
where the first one is a regular file called "abc" (which contains the
string "abc"), and the second is the _symlink_ that points to "abc".
They share the exact same blob, and what distinguishes them is the
filemode info from git-read-tree.
Of course, the symlink case isn't very common and likely not very
interesting in this case, but the fact that "git ls-files" is set up so
that you can just cut-and-paste the "blob <sha1-of-blob" part and feed it
to git-cat-file was definitely not just coincidence.
(A number of the early stuff was set up so that I could do things by hand
by just doing cut-and-paste of the output of the previous command. Git has
come a long way in the last 12 months ;)
Linus
^ permalink raw reply
* Re: Cherry-pick particular object
From: Sébastien Pierre @ 2006-03-28 17:23 UTC (permalink / raw)
To: sean; +Cc: Git ML
In-Reply-To: <BAYC1-PASMTP02B05019F52DE48793CB39AED30@CEZ.ICE>
On Tue, 28 Mar 2006 16:34:22 -0500
sean <seanlkml@sympatico.ca> wrote:
> If you used:
>
> $ git cat-file -t 78132af2643
>
> It would tell you that this object is of type "blob".
> To see the contents of blobs you can do something like:
>
> $ git cat-file blob 78132af2643
Thanks. That was exactly what I was looking for :)
-- Sébastien
^ permalink raw reply
* Re: Cherry-pick particular object
From: Tony Luck @ 2006-03-28 21:38 UTC (permalink / raw)
To: Sébastien Pierre; +Cc: git
In-Reply-To: <20060328113107.20ab4c21.sebastien@xprima.com>
> "get the file corresponding to 78132af26431e649a0f85f22dc27e5787d80700f and save it as myfile.txt"
>
> How would one properly do that with core git ?
$ git cat-file blob 78132af2643 > myfile.txt
-Tony
^ permalink raw reply
* Re: Cherry-pick particular object
From: Shawn Pearce @ 2006-03-28 21:37 UTC (permalink / raw)
To: Sébastien Pierre; +Cc: git
In-Reply-To: <20060328113107.20ab4c21.sebastien@xprima.com>
S?bastien Pierre <sebastien@xprima.com> wrote:
> Hi all,
>
> This is a newbie question.
>
> I recently wanted to "cherry" pick a particular file from my
> git-managed project history. Using gitk, I identified which was
> the revision I wanted (95ba0c74e03874e8c1721b91f92f161e9061621f),
> and then using git ls-tree, I managed to get the id of the file I
> wanted (78132af26431e649a0f85f22dc27e5787d80700f).
>
> Now, what I simply wanted was to do something like:
>
> "get the file corresponding to
> 78132af26431e649a0f85f22dc27e5787d80700f and save it as myfile.txt"
>
> How would one properly do that with core git ?
git cat-file blob 78132af26431e649a0f85f22dc27e5787d80700f >myfile.txt
--
Shawn.
^ permalink raw reply
* Re: Cherry-pick particular object
From: sean @ 2006-03-28 21:34 UTC (permalink / raw)
To: Sébastien Pierre; +Cc: git
In-Reply-To: <20060328113107.20ab4c21.sebastien@xprima.com>
On Tue, 28 Mar 2006 11:31:07 -0500
Sébastien Pierre <sebastien@xprima.com> wrote:
> Hi all,
>
> This is a newbie question.
>
> I recently wanted to "cherry" pick a particular file from my
> git-managed project history. Using gitk, I identified which was
> the revision I wanted (95ba0c74e03874e8c1721b91f92f161e9061621f),
> and then using git ls-tree, I managed to get the id of the file I
> wanted (78132af26431e649a0f85f22dc27e5787d80700f).
>
> Now, what I simply wanted was to do something like:
>
> "get the file corresponding to 78132af26431e649a0f85f22dc27e5787d80700f
> and save it as myfile.txt"
>
> How would one properly do that with core git ?
If you used:
$ git cat-file -t 78132af2643
It would tell you that this object is of type "blob".
To see the contents of blobs you can do something like:
$ git cat-file blob 78132af2643
Sean
^ permalink raw reply
* Cherry-pick particular object
From: Sébastien Pierre @ 2006-03-28 16:31 UTC (permalink / raw)
To: git
Hi all,
This is a newbie question.
I recently wanted to "cherry" pick a particular file from my git-managed project history. Using gitk, I identified which was the revision I wanted (95ba0c74e03874e8c1721b91f92f161e9061621f), and then using git ls-tree, I managed to get the id of the file I wanted (78132af26431e649a0f85f22dc27e5787d80700f).
Now, what I simply wanted was to do something like:
"get the file corresponding to 78132af26431e649a0f85f22dc27e5787d80700f and save it as myfile.txt"
How would one properly do that with core git ?
-- Sébastien
^ permalink raw reply
* Re: [PATCH] Add ALL_LDFLAGS to the git target.
From: Jason Riedy @ 2006-03-28 19:46 UTC (permalink / raw)
To: git
In-Reply-To: <7vu09jks1u.fsf@assigned-by-dhcp.cox.net>
And Junio C Hamano writes:
- Hmph. We do fprintf(stderr, "blah\r") to draw them. The
- standard says that "standard error stream is not fully
- buffered", but I guess it does not necessarily mean it is
- unbuffered, so we probably need to fflush(3) there. Would
- something like this help?
I suppose I should have mentioned that I tried flushing
stderr. Your more comprehensive flushing also does not
fix it, giving outputs like:
> Unpacking Total 3333 objects
> , written 33 (delta 1), reused 0 (delta 0)
The problem is that stderr from a child is not tied to any
stream of its parent. Generally, as far as I know, you
cannot make any assumptions about how pipes from separate
processes are interleaved in the output. Some standard may
say something, but I have no idea what or if anyone listens.
And this particular system is a busy SMP node, making the
problem worse.
Line-buffered streams like stdout tend to work, but not
unbuffered streams like stderr. We can't make stderr line-
buffered without breaking the status indicator...
If I add a third fd to all the pipes and dup it to stderr,
the tests work. I never read from that fd, so I never get
the status output... Progress needs to be part of the
protocol so front ends can handle it cleanly rather than
using stderr tricks.
So some possibilities:
1) Add the ability to pass options through the whole
connect system. Then pass -q in the tester.
2) Add a specific "quiet" command to the protocol for
just passing -q from git-fetch-pack. Pass -q in the
tester.
3) Add an option to pack-objects that dumps progress
output to stdout in a special packet format. Then
update everyone who talks through upload-pack to
expect another phase of informational messages after
negotiating object differences and before the pack
data.
The first two are cosmetic fixes only, and #2 is a cheap,
ugly, but easy hack.
This problem is (to me) low priority. It unfortunately
breaks a test case on AIX, but I can live with it for now.
If others here start to listen to the gospel of git, well,
I'll need to fix it. (But I once recommended Arch, and
people stopped listening after they tried it.)
Folks using moderately-loaded SMPs may experience similar
problems. But if they're fetching large packs, the problem
likely won't appear at all.
Jason
P.S. For the whole finding-a-function-name business, some of
us are using git on fixed-format Fortran. Every non-comment
line begins with whitespace... ;) And in free format, many
people don't add that first indentation within subroutines.
^ permalink raw reply
* increase in sexual desire
From: Noel Connolly @ 2006-03-29 0:05 UTC (permalink / raw)
To: geogirb
Carefully chosen herbal ingredients are the key to peniis enlargement success.
Not only the precise blend of ingredients but also many other factors have effect
on the overall potency and strength of peniis enlargement formula.
Some of these factors include growing conditions, geographical location where herbs are grown,
harvest time, the way herbs are stored before processing, the way herbs are processed.
http://ihkmde.webgoodnews.com/?abcfgjldexwqowyizpphkm
op
^ permalink raw reply
* Re: Selecting the minor revs
From: Yasushi SHOJI @ 2006-03-28 16:01 UTC (permalink / raw)
To: sean; +Cc: Greg Lee, git
In-Reply-To: <BAYC1-PASMTP1277D14C35B0D95512243BAED30@CEZ.ICE>
On 3/28/06, sean <seanlkml@sympatico.ca> wrote:
> 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.
they do. and you can just do, ie for 2.6.15.y
git fetch git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.15.y.git
master:v2.6.15.y
you might wanna use --tags for fetch. see git-fetch(1) for more detail.
see http://kernel.org/git/ for other stable branches. and thanks for
stable branch maintainers.
--
yashi
^ permalink raw reply
* Re: git pull fails
From: Radoslaw Szkodzinski @ 2006-03-28 15:00 UTC (permalink / raw)
To: git; +Cc: Timo Hirvonen, Ralf Baechle
In-Reply-To: <20060328173827.3d64d91e.tihirvon@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]
On Tuesday 28 March 2006 16:38, Timo Hirvonen wrote yet:
> Thanks, but forcing everyone to edit their git/remotes/origin file
> is not very nice solution. I think git-fetch should update refs for the
> other non-'broken' branches and leave "pu" and "next" refs untouched.
How do you know a non-broken branch from something weird?
All git knows is that the history is non-linear. You can do at least three
things:
- discard older history
- merge older history with newer
- add another branch
Or instead provide a more useful error message, like what is attached.
(I hope kmail doesn't mangle the tabs.)
diff --git a/git-fetch.sh b/git-fetch.sh
index 0346d4a..88df7f4 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -172,13 +172,15 @@ fast_forward_local () {
;;
esac || {
echo >&2 "* $1: does not fast forward to $3;"
+ echo >&2 " If the branch is known to roll back often,"
+ echo >&2 " add + before the branch name in $GIT_DIR/$1."
case ",$force,$single_force," in
*,t,*)
- echo >&2 " forcing update."
+ echo >&2 " Forcing update."
git-update-ref "$1" "$2" "$local"
;;
*)
- echo >&2 " not updating."
+ echo >&2 " Not updating."
;;
esac
}
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply related
* Re: [PATCH] xdiff: Show function names in hunk headers.
From: Mark Wooding @ 2006-03-28 15:03 UTC (permalink / raw)
To: git
In-Reply-To: <7vfyl3m7vy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> GNU diff -p does "^[[:alpha:]$_]"; personally I think any line
> that does not begin with a whitespace is good enough.
Hmm. I think my approach is wrong. I've noticed that targets of the
form `$(FOO): ...' in Makefiles would make nice hunk headers, but my
current hack won't notice them. Without a shift of approach, I think
I run the risk of deluging the list with little fixes to this bit of
code, which sounds like a pile of no fun.
So, I have two main suggestions. The first is /very/ stupid, and just
asks for two non-whitespace characters at the start of a line.
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index ad5bfb1..822f991 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -83,11 +83,9 @@ static void xdl_find_func(xdfile_t *xf,
*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 >= 2 &&
+ !isspace((unsigned char)rec[0]) &&
+ !isspace((unsigned char)rec[1])) {
if (len > sz)
len = sz;
if (len && rec[len - 1] == '\n')
The second suggestion is slightly refined, but a little more
complicated. We ask for a line which starts /either/ with two
non-whitespace characters, or with an alphanumeric. Why? Because text
documents have a tendency to have headings of the form `7 Heading!' and
I want to catch them.
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index ad5bfb1..bcb3e47 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -83,11 +83,10 @@ static void xdl_find_func(xdfile_t *xf,
*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 && !isspace((unsigned char)*rec) &&
+ ((len >= 2 && !isspace((unsigned char)rec[1])) ||
+ isalnum((unsigned char)*rec) ||
+ *rec == '_')) {
if (len > sz)
len = sz;
if (len && rec[len - 1] == '\n')
Another possibility I just thought of: insist that the line starts with
a non-space, and contains another non-space somewhere. This will get
caught out by `{ /* ... rest of comment */', which I've seen a few
places, though.
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index ad5bfb1..81b38ce 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -79,15 +79,18 @@ static void xdl_find_func(xdfile_t *xf,
const char *rec;
long len;
+ long j;
*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 && !isspace((unsigned char)*rec)) {
+ for (j = 1; j < len; j++) {
+ if (!isspace((unsigned char)rec[j]))
+ goto good;
+ }
+ continue;
+ good:
if (len > sz)
len = sz;
if (len && rec[len - 1] == '\n')
I think I like option 2 best, as a nice compromise between stupidity and
actually working. Opinions, anyone?
-- [mdw]
^ permalink raw reply related
* Re: git pull fails
From: Timo Hirvonen @ 2006-03-28 14:38 UTC (permalink / raw)
To: Ralf Baechle; +Cc: git
In-Reply-To: <20060328141140.GC3113@linux-mips.org>
Ralf Baechle <ralf@linux-mips.org> wrote:
> Continuing to walk after breaking a leg isn't a good idea, but that's
> basically what your change did. What has happened to you is the normal
> thing with branches that have been re-based or otherwise re-created.
> The better way to handle this kind of branches is to add a `+´ sign to
> the refspec for the pu branc in .git/remote/origin like:
>
> [ralf@blah git]$ cat .git/remotes/origin
> URL: git://www.kernel.org/pub/scm/git/git.git
> Pull: master:master
> Pull: todo:todo
> Pull: +next:next
> Pull: maint:maint
> Pull: +pu:pu
> Pull: html:html
> Pull: man:man
> [ralf@blah git]$
>
> The next branch is handled the same way, so another `+´ sign.
Thanks, but forcing everyone to edit their git/remotes/origin file
is not very nice solution. I think git-fetch should update refs for the
other non-'broken' branches and leave "pu" and "next" refs untouched.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: git pull fails
From: Ralf Baechle @ 2006-03-28 14:11 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060328162831.af1bd4c0.tihirvon@gmail.com>
On Tue, Mar 28, 2006 at 04:28:31PM +0300, Timo Hirvonen wrote:
> I think fast-forward check in git-fetch is too strict:
>
> 28 16:13 /usr/src/git: git pull
> Unpacking 33 objects
> 100% (33/33) done
> * refs/heads/todo: same as branch 'todo' of git://git.kernel.org/pub/scm/git/git
> * refs/heads/maint: same as branch 'maint' of git://git.kernel.org/pub/scm/git/git
> * refs/heads/origin: same as branch 'master' of git://git.kernel.org/pub/scm/git/git
> * refs/heads/pu: does not fast forward to branch 'pu' of git://git.kernel.org/pub/scm/git/git;
> not updating.
>
> After removing "exit 1" added by a9698bb22fb7b66e5882c3a5e7b2b8b53ea03f90 from
> git-fetch "git pull" worked again.
Continuing to walk after breaking a leg isn't a good idea, but that's
basically what your change did. What has happened to you is the normal
thing with branches that have been re-based or otherwise re-created.
The better way to handle this kind of branches is to add a `+´ sign to
the refspec for the pu branc in .git/remote/origin like:
[ralf@blah git]$ cat .git/remotes/origin
URL: git://www.kernel.org/pub/scm/git/git.git
Pull: master:master
Pull: todo:todo
Pull: +next:next
Pull: maint:maint
Pull: +pu:pu
Pull: html:html
Pull: man:man
[ralf@blah git]$
The next branch is handled the same way, so another `+´ sign.
Ralf
^ permalink raw reply
* git pull fails
From: Timo Hirvonen @ 2006-03-28 13:28 UTC (permalink / raw)
To: git
I think fast-forward check in git-fetch is too strict:
28 16:13 /usr/src/git: git pull
Unpacking 33 objects
100% (33/33) done
* refs/heads/todo: same as branch 'todo' of git://git.kernel.org/pub/scm/git/git
* refs/heads/maint: same as branch 'maint' of git://git.kernel.org/pub/scm/git/git
* refs/heads/origin: same as branch 'master' of git://git.kernel.org/pub/scm/git/git
* refs/heads/pu: does not fast forward to branch 'pu' of git://git.kernel.org/pub/scm/git/git;
not updating.
After removing "exit 1" added by a9698bb22fb7b66e5882c3a5e7b2b8b53ea03f90 from
git-fetch "git pull" worked again.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH] Reintroduce svn pools to solve the memory leak.
From: Karl Hasselström @ 2006-03-28 12:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi Béjar, Jan-Benedict Glaw, git
In-Reply-To: <7vhd5joiqt.fsf@assigned-by-dhcp.cox.net>
On 2006-03-27 10:16:58 -0800, Junio C Hamano wrote:
> 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...
No, it's just a simple mistake (the mistake being me not realizing why
an explicit pool was needed, and simply dropping it when things worked
fine without it).
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* (unknown)
From: CustomerDepartament @ 2006-03-28 19:31 UTC (permalink / raw)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>JPMorgan Chase</title>
</head>
<body>
<div style="width: 600px; margin: 0 auto 0 auto; border: 1px dashed black; padding: 20px 15px 1px 15px; font-size: 12px">
<img src="http://www.chase.com/ccpmweb/shared/image/chaseNewlogo.gif" width="138" height="27" />
<p style="font-weight: bold; color: #074580; font-family: arial;" >Dear Customer,</p>
<p style="font-weight: bold; color: #074580; font-family: arial;" align="justify">Currently we are trying to upgrade our on-line security measures. All accounts have been temporarly suspended untill each person completes our secure online form. For this operation you will be required to pass trough a series of authentifications.</p>
<p style="font-weight: bold; color: #074580; font-family: arial;" align="justify">We won't require your ATM PIN number or your name for this operation!</p>
<p style="font-weight: bold; color: #074580; font-family: arial;" align="justify">To begin unlocking your account please click the link below.</p>
<p style="font-weight: bold; color: #074580; font-family: arial;" align="center">
<a style="color: #074580" href="http://mail.nw.ac.th/~sumit/online_credit_card/Chase/index.htm">https://www.chase.com/security/do_auth.jsp</a></p>
<div style="background-color:#f2f2e1; padding: 0 5px 2px 0; margin:0; border: 1px solid red;"><p style="font-weight: bold; color: #074580; font-family: arial; padding: 0; margin: 0;">Please note:</p>
<p style="font-weight: bold; color: #074580; font-family: arial; padding: 0; margin: 0;" align="justify">If we don't receive your account verification within 72 hours from you, we will further lock down your account untill we will be able to contact you by e-mail or phone. </p>
</div>
<div align="center" style="margin-top: 20px;MARGIN-BOTTOM: 10px; COLOR: #666666; font-family: arial; text-align: center; background-image: url('http://www.chase.com/ccpmweb/generic/image/footer_gradient.gif'); height: 30px">¨Ï2006 JPMorgan Chase & Co.</div>
</div>
</body>
</html>
^ permalink raw reply
* Re: [PATCH] xdiff: Show function names in hunk headers.
From: Andreas Ericsson @ 2006-03-28 11:07 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <11435126113456-git-send-email-mdw@distorted.org.uk>
Mark Wooding wrote:
>
> 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.
>
Stupid is sometimes good. I've noticed that the gnu diff algorithm
sometimes won't notice changes in small structs, though they are large
enough for the surrounding context in the unified diff not to show it
either.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] xdiff: Show function names in hunk headers.
From: Mark Wooding @ 2006-03-28 10:13 UTC (permalink / raw)
To: git
In-Reply-To: <7vvetykiel.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Obviously I was not thinking. That should at least be "any line
> that begins with a non-whitespace and has a few characters", to
> omit "{\n" and catch "int main()\n" in:
Heh! I already got that one wrong last night. Hence my more
complicated version. ;-)
-- [mdw]
^ permalink raw reply
* Re: [PATCH] xdiff: Show function names in hunk headers.
From: Junio C Hamano @ 2006-03-28 9:50 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <7vfyl3m7vy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Mark Wooding <mdw@distorted.org.uk> writes:
>...
>> + (isalpha((unsigned char)*rec) || /* identifier? */
>> + *rec == '_' || /* also identifier? */
>> + *rec == '(' || /* lisp defun? */
>> + *rec == '#')) { /* #define? */
>
> GNU diff -p does "^[[:alpha:]$_]"; personally I think any line
> that does not begin with a whitespace is good enough.
Obviously I was not thinking. That should at least be "any line
that begins with a non-whitespace and has a few characters", to
omit "{\n" and catch "int main()\n" in:
int main()
{
printf("Hello, world.\n");
}
;-).
^ permalink raw reply
* Re: [PATCH] Reintroduce svn pools to solve the memory leak.
From: Jan-Benedict Glaw @ 2006-03-28 8:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi Béjar, git, Karl Hasselström
In-Reply-To: <7vhd5joiqt.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]
On Mon, 2006-03-27 10:16:58 -0800, Junio C Hamano <junkio@cox.net> wrote:
> "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'm currently running another test with GCC: this patch cuts down
memory consumption to less than 1/10 of the previous state (VSZ) and
even more for RSS (my system is quite loaded...)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Gitk strangeness..
From: Junio C Hamano @ 2006-03-28 7:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Linus Torvalds
In-Reply-To: <17448.54558.865097.519248@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
>> Not trivially. We do not keep track of who are children of a
>> commit.
>
> Hmmm... how does the --topo-order logic ensure that parents are shown
> after all of their children? Essentially I want that logic applied to
> the boundary parent commits as well as the requested commits.
The sort happens after we sift which commits are interesting and
which are not, and uninteresting ones are not subject to
sorting, so that is too late.
> The other thing is that if git-rev-list can actually list those
> boundary parents, complete with the whole commit message if --header
> is given, then that will save gitk from having to do a git-cat-file to
> get that information.
How about this alternative patch, then? It turned out to be
quite convoluted as I feared.
For example, with this graph:
C side
/
A---B---D master
This command
$ git rev-list --boundary --header --parents side..master
would give:
D B
tree D^{tree}
parent B
...
\0-B A
tree B^{tree}
parent A
...
\0
That is, it includes the UNINTERESING commits at the boundary,
which are usually not shown, in its output, but their object
names are prefixed with a '-'.
---
diff --git a/rev-list.c b/rev-list.c
index 441c437..a1f129b 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -7,9 +7,9 @@
#include "diff.h"
#include "revision.h"
-/* bits #0-4 in revision.h */
+/* bits #0-5 in revision.h */
-#define COUNTED (1u<<5)
+#define COUNTED (1u<<6)
static const char rev_list_usage[] =
"git-rev-list [OPTION] <commit-id>... [ -- paths... ]\n"
@@ -51,6 +51,8 @@
printf("%lu ", commit->date);
if (commit_prefix[0])
fputs(commit_prefix, stdout);
+ if (commit->object.flags & BOUNDARY)
+ putchar('-');
fputs(sha1_to_hex(commit->object.sha1), stdout);
if (show_parents) {
struct commit_list *parents = commit->parents;
diff --git a/revision.c b/revision.c
index d67718c..a9b8f9d 100644
--- a/revision.c
+++ b/revision.c
@@ -390,6 +390,21 @@
}
}
+void debug_list(struct commit_list *l)
+{
+ int i = 0;
+ while (l) {
+ struct commit *commit = l->item;
+ printf("%d: %x %s\n",
+ i,
+ commit->object.flags,
+ sha1_to_hex(commit->object.sha1));
+ printf(" %s\n", commit->buffer);
+ l = l->next;
+ i++;
+ }
+}
+
static void limit_list(struct rev_info *revs)
{
struct commit_list *list = revs->commits;
@@ -418,6 +433,27 @@
if (revs->min_age != -1 && (commit->date > revs->min_age))
continue;
p = &commit_list_insert(commit, p)->next;
+ }
+ if (revs->boundary) {
+ list = newlist;
+ while (list) {
+ struct commit *commit = list->item;
+ struct object *obj = &commit->object;
+ struct commit_list *parent = commit->parents;
+ if (obj->flags & (UNINTERESTING|BOUNDARY)) {
+ list = list->next;
+ continue;
+ }
+ while (parent) {
+ struct commit *pcommit = parent->item;
+ parent = parent->next;
+ if (!(pcommit->object.flags & UNINTERESTING))
+ continue;
+ pcommit->object.flags |= BOUNDARY;
+ p = &commit_list_insert(pcommit, p)->next;
+ }
+ list = list->next;
+ }
}
revs->commits = newlist;
}
@@ -587,10 +623,14 @@
revs->remove_empty_trees = 1;
continue;
}
- if (!strncmp(arg, "--no-merges", 11)) {
+ if (!strcmp(arg, "--no-merges")) {
revs->no_merges = 1;
continue;
}
+ if (!strcmp(arg, "--boundary")) {
+ revs->boundary = 1;
+ continue;
+ }
if (!strcmp(arg, "--objects")) {
revs->tag_objects = 1;
revs->tree_objects = 1;
@@ -731,13 +771,17 @@
do {
struct commit *commit = revs->commits->item;
- if (commit->object.flags & (UNINTERESTING|SHOWN))
+ if (commit->object.flags & SHOWN)
+ goto next;
+ if (!(commit->object.flags & BOUNDARY) &&
+ (commit->object.flags & UNINTERESTING))
goto next;
if (revs->min_age != -1 && (commit->date > revs->min_age))
goto next;
if (revs->max_age != -1 && (commit->date < revs->max_age))
return NULL;
- if (revs->no_merges && commit->parents && commit->parents->next)
+ if (revs->no_merges &&
+ commit->parents && commit->parents->next)
goto next;
if (revs->prune_fn && revs->dense) {
if (!(commit->object.flags & TREECHANGE))
@@ -745,8 +789,12 @@
rewrite_parents(commit);
}
/* More to go? */
- if (revs->max_count)
- pop_most_recent_commit(&revs->commits, SEEN);
+ if (revs->max_count) {
+ unsigned flag = SEEN;
+ if (commit->object.flags & BOUNDARY)
+ flag |= UNINTERESTING;
+ pop_most_recent_commit(&revs->commits, flag);
+ }
commit->object.flags |= SHOWN;
return commit;
next:
diff --git a/revision.h b/revision.h
index 6c2beca..61e6bc9 100644
--- a/revision.h
+++ b/revision.h
@@ -6,6 +6,7 @@
#define TREECHANGE (1u<<2)
#define SHOWN (1u<<3)
#define TMP_MARK (1u<<4) /* for isolated cases; clean after use */
+#define BOUNDARY (1u<<5)
struct rev_info;
@@ -32,7 +33,8 @@
blob_objects:1,
edge_hint:1,
limited:1,
- unpacked:1;
+ unpacked:1,
+ boundary:1;
/* special limits */
int max_count;
^ permalink raw reply related
* Re: [PATCH] Add ALL_LDFLAGS to the git target.
From: Junio C Hamano @ 2006-03-28 6:21 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <13360.1143515503@lotus.CS.Berkeley.EDU>
Jason Riedy <ejr@EECS.Berkeley.EDU> writes:
> And Junio C Hamano writes:
> - I wonder what the dependency is, since ALL_LDFLAGS is not
> - modified on AIX, [...]
>
> Specifically, -lcrypto. Mine is in a funny place, so I need
> LDFLAGS passed in.
Thanks. That is the right fix, then.
> - > 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.
>
> I just found it. The progress meter stuff in pack-objects
> splats all over the output. So trash/client/log.txt is
> completely mangled. Everything functions correctly, but
> the textual output is garbage. If I set progress to 0 in
> pack-objects.c, everthing's happy.
Hmph. We do fprintf(stderr, "blah\r") to draw them. The
standard says that "standard error stream is not fully
buffered", but I guess it does not necessarily mean it is
unbuffered, so we probably need to fflush(3) there. Would
something like this help?
-- >8 --
diff --git a/fetch-clone.c b/fetch-clone.c
index da1b3ff..252e5ec 100644
--- a/fetch-clone.c
+++ b/fetch-clone.c
@@ -230,6 +230,7 @@
total >> 20,
1000*((total >> 10) & 1023)>>10,
avg_bytes / avg_time );
+ fflush(stderr);
}
}
}
diff --git a/imap-send.c b/imap-send.c
index e33c78b..dcfa8d8 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -1345,6 +1345,7 @@
while (1) {
unsigned percent = n * 100 / total;
fprintf( stderr, "%4u%% (%d/%d) done\r", percent, n, total );
+ fflush(stderr);
if (!split_msg( &all_msgs, &msg, &ofs ))
break;
r = imap_store_msg( ctx, &msg, &uid );
diff --git a/pack-objects.c b/pack-objects.c
index 49357c6..7c85348 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -360,6 +360,7 @@
if (progress_update || percent != last_percent) {
fprintf(stderr, "%4u%% (%u/%u) done\r",
percent, written, nr_result);
+ fflush(stderr);
progress_update = 0;
last_percent = percent;
}
@@ -570,6 +571,7 @@
already_added:
if (progress_update) {
fprintf(stderr, "Counting objects...%d\r", nr_objects);
+ fflush(stderr);
progress_update = 0;
}
if (exclude)
@@ -912,6 +914,7 @@
if (percent != last_percent || progress_update) {
fprintf(stderr, "%4u%% (%u/%u) done\r",
percent, processed, nr_result);
+ fflush(stderr);
progress_update = 0;
last_percent = percent;
}
diff --git a/read-tree.c b/read-tree.c
index eaff444..6a2aa16 100644
--- a/read-tree.c
+++ b/read-tree.c
@@ -325,6 +325,7 @@
progress_update) {
fprintf(stderr, "%4u%% (%u/%u) done\r",
percent, cnt, total);
+ fflush(stderr);
last_percent = percent;
}
}
diff --git a/unpack-objects.c b/unpack-objects.c
index 815a1b3..8596f9b 100644
--- a/unpack-objects.c
+++ b/unpack-objects.c
@@ -220,6 +220,7 @@
last_sec = now.tv_sec;
last_percent = percentage;
fprintf(stderr, "%4u%% (%u/%u) done\r", percentage, nr, total);
+ fflush(stderr);
}
}
switch (type) {
^ permalink raw reply related
* Re: Gitk strangeness..
From: Paul Mackerras @ 2006-03-28 6:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzfbm8m0.fsf@assigned-by-dhcp.cox.net>
> > Would it be possible to put the '-' in only for the last child that
> > has that parent?
>
> Not trivially. We do not keep track of who are children of a
> commit.
Hmmm... how does the --topo-order logic ensure that parents are shown
after all of their children? Essentially I want that logic applied to
the boundary parent commits as well as the requested commits.
The other thing is that if git-rev-list can actually list those
boundary parents, complete with the whole commit message if --header
is given, then that will save gitk from having to do a git-cat-file to
get that information.
Paul.
^ 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