* Re: gitweb css - pixels?!
From: Jan Hudec @ 2007-05-08 8:36 UTC (permalink / raw)
To: Chris Riddoch; +Cc: git
In-Reply-To: <6efbd9b70705071613p23017509qaf9af12c1d14f9cb@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1731 bytes --]
On Mon, May 07, 2007 at 17:13:42 -0600, Chris Riddoch wrote:
> Hi, folks.
>
> I've been gradually converting my ~/src directory full of tarballs
> I've found interesting enough to download to a ~/repos/ directory
> containing bare git repositories of the projects. I was thinking it
> might be worth my while to set up gitweb so I can peruse my collection
> of projects.
>
> I noticed myself squinting, on my 1400x1050 laptop screen, at the 10
> and 12-*pixel* font settings gitweb's CSS specifies before thinking to
> myself that I should bring this to the list's attention.
>
> I'm no CSS guru, or I'd just provide a patch. It seems that *all* the
> measurements specified in the CSS file are in pixels, not ems or
> percentages. There's got to be a better way. I can't be the only
> person who would rather use my nice screen to render attractive,
> readable fonts rather than to render the smallest possible fonts?
Well, there should be three ways to set font sizes:
1. Use the symbolic small, normal, large..., which are derived from user
settings (normal is user setting, large is one step larger etc.). IMHO
this would be the best variant.
2. Use *points* (pt) instead of *pixels* (px). Unfortunately most browsers
don't know what their DPI is and will treat 1pt as 1px, even though they
have more than 72dpi. I believe this applies to all Micro$oft browsers.
3. Use designation relative to previous font. One step up is 1.2em, one step
down is 0.8333333em. I am not sure this actually works in Micro$oft
browsers. Also rounding errors may quickly get you to completely
different font size that you wanted.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Yet another git perforce integration
From: Simon Hausmann @ 2007-05-08 8:23 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2430 bytes --]
Hi,
Integrations of Git with Perforce seem to be fashion these days, so I'd like
to chip in and announce another one :)
I've written a Python script called git-p4 that allows (incremental) imports
from Perforce as well as submitting changes back from git into a Perforce
depot.
It is currently part of the fast-export repository that Chris Lee started at
http://repo.or.cz/w/fast-export.git
I've been using it now for about a month for my everyday work (which requires
Perforce), so it seems to work reasonably stable at least in my setup :)
The usage is pretty simple:
git-p4 clone //depot/path/my/project
Syncing:
git-p4 sync
or just
git-p4 rebase
to sync and automatically rebase into the current branch (much like git-svn
rebase :)
git-p4 submit
is used to submit changes back into Perforce (use at your own risk! :)
The import itself uses git-fast-import, so it's very fast. There is also no
need to have the imported Perforce projects in the Perforce client view as it
just uses "p4 changes //depot/path" and "p4
print //depot/path/file#revision", which I find very convenient and still
fast enough for use (since of course only changed files are printed).
It also doesn't require any additional meta-data. Instead every import commit
has a line added to the log message that contains the Perforce path the
changeset comes from as well as the change number. git-p4
sync/rebase "parses" this on the last commit in the "p4" git branch to find
out where to continue importing for incremental imports.
What's still missing is a bit of cleanup. For example I'd like to put the
import branch into refs/remotes instead of refs/heads, but I've had some
problems with fast-import when trying that. Also the support for Perforce
branches isn't quite working yet. I'd ideally like to for example map a
structure like
//depot/project/main
//depot/project/branch1
//depot/project/branch2
into
remotes/p4/main
remotes/p4/branch1
remotes/p4/branch2
in git and still support incremental commits. But that isn't working yet ;(
Also I've never tried it on Windows and I expect problems as the script uses
pipes, calls "patch", etc.
Nevertheless I hope that this tool may be interesting for others as well.
Maybe there's a possibility of including it in git/contrib/fast-import?
Simon
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Karl Hasselström @ 2007-05-08 7:37 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Julian Phillips, Matthieu Moy, git
In-Reply-To: <20070508014114.GC11311@spearce.org>
On 2007-05-07 21:41:14 -0400, Shawn O. Pearce wrote:
> Karl Hasselström <kha@treskal.com> wrote:
>
> > I thought "git add -i" was the best thing since sliced bread --
> > until I found the same feature in git-gui, but with a _much_
> > better interface. Just right-click on a hunk in a diff, and you
> > have the option of staging/unstaging that hunk. Pure magic.
>
> "git add -i" has a hunk splitting feature that git-gui lacks. I'm
> thinking of adding features to git-gui to let you select a region of
> a hunk using the text selection, and then stage only that selection.
That would be useful. It's currently possible to split some hunks by
reducing the number of content lines, but if the changes aren't
separated by any unchanged lines at all, that doesn't work.
> I also want to let you revert hunks from the working directory copy.
That would be handy. But unlike stage/unstage, this can lose
information, so there'd need to be some kind of "are you _really_
sure? [Yes] [No]" safety hatch, which would make it less convenient.
> But after reading Junio's comments about "git add -i" being a
> possibly bad idea and instead letting you park everything into a
> shelf, reset --hard your working directory to HEAD and then pull
> things back off the shelf to be staged, I might want to do that
> differently in git-gui... like use a shelf. ;-)
A shelf could be handy. Actually, it could be handy to have more than
one. Then one could go through the mess in one's working directory and
toss changes into one bin for each commit one plans to create --
including one "trash" bin for hunks one would like to revert.
I assume that shelves would be implemented as branches that are
precisely one commit on top of HEAD? If so, I'd just like to point out
that they're exactly like unapplied patches in StGIT.
Hmm. I find it inconsistent to force or strongly encourage the user to
commit precisely the working directory changes and not a subset
thereof, which the shelf idea seems to encourage, while at the same
time not committing straight from the working directory but from a
specific staging area (the index).
> But I'm glad someone else finds the hunk feature useful in git-gui.
> I use it far too often myself.
I don't think it's a bad thing. If I've made several unrelated changes
and want to commit them separately for the sake of readable history,
how exactly is that a bad thing when compared to committing it all at
once? If I care about clean history in the first place, then
presumably I'll test the commits in isolation if I deem it necessary
-- and if I don't, then I probably won't test anyway even if the tool
makes it easy.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Jeff King @ 2007-05-08 7:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: spearce, git
In-Reply-To: <17983.6136.147062.346626@cargo.ozlabs.ibm.com>
On Mon, May 07, 2007 at 10:13:44PM +1000, Paul Mackerras wrote:
> I have thought about rewriting it in a different language, but I
> haven't found anything that really appeals. I don't want to go to
> C/GTK or C/Qt since that would make it hard to port to Windows and
> MacOS AFAIK. Python/Tk would be a possibility, but I have never
> learnt python and I'm actually not all that comfortable with having to
> do things the object-oriented way.
>
> Any suggestions?
I just ran across this today (it was just packaged for Debian):
http://developer.imendio.com/projects/giggle
It seems to be a C/GTK repository browser (but also with a few git-gui
type features). It doesn't seem very far along (the viewer barfs on the
git.git repo, but shows some of my simpler repos), but it might worth
starting a dialogue with those guys.
-Peff
^ permalink raw reply
* Re: [PATCH] Use .git/MERGE_MSG in cherry-pick/revert
From: Gerrit Pape @ 2007-05-08 7:20 UTC (permalink / raw)
To: git
In-Reply-To: <20070508015447.GA22253@spearce.org>
On Mon, May 07, 2007 at 09:54:47PM -0400, Shawn O. Pearce wrote:
> Rather than storing the temporary commit message data in .msg (in
> the working tree) we now store the message data in .git/MERGE_MSG.
Hi, there's one more error message referring to '.msg':
static void add_to_msg(const char *string)
{
int len = strlen(string);
if (write_in_full(msg_fd, string, len) < 0)
die ("Could not write to .msg");
}
Thanks, Gerrit.
^ permalink raw reply
* Deprecate git-svnimport?
From: Steven Grimm @ 2007-05-08 7:16 UTC (permalink / raw)
To: git
In-Reply-To: <9fb1551c0705072048u3ff85ea7n5166596855b8f322@mail.gmail.com>
On 5/7/07, Steven Grimm <koreth@midwinter.com> wrote:
> Try git-svn rather than git-svnimport. The latter, AFAIK, is no longer
> really maintained. ...
I said that because in the time I've been using git and reading this
list, I think I've seen a grand total of one patch to git-svnimport, a
ton of them to git-svn, and an occasional new user posting about
git-svnimport failing to do something that git-svn would have done if
they'd used it instead.
It looks like git-svnimport hasn't been updated to the 1.5.x remote
branch naming convention (it still calls the svn head tracking branch
"origin" if its manpage is to be believed).
Originally it looked like git-svn was what you used if you wanted to
track just one svn branch bidirectionally, and git-svnimport was how you
tracked multiple svn branches read-only. But now that git-svn has good
handling of multi-branch svn repositories, I wonder if git-svnimport
still serves a purpose. Should it perhaps be deprecated and removed in a
future release? Or is it still useful for things that git-svn doesn't
handle?
-Steve
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Johannes Sixt @ 2007-05-08 7:15 UTC (permalink / raw)
To: git
In-Reply-To: <20070508014114.GC11311@spearce.org>
"Shawn O. Pearce" wrote:
> But I'm glad someone else finds the hunk feature useful in
> git-gui. I use it far too often myself.
It it among the most-wanted features here. We discovered it only because
Karl mentioned it yesterday. ;)
-- Hannes
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Marco Costalba @ 2007-05-08 6:30 UTC (permalink / raw)
To: Alex Riesen, Paul Mackerras
Cc: Linus Torvalds, Karl Hasselstr?m, Junio C Hamano, Carl Worth,
Michael Niedermayer, Git Mailing List
In-Reply-To: <81b0412b0705070556o25289676i2df60ad84a2a4e13@mail.gmail.com>
On 5/7/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 5/7/07, Paul Mackerras <paulus@samba.org> wrote:
> > I have thought about rewriting it in a different language, but I
> > haven't found anything that really appeals. I don't want to go to
> > C/GTK or C/Qt since that would make it hard to port to Windows and
> > MacOS AFAIK. Python/Tk would be a possibility, but I have never
>
> C++/Qt4 is ported to Windows.
>
> > Any suggestions?
>
> It(Qt4) wasn't a suggestion though. I still consider Tcl/Tk more portable.
> -
Qt4 is a very good designed and elegant API and it works perfectly
under Windows, see current porting of qgit under Windows:
git://git.kernel.org/pub/scm/qgit/qgit4
Language to use is C++, not C (much more powerful IMHO)
One thing that you should note is that if you go Qt4/C++ you can
forget to have it all in one file.
I think you should consider the new gitk 'footprint' becuase if you
leave TCL, any windows library you use will force you to create a
multi file project.
Marco
P.S: If you choose Qt/C++ (the best technically speaking ;-) please
you could consider starting from an already laid out code base instead
of starting from scratch.
As example, hmmmm, I think there is one called 'qgit', if I remember
correctly. It's nice and very very very fast.
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Martin Langhoff @ 2007-05-08 5:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.98.0705072137450.3974@woody.linux-foundation.org>
On 5/8/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, 8 May 2007, Martin Langhoff wrote:
> > Heh. Making the index very visible makes sense when you are merging,
> > Linus and Junio are both integrators and spend a lot of time merging.
> > Hence the default is for git-commit to observe the index.
>
> It is definitely true that some of the advantages of the way git does the
> index really start shinign when merging and you have content conflicts.
> What we've done to "git diff" really makes things a lot easier (and
> anybody who hasn't used "gitk --merge" after a content conflict really
> hasn't realized how *helpful* git is when merging content conflicts).
Totally, when merging git's approach is incredibly useful. gitk
--merge and the resolved conflicts not appearing in the default git
diff is great stuff.
For for small, simpleminded and mostly-linear development it's not
that important. Of course, I use git on projects large and small, so I
can understand it. For someone using it with a small mostly-linear
project, the whole index thing is overkill, and the explanations
pointless. I can understand people wondering WTF.
> So the whole "update stuff to be committed explicitly" ends up _really_
> shining during a merge, but it actually is how I do non-merge development
> too.
On a large project it's always a good idea to commit with explicit
paths -- regardless of your SCM. As it happens, I have to use explicit
paths with CVS, or it'll punish me by taking solid minutes to do a 2
file commit. I am sure that the mozilla and OpenOffice developers
using CVS also commit with explicit paths. Life's too short to waste
an hour.
(The times are from working on Moodle, hosted on SF.net with ~4K
files, 700 directories.).
cheers,
m
^ permalink raw reply
* Re: [ANNOUNCE] git-gui 0.7.0-rc1
From: Shawn O. Pearce @ 2007-05-08 5:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejlr52bj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > I'm tagging this release as rc1 as I hope to get a few more
> > improvements in this week, before I call it 0.7.0 final.
>
> So we will expect git 1.5.2 to ship with 0.7.0 perhaps mid to
> late next week?
Yes, that would be the plan.
--
Shawn.
^ permalink raw reply
* Re: [ANNOUNCE] git-gui 0.7.0-rc1
From: Junio C Hamano @ 2007-05-08 5:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070508040551.GJ11311@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> I'm tagging this release as rc1 as I hope to get a few more
> improvements in this week, before I call it 0.7.0 final.
So we will expect git 1.5.2 to ship with 0.7.0 perhaps mid to
late next week?
^ permalink raw reply
* Re: [PATCH] remove unnecessary loop
From: Junio C Hamano @ 2007-05-08 5:05 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <4640015F.1080407@gmail.com>
Liu Yubao <yubao.liu@gmail.com> writes:
> Here is a ugly fix, I don't hope it will be merged into git tree as it's not
> git's fault, I will file a bug report for Cygwin.
> @@ -50,9 +53,18 @@ static void prune_directory(struct dir_struct *dir, const char **pathspec, int p
> continue;
>
> /* Existing file? We must have ignored it */
> +#ifdef __CYGWIN__
> + /*
> + * On cygwin, lstat("hello", &st) returns 0 when
> + * "hello.exe" exists, so test with open() again.
> + */
> + if (lstat(match, &st) && -1 != (fd = open(match, O_RDONLY))) {
> + struct dir_entry *ent;
> + close(fd);
> +#else
We have lstat() everywhere, so if we were to work this around
without (or "waiting for") a proper fix on the Cygwin side, you
would be better off wrapping the above sequence in a separate
function (say "sane_lstat()"), and do
#ifdef __CYGWIN__
#define lstat(a,b) sane_lstat(a,b)
#endif
somewhere near the top of git-compat-util.h
^ permalink raw reply
* Re: [PATCH] wcwidth redeclaration
From: Junio C Hamano @ 2007-05-08 5:02 UTC (permalink / raw)
To: Amos Waterland; +Cc: git
In-Reply-To: <20070508044608.GA32223@us.ibm.com>
apw@us.ibm.com (Amos Waterland) writes:
> Build fails for git 1.5.1.3 on AIX, with the message:
>
> utf8.c:66: error: conflicting types for 'wcwidth'
> /.../lib/gcc/powerpc-ibm-aix5.3.0.0/4.0.3/include/string.h:266: error: previous declaration of 'wcwidth' was here
>
> Here is a patch that fixes it for me. If there is a different way that
> is preferred, please let me know.
It's static in that file, so renaming our version to our own
name as you did is perfectly good.
Thanks for helping, as not many people seem to be on AIX on this
list.
^ permalink raw reply
* Re: [PATCH] remove unnecessary loop
From: Liu Yubao @ 2007-05-08 4:49 UTC (permalink / raw)
To: git
In-Reply-To: <463FEC07.8080605@gmail.com>
Liu Yubao wrote:
> Hi,
> Here is a minor optimization, the involved second "for" loop doesn't
> need to start from beginning.
>
I found it when I debugged a strange problem on Cygwin, at last, I think
it's a bug of Cygwin.
$ touch hello.exe
$ git add hello
The following paths are ignored by one of your .gitignore files:
hello
Use -f if you really want to add them.
Here is a ugly fix, I don't hope it will be merged into git tree as it's not
git's fault, I will file a bug report for Cygwin.
---
builtin-add.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 9d10fdc..ff1e74f 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -42,6 +42,9 @@ static void prune_directory(struct dir_struct *dir, const char **pathspec, int p
for (i = 0; i < specs; i++) {
struct stat st;
const char *match;
+#ifdef __CYGWIN__
+ int fd;
+#endif
if (seen[i])
continue;
@@ -50,9 +53,18 @@ static void prune_directory(struct dir_struct *dir, const char **pathspec, int p
continue;
/* Existing file? We must have ignored it */
+#ifdef __CYGWIN__
+ /*
+ * On cygwin, lstat("hello", &st) returns 0 when
+ * "hello.exe" exists, so test with open() again.
+ */
+ if (lstat(match, &st) && -1 != (fd = open(match, O_RDONLY))) {
+ struct dir_entry *ent;
+ close(fd);
+#else
if (!lstat(match, &st)) {
struct dir_entry *ent;
-
+#endif
ent = dir_add_name(dir, match, strlen(match));
ent->ignored = 1;
if (S_ISDIR(st.st_mode))
--
1.5.2.rc0.95.ga0715-dirty
^ permalink raw reply related
* [PATCH] wcwidth redeclaration
From: Amos Waterland @ 2007-05-08 4:46 UTC (permalink / raw)
To: git
Build fails for git 1.5.1.3 on AIX, with the message:
utf8.c:66: error: conflicting types for 'wcwidth'
/.../lib/gcc/powerpc-ibm-aix5.3.0.0/4.0.3/include/string.h:266: error: previous declaration of 'wcwidth' was here
Here is a patch that fixes it for me. If there is a different way that
is preferred, please let me know.
Signed-off-by: Amos Waterland <apw@us.ibm.com>
---
utf8.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- utf8.c.orig Tue May 8 00:40:18 2007
+++ utf8.c Tue May 8 00:45:00 2007
@@ -62,7 +62,7 @@
* in ISO 10646.
*/
-static int wcwidth(ucs_char_t ch)
+static int git_wcwidth(ucs_char_t ch)
{
/*
* Sorted list of non-overlapping intervals of non-spacing characters,
@@ -207,7 +207,7 @@
return 0;
}
- return wcwidth(ch);
+ return git_wcwidth(ch);
}
int is_utf8(const char *text)
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Linus Torvalds @ 2007-05-08 4:45 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90705072016x17bd60c3ic779459438ffc19@mail.gmail.com>
On Tue, 8 May 2007, Martin Langhoff wrote:
>
> Heh. Making the index very visible makes sense when you are merging,
> Linus and Junio are both integrators and spend a lot of time merging.
> Hence the default is for git-commit to observe the index.
It is definitely true that some of the advantages of the way git does the
index really start shinign when merging and you have content conflicts.
What we've done to "git diff" really makes things a lot easier (and
anybody who hasn't used "gitk --merge" after a content conflict really
hasn't realized how *helpful* git is when merging content conflicts).
However, in all honesty, while the whole "index for merges" comes from
pretty damn early in git history (the whole "stage number" thing appeared
on April 15th 2005 - so it was about a week after the first release), it
wasn't the original impetus of the way git works.
Git used explicit index updates from day 1, even before it did the first
merge. It's simply how I've always worked. I tend to have dirty trees,
with some random patch in my tree that I do *not* want to commit, because
it's just a Makefile update for the next version (to remind me - I've
released kernel versions too many times with an old version number, just
because I forgot to update the Makefile).
Or other things like that - I have small test-patches in my tree that I
want to build, but that I don't want to commit, and I end up doing big
merges and whole patch-application sequences with such a dirty tree
(obviously if the patch or merge wants to change that file, I then need to
do something about that dirty state, but it happens surprisingly seldom).
So the whole "update stuff to be committed explicitly" ends up _really_
shining during a merge, but it actually is how I do non-merge development
too.
Linus
^ permalink raw reply
* Re: gitweb css - pixels?!
From: Chris Riddoch @ 2007-05-08 4:43 UTC (permalink / raw)
To: git
In-Reply-To: <20070508012351.GB12978@lifeintegrity.com>
On 5/7/07, Allan Wind <allan_wind@lifeintegrity.com> wrote:
> On 2007-05-07T17:13:42-0600, Chris Riddoch wrote:
> > I noticed myself squinting, on my 1400x1050 laptop screen, at the 10
> > and 12-*pixel* font settings gitweb's CSS specifies before thinking to
> > myself that I should bring this to the list's attention.
>
> ctrl-+ (ctrl plus possible a couple of times) fixes that if you are
> using a browser from the Mozilla Foundation. It was perfectly readable
> for me, but I fortunate enough to have a large LCD.
Yes, I'm aware of that feature. Very handy. And entirely too necessary.
Seriously, this isn't something to push on to users. Entirely too
many websites don't follow sensible accessibility standards; shouldn't
gitweb be fixed?
--
epistemological humility
Chris Riddoch
^ permalink raw reply
* Re: [PATCH] Add --no-reuse-delta, --window, and --depth options to git-gc
From: Junio C Hamano @ 2007-05-08 4:43 UTC (permalink / raw)
To: Theodore Tso; +Cc: Nicolas Pitre, git
In-Reply-To: <20070508032122.GA10940@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> On Mon, May 07, 2007 at 11:13:58PM -0400, Nicolas Pitre wrote:
>> ...
>> Especially if you're aware and interested in those options, you won't be
>> afraid of 'git repack -a -f -d --window=...".
>>
>> In the context of "gc", having an option that reads "window" looks a bit
>> strange too.
>
> I suppose, but you either need to then know all of the other commands
> which git-gc runs, and do them manually, skipping git-gc altogether,
> or use git-gc, and end up rewriting the pack twice,...
If the user really wants to tweak the parameters that much and
that often, I think what Nico says, plus your pack.depth/window
configuration variables, make more sense. git-gc is meant to be
a shorthand with reasonable "one size fits all" default, and
there is something wrong if a user has to give customization
option every time it is run. It could be that the default
parameters are grossly off for _everybody_, in which case we
should fix the default.
With the recent introduction of delta base caching code, we
might want to tweak the default pack depth to larger value for
everybody, by the way.
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Shawn O. Pearce @ 2007-05-08 4:19 UTC (permalink / raw)
To: Paul Mackerras
Cc: Brett Schwarz, Linus Torvalds, Karl Hasselstr?m, Junio C Hamano,
Carl Worth, Michael Niedermayer, Git Mailing List
In-Reply-To: <17983.63329.314321.305860@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> wrote:
> Brett Schwarz writes:
> > As Shawn mentions below, he started using namespaces for git-gui. I
> > think gitk could benefit from that as well, along with a few other
> > changes.
>
> Gitk ends up handling pretty significant amounts of data. In
> particular the per-commit data can get to gigabytes, and processing it
> is pretty cpu-intensive. I did try using namespaces for the
> per-commit data but I found that the performance hit to be more than I
> was willing to tolerate.
If that is the case then an obvious direction is to start using C
for the actual Git operations/datastore and Tcl/Tk for the basic
UI layout and event handlers.
If we go down that path for gitk then I may wind up doing the
same for git-gui. Because gitk would require the tcl/tk heders
and libraries at that point, so also requiring them for git-gui
wouldn't be too unreasonable.
But fortunately git-gui doesn't have to deal with gigabytes
of data; I'm only really looking at the "dirty" stuff, or
at worst, the blame for an entire file.
--
Shawn.
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Paul Mackerras @ 2007-05-08 4:06 UTC (permalink / raw)
To: Brett Schwarz
Cc: Shawn O. Pearce, Linus Torvalds, Karl Hasselstr?m, Junio C Hamano,
Carl Worth, Michael Niedermayer, Git Mailing List
In-Reply-To: <57600.59393.qm@web38909.mail.mud.yahoo.com>
Brett Schwarz writes:
> What is the real issue? Is it that there isn't enough people to
The real issue is that I would like, if possible, to make it easier
for people like Linus to hack on gitk and add cool features that I
wouldn't necessarily think of.
> maintain gitk? I've been hiding in the bushes, mostly because of
> time issues, but if there's a real need, I'd be willing to help. I'm
> a seasoned Tcl/Tk coder, and wouldn't have any problems helping
> out.
That could be very useful, thanks.
> As Shawn mentions below, he started using namespaces for git-gui. I
> think gitk could benefit from that as well, along with a few other
> changes.
Gitk ends up handling pretty significant amounts of data. In
particular the per-commit data can get to gigabytes, and processing it
is pretty cpu-intensive. I did try using namespaces for the
per-commit data but I found that the performance hit to be more than I
was willing to tolerate.
Paul.
^ permalink raw reply
* [ANNOUNCE] git-gui 0.7.0-rc1
From: Shawn O. Pearce @ 2007-05-08 4:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
There have been a good deal of changes in git-gui recently.
Most significantly within the inner workings. The code has been
refactored into multiple files and I'm starting to make use of the
auto_load feature of Tcl, as well as Tcl namespaces. As you can
see by the diffstat below I moved over 4000 lines out of git-gui.sh
and into other files. ;-)
There were some minor tweaks to the git-gui Makefile variable
handling so I have pre-merged git-gui.git's master into git.git
master, handling those tweaks as part of the merge. After pulling
it in you may also want to fetch from git-gui.git to grab the
gitgui-0.7.0-rc1 tag.
I'm tagging this release as rc1 as I hope to get a few more
improvements in this week, before I call it 0.7.0 final.
---
The following changes since commit 3082acfa7c626a34aa419a163585051c2df2bf09:
Alex Riesen (1):
Use GIT_OBJECT_DIR for temporary files of pack-objects
are available in the git repository at:
repo.or.cz:/srv/git/git/fastimport.git gitgui-master
Shawn O. Pearce (16):
git-gui: Include the subject in the status bar after commit
git-gui: Warn users before making an octopus merge
git-gui: Correct line wrapping for too many branch message
git-gui: Cleanup common font handling for font_ui
git-gui: Use option database defaults to set the font
git-gui: Refactor to use our git proc more often
git-gui: Track our own embedded values and rebuild when they change
git-gui: Refactor into multiple files to save my sanity
git-gui: Move console procs into their own namespace
git-gui: Allow vi keys to scroll the diff/blame regions
git-gui: Move merge support into a namespace
git-gui: Show all possible branches for merge
git-gui: Include commit id/subject in merge choices
git-gui: Use vi-like keys in merge dialog
Merge branch 'master' of git://repo.or.cz/git-gui
Remove duplicate exports from Makefile
Makefile | 18 +-
git-gui/.gitignore | 2 +
git-gui/Makefile | 38 +-
git-gui/git-gui.sh | 4121 ++-------------------------------------------
git-gui/lib/blame.tcl | 407 +++++
git-gui/lib/branch.tcl | 572 +++++++
git-gui/lib/browser.tcl | 263 +++
git-gui/lib/commit.tcl | 410 +++++
git-gui/lib/console.tcl | 201 +++
git-gui/lib/database.tcl | 89 +
git-gui/lib/diff.tcl | 336 ++++
git-gui/lib/error.tcl | 101 ++
git-gui/lib/index.tcl | 409 +++++
git-gui/lib/merge.tcl | 309 ++++
git-gui/lib/option.tcl | 290 ++++
git-gui/lib/remote.tcl | 159 ++
git-gui/lib/shortcut.tcl | 141 ++
git-gui/lib/transport.tcl | 164 ++
18 files changed, 4009 insertions(+), 4021 deletions(-)
create mode 100644 git-gui/lib/blame.tcl
create mode 100644 git-gui/lib/branch.tcl
create mode 100644 git-gui/lib/browser.tcl
create mode 100644 git-gui/lib/commit.tcl
create mode 100644 git-gui/lib/console.tcl
create mode 100644 git-gui/lib/database.tcl
create mode 100644 git-gui/lib/diff.tcl
create mode 100644 git-gui/lib/error.tcl
create mode 100644 git-gui/lib/index.tcl
create mode 100644 git-gui/lib/merge.tcl
create mode 100644 git-gui/lib/option.tcl
create mode 100644 git-gui/lib/remote.tcl
create mode 100644 git-gui/lib/shortcut.tcl
create mode 100644 git-gui/lib/transport.tcl
--
Shawn.
^ permalink raw reply
* Re: importing multi-project svn repositories
From: Dave Hanson @ 2007-05-08 3:48 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <463F6A95.30207@midwinter.com>
On 5/7/07, Steven Grimm <koreth@midwinter.com> wrote:
> David Hanson wrote:
> > I'd like to import calc at the top level, put calc/tags/foo in git's
> > tags/calc/foo and calc/branches/baz in git's heads/calc/baz. Ditto for
> > calendar, spreadsheet, etc.
>
> Try git-svn rather than git-svnimport. The latter, AFAIK, is no longer
> really maintained. ...
Thanks for the tip. I was running git 1.5.0, which didn't support
"clone" to git-svn. I upgraded to 1.5.1.3 and followed your
suggestions.
If I decide to flush the svn repository in favor of git, I'll probably
do some manual rearrangement so that commands like "git tag -l" gives
useful results.
thanks,
dave h
^ permalink raw reply
* Re: [PATCH] user-manual: fix clone and fetch typos
From: J. Bruce Fields @ 2007-05-08 3:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi Béjar, git
In-Reply-To: <20070508033426.GD9471@fieldses.org>
On Mon, May 07, 2007 at 11:34:26PM -0400, J. Bruce Fields wrote:
> More typo fixes from Santi Béjar, plus a couple other mistakes I noticed
> along the way.
>
> Cc: Santi Béjar <sbejar@gmail.com>
> Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Hm. I still see
Content-Type: text/plain; charset=iso-8859-1
in the headers, even in the copy saved in my sent-mail folder. My
locale seems to be set to something utf-8-ish everywhere, though. Is
there some odd mutt configuration setting I'm missing someplace?
Character sets mystify me....
--b.
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Brett Schwarz @ 2007-05-08 3:39 UTC (permalink / raw)
To: Shawn O. Pearce, Paul Mackerras
Cc: Linus Torvalds, Karl Hasselstr?m, Junio C Hamano, Carl Worth,
Michael Niedermayer, Git Mailing List
Sorry for the posting, my email reader sucks.
What is the real issue? Is it that there isn't enough people to maintain gitk? I've been hiding in the bushes, mostly because of time issues, but if there's a real need, I'd be willing to help. I'm a seasoned Tcl/Tk coder, and wouldn't have any problems helping out.
Also, I've been waiting for the git lib to get done. When this gets done, a lot of the procs in gitk can be re-written in 'C' as Tcl commands. This obviously gives the advantage of speed, but since it is written in 'C', the potential maintainership would be larger. The 'C' code would just be dyn loaded into the Tcl interpreter.
As Shawn mentions below, he started using namespaces for git-gui. I think gitk could benefit from that as well, along with a few other changes.
----- Original Message ----
From: Shawn O. Pearce <spearce@spearce.org>
To: Paul Mackerras <paulus@samba.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>; Karl Hasselstr?m <kha@treskal.com>; Junio C Hamano <junkio@cox.net>; Carl Worth <cworth@cworth.org>; Michael Niedermayer <michaelni@gmx.at>; Git Mailing List <git@vger.kernel.org>
Sent: Monday, May 7, 2007 7:03:38 PM
Subject: Re: FFmpeg considering GIT
Paul Mackerras <paulus@samba.org> wrote:
> I have thought about rewriting it in a different language, but I
> haven't found anything that really appeals. I don't want to go to
> C/GTK or C/Qt since that would make it hard to port to Windows and
> MacOS AFAIK. Python/Tk would be a possibility, but I have never
> learnt python and I'm actually not all that comfortable with having to
> do things the object-oriented way.
>
> Any suggestions?
Funny that you mention this. Lately I have been hacking on git-gui,
trying to improve it and clean up some of the code.
I've thought about wxWindows but didn't really dig into it to see
how usuable it would be - primary reason is not everyone has it
installed on their system. The same for GTK and Qt. Actually I
don't even have GTK installed on my Mac but I did install Qt3
(took half a day!) so I could build qgit at one point in time.
But almost everyone already has a wish installed.
I've thought about writing git-gui in C, but linking to the Tk
library for the "portable UI". But not everyone has the Tcl/Tk
development headers and libraries installed, but they probably do
have the wish executable installed.
I want to limit the barrier to entry for git, and that means limiting
the barrier of entry for git-gui. Keeping our requirements to a
minimum helps.
So I think I've settled on sticking to Tcl and its Tk extensions,
but making more use of newer Tcl constructs like namespaces. If you
look at my `pu` branch of git-gui I have actually split the program
down into many files, and have started to organize the code in each
into different namespaces, depending on function.
--
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] Add --no-reuse-delta, --window, and --depth options to git-gc
From: Dana How @ 2007-05-08 3:38 UTC (permalink / raw)
To: Theodore Tso; +Cc: Nicolas Pitre, Junio C Hamano, git, danahow
In-Reply-To: <20070508032122.GA10940@thunk.org>
On 5/7/07, Theodore Tso <tytso@mit.edu> wrote:
> On Mon, May 07, 2007 at 11:13:58PM -0400, Nicolas Pitre wrote:
> > On Mon, 7 May 2007, Theodore Ts'o wrote:
> > > Sometimes users might want to use more aggressive packing options
> > > when doing a git-gc. This allows them to do so without having
> > > to use the low-level plumbing commands.
> > In the context of "gc", having an option that reads "window" looks a bit
> > strange too.
> I suppose, but you either need to then know all of the other commands
> which git-gc runs, and do them manually, skipping git-gc altogether,
> or use git-gc, and end up rewriting the pack twice, ince using the
> git-repack in git-gc, and then once manually so you can give the
> options that you really want to give to git-repack.
>
> Maybe the right approach is to have a way to specify default --window
> and --depth as git configuration variables? Looks like there is a
> pack.window already, but not a pack.depth.
>
> What if we add a pack.depth configuration option, and add only
> --no-reuse-delta to git-gc? Would that be better?
I would use pack.depth .
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ 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