* Re: NT directory traversal speed on 25K files on Cygwin
From: Rutger Nijlunsing @ 2006-02-27 18:30 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060227011801.GB9264@trixie.casa.cgf.cx>
On Sun, Feb 26, 2006 at 08:18:01PM -0500, Christopher Faylor wrote:
> On Mon, Feb 27, 2006 at 12:17:01AM +0100, Rutger Nijlunsing wrote:
> >On Sun, Feb 26, 2006 at 02:55:52PM -0500, Christopher Faylor wrote:
> >>On Thu, Feb 23, 2006 at 03:07:07PM +0100, Alex Riesen wrote:
> >>>filesystem is slow and locked down, and exec-attribute is NOT really
> >>>useful even on NTFS (it is somehow related to execute permission and
> >>>open files. I still cannot figure out how exactly are they related).
> >>
> >>Again, it's not clear if you're talking about Windows or Cygwin but
> >>under Cygwin, in the default configuration, the exec attribute means
> >>the same thing to cygwin as it does to linux.
> >
> >I don't know about native Windows speed, but comparing NutCracker with
> >Cygwin on a simple 'find . | wc -l' already gives a clue that looking
> >at Cygwin to benchmark NT file inspection IO will give a skewed
> >picture:
> >
> >##### NutCracker $ time find . | wc -l
> >
> >real 0m 1.44s
> >user 0m 0.45s
> >sys 0m 0.98s
> >25794
> >
> >##### Cygwin $ time c:\\cygwin\\bin\\find . | wc -l
> >
> >real 0m 6.72s
> >user 0m 1.09s
> >sys 0m 5.59s
> >25794
> >
> >##### CMD.EXE + DIR /S C:\PROJECT> c:\cygwin\bin\time cmd /c dir /s
> >>NUL 0.01user 0.01system 0:05.70elapsed 0%CPU (0avgtext+0avgdata
> >6320maxresident)k 0inputs+0outputs (395major+0minor)pagefaults 0swaps
> >
> >##### Cygwin 'find -ls' (NutCracker doesn't have a '-ls') C:\PROJECT>
> >c:\cygwin\bin\time c:\cygwin\bin\find -ls | wc -l 2.79user 7.81system
> >0:10.60elapsed 100%CPU (0avgtext+0avgdata 14480maxresident)k 25794
>
> I'm lost. What does this have to do with the exec attribute?
>
> Or, were you just climbing aboard the "Cygwin sure is slow" bandwagon?
I tried to get on the bandwagon 'NT file IO magnitudes slower => git
magnitudes slower', but missed the parade a week ago. Then another
parade showed up, but I managed to delete most of it with a
misfortunate shift-something in mutt... And then even messed up in
keeping the wrong paragraph... *hmpf*
However, the point I was trying to make was that git might be sped up
by a magnitude (although not all of the magnitudes in comparison to
Linux) by looking at why the file IO is this slow: Windows' file IO is
_not_ the only reason. Using a different/new/better fitted interface
to Cygwin or Win32 for a specific git task might help, although I have
no clue what or how.
--
Rutger Nijlunsing ---------------------------------- eludias ed dse.nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------
^ permalink raw reply
* git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Nicolas Vilz 'niv' @ 2006-02-27 17:59 UTC (permalink / raw)
To: git
hi everyone,
as i mentioned, i do experimental work with git and svn... and i
experienced some problems with git when pulling much data from svn.
Actually that happens after i commit a revision with many and big files.
After that i cannot do a git-svn fetch anymore because git-svn
complains...
fatal: Ref refs/heads/svn-git-HEAD is at
504721bf4b2702d3e56cef69950f42a43568e846 but expected
504721bf4b2702d3e56cef69950f42a43568e846
now i am a little confused about that... oh, i actually modified the
svn-git directly instead of a private working branch... perhaps that was
not intended.
now i am still on rev 2 on this branch but i updated it to rev 5 on the
svn-side...
any hints?
Sincerly
Nicolas
^ permalink raw reply
* Re: Quick question: how to generate a patch?
From: Linus Torvalds @ 2006-02-27 17:28 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Aubrey, git
In-Reply-To: <44033241.6070001@op5.se>
On Mon, 27 Feb 2006, Andreas Ericsson wrote:
>
> Did you by any chance do chmod -R, chown -R or start an ntp daemon somewhere
> in between there (don't know if clock skews will be detected by git, but...)?
off on this tangent: git shouldn't care about clock skew, because git
never cares about the current time. The only thing that matters is that
"stat()" returns the same time when called sequentially.
Now, if you have a distributed filesystem, and the _filesystem_ has some
strange clock-skew problem, that would definitely screw up git.
That sounds insane, but a trivial case of it might be a networked
filesystem where the mtime/ctime for a file create is filled in by the
client first, but then the server will do the "final version" when it
actually writes the file.
We used to have some bugs in our NFS client that did things like that: the
"mtime" of a file had this confusing duality between "client time" and
"server time", and it depended on whether the client had done a "getattr"
to the server which one you saw.
I could well imagine that we still have some bug like that (ctime in
particular is much less used than mtime, and thus more likely to have not
been noticed). And it could be much worse on some less-commonly-used and
less-unixy networked filesystem like smb, which is why I was wondering
what OS version and filesystem Aubrey might be using.
Linus
^ permalink raw reply
* Re: Quick question: how to generate a patch?
From: Linus Torvalds @ 2006-02-27 17:19 UTC (permalink / raw)
To: Aubrey; +Cc: git
In-Reply-To: <6d6a94c50602270902k2c06aaffw7e70268b0753ef64@mail.gmail.com>
On Tue, 28 Feb 2006, Aubrey wrote:
>
> =================================================================
> aubrey@linux:/checkout/uboot/patch/work/drivers> git diff
> ----snip----
> diff --git a/drivers/sk98lin/skxmac2.c b/drivers/sk98lin/skxmac2.c
> diff --git a/drivers/sk98lin/u-boot_compat.h b/drivers/sk98lin/u-boot_compat.h
Ok, this is _definitely_ your index being out of touch with your file
contents.
Run "git-update-index --refresh" and it should be ok.
Now the question is why the index got out-of-kilter with the file contents
in the first place. I used to have all these debug aids to show why git
thought a file had changed, but we've not had any bugs here for a long
long time, so..
The final checkout of the "git clone" should have made sure that the index
is up-to-date.
> > git clone remote-repo localdir
> > cd localdir
> > vi somefile
> > git diff
>
> Yes, exactly right.
>
> > then you did everything right, and if it gives any diff other than your
> > changes to "somefile", something is buggy. Need more info.
> >
> > Does "git diff" and "git diff HEAD" give different results, btw?
>
> Yes. the two commands give the same results.
>
> I'm using git-1.2.3
What OS/filesystem?
The way the index keeps track of files that haven't changed is by checking
the size, the mtime and the ctime of the inode. It also checks the
user/gid and inode number. If you use a filesystem where those might
change (networked?), that might cause this..
Linus
^ permalink raw reply
* Re: Quick question: how to generate a patch?
From: Aubrey @ 2006-02-27 17:18 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Linus Torvalds, git
In-Reply-To: <44033241.6070001@op5.se>
> Did you by any chance do chmod -R, chown -R or start an ntp daemon
> somewhere in between there (don't know if clock skews will be detected
> by git, but...)?
No, I did nothing between "git clone" and "git diff" except changing one file.
>
>
> Decidedly odd. What happens when you do "git update-index --refresh" and
> then re-run the "git diff > my.patch" thing?
>
Yes, "git update-index --refresh" works. After this command, I got what I want.
It's the diff in unified git format.
Regards,
-Aubrey
^ permalink raw reply
* gitview: Remove trailing white space
From: Aneesh Kumar K.V @ 2006-02-27 17:12 UTC (permalink / raw)
To: git, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0002-gitview-Remove-trailing-white-space.txt --]
[-- Type: text/plain, Size: 2725 bytes --]
Subject: gitview: Remove trailing white space
Do the cleanup using Dave jones vim script
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
69e8209d5152b187dbcf2c09c5db5ae7534a80d5
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 1d042e3..048caf6 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -162,7 +162,7 @@ class CellRendererGraph(gtk.GenericCellR
for item in names:
names_len += len(item)
- width = box_size * (cols + 1 ) + names_len
+ width = box_size * (cols + 1 ) + names_len
height = box_size
# FIXME I have no idea how to use cell_area properly
@@ -261,11 +261,11 @@ class Commit:
children_sha1 = {}
def __init__(self, commit_lines):
- self.message = ""
+ self.message = ""
self.author = ""
- self.date = ""
- self.committer = ""
- self.commit_date = ""
+ self.date = ""
+ self.committer = ""
+ self.commit_date = ""
self.commit_sha1 = ""
self.parent_sha1 = [ ]
self.parse_commit(commit_lines)
@@ -426,7 +426,7 @@ class GitView:
def __init__(self, with_diff=0):
self.with_diff = with_diff
- self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
+ self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
self.window.set_border_width(0)
self.window.set_title("Git repository browser")
@@ -878,15 +878,15 @@ class GitView:
# Reset nodepostion
if (last_nodepos > 5):
- last_nodepos = -1
+ last_nodepos = -1
# Add the incomplete lines of the last cell in this
try:
colour = self.colours[commit.commit_sha1]
except KeyError:
self.colours[commit.commit_sha1] = last_colour+1
- last_colour = self.colours[commit.commit_sha1]
- colour = self.colours[commit.commit_sha1]
+ last_colour = self.colours[commit.commit_sha1]
+ colour = self.colours[commit.commit_sha1]
try:
node_pos = self.nodepos[commit.commit_sha1]
@@ -918,7 +918,7 @@ class GitView:
self.colours[parent_id] = last_colour+1
last_colour = self.colours[parent_id]
self.nodepos[parent_id] = last_nodepos+1
- last_nodepos = self.nodepos[parent_id]
+ last_nodepos = self.nodepos[parent_id]
in_line.append((node_pos, self.nodepos[parent_id],
self.colours[parent_id]))
@@ -954,7 +954,7 @@ class GitView:
try:
next_commit = self.commits[index+1]
if (next_commit.commit_sha1 == sha1 and pos != int(pos)):
- # join the line back to the node point
+ # join the line back to the node point
# This need to be done only if we modified it
in_line.append((pos, pos-0.5, self.colours[sha1]))
continue;
--
1.2.3.g2cf3-dirty
^ permalink raw reply related
* Re: Quick question: how to generate a patch?
From: Andreas Ericsson @ 2006-02-27 17:09 UTC (permalink / raw)
To: Aubrey; +Cc: Linus Torvalds, git
In-Reply-To: <6d6a94c50602270902k2c06aaffw7e70268b0753ef64@mail.gmail.com>
Aubrey wrote:
>>It really should "just have worked". Can you show what the diff actually
>>looked like, and your exact command history?
>
>
>
>>If it was something like
>>
>> git clone remote-repo localdir
>> cd localdir
>> vi somefile
>> git diff
>>
>
> Yes, exactly right.
>
Did you by any chance do chmod -R, chown -R or start an ntp daemon
somewhere in between there (don't know if clock skews will be detected
by git, but...)?
>
>>then you did everything right, and if it gives any diff other than your
>>changes to "somefile", something is buggy. Need more info.
>>
>>Does "git diff" and "git diff HEAD" give different results, btw?
>
>
> Yes. the two commands give the same results.
>
Decidedly odd. What happens when you do "git update-index --refresh" and
then re-run the "git diff > my.patch" thing?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Quick question: how to generate a patch?
From: Aubrey @ 2006-02-27 17:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602270830330.22647@g5.osdl.org>
> It really should "just have worked". Can you show what the diff actually
> looked like, and your exact command history?
=================================================================
aubrey@linux:/checkout/uboot/patch/work/drivers> git diff
----snip----
diff --git a/drivers/sk98lin/skxmac2.c b/drivers/sk98lin/skxmac2.c
diff --git a/drivers/sk98lin/u-boot_compat.h b/drivers/sk98lin/u-boot_compat.h
diff --git a/drivers/sk98lin/uboot_drv.c b/drivers/sk98lin/uboot_drv.c
diff --git a/drivers/sk98lin/uboot_skb.c b/drivers/sk98lin/uboot_skb.c
diff --git a/drivers/sl811.h b/drivers/sl811.h
diff --git a/drivers/sl811_usb.c b/drivers/sl811_usb.c
diff --git a/drivers/sm501.c b/drivers/sm501.c
diff --git a/drivers/smc91111.c b/drivers/smc91111.c
diff --git a/drivers/smc91111.h b/drivers/smc91111.h
index cf08582..e5742ba 100644
--- a/drivers/smc91111.h
+++ b/drivers/smc91111.h
@@ -185,6 +185,8 @@ typedef unsigned long int dword;
#ifdef CONFIG_ADNPESC1
#define SMC_inw(r) (*((volatile word
*)(SMC_BASE_ADDRESS+((r)<<1))))
+#elif CONFIG_BLACKFIN
+#define SMC_inw(r) ({ word __v = (*((volatile word
*)(SMC_BASE_ADDRESS+(r)))); __builtin_bfin_ssync(); __v;})
#else
#define SMC_inw(r) (*((volatile word *)(SMC_BASE_ADDRESS+(r))))
#endif
@@ -192,6 +194,8 @@ typedef unsigned long int dword;
#ifdef CONFIG_ADNPESC1
#define SMC_outw(d,r) (*((volatile word
*)(SMC_BASE_ADDRESS+((r)<<1))) = d)
+#elif CONFIG_BLACKFIN
+#define SMC_outw(d,r) {(*((volatile word *)(SMC_BASE_ADDRESS+(r)))
= d);__builtin_bfin_ssync();}
#else
#define SMC_outw(d,r) (*((volatile word *)(SMC_BASE_ADDRESS+(r))) = d)
#endif
@@ -232,6 +236,8 @@ typedef unsigned long int dword;
#ifdef CONFIG_XSENGINE
#define SMC_inl(r) (*((volatile dword *)(SMC_BASE_ADDRESS+(r<<1))))
+#elif CONFIG_BLACKFIN
+#define SMC_inl(r) ({ dword __v = (*((volatile dword
*)(SMC_BASE_ADDRESS+(r))));__builtin_bfin_ssync(); __v;})
#else
#define SMC_inl(r) (*((volatile dword *)(SMC_BASE_ADDRESS+(r))))
#endif
@@ -247,6 +253,8 @@ typedef unsigned long int dword;
#ifdef CONFIG_XSENGINE
#define SMC_outl(d,r) (*((volatile dword
*)(SMC_BASE_ADDRESS+(r<<1))) = d)
+#elif CONFIG_BLACKFIN
+#define SMC_outl(d,r) {(*((volatile dword *)(SMC_BASE_ADDRESS+(r)))
= d);__builtin_bfin_ssync();}
#else
#define SMC_outl(d,r) (*((volatile dword
*)(SMC_BASE_ADDRESS+(r))) = d)
#endif
diff --git a/drivers/smiLynxEM.c b/drivers/smiLynxEM.c
diff --git a/drivers/status_led.c b/drivers/status_led.c
diff --git a/drivers/sym53c8xx.c b/drivers/sym53c8xx.c
diff --git a/drivers/ti_pci1410a.c b/drivers/ti_pci1410a.c
diff --git a/drivers/tigon3.c b/drivers/tigon3.c
diff --git a/drivers/tigon3.h b/drivers/tigon3.h
diff --git a/drivers/tsec.c b/drivers/tsec.c
diff --git a/drivers/tsec.h b/drivers/tsec.h
----snip----
=================================================================
>
> If it was something like
>
> git clone remote-repo localdir
> cd localdir
> vi somefile
> git diff
>
Yes, exactly right.
> then you did everything right, and if it gives any diff other than your
> changes to "somefile", something is buggy. Need more info.
>
> Does "git diff" and "git diff HEAD" give different results, btw?
Yes. the two commands give the same results.
I'm using git-1.2.3
Regards,
-Aubrey
^ permalink raw reply related
* Re: [PATCH] First cut at libifying revlist generation
From: Linus Torvalds @ 2006-02-27 16:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602262119200.22647@g5.osdl.org>
On Sun, 26 Feb 2006, Linus Torvalds wrote:
>
> I suspect that the simplest fix is to just move "limited" into the "revs"
> structure, the way I did pretty much everything else. That way nothing
> really changes: we'll have the exact same logic, the flag just moved
> around.
Here's a cleanup patch that does that. It also moves "unpacked" (and the
flag parsing) into rev_info, since that actually does affect the revision
walker too, and thus logically belongs there.
If you prefer, I can generate a totally re-done patch that combines all
the fixes so far.
Linus
----
diff-tree d33c6e5017d52d36f8da44162c0d87899efd247c (from 4b0fd13e13f49fa73ddd03a69f7d2ad1109139d4)
Author: Linus Torvalds <torvalds@osdl.org>
Date: Mon Feb 27 08:50:26 2006 -0800
Fix rev-list "limited" handling
Also, move "unpacked" into the rev_info structure, where it logically belongs.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
diff --git a/rev-list.c b/rev-list.c
index e9e371c..2e80930 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -41,7 +41,6 @@ static const char rev_list_usage[] =
struct rev_info revs;
-static int unpacked = 0;
static int bisect_list = 0;
static int verbose_header = 0;
static int abbrev = DEFAULT_ABBREV;
@@ -572,7 +571,7 @@ static struct commit_list *limit_list(st
if (revs.max_age != -1 && (commit->date < revs.max_age))
obj->flags |= UNINTERESTING;
- if (unpacked && has_sha1_pack(obj->sha1))
+ if (revs.unpacked && has_sha1_pack(obj->sha1))
obj->flags |= UNINTERESTING;
add_parents_to_list(commit, &list);
if (obj->flags & UNINTERESTING) {
@@ -595,7 +594,7 @@ static struct commit_list *limit_list(st
int main(int argc, const char **argv)
{
struct commit_list *list;
- int i, limited = 0;
+ int i;
argc = setup_revisions(argc, argv, &revs);
@@ -655,11 +654,6 @@ int main(int argc, const char **argv)
bisect_list = 1;
continue;
}
- if (!strcmp(arg, "--unpacked")) {
- unpacked = 1;
- limited = 1;
- continue;
- }
if (!strcmp(arg, "--merge-order")) {
merge_order = 1;
continue;
@@ -673,34 +667,25 @@ int main(int argc, const char **argv)
}
list = revs.commits;
- if (list && list->next)
- limited = 1;
-
- if (revs.topo_order)
- limited = 1;
if (!list &&
(!(revs.tag_objects||revs.tree_objects||revs.blob_objects) && !revs.pending_objects))
usage(rev_list_usage);
- if (revs.paths) {
- limited = 1;
+ if (revs.paths)
diff_tree_setup_paths(revs.paths);
- }
- if (revs.max_age || revs.min_age)
- limited = 1;
save_commit_buffer = verbose_header;
track_object_refs = 0;
if (!merge_order) {
sort_by_date(&list);
- if (list && !limited && revs.max_count == 1 &&
+ if (list && !revs.limited && revs.max_count == 1 &&
!revs.tag_objects && !revs.tree_objects && !revs.blob_objects) {
show_commit(list->item);
return 0;
}
- if (limited)
+ if (revs.limited)
list = limit_list(list);
if (revs.topo_order)
sort_in_topological_order(&list, revs.lifo);
diff --git a/revision.c b/revision.c
index 17dbf9a..0422593 100644
--- a/revision.c
+++ b/revision.c
@@ -143,8 +143,10 @@ static struct commit *get_commit_referen
object->flags |= flags;
if (parse_commit(commit) < 0)
die("unable to parse commit %s", name);
- if (flags & UNINTERESTING)
+ if (flags & UNINTERESTING) {
mark_parents_uninteresting(commit);
+ revs->limited = 1;
+ }
return commit;
}
@@ -255,10 +257,12 @@ int setup_revisions(int argc, const char
}
if (!strncmp(arg, "--max-age=", 10)) {
revs->max_age = atoi(arg + 10);
+ revs->limited = 1;
continue;
}
if (!strncmp(arg, "--min-age=", 10)) {
revs->min_age = atoi(arg + 10);
+ revs->limited = 1;
continue;
}
if (!strcmp(arg, "--all")) {
@@ -277,11 +281,13 @@ int setup_revisions(int argc, const char
}
if (!strcmp(arg, "--topo-order")) {
revs->topo_order = 1;
+ revs->limited = 1;
continue;
}
if (!strcmp(arg, "--date-order")) {
revs->lifo = 0;
revs->topo_order = 1;
+ revs->limited = 1;
continue;
}
if (!strcmp(arg, "--dense")) {
@@ -309,6 +315,11 @@ int setup_revisions(int argc, const char
revs->edge_hint = 1;
continue;
}
+ if (!strcmp(arg, "--unpacked")) {
+ revs->unpacked = 1;
+ revs->limited = 1;
+ continue;
+ }
*unrecognized++ = arg;
left++;
continue;
@@ -365,6 +376,8 @@ int setup_revisions(int argc, const char
commit = get_commit_reference(revs, def, sha1, 0);
add_one_commit(commit, revs);
}
+ if (revs->paths)
+ revs->limited = 1;
*unrecognized = NULL;
return left;
}
diff --git a/revision.h b/revision.h
index 5170ac4..a22f198 100644
--- a/revision.h
+++ b/revision.h
@@ -21,7 +21,9 @@ struct rev_info {
tag_objects:1,
tree_objects:1,
blob_objects:1,
- edge_hint:1;
+ edge_hint:1,
+ limited:1,
+ unpacked:1;
/* special limits */
int max_count;
^ permalink raw reply related
* Re: the war on trailing whitespace
From: Andreas Ericsson @ 2006-02-27 16:41 UTC (permalink / raw)
To: Uwe Zeisberger; +Cc: git
In-Reply-To: <20060227163709.GA12538@informatik.uni-freiburg.de>
Uwe Zeisberger wrote:
> Andreas Ericsson wrote:
>
>>Uwe Zeisberger wrote:
>>
>>>Hello,
>>>
>>>Andreas Ericsson wrote:
>>>
>>>
>>>>I think the question is whether completely empty lines are also ignored
>>>>by Python, or if they start a new block of code. Whatever the case, it
>>>>must hold true for both 2.3 and 2.4.
>>>
>>>see
>>> http://www.python.org/doc/2.2.3/ref/blank-lines.html
>>> http://www.python.org/doc/2.3.5/ref/blank-lines.html
>>> http://www.python.org/doc/2.4.2/ref/blank-lines.html
>>>
>>
>>So in essence, a multi-line statement is closed when a completely empty
>>line is found,
>
> Wrong.
>
> i.e. In scripts, lines containing only (zero or more) whitespaces are
> ignored.
>
I stand corrected. Thrice, even. Voi, voi... :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: the war on trailing whitespace
From: Uwe Zeisberger @ 2006-02-27 16:37 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4403086F.5040704@op5.se>
Andreas Ericsson wrote:
> Uwe Zeisberger wrote:
> >Hello,
> >
> >Andreas Ericsson wrote:
> >
> >>I think the question is whether completely empty lines are also ignored
> >>by Python, or if they start a new block of code. Whatever the case, it
> >>must hold true for both 2.3 and 2.4.
> >
> >see
> > http://www.python.org/doc/2.2.3/ref/blank-lines.html
> > http://www.python.org/doc/2.3.5/ref/blank-lines.html
> > http://www.python.org/doc/2.4.2/ref/blank-lines.html
> >
>
> So in essence, a multi-line statement is closed when a completely empty
> line is found,
Wrong.
A logical line that contains only spaces, tabs, formfeeds and possibly a
comment, is ignored (i.e., no NEWLINE token is generated). During
interactive input of statements, handling of a blank line may differ
depending on the implementation of the read-eval-print loop. In the
standard implementation, an entirely blank logical line (i.e. one
containing not even whitespace or a comment) terminates a multi-line
statement.
To translate that to python:
if not interactive:
a line only containing whitespace is ignored.
else:
if standard implementation:
empty line terminates multi-line statement
else:
dependent on implementation
i.e. In scripts, lines containing only (zero or more) whitespaces are
ignored.
hth
Uwe
--
Uwe Zeisberger
Set the I_WANT_A_BROKEN_PS environment variable to force BSD syntax ...
-- manpage of procps
^ permalink raw reply
* Re: Quick question: how to generate a patch?
From: Linus Torvalds @ 2006-02-27 16:32 UTC (permalink / raw)
To: Aubrey; +Cc: git
In-Reply-To: <6d6a94c50602270818k5f82bb8ft68a19899db3db636@mail.gmail.com>
On Tue, 28 Feb 2006, Aubrey wrote:
>
> No, what I did was just "git clone" one repository to my local directory.
> And entered the local directory to modify one file I wanted.
> Then I run "git diff > my.patch". The "my.patch" was supposed to
> contain one file diff information. But it contained the all the files,
> including which were not changed.
It really should "just have worked". Can you show what the diff actually
looked like, and your exact command history?
If it was something like
git clone remote-repo localdir
cd localdir
vi somefile
git diff
then you did everything right, and if it gives any diff other than your
changes to "somefile", something is buggy. Need more info.
Does "git diff" and "git diff HEAD" give different results, btw?
Linus
^ permalink raw reply
* Re: the war on trailing whitespace
From: Adrien Beau @ 2006-02-27 16:22 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Uwe Zeisberger, git
In-Reply-To: <4403086F.5040704@op5.se>
On 2/27/06, Andreas Ericsson <ae@op5.se> wrote:
>
> So in essence, a multi-line statement is closed when a completely empty
> line is found, which means that making git internals recognize and strip
> such lines will result in Python code never being manageable by git.
Incorrect. This is only the case in the *interactive* interpreter in
the standard implementation. For source code in general, quoting the
Python Reference Manual:
"A logical line that contains only spaces, tabs, formfeeds and
possibly a comment, is ignored (i.e., no NEWLINE token is generated)."
So such lines, whether completely empty or only apparently so (i.e.
dirty), are ignored, and can be safely cleaned-up.
Adrien
^ permalink raw reply
* Re: Quick question: how to generate a patch?
From: Aubrey @ 2006-02-27 16:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602270801280.22647@g5.osdl.org>
> > The file my.patch is generated. But the unchanged files information is
> > also included in the patch file. It should be quiet.
>
> It sounds like your index is not synchronized with your file contents.
> Have you done "touch" on files? Or edited them, and then edited them back?
>
> If so, "git-update-index --refresh" will re-synchronize your index with
> whatever file contents you have.
>
No, what I did was just "git clone" one repository to my local directory.
And entered the local directory to modify one file I wanted.
Then I run "git diff > my.patch". The "my.patch" was supposed to
contain one file diff information. But it contained the all the files,
including which were not changed.
Thanks to reply. I''ll try to Andreas's suggestion.
Regards,
-Aubrey
^ permalink raw reply
* Re: the war on trailing whitespace
From: Josef Weidendorfer @ 2006-02-27 16:08 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4403086F.5040704@op5.se>
On Monday 27 February 2006 15:10, you wrote:
> So in essence, a multi-line statement is closed when a completely empty
> line is found,
As I read this reference, such handling of completely empty lines is
done only in interactive mode, ie. when python is attached to a terminal...
Git is about storing python scripts, and not "interactive input"; therefore,
this seems to be a non-issue.
I just checked it. The following, with a completely empty line 3, is working
as expected, and not looping on an empty statement:
===================
a = ['cat', 'window', 'defenestrate']
for x in a:
print x, len(x)
===================
Josef
PS: I am not a python programmer...
^ permalink raw reply
* Re: Quick question: how to generate a patch?
From: Linus Torvalds @ 2006-02-27 16:04 UTC (permalink / raw)
To: Aubrey; +Cc: git
In-Reply-To: <6d6a94c50602270657m453cc581p6ec290c20879de25@mail.gmail.com>
On Mon, 27 Feb 2006, Aubrey wrote:
>
> I'm a newbie of git. I have a question about how to generate a patch by git.
> I want to make a patch againt git repository HEAD. So in my local
> tree, I do the command:
>
> git diff -p > my.patch
You don't need the "-p" - it's the default for "git diff".
> The file my.patch is generated. But the unchanged files information is
> also included in the patch file. It should be quiet.
It sounds like your index is not synchronized with your file contents.
Have you done "touch" on files? Or edited them, and then edited them back?
If so, "git-update-index --refresh" will re-synchronize your index with
whatever file contents you have.
Linus
^ permalink raw reply
* gitview: Fix the encoding related bug
From: Aneesh Kumar K.V @ 2006-02-27 15:55 UTC (permalink / raw)
To: git, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0001-gitview-Fix-the-encoding-related-bug.txt --]
[-- Type: text/plain, Size: 2871 bytes --]
Subject: gitview: Fix the encoding related bug
Get the encoding information from repository and convert it to utf-8 before
passing to gtk.TextBuffer.set_text. gtk.TextBuffer.set_text work only with utf-8
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 20 ++++++++++++++------
1 files changed, 14 insertions(+), 6 deletions(-)
0900cf4b80aa18e314aa487d84189b8237d088e7
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 4e3847d..1d042e3 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -391,7 +391,7 @@ class DiffWindow:
sourceview.show()
- def set_diff(self, commit_sha1, parent_sha1):
+ def set_diff(self, commit_sha1, parent_sha1, encoding):
"""Set the differences showed by this window.
Compares the two trees and populates the window with the
differences.
@@ -401,7 +401,7 @@ class DiffWindow:
return
fp = os.popen("git diff-tree -p " + parent_sha1 + " " + commit_sha1)
- self.buffer.set_text(fp.read())
+ self.buffer.set_text(unicode(fp.read(), encoding).encode('utf-8'))
fp.close()
self.window.show()
@@ -430,6 +430,7 @@ class GitView:
self.window.set_border_width(0)
self.window.set_title("Git repository browser")
+ self.get_encoding()
self.get_bt_sha1()
# Use three-quarters of the screen by default
@@ -468,6 +469,13 @@ class GitView:
self.bt_sha1[sha1].append(name)
fp.close()
+ def get_encoding(self):
+ fp = os.popen("git repo-config --get i18n.commitencoding")
+ self.encoding=string.strip(fp.readline())
+ fp.close()
+ if (self.encoding == ""):
+ self.encoding = "utf-8"
+
def construct(self):
"""Construct the window contents."""
@@ -683,7 +691,7 @@ class GitView:
self.revid_label.set_text(revid_label)
self.committer_label.set_text(committer)
self.timestamp_label.set_text(timestamp)
- self.message_buffer.set_text(message)
+ self.message_buffer.set_text(unicode(message, self.encoding).encode('utf-8'))
for widget in self.parents_widgets:
self.table.remove(widget)
@@ -728,7 +736,7 @@ class GitView:
button.set_relief(gtk.RELIEF_NONE)
button.set_sensitive(True)
button.connect("clicked", self._show_clicked_cb,
- commit.commit_sha1, parent_id)
+ commit.commit_sha1, parent_id, self.encoding)
hbox.pack_start(button, expand=False, fill=True)
button.show()
@@ -967,10 +975,10 @@ class GitView:
self.treeview.grab_focus()
- def _show_clicked_cb(self, widget, commit_sha1, parent_sha1):
+ def _show_clicked_cb(self, widget, commit_sha1, parent_sha1, encoding):
"""Callback for when the show button for a parent is clicked."""
window = DiffWindow()
- window.set_diff(commit_sha1, parent_sha1)
+ window.set_diff(commit_sha1, parent_sha1, encoding)
self.treeview.grab_focus()
if __name__ == "__main__":
--
1.2.3.g2cf3-dirty
^ permalink raw reply related
* Re: Quick question: how to generate a patch?
From: Andreas Ericsson @ 2006-02-27 15:28 UTC (permalink / raw)
To: Aubrey; +Cc: git
In-Reply-To: <6d6a94c50602270657m453cc581p6ec290c20879de25@mail.gmail.com>
Aubrey wrote:
> Hi all,
>
> I'm a newbie of git. I have a question about how to generate a patch by git.
> I want to make a patch againt git repository HEAD. So in my local
> tree, I do the command:
>
> git diff -p > my.patch
>
> The file my.patch is generated. But the unchanged files information is
> also included in the patch file. It should be quiet.
> Was I wrong to use git by this way?
>
> Thanks for your hints.
>
The current best practice involves these steps:
1. Create a topic branch (git checkout -b feature-name)
2. Apply your changes and commit them, preferrably in small and isolated
steps, making sure it compiles after each change.
3. Run "git format-patch origin".
This will result in one or more commit-patches, which contains your
author info, the commit-messages you wrote, the commit-time and all
other such info and ofcourse the diff in unified git format. You can
send those patches on using "git send-email" or apply them using "git am
-k 00*.txt".
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: cg-status and empty directories
From: Andreas Ericsson @ 2006-02-27 15:22 UTC (permalink / raw)
To: Jim MacBaine; +Cc: git
In-Reply-To: <3afbacad0602270643k9fdd255w8f3769ad77c54e65@mail.gmail.com>
Jim MacBaine wrote:
> Hello,
>
> Short story: Recently I noticed a change in the way, cogito handles
> empty directories. Before, empty directories have been silently
> ignored. Now cg-status always lists the status of empty directories as
> unknown, but it still refuses to add them. If there is a good reason
> for this behaviour, can someone enlighten me?
>
> Long story: I'm using cogito to track and distribute changes on the
> /etc directories of a few (almost) identical machines. Whenever I
> install a package which modifies somthing in /etc, I commit those
> changes. But with cg-status reporting all the empty directories as
> "unknown", my brain needs a long time to parse the list and find the
> really unknown files which shall be put under version control.
>
> Many packages put empty directories under /etc, and although only a
> few of those directories are actually needed, the automatic removal of
> those packages will fail if I remove the empty directories manually.
> Equally, the removal will fail, if I put a .placeholder file into
> those direrectories and cg-add it. Is there a simple way out?
>
I'm afraid not.
You should also note that git doesn't track permissions exactly. It just
notices an execution bit and uses it to determine if it should write the
working tree using (0666 ^ umask) or (0777 ^ umask). This makes it
fairly unsuitable for /etc tracking unless you add some sort of
permission restoring thing to it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: the war on trailing whitespace
From: Randal L. Schwartz @ 2006-02-27 15:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Peter Hagervall, Andreas Ericsson, git
In-Reply-To: <Pine.LNX.4.63.0602271539160.4371@wbgn013.biozentrum.uni-wuerzburg.de>
>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Johannes> Exactly. That is what Andreas is saying: if you change a line which
Johannes> consists only of trailing whitespace to an empty line, it breaks python
Johannes> (or formatting).
[insert standard rant about Python treating invisible things significantly,
which is the prime counter-rant to people saying Perl looks like line noise]
[chuckling]
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Quick question: how to generate a patch?
From: Aubrey @ 2006-02-27 14:57 UTC (permalink / raw)
To: git
Hi all,
I'm a newbie of git. I have a question about how to generate a patch by git.
I want to make a patch againt git repository HEAD. So in my local
tree, I do the command:
git diff -p > my.patch
The file my.patch is generated. But the unchanged files information is
also included in the patch file. It should be quiet.
Was I wrong to use git by this way?
Thanks for your hints.
Regards,
-Aubrey
^ permalink raw reply
* cg-status and empty directories
From: Jim MacBaine @ 2006-02-27 14:43 UTC (permalink / raw)
To: git
Hello,
Short story: Recently I noticed a change in the way, cogito handles
empty directories. Before, empty directories have been silently
ignored. Now cg-status always lists the status of empty directories as
unknown, but it still refuses to add them. If there is a good reason
for this behaviour, can someone enlighten me?
Long story: I'm using cogito to track and distribute changes on the
/etc directories of a few (almost) identical machines. Whenever I
install a package which modifies somthing in /etc, I commit those
changes. But with cg-status reporting all the empty directories as
"unknown", my brain needs a long time to parse the list and find the
really unknown files which shall be put under version control.
Many packages put empty directories under /etc, and although only a
few of those directories are actually needed, the automatic removal of
those packages will fail if I remove the empty directories manually.
Equally, the removal will fail, if I put a .placeholder file into
those direrectories and cg-add it. Is there a simple way out?
Regards,
Jim
^ permalink raw reply
* Re: the war on trailing whitespace
From: Johannes Schindelin @ 2006-02-27 14:40 UTC (permalink / raw)
To: Peter Hagervall; +Cc: Andreas Ericsson, git
In-Reply-To: <20060227143147.GA12196@brainysmurf.cs.umu.se>
Hi,
On Mon, 27 Feb 2006, Peter Hagervall wrote:
> On Mon, Feb 27, 2006 at 03:10:55PM +0100, Andreas Ericsson wrote:
> > So in essence, a multi-line statement is closed when a completely empty
> > line is found, which means that making git internals recognize and strip
> > such lines will result in Python code never being manageable by git.
> >
>
> I believe completely empty lines are to be left untouched. The war is on
> trailing whitespace.
Exactly. That is what Andreas is saying: if you change a line which
consists only of trailing whitespace to an empty line, it breaks python
(or formatting).
Hth,
Dscho
^ permalink raw reply
* Re: the war on trailing whitespace
From: Peter Hagervall @ 2006-02-27 14:31 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Uwe Zeisberger, git
In-Reply-To: <4403086F.5040704@op5.se>
On Mon, Feb 27, 2006 at 03:10:55PM +0100, Andreas Ericsson wrote:
> So in essence, a multi-line statement is closed when a completely empty
> line is found, which means that making git internals recognize and strip
> such lines will result in Python code never being manageable by git.
>
I believe completely empty lines are to be left untouched. The war is on
trailing whitespace.
/ Peter
--
Peter Hagervall......................email: hager@cs.umu.se
Department of Computing Science........tel: +46(0)90 786 7018
University of Umeå, SE-901 87 Umeå.....fax: +46(0)90 786 6126
^ permalink raw reply
* Re: the war on trailing whitespace
From: Andreas Ericsson @ 2006-02-27 14:10 UTC (permalink / raw)
To: Uwe Zeisberger; +Cc: git
In-Reply-To: <20060227133124.GA8794@informatik.uni-freiburg.de>
Uwe Zeisberger wrote:
> Hello,
>
> Andreas Ericsson wrote:
>
>>I think the question is whether completely empty lines are also ignored
>>by Python, or if they start a new block of code. Whatever the case, it
>>must hold true for both 2.3 and 2.4.
>
> see
> http://www.python.org/doc/2.2.3/ref/blank-lines.html
> http://www.python.org/doc/2.3.5/ref/blank-lines.html
> http://www.python.org/doc/2.4.2/ref/blank-lines.html
>
So in essence, a multi-line statement is closed when a completely empty
line is found, which means that making git internals recognize and strip
such lines will result in Python code never being manageable by git.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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