* Re: Windows support
From: Shawn O. Pearce @ 2007-07-26 7:13 UTC (permalink / raw)
To: hanwen
Cc: Johannes Schindelin, git, Junio C Hamano, Dmitry Kakurin,
Nguyen Thai Ngoc Duy
In-Reply-To: <f329bf540707260002p117937tc9bc70050ef87838@mail.gmail.com>
Han-Wen Nienhuys <hanwenn@gmail.com> wrote:
> 2007/7/25, Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> >Did you succeed in adding perl?
>
> >It is not that important, because I plan
> >to make git-gui the main user interface with this installer. But Junio
> >keeps adding Perl scripts (ATM add -i and remote) that I have to convert
> >later...
>
> I don't see what this is good for.
What git-gui is good for? Its a GUI. For people who perfer to use
mice and push buttons over keys and a command prompt. A large number
of people in this world (many of them on Windows) like these things.
Me, I'm more command line than I am GUI, yet I develop git-gui.
So I find myself using it a lot, just so I can eat my own dogfood.
Or do you mean Dscho's other point about rewriting tools into C?
> I would suggest to making a clear
> decision of what are recommended languages, and move everything else
> to contrib/ .. Currently, C and bash seem the most reasonable choice,
> but you could decide for perl, but then the consequence should be that
> the bash scripts are translated into perl. Having both bash and perl
> serves no purpose, and will lead to duplication of library code to
> interact with the git binary.
Sure, but there's some stuff that shell is good at, and other stuff
that Perl is good at. Forcing everything into one mold while we
prototype new features is really limiting.
But both are slower on fork challenged systems than using native C.
Look at git-fetch for example; my ~400+ branch repository is taking
upwards of 5 minutes to run a no-argument, no-changes git-fetch in.
All sh and fork overhead.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 4/5] Add test for sanitized work-tree behaviour
From: Junio C Hamano @ 2007-07-26 7:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707260732130.14781@racer.site>
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?
^ permalink raw reply
* Re: Windows support
From: Han-Wen Nienhuys @ 2007-07-26 7:18 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Johannes Schindelin, git, Junio C Hamano, Dmitry Kakurin,
Nguyen Thai Ngoc Duy
In-Reply-To: <20070726071316.GE18114@spearce.org>
2007/7/26, Shawn O. Pearce <spearce@spearce.org>:
> Han-Wen Nienhuys <hanwenn@gmail.com> wrote:
> > 2007/7/25, Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > >Did you succeed in adding perl?
> >
> > >It is not that important, because I plan
> > >to make git-gui the main user interface with this installer. But Junio
> > >keeps adding Perl scripts (ATM add -i and remote) that I have to convert
> > >later...
> >
> > I don't see what this is good for.
>
> What git-gui is good for? Its a GUI. For people who perfer to use
> mice and push buttons over keys and a command prompt. A large number
> of people in this world (many of them on Windows) like these things.
> Me, I'm more command line than I am GUI, yet I develop git-gui.
> So I find myself using it a lot, just so I can eat my own dogfood.
>
> Or do you mean Dscho's other point about rewriting tools into C?
The last one. The windows installers actually includes a copy of
tcl/tk so you can run gitk on windows. .
> > I would suggest to making a clear
> > decision of what are recommended languages, and move everything else
> > to contrib/ .. Currently, C and bash seem the most reasonable choice,
> > but you could decide for perl, but then the consequence should be that
> > the bash scripts are translated into perl. Having both bash and perl
> > serves no purpose, and will lead to duplication of library code to
> > interact with the git binary.
>
> Sure, but there's some stuff that shell is good at, and other stuff
> that Perl is good at. Forcing everything into one mold while we
> prototype new features is really limiting.
I'm not contradicting that, but merely suggesting that they go into
contrib/ and are not recommended as standard git commands, and don't
need to be packaged for windows.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: problem after cvsimport
From: Bert Douglas @ 2007-07-26 7:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsl7b8x5w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Bert Douglas <bertd@tplogic.com> writes:
>
>
>> Am I going to have to do "-f" a lot?
>> How will I know when to do it?
>> Why not do it all the time?
>>
>
> With recent enough git, you shouldn't even have to do that extra
> "git checkout". It was noticed and fixed quite a while ago.
>
>
Thanks much.
$ git --version
git version 1.5.2.4
But I guess my basic question remains in two parts.
(1) Will it 'get out of sync' again sometime ?
(2) Will anything bad happen if I always do 'checkout -f' ?
^ permalink raw reply
* Re: [PATCH] Teach git-gui to split hunks
From: Johannes Sixt @ 2007-07-26 7:32 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0707260630570.14781@racer.site>
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. ;)
-- Hannes
^ permalink raw reply
* rename directory weirdness
From: Bert Douglas @ 2007-07-26 7:47 UTC (permalink / raw)
To: git
I am new user. Trying to understand git.
I renamed a directory.
$ mv dir1 dir2
$ git add dir2
$ git commit -a
It popped up my editor with long list of files that it recognized as
'renamed'.
But one file it listed as 'copied' and further down as 'deleted'.
Why this one file out of thousands not recognized as 'renamed' ?
Is this a sign of a problem ?
Thanks again for all help.
^ permalink raw reply
* Re: Windows support
From: Julian Phillips @ 2007-07-26 7:52 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: hanwen, Johannes Schindelin, git, Junio C Hamano, Dmitry Kakurin,
Nguyen Thai Ngoc Duy
In-Reply-To: <20070726071316.GE18114@spearce.org>
On Thu, 26 Jul 2007, Shawn O. Pearce wrote:
> Han-Wen Nienhuys <hanwenn@gmail.com> wrote:
>> 2007/7/25, Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>> Did you succeed in adding perl?
>>
>>> It is not that important, because I plan
>>> to make git-gui the main user interface with this installer. But Junio
>>> keeps adding Perl scripts (ATM add -i and remote) that I have to convert
>>> later...
>>
>> I don't see what this is good for.
>
> What git-gui is good for? Its a GUI. For people who perfer to use
> mice and push buttons over keys and a command prompt. A large number
> of people in this world (many of them on Windows) like these things.
> Me, I'm more command line than I am GUI, yet I develop git-gui.
> So I find myself using it a lot, just so I can eat my own dogfood.
>
> Or do you mean Dscho's other point about rewriting tools into C?
>
>> I would suggest to making a clear
>> decision of what are recommended languages, and move everything else
>> to contrib/ .. Currently, C and bash seem the most reasonable choice,
>> but you could decide for perl, but then the consequence should be that
>> the bash scripts are translated into perl. Having both bash and perl
>> serves no purpose, and will lead to duplication of library code to
>> interact with the git binary.
Well, that really doesn't make much sense from the Linux POV. Bash, perl
and C are all well supported languages, each with its own set of
strengths. The tools that are being written are true parts of git - not
optional contributed bolt-ons.
Admittedly it would probably increase the motivation to make everything
built in if only C programs were allowed outside of contrib - but git
would probably have not got where it is in that case.
> Sure, but there's some stuff that shell is good at, and other stuff
> that Perl is good at. Forcing everything into one mold while we
> prototype new features is really limiting.
>
> But both are slower on fork challenged systems than using native C.
> Look at git-fetch for example; my ~400+ branch repository is taking
> upwards of 5 minutes to run a no-argument, no-changes git-fetch in.
> All sh and fork overhead.
I have a repo with ~9000 refs - it's what motivated me to start rewriting
fetch in C ...
times for fetch to decide there were no changes (on Linux, local XFS
disk):
pure-shell: ~45 mins
shell + C (fetch--tool): ~30 secs
pure C: ~0.5 secs
(the C version isn't the current version that Daniel has, but rather an
older incomplete version that I had got far enough to do that much - so
it may actually be slightly slower now ...)
--
Julian
---
If you want to travel around the world and be invited to speak at a lot of
different places, just write a Unix operating system.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] gitk: let you easily specify lines of context in diff view
From: Steffen Prohaska @ 2007-07-26 7:59 UTC (permalink / raw)
To: git, paulus; +Cc: Steffen Prohaska
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.
Minor improvements are needed:
* The value you type in is only used on the next update.
* lines of context is initially always 3.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
gitk | 25 +++++++++++++++++++++++--
1 files changed, 23 insertions(+), 2 deletions(-)
The patch may need some polishing. I know some tcl but this is the
first time I tried tk:
* I initialized diffcontext globally, ok?
* I don't know how to update the view after entering a new value.
Steffen
diff --git a/gitk b/gitk
index 39e452a..4e9acff 100755
--- a/gitk
+++ b/gitk
@@ -500,6 +500,7 @@ proc makewindow {} {
global textfont mainfont uifont tabstop
global findtype findtypemenu findloc findstring fstring geometry
global entries sha1entry sha1string sha1but
+ global diffcontextstring
global maincursor textcursor curtextcursor
global rowctxmenu fakerowmenu mergemax wrapcomment
global highlight_files gdttype
@@ -714,7 +715,12 @@ proc makewindow {} {
-command changediffdisp -variable diffelide -value {0 1}
radiobutton .bleft.mid.new -text "New version" \
-command changediffdisp -variable diffelide -value {1 0}
- pack .bleft.mid.diff .bleft.mid.old .bleft.mid.new -side left
+ label .bleft.mid.labeldiffcontext -text " Lines of context: " \
+ -font $uifont
+ entry .bleft.mid.diffcontext -width 5 -font $textfont -textvariable diffcontextstring
+ trace add variable diffcontextstring write diffcontextchange
+ lappend entries .bleft.mid.diffcontext
+ pack .bleft.mid.diff .bleft.mid.old .bleft.mid.new .bleft.mid.labeldiffcontext .bleft.mid.diffcontext -side left
set ctext .bleft.ctext
text $ctext -background $bgcolor -foreground $fgcolor \
-tabs "[expr {$tabstop * $charspc}]" \
@@ -4872,12 +4878,25 @@ proc gettreediffline {gdtf ids} {
return 0
}
+proc diffcontextchange {n1 n2 op} {
+ global diffcontextstring diffcontext
+
+ if {[string is integer $diffcontextstring]} {
+ if {$diffcontextstring > 0} {
+ set diffcontext $diffcontextstring
+# TODO: need to trigger update of diff display
+# tried dodiffindex but that corrupted the history view
+ }
+ }
+}
+
proc getblobdiffs {ids} {
global diffopts blobdifffd diffids env
global diffinhdr treediffs
+ global diffcontext
set env(GIT_DIFF_OPTS) $diffopts
- if {[catch {set bdf [open [diffcmd $ids {-p -C}] r]} err]} {
+ if {[catch {set bdf [open [diffcmd $ids "-p -C -U$diffcontext"] r]} err]} {
puts "error getting diffs: $err"
return
}
@@ -7537,6 +7556,8 @@ set markingmatches 0
set optim_delay 16
+set diffcontext 3
+
set nextviewnum 1
set curview 0
set selectedview 0
--
1.5.3.rc3.20.g06b4
^ permalink raw reply related
* Re: Windows support
From: Andy Parkins @ 2007-07-26 8:14 UTC (permalink / raw)
To: git; +Cc: Henning Rogge
In-Reply-To: <87eacd830707252308t32c98108w39b52cdb9c61cd1e@mail.gmail.com>
On Thursday 2007 July 26, Henning Rogge wrote:
> QGit might be a good alternative too, especially because QT4 is
> available for Windows.
I have a colleague using qgit4 on Windows with git on cygwin. Works very
well; and qgit being native rather than tcl/tk+cygwin makes it a lot faster.
I've also seen him using gitweb for browsing around my repository.
We've never lost data, and have had significantly more success using git
itself rather than git-cvsserver, which was a constant struggle.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: Bug in gitk search box
From: Marco Costalba @ 2007-07-26 8:21 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, Brian Downing, git
In-Reply-To: <18088.10039.780711.708582@cargo.ozlabs.ibm.com>
On 7/26/07, Paul Mackerras <paulus@samba.org> wrote:
>
> OK, I'll have to change gitk then. It looks like both Marco and I got
> tricked by this.
Yes. With commit c1672ba272c8e of 22 of Jun I make qgit to always
append a '\0' at the end of the stream so to avoid to change parsing
function.
Marco
^ permalink raw reply
* Antwort: git-gui i18n introductory document
From: Christian Stimming @ 2007-07-26 8:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: Irina Riesen, Johannes Schindelin, Paolo Ciarrocchi,
Shawn O. Pearce, Xudong Guan, git, stimming
In-Reply-To: <7vir87adzo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> schrieb am 26.07.2007 08:14:03:
> I also noticed that po/ directory lacks
> any guidance document for translators. Here is an attempt to
> add po/README.
Thanks for this write-up. This is very nice, and I agree it is helpful for
everyone working on the translations.
FYI, in the gnucash project we have a similar write-up, only that over time
we were asked to cover pretty much any subject that came up, so the
document ended up quite long. See http://wiki.gnucash.org/wiki/Translation
One topic that hasn't been covered but should be added is the po/glossary/
directory. I'd suggest to point new translators to there *first*, because
getting the glossary right is a necessary condition for achieving a
high-quality translation.
> I understand that Christian's stance on this issue, to put it
> bluntly, is that you should not be in the l10n business if you
> are not versed with gettext toolchain.
I wouldn't require someone to be "versed". But I would indeed require
someone to 1. have the gettext toolchain *installed* (after all, that
person also must have git installed), and 2. I'd strongly recommend to work
on the po files with one of the specialized *po file editors* instead of a
plain text editor. There are so many editors available: emacs po-mode,
KBabel, poedit, GTranslator; it definitely shouldn't be difficult to use at
least one of them.
Nevertheless, explaining the po file structure here in the README is a good
thing in itself.
Some comments on your explanation in the file itself:
> +0. Getting started.
> +
> +You would first need to have a working "git". Your distribution
> +may have git-core package (do not get "GNU Interactive Tools" --
> +that is a different "git"). Please install it.
You should mention the gettext package (required for .msg creation) and one
of the po editors here as well.
> + - Control characters, such as newlines, are written in
> + backslash sequence
> +
> + - A long message can be split across multiple lines by ending
> + the string with a doublequote, and starting another string on
> + the next line with another doublequote.
Good points. Additionally, we need to explain the [format...] arguments
here, i.e. what to do with a "%s" or "%i" or "%%" in the string.
> +You can test the result by running "make", which would create
> +po/af.msg file, and then running the resulting git-gui in your
> +locale:
> +
> + $ make install
> + $ LANG=af git-gui
Does the latter line give the newly created translation for you, even
without "make install"? For me and from what I understand from the code,
the message catalogs are searched for in the subdirectory msgs/ of the lib/
directory, which means they wouldn't be found in an unmodified checkout.
But you can create a symlink of that name to have the checkout use directly
the po/ directory, like so:
cd lib
ln -s ../po msgs
cd ..
LANG=jp ./git-gui.sh
and I also have to call the local git-gui with ./ because . is not in my
PATH, which is probably the same for some people out there as well.
> + $ edit po/af.po
> + ... be sure to update Last-Translator: and
> + ... PO-Revision-Date: lines.
Yes, thanks for the reminder here.
> + - The original text in English of an older message you already
> + translated might have been changed. You will notice a
> + comment line that begins with "#, fuzzy" in front of such a
> + message. msgmerge tool made its best effort to match your
> + old translation with the message from the updated software,
> + but you will find it matched your old translated message to a
> + new msgid that does not make any sense -- you would need to
> + fix them.
Yes. You should also mention here that a msgstr marked as "#, fuzzy" will
be treated as if no translation existed at all by msgfmt. Hence, the
instructions for the translators should be something like this: "Messages
which are marked as fuzzy will not be used in the program. You have to
check the msgstr, fix it to match the msgid message, and remove the #,
fuzzy line."
Overall, this is a nice writeup and it is very helpful. Thanks a lot.
Christian
IBEO Automobile Sensor GmbH - Sitz: Hamburg - Handelsregister: Hamburg HRB
67903
Geschäftsführer: Dr. Ulrich S. Lages
^ permalink raw reply
* Re: git-gui-i18n: Make "Revert changes in these $n files" translatable.
From: Christian Stimming @ 2007-07-26 8:47 UTC (permalink / raw)
To: Harri Ilari Tapio Liusvaara
Cc: Shawn O. Pearce, Brett Schwarz, git, Paul Mackerras,
Junio C Hamano
Dear Harri, (responding to the commit in the mob branch)
thanks for discovering this message that was missed from translation.
I'd like to use the opportunity to explain shortly the situation with
plural form translations. You wrote:
+ # Split question between singular and plural cases, because
+ # such distinction is needed in some languages.
The issue with plural forms is even more complicated than that. In
fact, the gettext library in C has the separate function ngettext()
solely for the purpose of dealing with plural forms correctly; see
http://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html#Plural-forms for the (lengthy but interesting) explanation. All one has to know is this: There are many languages out there that have not only one singular and one plural form, but much more of them, depending on the actual number of items being talked about. (Example: Three forms, with special cases for 1 and 2, 3, 4, in Slovak and
Czech)
Unfortunately the msgcat package of Tcl is missing all support for a
meaningful implementation of plural forms. (IMHO that's quite a
shortcoming of msgcat and quite a big advantage of gettext, but there
isn't an easy solution in sight. Whatever.) For that reason we have to
refrain from using any plural-form-depending messages at all.
Enough of this discussion.
In this *particular* commit, the plural-form discussion misses the
point with the message in question. In this particular message, if
$n==1 (one single file to be reverted), the *file name* should be
printed in the message. If $n > 1, the *number of files* should be
printed in the message. The i18n error that had to be fixed is that
the English message used to be built up from several parts, which is a
no-no for translatable strings, and you have fixed that correctly.
Nevertheless the last [mc...] message in your commit doesn't end up
that nicely for the translator. As you have the first sentence already
in another language and translated separately, I would suggest to have
the second sentence translated separately as well, and then appending
these together in the actual message being shown. Like the patch below.
Thanks again for spotting this error.
Christian
diff --git a/lib/index.tcl b/lib/index.tcl
index 9080ac6..e1bda52 100644
--- a/lib/index.tcl
+++ b/lib/index.tcl
@@ -350,17 +350,15 @@ proc revert_helper {txt paths} {
unlock_index
return
} elseif {$n == 1} {
- set s "[short_path [lindex $pathList]]"
+ set query [mc "Revert changes in file %s?" [short_path
[lindex $pathList]]]
} else {
- set s "these $n files"
+ set query [mc "Revert changes in these %i files?" $n]
}
set reply [tk_dialog \
.confirm_revert \
"[appname] ([reponame])" \
- [mc "Revert changes in %s?
-
-Any unadded changes will be permanently lost by the revert." $s] \
+ "$query\n\n[mc "Any unadded changes will be
permanently lost by the revert."]" \
question \
1 \
[mc "Do Nothing"] \
--
1.5.3.rc2.12.gbc280
^ permalink raw reply related
* Re: rename directory weirdness
From: Steven Grimm @ 2007-07-26 8:54 UTC (permalink / raw)
To: Bert Douglas; +Cc: git
In-Reply-To: <46A8519D.5050801@tplogic.com>
Bert Douglas wrote:
> $ mv dir1 dir2
> $ git add dir2
> $ git commit -a
>
> It popped up my editor with long list of files that it recognized as
> 'renamed'.
> But one file it listed as 'copied' and further down as 'deleted'.
>
> Why this one file out of thousands not recognized as 'renamed' ?
> Is this a sign of a problem ?
Are the contents of the file in question identical to those of some
other file in your directory tree? I've seen that happen too. There were
some proposed improvements to address this last time it came up on the
list, but I'm not sure if any of them actually made it into the code base.
-Steve
^ permalink raw reply
* Re: Windows support
From: Robin Rosenberg @ 2007-07-26 9:11 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Shawn O. Pearce, Dmitry Kakurin,
Nguyen Thai Ngoc Duy, git
In-Reply-To: <Pine.LNX.4.64.0707260614500.14781@racer.site>
torsdag 26 juli 2007 skrev Johannes Schindelin:
> Hi,
>
> On Wed, 25 Jul 2007, Junio C Hamano wrote:
>
> > If that is the case, "Git for Windows" probably should package MSYS as
> > part of it, I would think, to match the expectation of the users there.
> > I know two Johannes'es and Han-Wen spent quite a lot of effort on
> > Windows port and packaging, but perhaps that little (well, I should not
> > be judging if that is a little or huge, as I do not do Windows)
> > finishing touch would make Windows users much happier?
>
> Windows users are only happy when they can bug developers.
>
> Seriously again, the biggest problem with Han-Wen's installer was that it
> insists on cross-compiling _all_ the packages. This makes it easy for
> Han-Wen to upgrade packages and compile the thing on Linux in one go.
> However, it never worked with bash, and I could not fix it: I can read
> Python, but not _that_ Python.
Will windows developers need to get Linux just in order to do a two line fix,
or will the build process work on Windows too (provided the developer gets
a number of extra packages).
-- robin
^ permalink raw reply
* Re: [PATCH] gitweb: Fix error in generating snapshot
From: Jakub Narebski @ 2007-07-26 9:17 UTC (permalink / raw)
To: git
In-Reply-To: <11854018464134-git-send-email-jnareb@gmail.com>
Jakub Narebski wrote:
> There was an error while generating cmmandline to run git-archive:
> there were no whitespace between two options.
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Noticed-by: Mark Levedahl <mlevedahl@gmail.com>
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] git-gui wording suggestions
From: Christian Stimming @ 2007-07-26 9:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Brett Schwarz, git, Paul Mackerras, Junio C Hamano
Unifiy wording to say "to stage" instead of "to add" always.
Currently, there is a mixup of saying "staged changes" vs. "added
changes" in the git-gui program. You obviously decided to say "staging
area" instead of "index", hence "add to staging area"/"stage" instead
of "add to index". I think this change is very good. Talking about
the "staging area" explains the nature of this thingy much better and
much more unambiguous than "index". Actually only after reading the
wording "staging area" I eventually understood what this "index" thing
is about... (Also, your chosen wording helps for creating a nice and
consistent translation of that, but that's only an added bonus.)
With this patch I'd propose to talk every only about "stage" instead
of "add". IMHO that's just the logical conclusion of the above wording
decision. What do you think?
---
git-gui.sh | 6 +++---
lib/checkout_op.tcl | 2 +-
lib/commit.tcl | 4 ++--
lib/index.tcl | 2 +-
lib/merge.tcl | 2 +-
5 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 3536d38..fd8b4b4 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1824,12 +1824,12 @@ if {[is_enabled multicommit] || [is_enabled
singlecommit]} {
lappend disable_on_lock \
[list .mbar.commit entryconf [.mbar.commit index last] -state]
- .mbar.commit add command -label [mc "Add To Commit"] \
+ .mbar.commit add command -label [mc "Stage To Commit"] \
-command do_add_selection
lappend disable_on_lock \
[list .mbar.commit entryconf [.mbar.commit index last] -state]
- .mbar.commit add command -label [mc "Add Existing To Commit"] \
+ .mbar.commit add command -label [mc "Stage Changed Files To Commit"] \
-command do_add_all \
-accelerator $M1T-I
lappend disable_on_lock \
@@ -2180,7 +2180,7 @@ pack .vpane.lower.commarea.buttons.rescan -side
top -fill x
lappend disable_on_lock \
{.vpane.lower.commarea.buttons.rescan conf -state}
-button .vpane.lower.commarea.buttons.incall -text [mc "Add Existing"] \
+button .vpane.lower.commarea.buttons.incall -text [mc "Stage Changed"] \
-command do_add_all
pack .vpane.lower.commarea.buttons.incall -side top -fill x
lappend disable_on_lock \
diff --git a/lib/checkout_op.tcl b/lib/checkout_op.tcl
index 25bf9cf..a2f2509 100644
--- a/lib/checkout_op.tcl
+++ b/lib/checkout_op.tcl
@@ -247,7 +247,7 @@ method _checkout {} {
if {[lock_index checkout_op]} {
after idle [cb _start_checkout]
} else {
- _error $this [mc "Index is already locked."]
+ _error $this [mc "Staging area (index) is already locked."]
delete_this
}
}
diff --git a/lib/commit.tcl b/lib/commit.tcl
index f60b11e..aa9110d 100644
--- a/lib/commit.tcl
+++ b/lib/commit.tcl
@@ -153,7 +153,7 @@ The rescan will be automatically started now.
U? {
error_popup [mc "Unmerged files cannot be committed.
-File %s has merge conflicts. You must resolve them and add the file
before committing.
+File %s has merge conflicts. You must resolve them and stage the
file before committing.
" [short_path $path]]
unlock_index
return
@@ -169,7 +169,7 @@ File %s cannot be committed by this program.
if {!$files_ready && ![string match *merge $curType]} {
info_popup [mc "No changes to commit.
-You must add at least 1 file before you can commit.
+You must stage at least 1 file before you can commit.
"]
unlock_index
return
diff --git a/lib/index.tcl b/lib/index.tcl
index 38aa6ee..e91b864 100644
--- a/lib/index.tcl
+++ b/lib/index.tcl
@@ -367,7 +367,7 @@ proc revert_helper {txt paths} {
"[appname] ([reponame])" \
[mc "%s
-Any unadded changes will be permanently lost by the revert." $query] \
+Any unstaged changes will be permanently lost by the revert." $query] \
question \
1 \
[mc "Do Nothing"] \
diff --git a/lib/merge.tcl b/lib/merge.tcl
index 40e82a9..a6e8cc9 100644
--- a/lib/merge.tcl
+++ b/lib/merge.tcl
@@ -46,7 +46,7 @@ The rescan will be automatically started now.
File %s has merge conflicts.
-You must resolve them, add the file, and commit to complete the
current merge. Only then can you begin another merge.
+You must resolve them, stage the file, and commit to complete the
current merge. Only then can you begin another merge.
" [short_path $path]]
unlock_index
return 0
--
1.5.3.rc2.12.gbc280
^ permalink raw reply related
* Re: Windows support
From: Marius Storm-Olsen @ 2007-07-26 9:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Stephen Cuppett, Steffen Prohaska, git
In-Reply-To: <alpine.LFD.0.999.0707251131540.3607@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2253 bytes --]
Linus Torvalds said the following on 25.07.2007 20:43:
> On Wed, 25 Jul 2007, Stephen Cuppett wrote:
>> I don't know if the performance problems are cygwin or not. More
>> knowledgeable people might be able to answer, it's just what I'm
>> observing right now. It could be more fundamental to the types
>> of access being performed en masse on inode-based versus NTFS
>> systems.
>
> I think cygwin may add some overhead, but people should really
> realize that Linux is quite often an order of magnitude faster (or
> more) than other systems on some very basic operations.
>
(..snip..)
>
> (It will just not be so *blazingly* fast, ie things like "git
> status" will generally not be instantaneous).
Let me present some numbers:
My repository is ~680MB, and 19323 tracked files, in 2264 directories.
When in a compiled state the total is 27540 files, in 4885 directories.
When file system cache is warm, I get the following times:
Native: dir /B /S 1.077s
dir /S 1.707s (shows time, size/type)
MSys: ls -f1AUR 34.608s
find . -type f 6.718s
git diff (empty diff) 1.18s
git status 5.5s
and when the system cach is cold:
git status 54.55s
Maybe you guys have other git commands which are also/more interesting
to look at/benchmark?
Windows people should also be aware that it's possible to tweak the
amount of memory which the OS uses for the file cache. On XP you can
change it _roughly_ in System Properties panel (Right-click on My
Computer), then Advanced - Performance Settings - Advanced -
Memory Usage:
Normal setting is "Programs" for non-servers Windows systems, while
you can select "System cache" make the OS allocate more memory for
the system caches. I've tried both, and the setting doesn't really
affect the file operations much when the cache is warm, but it
probably affects how long the cache stays warm.
Also note that you can use Sysinternal's CacheSet (free), to
manipulate the working-set parameters of the system file cache.
You'll find that here:
http://www.microsoft.com/technet/sysinternals/FileAndDisk/CacheSet.mspx
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: Windows support
From: Marius Storm-Olsen @ 2007-07-26 9:41 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Steffen Prohaska, Dmitry Kakurin, Steven Grimm, git
In-Reply-To: <20070726065332.GB18114@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 892 bytes --]
>> * Be careful with the case in filenames. Similarly, avoid
>> special chars in filenames.
>
> This is true. Git doesn't like getting file names with case only
> differences on such a platform. E.g. just today I wanted to do the
> following:
>
> git mv foo.c Foo.c
>
> but had to instead do:
>
> git mv foo.c CRAP && git mv CRAP Foo.c
>
> because the former won't work on a filesystem that ignores case. I
> have the same problem on my Mac OS X HFS+ volume as it also ignores
> case.
You can turn off case-insensitivity in the Windows kernel, by
using RegEdit, and setting the following registry key to 0:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive
I haven't tried it, but it should help your case above. Just keep
in mind that you can then check in files which your coworkers can't
checkout :-)
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: Windows support
From: Marius Storm-Olsen @ 2007-07-26 9:44 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Steffen Prohaska, Dmitry Kakurin, Steven Grimm, git
In-Reply-To: <46A86C42.8070103@trolltech.com>
[-- Attachment #1: Type: text/plain, Size: 511 bytes --]
> You can turn off case-insensitivity in the Windows kernel, by using
> RegEdit, and setting the following registry key to 0:
>
> HKLM\SYSTEM\CurrentControlSet\Control\Session
> Manager\kernel\obcaseinsensitive
>
> I haven't tried it, but it should help your case above. Just keep
> in mind that you can then check in files which your coworkers can't
> checkout :-)
PS: You'll have to reboot for it to take effect, and don't blame _me_
if it doesn't reboot successfully! ;-)
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: Windows support
From: Johannes Sixt @ 2007-07-26 10:35 UTC (permalink / raw)
To: git
In-Reply-To: <200707261111.54439.robin.rosenberg.lists@dewire.com>
Robin Rosenberg wrote:
> torsdag 26 juli 2007 skrev Johannes Schindelin:
> > Seriously again, the biggest problem with Han-Wen's installer was that it
> > insists on cross-compiling _all_ the packages. This makes it easy for
> > Han-Wen to upgrade packages and compile the thing on Linux in one go.
> > However, it never worked with bash, and I could not fix it: I can read
> > Python, but not _that_ Python.
>
> Will windows developers need to get Linux just in order to do a two line fix,
> or will the build process work on Windows too (provided the developer gets
> a number of extra packages).
The build process works on Windows, too. That's how I do it.
README.MinGW lists the packages that you need.
-- Hannes
^ permalink raw reply
* [ANNOUNCE] GIT MinGW port updated to v1.5.3.rc2
From: Johannes Sixt @ 2007-07-26 11:02 UTC (permalink / raw)
To: git
I've just pushed an update of the MinGW port to:
clone: git://repo.or.cz/git/mingw.git
gitweb: http://repo.or.cz/w/git/mingw.git
It is now at v1.5.3.rc2.
NOTE! This is only lightly tested, i.e. it passes (most of) the test
suite(*), but it hasn't been used in production, yet.
If you need a known working version, pick the state at the tags
mingw-v1.5.2.4-devel
mingw-v1.5.2.4
(You must fetch mingw-v1.5.2.4-devel explicitly; it is not on any
branch.)
(*) It does pass the tests of the important tools, so...
-- Hannes
PS: I'll be on vacation for a while, hence this hurried update.
^ permalink raw reply
* git-gui problem with version number.
From: David Kastrup @ 2007-07-26 11:20 UTC (permalink / raw)
To: git
Hi, git-gui does not get along with the creativeness in git
versioning:
git-gui
Error in startup script: expected version number but got "1.5.3.rc2.4.g726f9-dirty"
while executing
"package vcompare $_git_version $vr"
("2" arm line 4)
invoked from within
"switch [llength $args] {
0 {
return $_git_version
}
2 {
set op [lindex $args 0]
set vr [lindex $args 1]
set cm [package vcompare $_git_ver..."
(procedure "git-version" line 4)
invoked from within
"git-version < 1.5"
(file "/usr/local/bin/git-gui" line 1)
--
David Kastrup
^ permalink raw reply
* Re: Windows support
From: Nguyen Thai Ngoc Duy @ 2007-07-26 11:29 UTC (permalink / raw)
To: hanwen
Cc: Johannes Schindelin, git, Junio C Hamano, Shawn O. Pearce,
Dmitry Kakurin
In-Reply-To: <f329bf540707260002p117937tc9bc70050ef87838@mail.gmail.com>
On 7/26/07, Han-Wen Nienhuys <hanwenn@gmail.com> wrote:
> 2007/7/25, Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > Hi,
> >
> > [Funny, you quoted me, but culled _me_ from the Cc: list]
>
> It's because gmane does not do SMTP
>
> > > If you supply me with a shell script that will x-compile bash, I'll
> > > hapily code the python spec. IMO the real problem is that bash is a unix
> > > shell (tied to unix internals) and therefore, compiling it for something
> > > as horrid as windows is far from trivial.
> >
> > Will do.
> >
> > Did you succeed in adding perl?
>
> God forbid no. Perl is enormous, and I shudder at the thought of
> making all those modules compile, or even worse, writing actual perl
> code.
microperl [1] maybe? I haven't tried it yet.
[1] http://www.foo.be/docs/tpj/issues/vol5_3/tpj0503-0003.html
--
Duy
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Christian MICHON @ 2007-07-26 11:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andy Parkins, git, Johannes Schindelin, Marius Storm-Olsen,
Alex Riesen, Junio C Hamano, Shawn O. Pearce, Julian Phillips
In-Reply-To: <alpine.LFD.0.999.0707251327390.3607@woody.linux-foundation.org>
On 7/25/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Now, admittedly, I think one issue with Windows is that the "hump" is
> simply much bigger. The initial cost (not necessarily in money, but in
> effort) of getting involved in a development process is just a *lot*
> higher for Windows users than it is for just about any UNIX.
>
> If you're on some unix platform, the cost of getting involved is basically
> that the project should already work to some degree, and then there may be
> some relatively *trivial* issues with making sure that you've got a
> compiler installed and the basic libraries. But that's really quite easy
> on just about any UNIX, to the point that most people don't even have to
> think about it.
http://www.openlina.org could closing this gap, as a temp fix.
It's supposed to help running linux native binaries on windows through
some virtualization layer. Speed is supposed to be good, the host filesystem
is supposed to be accessible. Many suppositions, I haven't evaluated
this beast yet.
If this is truly usable, it would mean an easy migration for unix users,
using the command line.
For true windows users, git-gui, gitk and ultimately a windows explorer
plugin/addon will be needed still, as mentionned earlier in this thread.
It is to be noted though that C conversion and shell replacement
will not be all that is needed.
Today, I've a colinux environment containing git-1.5.2.3 and all needed
tools for development (shell, compiler, editor). When I perform some git
operations in any linux controlled filesystem (ramfs, ext2 over cobd), no
problem, git works as advertised.
When I used shared windows folder in the ntfs filesystem, there are
issues. Fsync fails when writing files (could be colinux related), but
git-init produces different .git/config file and git-commit does not work
(fatal: index file smaller than expected). The last 2 problems should be
windows related I believe and should hit as soon as the shell over C
portage will be done.
Unless the current patches in mingw.git can fix these of course.
--
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: 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
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