* Re: [PATCH] gitweb: Enable tree (directory) history display
From: Linus Torvalds @ 2006-02-27 19:56 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20060227185554.75822.qmail@web31810.mail.mud.yahoo.com>
On Mon, 27 Feb 2006, Luben Tuikov wrote:
>
> This patch allows history display of whole trees/directories,
> a la "git-rev-list HEAD <dir or file>", but somewhat
> slower, since exported git repository doesn't have
> the files checked out so we have to use
> "$gitbin/git-rev-list $hash | $gitbin/git-diff-tree -r --stdin \'$file_name\'"
No no.
Just use
git-rev-list $hash -- $file_name
where the "--" is the important part.
As a usability-enhancer, you can leave out the "--" to separate filenames
and other things, but when you leave out the "--", git requires that the
filenames exist.
Linus
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Nicolas Vilz 'niv' @ 2006-02-27 19:34 UTC (permalink / raw)
To: git
In-Reply-To: <20060227184641.GA21684@hand.yhbt.net>
> Nicolas Vilz 'niv' <niv@iaglans.de> wrote:
>> 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
>
> Those messages are from git-update-ref. What were some of the messages
> from git-svn leading up to that point?
>
>> 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.
>
> You should never, ever modify the git-svn-HEAD branch yourself.
> Interface branches should never be modified. It's the golden rule of
> interfacing between different SCM interfaces. Sorry, I've been doing
> things like this this for a while now I guess I didn't make it
> abundantly clear in the documentation.
ok, i experienced that on little modifications on the git-svn-HEAD branch
either... so its really about modifying and not about the huge data
ammount...
>> now i am still on rev 2 on this branch but i updated it to rev 5 on the
>> svn-side...
>>
>> any hints?
>
> Save your current work in git-svn-HEAD to a private branch
>
> git branch -b private git-svn-HEAD
>
> then reset git-svn-HEAD to the last revision where it was managed by
> git-svn fetch:
>
> git-checkout git-svn-HEAD
> git-log (look for the last commit with 'git-svn-id:' in it)
> git-reset --hard <last commit with 'git-svn-id:' in it>
>
> Now go to your private branch:
>
> git checkout private
>
> And continue working on your private branch as usual.
I will keep that in mind for the future. Fortunatelly i am still testing
and i saved the git repository before experimenting with git-svn.
Have you any suggestions howto migrate a git-repository to svn and then
work with git-svn on both of it? I tried cg-merge -j to merge my git
branch with the private git svn branch, i am allowed to modify safely.
that does work actually... now i can start getting this automated.
perhaps i will write a patch with that automated script, when it is
finished, just to contribute git.
Sincerly
Nicolas
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Eric Wong @ 2006-02-27 19:24 UTC (permalink / raw)
To: git
In-Reply-To: <20060227185557.GA32142@delft.aura.cs.cmu.edu>
Jan Harkes <jaharkes@cs.cmu.edu> wrote:
> On Mon, Feb 27, 2006 at 10:46:41AM -0800, Eric Wong wrote:
> > > 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.
> >
> > You should never, ever modify the git-svn-HEAD branch yourself.
> > Interface branches should never be modified. It's the golden rule of
> > interfacing between different SCM interfaces. Sorry, I've been doing
> > things like this this for a while now I guess I didn't make it
> > abundantly clear in the documentation.
>
> If it is not supposed to be changed by the user, maybe it could be
> stored as a tag.
>
> Or maybe another type of reference can be introduced. refs/remote/, for
> branches we are tracking, but which should not be modified locally.
Either of those could work for me. Changing git-svn-HEAD to become a
tag would probably be easier (not having to update other tools, such as
git-fetch), but refs/remote may make more sense.
--
Eric Wong
^ permalink raw reply
* [PATCH] contrib/git-svn: tell the user to not modify git-svn-HEAD directly
From: Eric Wong @ 2006-02-27 19:04 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <20060227184641.GA21684@hand.yhbt.net>
As a rule, interface branches to different SCMs should never be modified
directly by the user. They are used exclusively for talking to the
foreign SCM.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.txt | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
4676a850ad5a9e4a88fa5dfba1ac231a58bffda1
diff --git a/contrib/git-svn/git-svn.txt b/contrib/git-svn/git-svn.txt
index b4b7789..b588a2a 100644
--- a/contrib/git-svn/git-svn.txt
+++ b/contrib/git-svn/git-svn.txt
@@ -43,6 +43,11 @@ fetch::
Fetch unfetched revisions from the SVN_URL we are tracking.
refs/heads/git-svn-HEAD will be updated to the latest revision.
+ Note: You should never attempt to modify the git-svn-HEAD branch
+ outside of git-svn. Instead, create a branch from git-svn-HEAD
+ and work on that branch. Use the 'commit' command (see below)
+ to write git commits back to git-svn-HEAD.
+
commit::
Commit specified commit or tree objects to SVN. This relies on
your imported fetch data being up-to-date. This makes
@@ -179,7 +184,9 @@ SVN repositories via one git repository.
environment variable to a name other other than "git-svn" (the default)
and git-svn will ignore the contents of the $GIT_DIR/git-svn directory
and instead do all of its work in $GIT_DIR/$GIT_SVN_ID for that
-invocation.
+invocation. The interface branch will be $GIT_SVN_ID-HEAD, instead of
+git-svn-HEAD. Any $GIT_SVN_ID-HEAD branch should never be modified
+by the user outside of git-svn commands.
ADDITIONAL FETCH ARGUMENTS
--------------------------
--
1.2.3.gfc24dc-dirty
^ permalink raw reply related
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Jan Harkes @ 2006-02-27 18:55 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20060227184641.GA21684@hand.yhbt.net>
On Mon, Feb 27, 2006 at 10:46:41AM -0800, Eric Wong wrote:
> > 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.
>
> You should never, ever modify the git-svn-HEAD branch yourself.
> Interface branches should never be modified. It's the golden rule of
> interfacing between different SCM interfaces. Sorry, I've been doing
> things like this this for a while now I guess I didn't make it
> abundantly clear in the documentation.
If it is not supposed to be changed by the user, maybe it could be
stored as a tag.
Or maybe another type of reference can be introduced. refs/remote/, for
branches we are tracking, but which should not be modified locally.
Jan
^ permalink raw reply
* [PATCH] gitweb: Enable tree (directory) history display
From: Luben Tuikov @ 2006-02-27 18:55 UTC (permalink / raw)
To: git
Hi,
I find this patch very useful, especially when a directory (tree) describes
a project.
This patch allows history display of whole trees/directories,
a la "git-rev-list HEAD <dir or file>", but somewhat
slower, since exported git repository doesn't have
the files checked out so we have to use
"$gitbin/git-rev-list $hash | $gitbin/git-diff-tree -r --stdin \'$file_name\'"
method. Maybe someone can find a speed up for this. And better yet,
maybe links can be static as opposed to dynamic, so that you don't have to
navigate each and everytime if you want to find the history of the same
directory.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb.cgi | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
5c8ae3db3561238a57201fcb3297f16d7b37f377
diff --git a/gitweb.cgi b/gitweb.cgi
index c1bb624..452528f 100755
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -1504,6 +1504,7 @@ sub git_tree {
"</td>\n" .
"<td class=\"link\">" .
$cgi->a({-href => "$my_uri?" .
esc_param("p=$project;a=tree;h=$t_hash$base_key;f=$base$t_name")}, "tree") .
+ " | " . $cgi->a({-href => "$my_uri?" .
esc_param("p=$project;a=history;h=$hash_base;f=$base$t_name")}, "history") .
"</td>\n";
}
print "</tr>\n";
--
1.2.3.g6db0
^ permalink raw reply related
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Eric Wong @ 2006-02-27 18:46 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <62502.84.163.87.135.1141063190.squirrel@mail.geht-ab-wie-schnitzel.de>
Nicolas Vilz 'niv' <niv@iaglans.de> wrote:
> 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
Those messages are from git-update-ref. What were some of the messages
from git-svn leading up to that point?
> 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.
You should never, ever modify the git-svn-HEAD branch yourself.
Interface branches should never be modified. It's the golden rule of
interfacing between different SCM interfaces. Sorry, I've been doing
things like this this for a while now I guess I didn't make it
abundantly clear in the documentation.
> now i am still on rev 2 on this branch but i updated it to rev 5 on the
> svn-side...
>
> any hints?
Save your current work in git-svn-HEAD to a private branch
git branch -b private git-svn-HEAD
then reset git-svn-HEAD to the last revision where it was managed by
git-svn fetch:
git-checkout git-svn-HEAD
git-log (look for the last commit with 'git-svn-id:' in it)
git-reset --hard <last commit with 'git-svn-id:' in it>
Now go to your private branch:
git checkout private
And continue working on your private branch as usual.
--
Eric Wong
^ permalink raw reply
* Re: NT directory traversal speed on 25K files on Cygwin
From: Rutger Nijlunsing @ 2006-02-27 18:45 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Christopher Faylor, git
In-Reply-To: <4402C40D.2010805@op5.se>
On Mon, Feb 27, 2006 at 10:19:09AM +0100, Andreas Ericsson wrote:
> 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:
> >
>
> Well, naturally. Cygwin is a userland implementation of a sane
> filesystem on top of a less sane one. File IO is bound to be slower when
> one FS is emulated on top of another. I think cygwin users are aware of
> this and simply accept the speed-for-sanity tradeoff. I know I would.
MKS NutCracker tries to solve the same issues as Cygwin tries to
solve. But maybe less sane, I don't know. But a simple 'find' is
several times faster than a Cygwin 'find'. Yes, very
unscientific. Just as unscientific as 'git is slow on Windows,
therefore Windows IO is slow'.
I'm not saying Cygwin is bad (actually, I'm installing on every
Windows PC I get my hand on ;), but using Cygwin for all file IO
instead of native Windows IO makes git a magnitude slower on Windows
than could-be. So a small portability layer with a function like
'given all filenames with all mtimes' might help, or we could look at
why Cygwin is slower in this case. Alas my Windows profiling skills
aren't that good...
Regards,
Rutger.
--
Rutger Nijlunsing ---------------------------------- eludias ed dse.nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------
^ permalink raw reply
* Re: cg-status and empty directories
From: Jim MacBaine @ 2006-02-27 18:39 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <44031941.1020806@op5.se>
On 2/27/06, Andreas Ericsson <ae@op5.se> wrote:
> 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.
I'm aware of those limitations. It is not a backup mechanism at all
and permissions are handled by a small perl script.
However, I'm just curious to know, why cg-status suddenly started to
care about empty directories.
Regards,
Jim
^ permalink raw reply
* Re: NT directory traversal speed on 25K files on Cygwin
From: Christopher Faylor @ 2006-02-27 18:34 UTC (permalink / raw)
To: git
In-Reply-To: <20060227183049.GA13195@nospam.com>
On Mon, Feb 27, 2006 at 07:30:49PM +0100, Rutger Nijlunsing wrote:
>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.
I'm going to revisit Cygwin's file I/O soon to see if I can figure out
what's adding the overhead and see if it really is inavoidable. It's
been a while since I've gone through that exercise so it should prove
instructive.
cgf
^ permalink raw reply
* 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
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