* Gitweb and submodules
From: Jakub Narebski @ 2007-07-27 11:22 UTC (permalink / raw)
To: git
I'd like to add submodule support to gitweb, among others marking
submodules as such in the 'tree' view and adding 'log' view link to
them.
But for that I need a question answered: how to find GIT_DIR of
repository which contains submodule objects? We have to assume in
gitweb that repositories are bare...
--
Jakub Narebski
Poland
^ permalink raw reply
* [RFC] Git User's Survey 2007
From: Jakub Narebski @ 2007-07-27 11:20 UTC (permalink / raw)
To: git; +Cc: Paolo Ciarrocchi
In-Reply-To: <200707250358.58637.jnareb@gmail.com>
It's been more than a year since last Git User's Survey. It would be
interesting to find what changed since then. Therefore the idea to
have another survey.
First there is a question about the form of survey. Should we use web
based survey, as the survey before (http://www.survey.net.nz), sending
emails with link to this survey, or perhaps do email based survey,
with email Reply-To: address put for this survey alone?
Second, what questions should be put in the survey, and in the case of
single choice and ultiple choice questions what possible answers
should be? Below are slightly extended questions from the last
survey. Please comment on it.
Third, where to send survey to? I was thinking about git mailing list,
LKML, and mailing list for git projects found on GitProjects page on
GIT wiki. Do you want to add some address? Or should info about GIT
User's Survey 2007 be sent also to one of on-line magazines like
LinuxToday, or asked to put on some blog?
References:
http://marc.info/?l=git&m=115116592330648&w=2
http://marc.info/?l=git&m=115364303813936&w=2
http://git.or.cz/gitwiki/GitSurvey
----
About you
1. What country are you in?
2. What is your preferred non-programming language?
3. Which programming languages you are proficient with?
(zero or more: multiple choice)
- C, shell, Perl, Python, Tcl/Tk
Getting started with GIT
1. How did you hear about GIT?
2. Did you find GIT easy to learn?
- very easy/easy/reasonably/hard/very hard
3. What helped you most in learning to use it?
4. What did you find hardest?
5. When did you start using git? From which version?
How you use GIT
1. Do you use GIT for work, unpaid projects, or both?
work/unpaid projects/work
2. How do you obtain GIT? Source tarball, binary package, or
pull the main repository?
- binary package/source tarball/pull from main repository
3. What hardware platforms do you use GIT on?
* examples: i386, x86_64, ARM, PowerPC, Alpha, g5, ...
4. What OS (please include the version) do you use GIT on?
* examples: Linux, MS Windows (Cygwin/MinGW/gitbox),
IRIX, HP-UX, Solaris, FreeBSD, ...
(please give kernel version and distribution for Linux)
5. How many people do you collaborate with using GIT?
6. How big are the repositories that you work on? (e.g. how many
files, how much disk space, how deep is the history?)
* number of files in repository: "git ls-tree -r HEAD | wc -l"
* pack size of freshly cloned fully packed repository
* number of commits in straight line, number of commits in branch
("git rev-list --first-parent HEAD | wc -l",
"git rev-list HEAD | wc -l")
7. How many different projects do you manage using GIT?
8. Which porcelains do you use?
(zero or more: multiple choice)
- core-git, cogito, StGIT, pg, guilt, other
9. Which git GUI do you use
(zero or more: multiple choice)
- gitk, git-gui, qgit, gitview, giggle, other
10. Which git web interface do you use for your projects?
- gitweb/cgit/wit (Ruby)/git-php/other
11. How do you publish/propagate your changes?
(zero or more: multiple choice)
- push, pull request, format-patch + email, bundle, other
12. Does git.git repository include code produced by you?
- yes/no
Internationalization
1. Is translating GIT required for wider adoption?
- yes/no/somewhat
2. What do you need translated?
(zero or more: multiple choice)
- GUI (git-gui, gitk, qgit, ...), git-core messages,
manpages, other documentation
3. For what language do you need translation for?
What you think of GIT
1. Overall, how happy are you with GIT?
- unhappy/not so happy/happy/very happy/completely extatic
2. How does GIT compare to other SCM tools you have used?
- worse/equal (or comparable)/better
3. What do you like about using GIT?
4. What would you most like to see improved about GIT?
(features, bugs, plugins, documentation, ...)
5. If you want to see GIT more widely used, what do you
think we could do to make this happen?
Documentation
1. Do you use the GIT wiki?
- yes/no
2. Do you find GIT wiki useful?
- yes/no/somewhat
3. Do you contribute to GIT wiki?
- yes/no/only corrections or spam removal
4. Do you find GIT's online help (homepage, documentation) useful?
- yes/no/somewhat
5. Do you find help distributed with GIT useful
(manpages, manual, tutorial, HOWTO, release notes)?
- yes/no/somewhat
6. Do you contribute to GIT documentation?
- yes/no
7. What is your favourite user documentation for any software
projects or products you have used?
8. What could be improved on the GIT homepage?
Getting help, staying in touch
1. Have you tried to get GIT help from other people?
- yes/no
2. If yes, did you get these problems resolved quickly
and to your liking?
- yes/no
3. Do you subscribe to the mailing list?
- yes/no
4. Do you read the mailing list? What method do you use?
- subscribed/news interface/RSS interface/archives/
/post + reply-to request/digests/I don't read it
5. If yes, do you find it useful?
- yes/no (optional)
6. Do you find traffic levels on GIT mailing list OK.
- yes/no? (optional)
7. Do you use the IRC channel (#git on irc.freenode.net)?
- yes/no
8. If yes, do you find IRC channel useful?
- yes/no (optional)
Open forum
1. What other comments or suggestions do you have that are not
covered by the questions above?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-gui: i18n introductory document (2nd draft)
From: VMiklos @ 2007-07-27 11:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Shawn O. Pearce, Christian Stimming,
Irina Riesen, Paolo Ciarrocchi, Xudong Guan, Nanako Shiraishi,
git
In-Reply-To: <7v4pjq7net.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 192 bytes --]
Hello,
Na Thu, Jul 26, 2007 at 04:31:06PM -0700, Junio C Hamano <gitster@pobox.com> pisal(a):
> + $ cd git-gui-i18n.git
this should be git-gui-i18n (no .git), if i'm not wrong :)
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5] Clean up work-tree handling
From: Johannes Schindelin @ 2007-07-27 10:50 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <20070726220949.GA4420@moooo.ath.cx>
Hi,
On Fri, 27 Jul 2007, Matthias Lederhofer wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > +const char *get_git_work_tree(void)
> > +{
> > + static int initialized = 0;
> > + if (!initialized) {
> > + work_tree = getenv(GIT_WORK_TREE_ENVIRONMENT);
> > + if (!work_tree) {
> > + work_tree = git_work_tree_cfg;
> > + if (work_tree && !is_absolute_path(work_tree))
> > + work_tree = git_path(work_tree);
>
> A tab is missing here.
Right. And as Junio pointed out, an xstrdup().
> > - fprintf(stderr, "No directory given for --work-tree.\n" );
> > + error("No directory given for --work-tree.\n");
>
> There should probably be no '\n' at the end when the 'error' function
> is used. There are two other calls to fprintf(stderr, <error message>)
> next to the one you changed, why did you change this one but not the
> other ones?
Well, that is a left over of some unrelated editing.
The patch series that I sent out was deficient in many ways, but I was
tired, and wanted to show where I am heading.
ATM I am trying to finish up this series, with quite a few changes to the
code I sent out.
But there is a fundamental question I have to ask: Is there any reason why
$ git --git-dir=/some/where/else.git bla
should pretend that the repo is bare if core.bare == 1? I mean, we are
implicitely setting the work tree to the cwd, no?
IOW I see the merits of "core.bare = false" (to prevent harm when calling
git inside the git directory), but I cannot see the merits of "core.bare =
true". Someone enlighten me?
Ciao,
Dscho
^ permalink raw reply
* Re: index-pack died on pread
From: Tomash Brechko @ 2007-07-27 10:33 UTC (permalink / raw)
To: GIT; +Cc: Junio C Hamano, Alex Riesen, Robin Rosenberg, Michal Rokos
In-Reply-To: <20070727095013.GA5047@moonlight.home>
On Fri, Jul 27, 2007 at 13:50:13 +0400, Tomash Brechko wrote:
> There's no dup() call, so when we mess pack_fd (that is used in
> pread() only), we also mess one more file descriptor that is used
> sequentially (output_fd in my case), and so may corrupt the pack.
I was wrong on the dup() part, since dup()'ed descriptors share the
same file position. Anyway, if my guess is right, the fix would
probably be not to use broken pread() that messes file position,
rather than to be ready and workaround that.
--
Tomash Brechko
^ permalink raw reply
* Re: [PATCH] gitk: let you easily specify lines of context in diff view
From: Paul Mackerras @ 2007-07-27 10:31 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <6EA8D0EC-6E64-4F0E-BEDB-A8C5C91AAB53@zib.de>
Steffen Prohaska writes:
> This is already included in the patch but I don't know which of gtk's
> procs to call to update the view. gitk would need to execute git diff
> and update the text box in the bottom left. I tried 'dodiffindex'
> but this causes corruptions of the history view.
reselectline should do what you want.
Paul.
^ permalink raw reply
* Re: index-pack died on pread
From: Tomash Brechko @ 2007-07-27 9:50 UTC (permalink / raw)
To: GIT; +Cc: Junio C Hamano, Alex Riesen, Robin Rosenberg, Michal Rokos, GIT
In-Reply-To: <alpine.LFD.0.999.0707262231280.3442@woody.linux-foundation.org>
Maybe this may help:
I compiled Git under Linux with NO_PREAD=1, and also _disabled_
file position save/restore in git_pread(). Now (I clone small repo to
save traffic):
moonlight:/tmp$ git-clone git://people.freedesktop.org/~keithp/parsecvs
Initialized empty Git repository in /tmp/parsecvs/.git/
remote: Generating pack...
remote: Done counting 476 objects.
remote: Deltifying 476 objects.
remote: 100% (476/476) done
Indexing 476 objects...
remote: Total 476 (delta 339), reused 0 (delta 0)
100% (476/476) done
Resolving 339 deltas...
100% (339/339) done
error: packfile /tmp/parsecvs/.git/objects/pack/pack-dda2f32249fab26059a035bd273dce9feaf6bade.pack does not match index
error: packfile /tmp/parsecvs/.git/objects/pack/pack-dda2f32249fab26059a035bd273dce9feaf6bade.pack cannot be accessed
error: packfile /tmp/parsecvs/.git/objects/pack/pack-dda2f32249fab26059a035bd273dce9feaf6bade.pack does not match index
error: packfile /tmp/parsecvs/.git/objects/pack/pack-dda2f32249fab26059a035bd273dce9feaf6bade.pack cannot be accessed
fatal: failed to unpack tree object HEAD
Errors are different, but seems Git is sensitive to pread() that messes
file position. The problem may be in index-pack.c:
static const char *open_pack_file(const char *pack_name)
{
if (from_stdin) {
...
pack_fd = output_fd;
} else {
...
pack_fd = input_fd;
}
...
}
There's no dup() call, so when we mess pack_fd (that is used in
pread() only), we also mess one more file descriptor that is used
sequentially (output_fd in my case), and so may corrupt the pack.
--
Tomash Brechko
^ permalink raw reply
* Re: git-gui problem with version number.
From: David Kastrup @ 2007-07-27 9:11 UTC (permalink / raw)
To: git
In-Reply-To: <86k5smnvhw.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> Now that is funny. I am pretty sure (or rather _have_ been pretty
> sure) that I cloned the respective repositories with the same command.
> Yet now both are up-to-date according to git-pull (and have identical
> .config contents), and the first compiles version git version
> 1.5.3.rc2.41.gb47b1 while the second compiles version
> 1.5.3.rc3.7.gd58e-dirty. Both have been cloned from git.git, the
A combination of rebasing and pushing made the difference go away and
made git-gui work again. Nevertheless, it would be a good idea not to
balk at the dirty version strings.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] use lockfile.c routines in git_commit_set_multivar()
From: Johannes Schindelin @ 2007-07-27 9:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bradford Smith, git
In-Reply-To: <7v7iom5twd.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 26 Jul 2007, Junio C Hamano wrote:
> How about this? On top of your "lockfile to keep symlink" and
> "set-multivar to use lockfile protocol" patches.
Looks very good to me!
Ciao,
Dscho
^ permalink raw reply
* gitweb chokes on recursive symlink
From: Junio C Hamano @ 2007-07-27 8:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
If somebody used to advertise his repository that physically
resides at /pub/lic.git/ as:
git://git.example.com/pub/lic.git/
but now wants to use --base-path to allow:
git://git.example.com/lic.git/
she can start git-daemon with --base-path option, like this:
git-daemon --base-path=/pub --export-all
During the transition, however, she would also want to allow
older URL as well. One natural way to achieve that is to create
a symlink:
ln -s /pub /pub/pub
so that a request to git://git.example.com/pub/lic.git/ is first
translated by --base-path to a request to /pub/pub/lic.git/
which goes to /pub/lic.git, thanks to the symlink.
So far so good.
However, gitweb chokes if there is such a symlink (File::Find
barfs with "/pub/pub is a recursive symbolic link" --- I think
this is because you use "follow_fast => 1").
As I happen to think using a symlink that goes up for backward
compatible URL support is a rather common practice, I think we
should do something about it. My gut feeling is that we could
simply ignore such symlinks.
What do you think about this issue?
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b381692..c8ad84e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1492,6 +1492,7 @@ sub git_get_projects_list {
File::Find::find({
follow_fast => 1, # follow symbolic links
+ follow_skip => 2, # ignore duplicates
dangling_symlinks => 0, # ignore dangling symlinks, silently
wanted => sub {
# skip project-list toplevel, if we get it.
^ permalink raw reply related
* Re: git-gui: i18n introductory document (2nd draft)
From: しらいしななこ @ 2007-07-27 8:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Shawn O. Pearce, Christian Stimming,
Irina Riesen, Paolo Ciarrocchi, Xudong Guan, git
In-Reply-To: <7v4pjq7net.fsf@assigned-by-dhcp.cox.net>
Quoting Junio C Hamano <gitster@pobox.com>:
> This short note is to help a translation contributor to help us
> localizing git-gui message files by covering the basics.
Thank you for this document, and thank you for helping me the
other day with my translations.
I tried to follow your message and updated my Japanese
translation. Almost everything worked as described, but this
part.
> +After setting up such a symbolic link, you can:
> +
> + $ make
> + $ LANG=af ./git-gui
> +
> +[NEEDSWORK: this symlink trick needs to be verified if it works.]
I used LANG=ja instead; this did not work. A "fatal error"
dialog said:
couldn't open "/home/nanako/git/share/git-gui/lib/tclIndex":
no such file or directory
But this worked:
$ LANG=ja ./git-gui.sh
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Get a free email address with REAL anti-spam protection.
http://www.bluebottle.com/tag/1
^ permalink raw reply
* Re: incremental fast-import
From: Simon 'corecode' Schubert @ 2007-07-27 7:44 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Julian Phillips, git
In-Reply-To: <20070727005103.GC20052@spearce.org>
Shawn O. Pearce wrote:
> fast-import doesn't assume the local branches already exist.
> It actually assumes its importing from scratch every time. The
> frontend tool needs to restart the branch if that is what it wants.
Is there a compelling reason for this behavior? Shouldn't be so complicated to get an overview on which branches already exist?
Right now I have to do this with a side channel to fast-import, asking the git repo directly, and then "recreating" the branch, etc. Works, but could be nicer, I guess.
cheers
simon
--
Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\
Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ /
Party Enjoy Relax | http://dragonflybsd.org Against HTML \
Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
^ permalink raw reply
* Re: git-gui problem with version number.
From: David Kastrup @ 2007-07-27 7:42 UTC (permalink / raw)
To: git
In-Reply-To: <85ejiu5r9r.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
>> David Kastrup <dak@gnu.org> wrote:
>>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>>> > Anyway, you can setup a build with the most recent 'stable
>>> > development' version of git-gui:
>>> >
>>> > git checkout -b with-new-gitgui
>>> > git pull -s subtree git://repo.or.cz/git-gui.git
>>>
>>> Ok. Would the necessity for this depend on the Tcl version?
>>
>> I thought all versions of Tcl did not understand the 'creative'
>> git version strings. So I'm surprised to hear it works on one
>> system but not on another, even though you have the same version
>> of git and git-gui.
>
> I'll check once I am at work, but I am pretty sure that the versions
> are pretty much in synch.
Now that is funny. I am pretty sure (or rather _have_ been pretty
sure) that I cloned the respective repositories with the same command.
Yet now both are up-to-date according to git-pull (and have identical
.config contents), and the first compiles version git version
1.5.3.rc2.41.gb47b1 while the second compiles version
1.5.3.rc3.7.gd58e-dirty. Both have been cloned from git.git, the
second with
* master
origin/HEAD
origin/html
origin/maint
origin/man
origin/master
origin/next
origin/pu
origin/todo
and the first with
* master
origin/HEAD
origin/html
origin/maint
origin/man
origin/master
origin/next
origin/pu
origin/todo
On the one with the problematic version, I get
git-rev-list -2 origin/HEAD |git-name-rev --stdin
d58e8d34b019d435b424811c6f972910dfac6f55 (master)
1a44be9a0ff6fa623ff6061992f5ad1831dc7cab (master~1)
and on the other one I get
git-rev-list -2 origin/HEAD |git-name-rev --stdin
d58e8d34b019d435b424811c6f972910dfac6f55 (remotes/origin/HEAD)
1a44be9a0ff6fa623ff6061992f5ad1831dc7cab (remotes/origin/HEAD~1)
git-rev-list -2 master |git-name-rev --stdin
0d59d6cfd3ed2510a8e7d8c9fbc54c21133bc3a6 (master)
d58e8d34b019d435b424811c6f972910dfac6f55 (remotes/origin/HEAD)
So let me guess: the "dirty" in the version number comes about when
one has changes that are not in the upstream version, and it is this
string which confuses git-gui?
But then the version numbers are _so_ different. I probably am
overlooking something.
--
David Kastrup
^ permalink raw reply
* Re: [PATCH] Make verify-tag a builtin.
From: Junio C Hamano @ 2007-07-27 7:05 UTC (permalink / raw)
To: Carlos Rica; +Cc: git, Johannes Schindelin
In-Reply-To: <46A96F86.2030704@gmail.com>
Carlos Rica <jasampler@gmail.com> writes:
> This replaces "git-verify-tag.sh" with "builtin-verify-tag.c".
This is better overall, but you need to drop free(path) as you
are using git_mkstemp() now on a on-stack buffer.
> Signal SIGPIPE is ignored because the program sometimes was
> terminated because that signal when writing the input for gpg.
This "sometimes" does not give confidence to readers, I am
afraid.
What is happening is perfectly normal, not "sometimes it gets
the signal mysteriously, so we need to paper it over by ignoring
it".
You invoke gpg, giving it a file that is supposed to contain a
detached signature, and start feeding the payload that ought to
verify Ok with the signature. If the tag is not signed, after
gpg has read the detached signature, it already knows that the
signature will not verify and it can exit without reading the
payload from its standard input. When you try to write the
payload to the pipe, you would get SIGPIPE.
Anyway, I'll replace the tip of cr/tag topic with this version,
and merge it to 'next'.
^ permalink raw reply
* Re: [PATCH] fully resolve symlinks when creating lockfiles
From: Junio C Hamano @ 2007-07-27 7:05 UTC (permalink / raw)
To: Bradford C. Smith; +Cc: git
In-Reply-To: <11854712542350-git-send-email-bradford.carl.smith@gmail.com>
"Bradford C. Smith" <bradford.carl.smith@gmail.com> writes:
> Make the code for resolving symlinks in lockfile.c more robust as
> follows:
>
> 1. Handle relative symlinks
> 2. recursively resolve symlink chains up to OS limit
I munged this patch with Morten's comments. Will queue for
'next'. Further polishing will be done in 'next' as needed.
^ permalink raw reply
* [PATCH] git-bisect: do not get confused by packed-ref
From: Junio C Hamano @ 2007-07-27 6:50 UTC (permalink / raw)
To: git
If an unfortunate user runs a pack-ref while a git-bisect is
active, refs/bisect/* references will stay behind even after the
git-bisect finishes, because the clean-up code only paid
attention to loose refs. This has a potential to confuse later
bisect runs greatly.
Ideally we should further fix parts that manually creates the
good references refs/bisect/good-*, and updates bad reference
refs/bisect/bad, but that is a cleanliness not correctness
issue. For 1.5.3, this minimum fix should do.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-bisect.sh | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 388887a..77dad51 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -265,8 +265,16 @@ bisect_reset() {
}
bisect_clean_state() {
+ git for-each-ref --format='%(objectname) %(refname)' refs/bisect |
+ while read sha1 ref
+ do
+ git update-ref -d "$ref" "$sha1"
+ done
+ if current=$(git rev-parse --verify refs/heads/bisect 2>/dev/null)
+ then
+ git update-ref -d refs/heads/bisect "$current"
+ fi
rm -fr "$GIT_DIR/refs/bisect"
- rm -f "$GIT_DIR/refs/heads/bisect"
rm -f "$GIT_DIR/BISECT_LOG"
rm -f "$GIT_DIR/BISECT_NAMES"
rm -f "$GIT_DIR/BISECT_RUN"
^ permalink raw reply related
* Re: git-gui-i18n: Make "Revert changes in these $n files" translatable.
From: Brett Schwarz @ 2007-07-27 6:41 UTC (permalink / raw)
To: Christian Stimming, Harri Ilari Tapio Liusvaara
Cc: Shawn O. Pearce, git, Paul Mackerras, Junio C Hamano
>
>
> ----- Original Message ----
> From: Christian Stimming <stimming@tuhh.de>
> To: Harri Ilari Tapio Liusvaara <hliusvaa@cc.hut.fi>
> Cc: Shawn O. Pearce <spearce@spearce.org>; Brett Schwarz <brett_schwarz@yahoo.com>; git@vger.kernel.org; Paul Mackerras <paulus@samba.org>; Junio C Hamano <gitster@pobox.com>
> Sent: Thursday, July 26, 2007 5:34:49 AM
> Subject: Re: git-gui-i18n: Make "Revert changes in these $n files" translatable.
>
> Quoting Harri Ilari Tapio Liusvaara <hliusvaa@cc.hut.fi>:
> > On Thu, Jul 26, 2007 at 10:47:23AM +0200, Christian Stimming wrote:
> >> The issue with plural forms is even more complicated than that.
> >
<snip>
> > - Buttons in hard reset confirmation (branch->revert or merge->abort,
> > and it is yes/no dialog).
>
> I see this in translated form (German Ja/Nein), and also the button
> text (translated or not) doesn't appear in the git-gui source code.
> Maybe those need to be translated in the tcl/tk system libraries?
>
These are indeed in the Tk libs. Unfortunately, there is no straight forward way to change the button text for tk_messageBox. I'll probably submit a patch to Tcl core for this.
In the mean time, if this is important, there are 2 ways around this:
1) override the button text in the msgcat. Tk does it's own msgcat internally (under the Tk namespace), and that's what prevents msgcat from changing these. You can see these under msgs directory where Tk is installed (/usr/local/tk8.4/msgs on my system). So, you would have to override for each language specified in that directory (if it warrants overriding). So, somewhere in the git-gui, you would have to do something like:
namespace eval ::Tk {
::msgcat::mcset en_us &OK <new_term>
::msgcat::mcset en_us &Cancel <new_term>
::msgcat::mcset en_us &Yes <new_term>
::msgcat::mcset en_us &No <new_term>
<continue for each language, if needed>
}
2) Re-write the tk_messageBox, to include an option to specify the button text. This wouldn't be too hard actually, but this would live with git-gui.
I don't think option #1 is robust enough, but would be the easiest approach. Note also that this would only be for unix platforms, since for windows and Mac, it calls the platform's equivalent.
HTH,
--brett
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting
^ permalink raw reply
* Re: [PATCH] zlib in custom location
From: Robert Schiele @ 2007-07-27 6:14 UTC (permalink / raw)
To: git
In-Reply-To: <20070727054251.GC30038@schiele.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2681 bytes --]
On Fri, Jul 27, 2007 at 07:42:51AM +0200, Robert Schiele wrote:
> Hi,
>
> I have some systems with zlib in a custom location and thus did the following
> change to support a variable ZLIBDIR like it does already exist for
> OPENSSLDIR. Would be great to see this in the main tree.
Just to follow up this change I have another one:
Since some Linux archs use different names for the library directory than
"lib" (like "lib64") I made this a config variable as well. Currently this is
only an issue if you use custom directories for libraries used by git.
commit a1cffe56cc9092443cd8bd03b18eb7e222528e35
Author: Robert Schiele <rschiele@gmail.com>
Date: Thu Jul 26 23:08:47 2007 -0700
- make the name of the library directory a config option
diff --git a/Makefile b/Makefile
index 0179339..64c0a59 100644
--- a/Makefile
+++ b/Makefile
@@ -151,6 +151,7 @@ sysconfdir = /etc
else
sysconfdir = $(prefix)/etc
endif
+lib = lib
ETC_GITCONFIG = $(sysconfdir)/gitconfig
# DESTDIR=
@@ -170,7 +171,7 @@ GITWEB_FAVICON = git-favicon.png
GITWEB_SITE_HEADER =
GITWEB_SITE_FOOTER =
-export prefix bindir gitexecdir sharedir template_dir sysconfdir
+export prefix bindir gitexecdir sharedir template_dir sysconfdir lib
CC = gcc
AR = ar
@@ -499,9 +500,9 @@ endif
ifndef NO_CURL
ifdef CURLDIR
- # Try "-Wl,-rpath=$(CURLDIR)/lib" in such a case.
+ # Try "-Wl,-rpath=$(CURLDIR)/$(lib)" in such a case.
BASIC_CFLAGS += -I$(CURLDIR)/include
- CURL_LIBCURL = -L$(CURLDIR)/lib $(CC_LD_DYNPATH)$(CURLDIR)/lib -lcurl
+ CURL_LIBCURL = -L$(CURLDIR)/$(lib) $(CC_LD_DYNPATH)$(CURLDIR)/$(lib) -lcurl
else
CURL_LIBCURL = -lcurl
endif
@@ -519,7 +520,7 @@ endif
ifdef ZLIBDIR
BASIC_CFLAGS += -I$(ZLIBDIR)/include
- EXTLIBS += -L$(ZLIBDIR)/lib $(CC_LD_DYNPATH)$(ZLIBDIR)/lib
+ EXTLIBS += -L$(ZLIBDIR)/$(lib) $(CC_LD_DYNPATH)$(ZLIBDIR)/$(lib)
endif
EXTLIBS += -lz
@@ -527,7 +528,7 @@ ifndef NO_OPENSSL
OPENSSL_LIBSSL = -lssl
ifdef OPENSSLDIR
BASIC_CFLAGS += -I$(OPENSSLDIR)/include
- OPENSSL_LINK = -L$(OPENSSLDIR)/lib $(CC_LD_DYNPATH)$(OPENSSLDIR)/lib
+ OPENSSL_LINK = -L$(OPENSSLDIR)/$(lib) $(CC_LD_DYNPATH)$(OPENSSLDIR)/$(lib)
else
OPENSSL_LINK =
endif
@@ -544,7 +545,7 @@ endif
ifdef NEEDS_LIBICONV
ifdef ICONVDIR
BASIC_CFLAGS += -I$(ICONVDIR)/include
- ICONV_LINK = -L$(ICONVDIR)/lib $(CC_LD_DYNPATH)$(ICONVDIR)/lib
+ ICONV_LINK = -L$(ICONVDIR)/$(lib) $(CC_LD_DYNPATH)$(ICONVDIR)/$(lib)
else
ICONV_LINK =
endif
Robert
--
Robert Schiele
Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com
"Quidquid latine dictum sit, altum sonatur."
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH] gitk: let you easily specify lines of context in diff view
From: Steffen Prohaska @ 2007-07-27 5:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18088.38093.876993.410483@cargo.ozlabs.ibm.com>
On Jul 26, 2007, at 2:34 PM, Paul Mackerras wrote:
> Steffen Prohaska writes:
>
>> More lines of context sometimes help to better understand a diff.
>> This patch introduces a text field above the box displaying the
>> blobdiffs. You can type in the number of lines of context that
>> you wish to view.
>
> Nice idea! I suggest you use a spinbox instead of an entry though,
> since that has up and down buttons, and allows you to restrict the
> value to an integer.
Thanks. Will try that.
>> * I don't know how to update the view after entering a new value.
>
> You can put a trace on the associated variable and specify a function
> to be called when the variable's value changes. Grep for "trace add
> variable" in gitk to see how it's done.
This is already included in the patch but I don't know which of gtk's
procs to call to update the view. gitk would need to execute git diff
and update the text box in the bottom left. I tried 'dodiffindex'
but this causes corruptions of the history view.
Steffen
^ permalink raw reply
* Re: git-gui problem with version number.
From: David Kastrup @ 2007-07-27 5:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070727054815.GJ20052@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> David Kastrup <dak@gnu.org> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>> > Anyway, you can setup a build with the most recent 'stable
>> > development' version of git-gui:
>> >
>> > git checkout -b with-new-gitgui
>> > git pull -s subtree git://repo.or.cz/git-gui.git
>>
>> Ok. Would the necessity for this depend on the Tcl version?
>
> I thought all versions of Tcl did not understand the 'creative'
> git version strings. So I'm surprised to hear it works on one
> system but not on another, even though you have the same version
> of git and git-gui.
I'll check once I am at work, but I am pretty sure that the versions
are pretty much in synch.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: gitk screenshots of complex history
From: David Kastrup @ 2007-07-27 5:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Linus Torvalds, git
In-Reply-To: <20070727052934.GH20052@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>> On Fri, 27 Jul 2007, Shawn O. Pearce wrote:
>> >
>> > I just compared my own history to Linus' linux-2.6 history.
>> > The kernel team can't hold a candle to this mess.
>>
>> Rather on purpose, I might add. I've actually been fairly anal about
>> having people maintain clean histories, to the point where I refuse to
>> pull from trees that don't do a good enough job.
>
> For 4 of our internal repositories I've taken that policy up now
> myself, and nobody is allowed to create releases from them except me.
> This has helped. A lot. So does sensible use of `git rebase -i`.
> You and Junio have really sold me on the value of having someone
> play a very strict gatekeeper role. I get better work product from
> my coworkers this way too. They know someone else is looking at
> what they are doing and try harder.
>
> But it doesn't help the really old history, nor does it help
> the repository these images came from. I don't own/control that
> development. I just provide git help as much as I can.
One idea I have not yet put into any code is using graphviz for
creating a nice (possibly clickable) layout of a commit history. It
might be able to rearrange things such that the long parallel lines
get avoided. Could be an interesting feature for the HTML
visualizers.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: git-gui problem with version number.
From: Shawn O. Pearce @ 2007-07-27 5:48 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85odhy5rm6.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > Anyway, you can setup a build with the most recent 'stable
> > development' version of git-gui:
> >
> > git checkout -b with-new-gitgui
> > git pull -s subtree git://repo.or.cz/git-gui.git
>
> Ok. Would the necessity for this depend on the Tcl version?
I thought all versions of Tcl did not understand the 'creative'
git version strings. So I'm surprised to hear it works on one
system but not on another, even though you have the same version
of git and git-gui.
--
Shawn.
^ permalink raw reply
* Re: git-gui problem with version number.
From: David Kastrup @ 2007-07-27 5:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070727053627.GI20052@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> David Kastrup <dak@gnu.org> wrote:
>>
>> The one coming with the mentioned version number. I suspect that
>> this may be a matter of the Perl libraries being used: I experience
>> this on an Ubuntu Dapper, but not on other (newer) systems compiled
>> from the same source.
>
> Ah. Junio hasn't pulled those version numbering fixes from me yet.
> Because I haven't asked him to pull in a while. That explains that.
>
> There's no Perl involved in git-gui, except for the Perl in an
> underlying Git command it might invoke. So perhaps you were talking
> about Tcl above?
Uh, whatever this backtrace was in... I did not look too closely.
> Anyway, you can setup a build with the most recent 'stable
> development' version of git-gui:
>
> git checkout -b with-new-gitgui
> git pull -s subtree git://repo.or.cz/git-gui.git
Ok. Would the necessity for this depend on the Tcl version?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* [PATCH] zlib in custom location
From: Robert Schiele @ 2007-07-27 5:42 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]
Hi,
I have some systems with zlib in a custom location and thus did the following
change to support a variable ZLIBDIR like it does already exist for
OPENSSLDIR. Would be great to see this in the main tree.
commit d61424558cda558b0c7893f545d548c6d6f211ff
Author: Robert Schiele <rschiele@gmail.com>
Date: Thu Jul 26 22:34:16 2007 -0700
- add option to find zlib in custom path
diff --git a/Makefile b/Makefile
index 73b487f..0179339 100644
--- a/Makefile
+++ b/Makefile
@@ -372,7 +372,7 @@ BUILTIN_OBJS = \
builtin-pack-refs.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
-EXTLIBS = -lz
+EXTLIBS =
#
# Platform specific tweaks
@@ -517,6 +517,12 @@ ifndef NO_CURL
endif
endif
+ifdef ZLIBDIR
+ BASIC_CFLAGS += -I$(ZLIBDIR)/include
+ EXTLIBS += -L$(ZLIBDIR)/lib $(CC_LD_DYNPATH)$(ZLIBDIR)/lib
+endif
+EXTLIBS += -lz
+
ifndef NO_OPENSSL
OPENSSL_LIBSSL = -lssl
ifdef OPENSSLDIR
Robert
--
Robert Schiele
Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com
"Quidquid latine dictum sit, altum sonatur."
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: index-pack died on pread
From: Linus Torvalds @ 2007-07-27 5:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Robin Rosenberg, Michal Rokos, GIT
In-Reply-To: <7vps2e5x4y.fsf@assigned-by-dhcp.cox.net>
On Thu, 26 Jul 2007, Junio C Hamano wrote:
>
> If you mean the offset associated with fd, we actually do.
Ahh, for some reason I thought we didn't (probably because the user likely
doesn't care at all), but right you are..
> The original HP-UX error is confusing, as we ask pread() to
> transfer 428 bytes and it returns 0 (not returning -1 with
> EINTR). Return value of zero is understandable, if the starting
> position is at or after the EOF, but the offset is 123601 and
> 56k objects packed from git.git repository should be longer than
> that, so that also sounds implausible.
Yeah. It is suspicious.
If somebody could run git under gdb on HP-UX (preferably compiled
statically), and just disassemble the pread() thing, it would be
interesting.
PA-RISC assembly is *almost* entirely unreadable, but it might show
whether hpux-11.11 actually has a pread() system call or whether it is
doing the "emulate with lseek" and maybe obviously buggily at that..
It really isn't that complex a system call. So I'm surprised at bugs
there, and that makes me worry that there is something in git that
triggers this.
Linus
^ 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