* Re: [PATCH] translate bad characters in refnames during git-svn fetch
From: Robert Ewald @ 2007-07-26 10:59 UTC (permalink / raw)
To: git
In-Reply-To: <20070717131719.GB19724@piper.oerlikon.madduck.net>
Hello,
I am very interested in a functionality like this.
martin f krafft wrote:
>> sub desanitize_ref_name {
>> my ($refname) = @_;
>> $refname =~ s{%(?:([0-9A-F]{2})}{chr hex($1)}g;
>>
>> $refname;
>> }
>
> We could make it escape to %25; instead of %25. That's ugly but it
> would make desanitation a little safer.
In my limited knowledge I wonder if that would confuse shell scripts.
>> > On the other hand, we could make the translation regexps
>> > configurable...
>>
>> Hopefully not needed. I fear it would just add to confusion.
>
> I was thinking about something like.
>
> git-svn clone ...
> ...
> error: remote branch/tagn name includes ~, which git does not
> allow. please specify a replacement character in .git/config
>
> and then have config.svn-remote.svn.translations simply be a list of
> pairs in vim pairlist syntax:
>
> ~:!,^:#,.:\,
>
Having the user specify replacements leads to diversion which would not be
desired. Consider the case where two git users clone a svn repo and later
pull from each other. Different replacements would cause confusion in this
case. That can of course be remedied by having the same replacements but
then configuration is not needed.
Is there anybody working on this feature at the moment? Can I pull from
somewhere? I am hard pressed for that feature but my ability to contribute
is only in testing and reporting bugs.
Greetings
--
Robert Ewald
^ permalink raw reply
* Re: Windows support
From: Christian MICHON @ 2007-07-26 12:21 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: hanwen, Johannes Schindelin, git, Junio C Hamano, Shawn O. Pearce,
Dmitry Kakurin
In-Reply-To: <fcaeb9bf0707260429l327f446bq73a8a0a13cd77cf1@mail.gmail.com>
On 7/26/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> microperl [1] maybe? I haven't tried it yet.
>
it won't work. I tried that few months back.
plus the fact you'll still need perl modules.
I just had a look at your gitbox gitweb. Did you really manage
to get busybox-1.6.1 to work with mingw ?
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu
^ permalink raw reply
* Re: [PATCH] translate bad characters in refnames during git-svn fetch
From: Martin F Krafft @ 2007-07-26 12:35 UTC (permalink / raw)
To: git
In-Reply-To: <f89uqv$tf2$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
also sprach Robert Ewald <robert.ewald@nov.com> [2007.07.26.1259 +0200]:
> Is there anybody working on this feature at the moment? Can I pull
> from somewhere? I am hard pressed for that feature but my ability
> to contribute is only in testing and reporting bugs.
As I told you on IRC, I am on my way out for holiday but will read
email, so if you need non-urgent feedback, please write. Please
include my name or reply to this thread for me to see it.
--
Martin F. Krafft Artificial Intelligence Laboratory
Ph.D. Student Department of Information Technology
Email: krafft@ailab.ch University of Zurich
Tel: +41.(0)44.63-54323 Andreasstrasse 15, Office 2.18
http://ailab.ch/people/krafft CH-8050 Zurich, Switzerland
Spamtraps: krafft.bogus@ailab.ch krafft.bogus@ifi.unizh.ch
gentoo: the performance placebo.
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-gui-i18n: Make "Revert changes in these $n files" translatable.
From: Christian Stimming @ 2007-07-26 12:34 UTC (permalink / raw)
To: Harri Ilari Tapio Liusvaara
Cc: Shawn O. Pearce, Brett Schwarz, git, Paul Mackerras,
Junio C Hamano
In-Reply-To: <20070726115301.GA27821@cc.hut.fi>
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.
>
> Yes, I know that some languages have very complex plural forms. I even
> tought about that, but forgot to tack in FIXME comment. :-(
Ok. Thanks for adding the explanation.
> One can do bit nasty workarounds for the msgcat's inability to do
> proper plural form translation.
I don't think any workarounds for the plural forms would bring us very
far. For now, I think it is just fine to state there is no plural form
support in msgcat, so we can't use it. (That being said, I think the
approach taken by gettext is by far the best one: Let the translator
define the available plural forms inside the po file header by
"Plural-Forms:". One would have to transfer this information over to
tcl and add the necessary instrumentation into msgcat to process this
expression. Maybe some day, some time.)
> BTW: Here is list of some missed translations:
>
> - Git version query when it can't grok the version (the yes/no one).
> - 3 Menu entries in "Repository" menu ("Browse branch files", "Browse
> foo's files", "Visualize foo's history".
Thanks for all of them. I think now I caught them all. See patch
below, which I'll push but not before the weekend (due to firewall
restrictions).
> - Font setting names in options window.
You mean the names of the fonts? But those are names. I thought by
definition they cannot be translated.
> - "Starting revision" in branch create window.
> - "Revision" in branch checkout window.
Thanks, fixed.
> - 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?
> - "Fetch from foo" entries in fetch menu.
Done. Thanks a lot.
---
git-gui.sh | 16 ++++++++--------
lib/branch_checkout.tcl | 2 +-
lib/branch_create.tcl | 2 +-
lib/browser.tcl | 2 +-
lib/checkout_op.tcl | 2 +-
lib/option.tcl | 3 +--
lib/remote.tcl | 2 +-
7 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 3536d38..9f903ba 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -564,14 +564,14 @@ if {![regexp {^[1-9]+(\.[0-9]+)+$} $_git_version]} {
-type yesno \
-default no \
-title "[appname]: warning" \
- -message "Git version cannot be determined.
+ -message [mc "Git version cannot be determined.
-$_git claims it is version '$_real_git_version'.
+%s claims it is version '%s'.
-[appname] requires at least Git 1.5.0 or later.
+%s requires at least Git 1.5.0 or later.
-Assume '$_real_git_version' is version 1.5.0?
-"] eq {yes}} {
+Assume '%s' is version 1.5.0?
+" $_git $_real_git_version [appname] $_real_git_version]] eq {yes}} {
set _git_version 1.5.0
} else {
exit 1
@@ -1689,16 +1689,16 @@ menu .mbar.repository
.mbar.repository add command \
-label [mc "Browse Current Branch's Files"] \
-command {browser::new $current_branch}
-trace add variable current_branch write ".mbar.repository entryconf
[.mbar.repository index last] -label \"Browse \$current_branch's
Files\" ;#"
+trace add variable current_branch write ".mbar.repository entryconf
[.mbar.repository index last] -label \[format \"[mc "Browse %s's
Files"]\" \$current_branch\] ;#"
.mbar.repository add command \
- -label {Browse Branch Files...} \
+ -label [mc "Browse Branch Files..."] \
-command browser_open::dialog
.mbar.repository add separator
.mbar.repository add command \
-label [mc "Visualize Current Branch's History"] \
-command {do_gitk $current_branch}
-trace add variable current_branch write ".mbar.repository entryconf
[.mbar.repository index last] -label \"Visualize \$current_branch's
History\" ;#"
+trace add variable current_branch write ".mbar.repository entryconf
[.mbar.repository index last] -label \[format \"[mc "Visualize %s's
History"]\" \$current_branch\] ;#"
.mbar.repository add command \
-label [mc "Visualize All Branch History"] \
-command {do_gitk --all}
diff --git a/lib/branch_checkout.tcl b/lib/branch_checkout.tcl
index c727437..7d71821 100644
--- a/lib/branch_checkout.tcl
+++ b/lib/branch_checkout.tcl
@@ -29,7 +29,7 @@ constructor dialog {} {
pack $w.buttons.cancel -side right -padx 5
pack $w.buttons -side bottom -fill x -pady 10 -padx 10
- set w_rev [::choose_rev::new $w.rev {Revision}]
+ set w_rev [::choose_rev::new $w.rev [mc Revision]]
$w_rev bind_listbox <Double-Button-1> [cb _checkout]
pack $w.rev -anchor nw -fill both -expand 1 -pady 5 -padx 5
diff --git a/lib/branch_create.tcl b/lib/branch_create.tcl
index acfe411..53dfb4c 100644
--- a/lib/branch_create.tcl
+++ b/lib/branch_create.tcl
@@ -63,7 +63,7 @@ constructor dialog {} {
grid columnconfigure $w.desc 1 -weight 1
pack $w.desc -anchor nw -fill x -pady 5 -padx 5
- set w_rev [::choose_rev::new $w.rev {Starting Revision}]
+ set w_rev [::choose_rev::new $w.rev [mc "Starting Revision"]]
pack $w.rev -anchor nw -fill both -expand 1 -pady 5 -padx 5
labelframe $w.options -text [mc Options]
diff --git a/lib/browser.tcl b/lib/browser.tcl
index 9435e67..f9cfc6a 100644
--- a/lib/browser.tcl
+++ b/lib/browser.tcl
@@ -271,7 +271,7 @@ constructor dialog {} {
pack $w.buttons.cancel -side right -padx 5
pack $w.buttons -side bottom -fill x -pady 10 -padx 10
- set w_rev [::choose_rev::new $w.rev {Revision}]
+ set w_rev [::choose_rev::new $w.rev [mc Revision]]
$w_rev bind_listbox <Double-Button-1> [cb _open]
pack $w.rev -anchor nw -fill both -expand 1 -pady 5 -padx 5
diff --git a/lib/checkout_op.tcl b/lib/checkout_op.tcl
index 25bf9cf..d2fbc30 100644
--- a/lib/checkout_op.tcl
+++ b/lib/checkout_op.tcl
@@ -76,7 +76,7 @@ method run {} {
_toplevel $this {Refreshing Tracking Branch}
set w_cons [::console::embed \
$w.console \
- "Fetching $r_name from $remote"]
+ [mc "Fetching %s from %s" $r_name $remote]]
pack $w.console -fill both -expand 1
$w_cons exec $cmd [cb _finish_fetch]
diff --git a/lib/option.tcl b/lib/option.tcl
index 8d9e09d..20f1e8e 100644
--- a/lib/option.tcl
+++ b/lib/option.tcl
@@ -74,8 +74,7 @@ proc do_about {} {
pack $w.buttons -side bottom -fill x -pady 10 -padx 10
label $w.desc \
- -text [append [mc "git-gui - a graphical user interface for Git."] "
-$copyright"] \
+ -text "[mc "git-gui - a graphical user interface for Git."]\n$copyright" \
-padx 5 -pady 5 \
-justify left \
-anchor w \
diff --git a/lib/remote.tcl b/lib/remote.tcl
index c47ae50..71c7a0d 100644
--- a/lib/remote.tcl
+++ b/lib/remote.tcl
@@ -153,7 +153,7 @@ proc populate_fetch_menu {} {
if {$enable} {
lappend prune_list $r
$m add command \
- -label "Fetch from $r..." \
+ -label [mc "Fetch from %s..." $r] \
-command [list fetch_from $r]
}
}
--
1.5.3.rc2.12.gbc280
^ permalink raw reply related
* Re: Windows support
From: Nguyen Thai Ngoc Duy @ 2007-07-26 12:37 UTC (permalink / raw)
To: Christian MICHON
Cc: hanwen, Johannes Schindelin, git, Junio C Hamano, Shawn O. Pearce,
Dmitry Kakurin
In-Reply-To: <46d6db660707260521u15c2bd85j806d48e0f51a3b9@mail.gmail.com>
On 7/26/07, Christian MICHON <christian.michon@gmail.com> wrote:
> On 7/26/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > microperl [1] maybe? I haven't tried it yet.
> >
>
> it won't work. I tried that few months back.
>
> plus the fact you'll still need perl modules.
>
> I just had a look at your gitbox gitweb. Did you really manage
> to get busybox-1.6.1 to work with mingw ?
Most of tools (that are included) work fine. Ash almost works. It can
run git status, git commit, git clone.. and most of test cases. There
are still some missing pieces and bugs to hunt down though.
--
Duy
^ permalink raw reply
* Re: index-pack died on pread
From: Alex Riesen @ 2007-07-26 12:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Robin Rosenberg, Michal Rokos, GIT
In-Reply-To: <alpine.LFD.0.999.0707251636490.3607@woody.linux-foundation.org>
On 7/26/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Thu, 26 Jul 2007, Robin Rosenberg wrote:
> >
> > Does cygwin have the same pread problem then.. ? after make NO_PREAD=1 with 1.5.2.4
> > clone works.
>
> Interesting.
>
> It's true that pread() is used much less than normal reads, and maybe the
> cygwin pread() is indeed broken. But it's intriguing how apparently both
> HP-UX and Cygwin are showing the same breakage.
Maybe because neither _has_ POSIX pread? This is cygwin's pread, I believe:
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_disk_file.cc?rev=1.225&content-type=text/x-cvsweb-markup&cvsroot=src
Windows has means to implement it natively, but the interface is so ugly
(see OVERLAPPED, if interested), that it is no wonder Cygwin chose to
just use lseek.
^ permalink raw reply
* Re: Windows support
From: Christian MICHON @ 2007-07-26 13:00 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0707250715p7c183a81vc78f641eef493777@mail.gmail.com>
On 7/25/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On 7/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Wed, 25 Jul 2007, Nguyen Thai Ngoc Duy wrote:
> >
> > > FYI, I'm working on getting rid of msys requirement from mingw port. I
> > > can't tell you how long it would take though. Could be one month or two.
> >
> > Is there a repo out there?
>
> http://repo.or.cz/w/git/pclouds.git?a=shortlog;h=gitbox
>
> There are some patches on mob I have not merged to gitbox branch yet.
>
beautiful piece of work, IMHO. I really like the fact you managed some
busybox applets to actually work without msys. Really cool idea!
it seems you're not very far off. I believe you intend to replace in git-commit
"#!c:/msys/bin/sh" with something like "#!c:/gitbox/bin/gitbox ash", right ?
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu
^ permalink raw reply
* Re: Windows support
From: Nguyen Thai Ngoc Duy @ 2007-07-26 13:20 UTC (permalink / raw)
To: Christian MICHON; +Cc: Johannes Schindelin, git
In-Reply-To: <46d6db660707260600w6c3ca5d2ve6aaf06c7684789d@mail.gmail.com>
On 7/26/07, Christian MICHON <christian.michon@gmail.com> wrote:
> On 7/25/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > On 7/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > Hi,
> > >
> > > On Wed, 25 Jul 2007, Nguyen Thai Ngoc Duy wrote:
> > >
> > > > FYI, I'm working on getting rid of msys requirement from mingw port. I
> > > > can't tell you how long it would take though. Could be one month or two.
> > >
> > > Is there a repo out there?
> >
> > http://repo.or.cz/w/git/pclouds.git?a=shortlog;h=gitbox
> >
> > There are some patches on mob I have not merged to gitbox branch yet.
> >
>
> beautiful piece of work, IMHO. I really like the fact you managed some
> busybox applets to actually work without msys. Really cool idea!
>
> it seems you're not very far off. I believe you intend to replace in git-commit
> "#!c:/msys/bin/sh" with something like "#!c:/gitbox/bin/gitbox ash", right ?
No. I tweaked try_shell_exec() to use gitbox shell if the interpreter is "sh".
--
Duy
^ permalink raw reply
* Re: Windows support
From: Christian MICHON @ 2007-07-26 13:32 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0707260620i2ec1ab36ka470758edfd570d2@mail.gmail.com>
On 7/26/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On 7/26/07, Christian MICHON <christian.michon@gmail.com> wrote:
> > it seems you're not very far off. I believe you intend to replace in git-commit
> > "#!c:/msys/bin/sh" with something like "#!c:/gitbox/bin/gitbox ash", right ?
>
> No. I tweaked try_shell_exec() to use gitbox shell if the interpreter is "sh".
>
interesting. have you tried inserting busybox vi inside git-box ?
I can commit using "git commit -a -m ok", but then I get this kind of
error message (and ash dies, I go back to xp/cmd prompt)
mv: cannot rename '.git/next-index4540': File exists
C:/gitbox/bin/git-commit: exit: line 658: Illegal number: -1
nice piece of work. it could really be tiny once fixed.
I suggest to replace most git-* by git-box/ash shell wrappers,
calling the git.exe binary directly.
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu
^ permalink raw reply
* Re: Windows support
From: Nguyen Thai Ngoc Duy @ 2007-07-26 13:55 UTC (permalink / raw)
To: Christian MICHON; +Cc: Johannes Schindelin, git
In-Reply-To: <46d6db660707260632q16f927a2r64f6b4588dd3cb48@mail.gmail.com>
On 7/26/07, Christian MICHON <christian.michon@gmail.com> wrote:
> On 7/26/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > On 7/26/07, Christian MICHON <christian.michon@gmail.com> wrote:
> > > it seems you're not very far off. I believe you intend to replace in git-commit
> > > "#!c:/msys/bin/sh" with something like "#!c:/gitbox/bin/gitbox ash", right ?
> >
> > No. I tweaked try_shell_exec() to use gitbox shell if the interpreter is "sh".
> >
>
> interesting. have you tried inserting busybox vi inside git-box ?
Not yet. That would be fun but I rather focus on ash in the moment.
You could set EDITOR to notepad or something else.
> I can commit using "git commit -a -m ok", but then I get this kind of
> error message (and ash dies, I go back to xp/cmd prompt)
>
> mv: cannot rename '.git/next-index4540': File exists
Baah.. something goes wrong again.
> C:/gitbox/bin/git-commit: exit: line 658: Illegal number: -1
>
> nice piece of work. it could really be tiny once fixed.
Um.. that "Illegal number" might be an ash bug. Intended to fix it but
then forgot :(
>
> I suggest to replace most git-* by git-box/ash shell wrappers,
> calling the git.exe binary directly.
Cool. Will do.
> --
> Christian
> --
> http://detaolb.sourceforge.net/, a linux distribution for Qemu
>
--
Duy
^ permalink raw reply
* Re: [PATCH 1/5] Add is_absolute_path(), make_absolute_path() and normalize_path()
From: Johannes Schindelin @ 2007-07-26 13:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wevac63.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 25 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > +/* strip out .. and . */
> > +char *normalize_path(char *path)
> > +{
>
> This always makes one worry what should happen when foo/../bar
> is _not_ bar in reality (i.e. foo is symlink to a directory
> elsewhere).
>
> It depends on what kind of "path" you feed to the function (and
> its caller, make_absolute_path()). If you always feed a path
> >from the index (or a path obtained by recursively reading a
> tree), it is Ok. If it is arbitrary path obtained from the user
> or the filesystem, it is not.
Agree. Maybe a comment above the function, like
/*
* The function normalize_path() converts ".." and "." names in
* the given path so that "foo/../bar/./" will come out as "bar".
*
* Note: normalize_path() does not follow symlinks, so if "foo" is
* a symlink in the example above, the result will not work as
* expected.
*/
Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/5] Clean up work-tree handling
From: Johannes Schindelin @ 2007-07-26 14:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmyxj8wza.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 26 Jul 2007, Junio C Hamano wrote:
> This seems to break t1020 and t1500, probably among other
> things.
It does, yes. I only realised that when I woke up.
Will fix. In the meantime, you guys can discuss the merits of my patch
series. Am I the only one who finds the new version much easier to read,
much like the pre-work-tree version?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 4/5] Add test for sanitized work-tree behaviour
From: Johannes Schindelin @ 2007-07-26 14:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfy3b8wkp.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 26 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> > ...
> > @@ -3,90 +3,109 @@
> > test_description='test separate work tree'
> > . ./test-lib.sh
> >
> > +i=1
> > +
> > test_rev_parse() {
> > - ...
> > + name="$1"
> > + for option in --is-bare-repository --is-inside-git-dir \
> > + --is-inside-work-tree --show-prefix
> > + do
> > + shift
> > + test_expect_success "$name: $option" \
> > + "test '$1' = \"\$(git rev-parse $option)\""
>
> > +i=$(($i+1))
> > +test $i = $STOPI && gdb --args git rev-parse $option
>
> Eh?
Yes, got me there. It was a real PITA to debug that thing, given that the
tests were written in the spirit of Malbolge. So the easiest method to
debug it was for me to "-i -v" the test, run it again with "STOPI=$n ..
-v", and work out what was the intended behaviour, and whether to fix the
test or the logic.
Will clean up.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach git-gui to split hunks
From: Johannes Schindelin @ 2007-07-26 14:26 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Shawn O. Pearce, git
In-Reply-To: <46A84E06.2ED4CFBC@eudaptics.com>
Hi,
On Thu, 26 Jul 2007, Johannes Sixt wrote:
> Johannes Schindelin wrote:
> >
> > When you select the context menu item "Split Hunk" in the diff area,
> > git-gui will now split the current hunk so that a new hunk starts at
> > the current position.
> >
> > For this to work, apply has to be called with --unidiff-zero, since
> > the new hunks can start or stop with a "-" or "+" line.
>
> For chrissake, NO!
>
> I tried this already, and it immediately corrupted my data.
>
> The problem case is when the hunk you want to apply is not the first one
> and the first one does not add and remove the same number of lines. In
> this case, all that git-apply can do is to rely on line numbers. But
> they are WRONG and apply the patch at the WRONG spot.
>
> First, I didn't believe Linus when he preached that --unidiff-zero is
> bad; it took only a day to become a follower. ;)
Okay, convinced. But I have some issues there, which I will outline in
the reply to Shawn.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach git-gui to split hunks
From: Johannes Schindelin @ 2007-07-26 14:34 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Sixt, git
In-Reply-To: <20070726070744.GD18114@spearce.org>
Hi,
On Thu, 26 Jul 2007, Shawn O. Pearce wrote:
> [talk about the --unidiff-zero stuff]
>
> Yea, there's context there. Junio and I talked about this patch on #git
> a few minutes ago. I really appreciate that Dscho wrote it, especially
> given that he hasn't really been into Tcl hacking for Git much before.
Heh. I did my share of Tcl hacking. In one (closed source) project, I
was in constant awe why the devs chose Tcl as a scripting language, but Qt
as windowing library (back when it was pretty expensive for a startup to
use Qt).
> But I'd really like to save/create context, like `git add -i` does, so
> that we don't have to use --unidiff-zero here.
See below.
> It won't matter if git-apply rejected overlapping context in this case.
> git-gui will only ever feed one hunk at a time to git-apply. And if
> things get really f'd in the diff buffer the user can easily regenerate
> it (right click, Refresh).
But you're right, the other hunk headers should be updated. I'll have a
look at it this weekend.
> Right now git-gui's apply doesn't correctly update the other hunk
> headers when you apply a hunk. I've seen git-apply fail on some hunks
> just for this reason. Refreshing the diff (so git recomputes the
> headers) works around the issue. So I'm a little worried about using
> --unidiff-zero here.
Okay, but just using more context means that you also have to _update_ the
context of another hunk. Imagine this:
--- a/x
+++ a/x
one line
-a removed one
+an added one
another line
Now you split between the "-" and "+" line. If you stage the first hunk,
not only do you have to update the hunk header of the second hunk (now the
only one shown), which you already hinted should be done; you _also_ have
to update the context in the second hunk, since it changed.
This is just tricky enough that I am tempted to have a go at it. Not
today, though, since I have other work to do, and the issues are easier to
work around for the moment than to work around the lack of "Split Hunk"
for me.
BTW did you think about any kind of integrity checking, i.e. see if the
files involved still have the same hashes as when the diff was generated?
It _is_ possible to use git-gui _and_ the command line...
Ciao,
Dscho
^ permalink raw reply
* Re: Windows support
From: Johannes Schindelin @ 2007-07-26 14:37 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0707260537y4233abaamadf4cb6190ea0eeb@mail.gmail.com>
Hi,
On Thu, 26 Jul 2007, Nguyen Thai Ngoc Duy wrote:
> On 7/26/07, Christian MICHON <christian.michon@gmail.com> wrote:
> > On 7/26/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > > microperl [1] maybe? I haven't tried it yet.
> > >
> >
> > it won't work. I tried that few months back.
> >
> > plus the fact you'll still need perl modules.
> >
> > I just had a look at your gitbox gitweb. Did you really manage
> > to get busybox-1.6.1 to work with mingw ?
>
> Most of tools (that are included) work fine. Ash almost works. It can
> run git status, git commit, git clone.. and most of test cases. There
> are still some missing pieces and bugs to hunt down though.
Thank you for working on this!
However, I am not completely convinced that having a builtin shell is all
that useful. I for one would like to have MinGW busybox _separate_ from
git...
Yes, you could not use the nice "ln -s busybox ash" idiom, since Windows
lacks symlinks, but you could still say "busybox ash" with a relatively
small, single executable.
Ciao,
Dscho
^ permalink raw reply
* Re: git-gui-i18n: Make "Revert changes in these $n files" translatable.
From: Christian Stimming @ 2007-07-26 14:53 UTC (permalink / raw)
To: Harri Ilari Tapio Liusvaara; +Cc: git, Paul Mackerras, Shawn O. Pearce
In-Reply-To: <20070726142152.GA5335@cc.hut.fi>
Quoting Harri Ilari Tapio Liusvaara <hliusvaa@cc.hut.fi>:
>> >BTW: Here is list of some missed translations:
>>
>> >- Font setting names in options window.
>>
>> You mean the names of the fonts? But those are names. I thought by
>> definition they cannot be translated.
>
> Nope. The texts are "Main Font:" and "Diff/Console Font:". They are
> specified in somewhat bizarre manner (Search for "Main Font") from
> git-gui.sh.
Ok, thanks for the pointer. Patch attached (will be push on the weekend).
>> >- 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?
>
> I think that they might come from system libraries. But I'd rather
> use better labels. AFAIK, HCI guidelines say that yes/no dialogs
> are to be avoided, especally for confirming potentially destructive
> actions.
True for now. This would concern basically all question dialogs that
appear in git-gui.
Christian
---
git-gui.sh | 4 ++--
lib/option.tcl | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 9f903ba..463ec32 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1652,8 +1652,8 @@ set default_config(gui.newbranchtemplate) {}
set default_config(gui.fontui) [font configure font_ui]
set default_config(gui.fontdiff) [font configure font_diff]
set font_descs {
- {fontui font_ui {Main Font}}
- {fontdiff font_diff {Diff/Console Font}}
+ {fontui font_ui {mc "Main Font"}}
+ {fontdiff font_diff {mc "Diff/Console Font"}}
}
load_config 0
apply_config
diff --git a/lib/option.tcl b/lib/option.tcl
index 20f1e8e..31c7d47 100644
--- a/lib/option.tcl
+++ b/lib/option.tcl
@@ -245,7 +245,7 @@ proc do_options {} {
foreach option $font_descs {
set name [lindex $option 0]
set font [lindex $option 1]
- set text [lindex $option 2]
+ set text [eval [lindex $option 2]]
set global_config_new(gui.$font^^family) \
[font configure $font -family]
--
1.5.3.rc2.12.gbc280
^ permalink raw reply related
* Re: Windows support
From: Nguyen Thai Ngoc Duy @ 2007-07-26 15:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707261534550.14781@racer.site>
On 7/26/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 26 Jul 2007, Nguyen Thai Ngoc Duy wrote:
>
> > On 7/26/07, Christian MICHON <christian.michon@gmail.com> wrote:
> > > On 7/26/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > > > microperl [1] maybe? I haven't tried it yet.
> > > >
> > >
> > > it won't work. I tried that few months back.
> > >
> > > plus the fact you'll still need perl modules.
> > >
> > > I just had a look at your gitbox gitweb. Did you really manage
> > > to get busybox-1.6.1 to work with mingw ?
> >
> > Most of tools (that are included) work fine. Ash almost works. It can
> > run git status, git commit, git clone.. and most of test cases. There
> > are still some missing pieces and bugs to hunt down though.
>
> Thank you for working on this!
>
> However, I am not completely convinced that having a builtin shell is all
> that useful. I for one would like to have MinGW busybox _separate_ from
> git...
I make MinGW busybox part of git for some reasons:
- Making a full MinGW busybox would take lots of time. I don't need
busybox for Windows. What I need is a shell and enough POSIX utilities
to run git shell scripts without any dependencies. Windows users
(including myself when I have to use Windows) hate dependencies.
- I don't want MinGW busybox to be used outside of git (if it is
installed separated from git), there are cygwin and msys already. I
don't want to compete them. And I don't like conflicts (not sure
though) because you have multiple UNIX emulations on the same system.
- Making ash part of git has an advantage that you could tune the
shell to fit git. Earlier you had to replace find/sort with
/usr/bin/find and /usr/bin/sort in git scripts to avoid Windows
alternatives. I don't like that. If you have control over the shell,
you could make it ignore whatever program out there and use your own
ones. This one is not a strong point though.
- MinGW busybox (or gitbox as I call it now) utilizes compat/mingw.c
and other stuff like run-command.c... Making it separate (as source
code) duplicates code for nothing.
- If you meant separating from git.exe binary, not from source code,
then it's ok.
>
> Yes, you could not use the nice "ln -s busybox ash" idiom, since Windows
> lacks symlinks, but you could still say "busybox ash" with a relatively
> small, single executable.
>
> Ciao,
> Dscho
>
>
--
Duy
^ permalink raw reply
* Re: Windows support
From: Johannes Sixt @ 2007-07-26 15:25 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Christian MICHON
In-Reply-To: <fcaeb9bf0707260655v1dbbacfbta23e670713683963@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
>
> On 7/26/07, Christian MICHON <christian.michon@gmail.com> wrote:
> > I can commit using "git commit -a -m ok", but then I get this kind of
> > error message (and ash dies, I go back to xp/cmd prompt)
> >
> > mv: cannot rename '.git/next-index4540': File exists
>
> Baah.. something goes wrong again.
The problem is likely that rename() of MSCVRT.DLL is implemented in
terms of MoveFile(), which can't move over an existing file. A wrapper
is needed that uses MoveFileEx() instead.
We have the same problem also in git-apply: One of the tests fails for
this reason.
-- Hannes
^ permalink raw reply
* Re: Windows support
From: Johannes Schindelin @ 2007-07-26 15:43 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0707260807u476719e3rec2dcf5f780013c0@mail.gmail.com>
Hi,
On Thu, 26 Jul 2007, Nguyen Thai Ngoc Duy wrote:
> I make MinGW busybox part of git for some reasons:
>
> - Making a full MinGW busybox would take lots of time. I don't need
> busybox for Windows. What I need is a shell and enough POSIX utilities
> to run git shell scripts without any dependencies. Windows users
> (including myself when I have to use Windows) hate dependencies.
I think that if you succeed to compile ash on MinGW, the rest is easy.
> - I don't want MinGW busybox to be used outside of git (if it is
> installed separated from git), there are cygwin and msys already. I
> don't want to compete them. And I don't like conflicts (not sure
> though) because you have multiple UNIX emulations on the same system.
But you'd be my hero.
Installing Cygwin is often overkill if all I need is just a tiny shell
with just enough POSIX tools to run my scripts.
Installing MinGW is painful. Not because of MinGW, but because there is
no single installer for all I want. You need to install MinGW, MSYS, MSYS
DTK, iconv, bash (because the default is to old), etc. etc.
With busybox it would be busybox.exe.
> - Making ash part of git has an advantage that you could tune the
> shell to fit git. Earlier you had to replace find/sort with
> /usr/bin/find and /usr/bin/sort in git scripts to avoid Windows
> alternatives. I don't like that. If you have control over the shell,
> you could make it ignore whatever program out there and use your own
> ones. This one is not a strong point though.
I doubt that this is useful. We do want to support the other systems as
well, so we have to kinda stick with the available workarounds.
> - MinGW busybox (or gitbox as I call it now) utilizes compat/mingw.c
> and other stuff like run-command.c... Making it separate (as source
> code) duplicates code for nothing.
It is not duplication. It is forking. Which is a good thing.
> - If you meant separating from git.exe binary, not from source code,
> then it's ok.
Yes. Although I see your point in making it a builtin "git-ash" that can
be called without an extra fork(), using beginthread instead.
Ciao,
Dscho
^ permalink raw reply
* Re: Windows support
From: Nguyen Thai Ngoc Duy @ 2007-07-26 16:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707261638100.14781@racer.site>
On 7/26/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 26 Jul 2007, Nguyen Thai Ngoc Duy wrote:
>
> > I make MinGW busybox part of git for some reasons:
> >
> > - Making a full MinGW busybox would take lots of time. I don't need
> > busybox for Windows. What I need is a shell and enough POSIX utilities
> > to run git shell scripts without any dependencies. Windows users
> > (including myself when I have to use Windows) hate dependencies.
>
> I think that if you succeed to compile ash on MinGW, the rest is easy.
No it's not. With a couple of ifdefs you can compile it fine. Then
there goes fork(), fcntl(F_DUPFD), /dev/*, job/signal handling...
Fortunately Git does not use lots of features. It only needs /dev/null
(and /dev/zero for tests), SIGEXIT and no job usage.. That cuts down
the effort porting ash.
> > - I don't want MinGW busybox to be used outside of git (if it is
> > installed separated from git), there are cygwin and msys already. I
> > don't want to compete them. And I don't like conflicts (not sure
> > though) because you have multiple UNIX emulations on the same system.
>
> But you'd be my hero.
Can't say I don't love to ;-) It's just that I don't have enough time.
Once project "busybox for Windows" is born, people may scream for
features. Even if they don't, there are still bunch of work because I
have only ported a small number of tools. With Git as its sole
customer, I can beg Git contributors to limit POSIX tools that they
use.
But if someone steps up for the project, I'm all for it.
> Installing Cygwin is often overkill if all I need is just a tiny shell
> with just enough POSIX tools to run my scripts.
I see your point. Although you can install git and have git-box to
play with (oh spread git! lolz) Just keep in mind you don't have all
POSIX tools.
> > - MinGW busybox (or gitbox as I call it now) utilizes compat/mingw.c
> > and other stuff like run-command.c... Making it separate (as source
> > code) duplicates code for nothing.
>
> It is not duplication. It is forking. Which is a good thing.
I still don't see why duplicating compat/*, git-compat-util.h,
run-command.[ch]... and keeping fixing bugs in two places is a good
thing.
--
Duy
^ permalink raw reply
* Re: index-pack died on pread
From: Linus Torvalds @ 2007-07-26 16:13 UTC (permalink / raw)
To: Alex Riesen; +Cc: Robin Rosenberg, Michal Rokos, GIT
In-Reply-To: <81b0412b0707260542o58fcb73bu81ae09aa1df84c81@mail.gmail.com>
On Thu, 26 Jul 2007, Alex Riesen wrote:
> >
> > It's true that pread() is used much less than normal reads, and maybe the
> > cygwin pread() is indeed broken. But it's intriguing how apparently both
> > HP-UX and Cygwin are showing the same breakage.
>
> Maybe because neither _has_ POSIX pread?
HP-UX? No pread()? It wouldn't link if it didn't have pread(). So it
clearly has pread(), it's just somehow broken.
And no, git doesn't need "POSIX pread". Look at what git does if you say
"NO_PREAD=1". It does a simple lseek/read pair instead.
> This is cygwin's pread, I believe:
>
> http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_disk_file.cc?rev=1.225&content-type=text/x-cvsweb-markup&cvsroot=src
I'm not saying that's great programming, but the "git_pread()" that git
will use in the absense of a real pread() is actually even *less* of a
POSIX pread, since it doesn't even try to save/restore the old position
(it knows that git doesn't care).
So I don't think that explains why git doesn't like cygwin's pread. I
suspect an earlier version of cygwin had an even more broken version of
pread at some point.
Linus
^ permalink raw reply
* Re: index-pack died on pread
From: Alex Riesen @ 2007-07-26 16:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Robin Rosenberg, Michal Rokos, GIT
In-Reply-To: <alpine.LFD.0.999.0707260911040.3442@woody.linux-foundation.org>
On 7/26/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Thu, 26 Jul 2007, Alex Riesen wrote:
> > >
> > > It's true that pread() is used much less than normal reads, and maybe the
> > > cygwin pread() is indeed broken. But it's intriguing how apparently both
> > > HP-UX and Cygwin are showing the same breakage.
> >
> > Maybe because neither _has_ POSIX pread?
>
> HP-UX? No pread()? It wouldn't link if it didn't have pread(). So it
> clearly has pread(), it's just somehow broken.
I remember it didn't and was emulated with lseek.
> > This is cygwin's pread, I believe:
> >
> > http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_disk_file.cc?rev=1.225&content-type=text/x-cvsweb-markup&cvsroot=src
>
> I'm not saying that's great programming, but the "git_pread()" that git
> will use in the absense of a real pread() is actually even *less* of a
> POSIX pread, since it doesn't even try to save/restore the old position
> (it knows that git doesn't care).
Not that. I meant the value read returned wasn't checked nor returned.
Suppose read failed (on Windows it happens all the time, especially if you
stress it a bit) - you'll never know it did and the buffer will contain either
garbage or previous data. Now imagine we _did_ have a past-eof
condition or bleeding into sign-bit (because of some 64-bit confusion)...
> So I don't think that explains why git doesn't like cygwin's pread. I
> suspect an earlier version of cygwin had an even more broken version of
> pread at some point.
Yep, that could be another reason.
^ permalink raw reply
* [PATCH] use lockfile.c routines in git_commit_set_multivar()
From: Bradford C. Smith @ 2007-07-26 16:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Bradford C. Smith
In-Reply-To: <7vbqe0cazy.fsf@assigned-by-dhcp.cox.net>
Changed git_commit_set_multivar() to use the routines provided by
lockfile.c to reduce code duplication and ensure consistent behavior.
Signed-off-by: Bradford C. Smith <bradford.carl.smith@gmail.com>
---
I am resubmitting this patch to be considered separately from the
symlink resolution change. It differs from the first time I submitted
it only in that I have corrected the multi-line comment formatting I
used.
I ran the full test suite (make test) on this patch without failures.
config.c | 30 ++++++++++++++++++------------
1 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/config.c b/config.c
index f89a611..dd2de6e 100644
--- a/config.c
+++ b/config.c
@@ -715,7 +715,7 @@ int git_config_set_multivar(const char* key, const char* value,
int fd = -1, in_fd;
int ret;
char* config_filename;
- char* lock_file;
+ struct lock_file *lock = NULL;
const char* last_dot = strrchr(key, '.');
config_filename = getenv(CONFIG_ENVIRONMENT);
@@ -725,7 +725,6 @@ int git_config_set_multivar(const char* key, const char* value,
config_filename = git_path("config");
}
config_filename = xstrdup(config_filename);
- lock_file = xstrdup(mkpath("%s.lock", config_filename));
/*
* Since "key" actually contains the section name and the real
@@ -770,11 +769,12 @@ int git_config_set_multivar(const char* key, const char* value,
store.key[i] = 0;
/*
- * The lock_file serves a purpose in addition to locking: the new
+ * The lock serves a purpose in addition to locking: the new
* contents of .git/config will be written into it.
*/
- fd = open(lock_file, O_WRONLY | O_CREAT | O_EXCL, 0666);
- if (fd < 0 || adjust_shared_perm(lock_file)) {
+ lock = xcalloc(sizeof(struct lock_file), 1);
+ fd = hold_lock_file_for_update(lock, config_filename, 0);
+ if (fd < 0) {
fprintf(stderr, "could not lock config file\n");
free(store.key);
ret = -1;
@@ -914,25 +914,31 @@ int git_config_set_multivar(const char* key, const char* value,
goto write_err_out;
munmap(contents, contents_sz);
- unlink(config_filename);
}
- if (rename(lock_file, config_filename) < 0) {
- fprintf(stderr, "Could not rename the lock file?\n");
+ if (close(fd) || commit_lock_file(lock) < 0) {
+ fprintf(stderr, "Cannot commit config file!\n");
ret = 4;
goto out_free;
}
+ /* fd is closed, so don't try to close it below. */
+ fd = -1;
+ /*
+ * lock is committed, so don't try to roll it back below.
+ * NOTE: Since lockfile.c keeps a linked list of all created
+ * lock_file structures, it isn't safe to free(lock). It's
+ * better to just leave it hanging around.
+ */
+ lock = NULL;
ret = 0;
out_free:
if (0 <= fd)
close(fd);
+ if (lock)
+ rollback_lock_file(lock);
free(config_filename);
- if (lock_file) {
- unlink(lock_file);
- free(lock_file);
- }
return ret;
write_err_out:
--
1.5.3.rc3.9.g1b487
^ permalink raw reply related
* Re: Windows support
From: Marius Storm-Olsen @ 2007-07-26 16:58 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Johannes Schindelin
In-Reply-To: <fcaeb9bf0707260807u476719e3rec2dcf5f780013c0@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]
Nguyen Thai Ngoc Duy wrote:
> On 7/26/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> Thank you for working on this!
>>
>> However, I am not completely convinced that having a builtin shell is all
>> that useful. I for one would like to have MinGW busybox _separate_ from
>> git...
>
> I make MinGW busybox part of git for some reasons:
>
> - Making a full MinGW busybox would take lots of time. I don't need
> busybox for Windows. What I need is a shell and enough POSIX utilities
> to run git shell scripts without any dependencies. Windows users
> (including myself when I have to use Windows) hate dependencies.
> - I don't want MinGW busybox to be used outside of git (if it is
> installed separated from git), there are cygwin and msys already. I
> don't want to compete them. And I don't like conflicts (not sure
> though) because you have multiple UNIX emulations on the same system.
(..snip..)
Hi Duy,
*drool*
This was an extremely good idea! Thank you so much for working on it!
I'll be sure to play around with it, and see if there's any way I can
help out. Guess I finally have to get that MinGW compile environment set
up then :-)
Btw, are you compiling with MinGW on Windows, or cross-compiling on Linux?
Neat neat neat!
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ 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