* Re: [PATCH] Trim leading / off of paths in git-svn prop_walk
From: Eric Wong @ 2008-01-09 22:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Kevin Ballard, Benoit Sigoure
In-Reply-To: <7v63y2hg8x.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Kevin Ballard <kevin@sb.org> writes:
>
> > prop_walk adds a leading / to all subdirectory paths. Unfortunately
> > this causes a problem when the remote repo lives in a subdirectory itself,
> > as the leading / causes subsequent PROPFIND calls to be executed on
> > the wrong path. Trimming the / before calling the PROPFIND fixes this problem.
> >
> > Signed-off-by: Kevin Ballard <kevin@sb.org>
>
> Eric, the change is very limited in scope (only the parameter to
> ra->get_dir() changes) so I can apply myself, if you agree this
> is a trivially correct fix. I just do not know svn-perl
> interface well enough to judge.
Yes it is. It appears this regression was introduced in
01bdab84e31763a98206c31cf99b9dc3cb221356 so yes, it's trivially
correct :)
Acked-by: Eric Wong <normalperson@yhbt.net>
>
> > All tests passed after this change, but since it seems to only apply
> > to WebDAV SVN repos I saw no way to add a new test.
> > git-svn.perl | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/git-svn.perl b/git-svn.perl
> > index 3308fe1..d5316eb 100755
> > --- a/git-svn.perl
> > +++ b/git-svn.perl
> > @@ -1858,6 +1858,7 @@ sub rel_path {
> > sub prop_walk {
> > my ($self, $path, $rev, $sub) = @_;
> >
> > + $path =~ s#^/##;
> > my ($dirent, undef, $props) = $self->ra->get_dir($path, $rev);
> > $path =~ s#^/*#/#g;
> > my $p = $path;
> > --
> > 1.5.4.rc2.68.ge708a-dirty
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Add [HOWTO] using merge subtree.
From: Junio C Hamano @ 2008-01-09 22:33 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Sean, git
In-Reply-To: <1199882097-10420-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> here is an updated version. i added a section (before the commands) to
> describe the workflow where the subtree merge strategy can be useful. i
> also added a section at the end where i mention submodules.
That's better.
> @@ -0,0 +1,48 @@
> +Date: Sat, 5 Jan 2008 20:17:40 -0500
> +From: Sean <seanlkml@sympatico.ca>
> +To: Miklos Vajna <vmiklos@frugalware.org>
> +Cc: git@vger.kernel.org
> +Subject: Re: how to use git merge -s subtree?
> +Abstract: In this article, Sean demonstrates how one can use the subtree merge
> + strategy.
> +Message-ID: <BAYC1-PASMTP12374B54BA370A1E1C6E78AE4E0@CEZ.ICE>
> +
> +How to use the subtree merge strategy
> +=====================================
> +
> +The merge strategy 'subtree' is a slightly modified 'recursive'. It merges
> +current branch A with other branch B using common merge base O (and if there
> +are more than one common merge bases, they are recursively merged), but it can
> +"shift" trees while doing so.
> +
> +This can be handy if you want to merge a branch to a subdirectory, for example
> +git has the git-gui master branch in its git-gui/ subdirectory.
> +
> +So the target is to merge a branch of repo B to a subdirectory of the current
> +branch.
> +
> +You need the followings steps to perform the master branch of B to the
> +subdirectory B/ for the first merge:
I think the presentation order is still screwy. Before saying
what it does, let's state why the reader might want to use what
we are going to describe, so that the reader can say "I am not
in that situation, I do not have to read the rest" and skip the
document quickly.
When you want to include contents in your project from
another project that has started its life independently, you
can do so by merging the other project into your project.
If there is no (and more importantly if there will never be
any) overlap in paths the two project have, you can merge
them without any tricks.
However, if there are overlapping paths (e.g. you have
Makefile, they have Makefile but as separate projects, these
two Makefiles do not have anything to do with each other),
you have a problem. You do not necessarily have the option
to merge these Makefiles together. Instead, you may want to
merge the other project as a subdirectory in your project.
The 'subtree' merge strategy is designed to help you in such
a situation.
Then give the birds-eye-view of the names you use in the example
description, so that the readers can substitute them to suit
their needs:
Suppose you are merging the "master" branch of another
project located at /path/to/B (the repository does not have
to be local but we use /path/to/B for the sake of
simplicity) as a subdirectory "dir-B" in our project. Here
is the procedure to bootstrap and maintain such a layout.
> +----
> +$ git remote add -f B /path/to/B <1>
> +$ git merge -s ours --no-commit B/master <2>
> +$ git read-tree --prefix=B/ -u B/master <3>
> +$ git commit -m "Merge commit 'B/master'" <4>
> +$ git pull -s subtree B master <5>
> +----
> +<1> creates and fetches the remote.
> +<2> initiates a merge, but stops before committing it.
> +<3> reads B/master into the subdirectory "sub".
> +<4> all that remains is committing the completed merge.
>
> +You only need the above four steps once, after that you can keep doing:
> +
> +----
> +$ git pull -s subtree B master
> +----
This part looks like a half-updated WIP.
----------------
$ git remote add -f Bproject /path/to/B <1>
$ git merge -s ours --no-commit B/master <2>
$ git read-tree --prefix=dir-B/ -u B/master <3>
$ git commit -m "Merge B project as our subdirectory" <4>
$ git pull -s subtree Bproject master <5>
----------------
<1> name the other project "Bproject", and fetch.
<2> prepare for the later step to record the result as a merge.
<3> read "master" branch of Bproject to the subdirectory "dir-B".
<4> record the merge result.
<5> maintain the result with subsequent merges using "subtree"
Then the discussion.
> +The benefit of the subtree merge strategy over submodules is that submodules
> +were not always available and it may still make sense to avoid it today,
> +because use of a submodule in a repository makes the repository
> +non-interoperable with any clients older than 1.5.2 series.
That's not incorrect, but I think we would need to discuss more
important matters first. The discussion should consist of two
parts.
First, the tips, tricks and caveats when using subtree merge.
- The participant to your project may want to make changes
pertaining to the subtree merged project independently and
send the result upward, although it is not required (the
other project can merge from your project using subtree --
the subtree strategy can shift your tree up and let the other
project merge only the parts of your tree that corresponds to
it).
- The other project may not choose to. One possible reason not
to is if it does not want to connect its history to yours
(although you wanted to do so in your repository).
And comparison with an alternative, "submodules":
- It is simpler to merge another project using subtree than
treating the other project as "submodule", due to less
management hassles (pro).
- It ties the two histories together as equals. If the other
project chooses to also use subtree merge from you, the two
histories will be tied very closely, which often is not
desirable from the point of view of the "contained" project
(con).
- It does not allow "narrow checkout" and "narrow clone" as
submodule does (con).
^ permalink raw reply
* Re: git svn fetch segfaults
From: Björn Steinbrink @ 2008-01-09 22:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dennis Schridde, Miklos Vajna, git
In-Reply-To: <20080109205354.GA1433@atjola.homenet>
On 2008.01.09 21:53:54 +0100, Björn Steinbrink wrote:
> On 2008.01.09 12:14:19 -0800, Junio C Hamano wrote:
> > Dennis Schridde <devurandom@gmx.net> writes:
> >
> > > Am Mittwoch, 9. Januar 2008 01:33:07 schrieb Miklos Vajna:
> > >> On Tue, Jan 08, 2008 at 11:25:45PM +0100, Dennis Schridde
> > > <devurandom@gmx.net> wrote:
> > >> > mkdir org.gna.warzone2100.git
> > >> > cd org.gna.warzone2100.git
> > >> > git --bare init
> > >> > git --bare svn init --use-svnsync-props --stdlayout
> > >> > file:///var/svn/warzone2100/
> > >> > git --bare svn fetch
> > >>
> > >> wget http://svn.kynes.de/warzone2100.bz2
> > >>
> > >> svnadmin create warzone2100 && bzcat warzone2100.bz2 | svnadmin load
> > >> warzone2100
> > >>
> > >> the rest is the same i get a segfault at the very same place.
> > >>
> > >> > If I do not specify --use-svnsync-prop to "git svn init", it gets past
> > >> > r13 in tags/1.10a.
> > >>
> > >> same.
> > >>
> > >> > I am using these versions:
> > >> > svn, version 1.4.6 (r28521)
> > >> > git version 1.5.4.rc2
> > >>
> > >> $ svn --version
> > >> svn, version 1.4.5 (r25188)
> > >>
> > >> $ git --version
> > >> git version 1.5.4.rc2.38.gd6da3
> > > Same with git version 1.5.3.7
> >
> > Has anybody determined which executable is the segfaulting one?
>
> I just tried to, but it's still running, at r600 now.
It finished by now, no segfault with --use-svnsync-props.
Björn
^ permalink raw reply
* Decompression speed: zip vs lzo
From: Marco Costalba @ 2008-01-09 22:01 UTC (permalink / raw)
To: Git Mailing List
I have created a big tar from linux tree:
linux-2.6.tar 300,0 MB
Then I have created to compressed files with zip and lzop utility (the
latter uses the lzo compression algorithm):
linux-2.6.zip 70,1 MB
linux-2.6.tar.lzo 108,0 MB
Then I have tested the decompression speed:
$ time unzip -p linux-2.6.zip > /dev/null
3.95user 0.09system 0:04.05elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+189minor)pagefaults 0swaps
$ time lzop -d -c linux-2.6.tar.lzo > /dev/null
2.10user 0.07system 0:02.18elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+234minor)pagefaults 0swaps
So bottom line is that lzo decompression speed is almost the double of zip.
Marco
P.S: Compression size is better for zip but a more realistic test
would be to try with a delta packaged repo instead of a simple tar of
source files. Because delta packaged is already compressed in his way
perhaps difference in final file sizes is smaller.
^ permalink raw reply
* Re: [RFC] refer to post-patch lines in whitespace warnings
From: Daniel Barkalow @ 2008-01-09 21:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7ayhhpj.fsf@gitster.siamese.dyndns.org>
On Wed, 9 Jan 2008, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > When I rebase series with bad whitespace, I end up with unhelpful messages
> > like:
> >
> > .dotest/patch:412: trailing whitespace.
> > --
> > .dotest/patch:446: trailing whitespace.
> > --
> >
> > These line numbers obviously refer to lines in a file that's been removed
> > by the time I can do anything about it.
>
> The message is more appropriate for a workflow to "git apply --check"
> first, fix the patchfile and then applying for real.
Right; I'd keep it the same for all cases in which the patch is not
applied: "git apply --check" (which doesn't apply it regardless) or when
whitespace errors prevent application; so the message would be, in either
case, appropriate to the workflow.
In fact, in your workflow, it wouldn't make any sense to give the
resulting location of the whitespace, because that version of the file
hasn't been created. I think that only one of the possible location
reports is actually helpful: if it wasn't applied, the line in the patch
file; if it was, the line in the working tree.
> > ... if, in the case where it leaves the working tree
> > modified with the non-compliant whitespace, it gave this location rather
> > than the patch's location (because, even if you have the patch still,
> > you'd need to revert it first in order to be able to apply a fixed version
> > anyway).
>
> In such a case, "git diff" will highlight the non-compliant whitespace.
>
> More problematic is if you used whitespace=warn to let it commit anyway.
> You can use "git diff $beginning_of_series..HEAD" the same way
> to locate the breakages, but you then need to do "rebase -i" to
> fix it up (I personally would run "format-patch", fix the problems in
> the patch text, and run "am", instead of "rebase -i", mostly
> because I am used to working that way).
I should point out that, in this particular series, the non-compliant
whitespace is in the "expected result" file for tests for email message
generation, and it actually has to be like that. The annoying thing is
that it's not clear what file has the trailing whitespace, so it's not
clear that it is supposed to be that way from the message.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] gitk: Update German translation.
From: Christian Stimming @ 2008-01-09 21:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 19085 bytes --]
Now 100% complete (163 strings).
Signed-off-by: Christian Stimming <stimming@tuhh.de>
---
Additionally attached in gzip'd form to avoid encoding
or whitespace problems.
po/de.po | 418 +++++++++++++++++++++++++++++++++-----------------------------
1 files changed, 220 insertions(+), 198 deletions(-)
diff --git a/po/de.po b/po/de.po
index d7881dd..5ee2fca 100644
--- a/po/de.po
+++ b/po/de.po
@@ -7,8 +7,8 @@ msgid ""
msgstr ""
"Project-Id-Version: git-gui\n"
"Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2007-12-21 12:04+0100\n"
-"PO-Revision-Date: 2008-01-08 21:48+0100\n"
+"POT-Creation-Date: 2008-01-09 22:20+0100\n"
+"PO-Revision-Date: 2008-01-09 22:21+0100\n"
"Last-Translator: Christian Stimming <stimming@tuhh.de>\n"
"Language-Team: German\n"
"MIME-Version: 1.0\n"
@@ -17,13 +17,13 @@ msgstr ""
#: gitk:101
msgid "Error executing git rev-list:"
-msgstr ""
+msgstr "Fehler beim Ausführen von git-rev-list:"
#: gitk:114
msgid "Reading"
msgstr "Lesen"
-#: gitk:141 gitk:2151
+#: gitk:141 gitk:2143
msgid "Reading commits..."
msgstr "Versionen lesen..."
@@ -31,197 +31,197 @@ msgstr "Versionen lesen..."
msgid "Can't parse git log output:"
msgstr "Git log Ausgabe kann nicht erkannt werden:"
-#: gitk:375 gitk:2155
+#: gitk:375 gitk:2147
msgid "No commits selected"
msgstr "Keine Versionen ausgewählt."
#: gitk:486
msgid "No commit information available"
-msgstr ""
+msgstr "Keine Versionsinformation verfügbar"
-#: gitk:585 gitk:607 gitk:1914 gitk:6374 gitk:7875 gitk:8035
+#: gitk:585 gitk:607 gitk:1908 gitk:6366 gitk:7866 gitk:8020
msgid "OK"
msgstr "Ok"
-#: gitk:609 gitk:1916 gitk:6054 gitk:6125 gitk:6226 gitk:6272 gitk:6376
-#: gitk:7877 gitk:8037
+#: gitk:609 gitk:1909 gitk:6046 gitk:6117 gitk:6218 gitk:6264 gitk:6368
+#: gitk:7867 gitk:8021
msgid "Cancel"
msgstr "Abbrechen"
-#: gitk:633
+#: gitk:646
msgid "File"
msgstr "Datei"
-#: gitk:636
+#: gitk:648
msgid "Update"
msgstr "Aktualisieren"
-#: gitk:637
+#: gitk:649
msgid "Reread references"
msgstr "Zweige neu laden"
-#: gitk:638
+#: gitk:650
msgid "List references"
msgstr "Zweige auflisten"
-#: gitk:639
+#: gitk:651
msgid "Quit"
msgstr "Beenden"
-#: gitk:642
+#: gitk:653
msgid "Edit"
msgstr "Bearbeiten"
-#: gitk:643
+#: gitk:654
msgid "Preferences"
msgstr "Einstellungen"
-#: gitk:647
+#: gitk:657
msgid "View"
msgstr "Ansicht"
-#: gitk:648
+#: gitk:658
msgid "New view..."
msgstr "Neue Ansicht..."
-#: gitk:649 gitk:2093 gitk:8666
+#: gitk:659 gitk:2085 gitk:8651
msgid "Edit view..."
msgstr "Ansicht bearbeiten..."
-#: gitk:651 gitk:2094 gitk:8667
+#: gitk:661 gitk:2086 gitk:8652
msgid "Delete view"
msgstr "Ansicht löschen"
-#: gitk:653
+#: gitk:663
msgid "All files"
msgstr "Alle Dateien"
-#: gitk:657
+#: gitk:667
msgid "Help"
msgstr "Hilfe"
-#: gitk:658 gitk:1280
+#: gitk:668 gitk:1280
msgid "About gitk"
msgstr "Über gitk"
-#: gitk:659
+#: gitk:669
msgid "Key bindings"
msgstr "Tastenkürzel"
-#: gitk:716
+#: gitk:726
msgid "SHA1 ID: "
-msgstr ""
+msgstr "SHA1:"
-#: gitk:766
+#: gitk:776
msgid "Find"
msgstr "Suche"
-#: gitk:767
+#: gitk:777
msgid "next"
msgstr "nächste"
-#: gitk:768
+#: gitk:778
msgid "prev"
msgstr "vorige"
-#: gitk:769
+#: gitk:779
msgid "commit"
msgstr "Version"
-#: gitk:772 gitk:774 gitk:2316 gitk:2339 gitk:2363 gitk:4265 gitk:4328
+#: gitk:782 gitk:784 gitk:2308 gitk:2331 gitk:2355 gitk:4257 gitk:4320
msgid "containing:"
msgstr "enthaltend:"
-#: gitk:775 gitk:1746 gitk:1751 gitk:2391
+#: gitk:785 gitk:1741 gitk:1746 gitk:2383
msgid "touching paths:"
msgstr "Pfad betreffend:"
-#: gitk:776 gitk:2396
+#: gitk:786 gitk:2388
msgid "adding/removing string:"
msgstr "String dazu/löschen:"
-#: gitk:787 gitk:789
+#: gitk:795 gitk:797
msgid "Exact"
msgstr "Exakt"
-#: gitk:789 gitk:2474 gitk:4233
+#: gitk:797 gitk:2466 gitk:4225
msgid "IgnCase"
msgstr "Kein Groß/Klein"
-#: gitk:789 gitk:2365 gitk:2472 gitk:4229
+#: gitk:797 gitk:2357 gitk:2464 gitk:4221
msgid "Regexp"
msgstr "Regexp"
-#: gitk:793 gitk:794 gitk:2493 gitk:2523 gitk:2530 gitk:4339 gitk:4395
+#: gitk:799 gitk:800 gitk:2485 gitk:2515 gitk:2522 gitk:4331 gitk:4387
msgid "All fields"
msgstr "Alle Felder"
-#: gitk:794 gitk:2491 gitk:2523 gitk:4295
+#: gitk:800 gitk:2483 gitk:2515 gitk:4287
msgid "Headline"
msgstr "Überschrift"
-#: gitk:795 gitk:2491 gitk:4295 gitk:4395 gitk:4783
+#: gitk:801 gitk:2483 gitk:4287 gitk:4387 gitk:4775
msgid "Comments"
msgstr "Beschreibung"
-#: gitk:795 gitk:2491 gitk:2495 gitk:2530 gitk:4295 gitk:4719 gitk:5903
-#: gitk:5918
+#: gitk:801 gitk:2483 gitk:2487 gitk:2522 gitk:4287 gitk:4711 gitk:5895
+#: gitk:5910
msgid "Author"
msgstr "Autor"
-#: gitk:795 gitk:2491 gitk:4295 gitk:4721
+#: gitk:801 gitk:2483 gitk:4287 gitk:4713
msgid "Committer"
msgstr "Eintragender"
-#: gitk:825
+#: gitk:829
msgid "Search"
msgstr "Suche"
-#: gitk:833
+#: gitk:836
msgid "Diff"
msgstr "Vergleich"
-#: gitk:835
+#: gitk:838
msgid "Old version"
msgstr "Alte Version"
-#: gitk:837
+#: gitk:840
msgid "New version"
msgstr "Neue Version"
-#: gitk:839
+#: gitk:842
msgid "Lines of context"
msgstr "Kontextzeilen"
-#: gitk:898
+#: gitk:900
msgid "Patch"
-msgstr ""
+msgstr "Patch"
-#: gitk:901
+#: gitk:902
msgid "Tree"
msgstr "Baum"
-#: gitk:1018 gitk:1033 gitk:5969
+#: gitk:1018 gitk:1033 gitk:5961
msgid "Diff this -> selected"
msgstr "Vergleich diese -> gewählte"
-#: gitk:1020 gitk:1035 gitk:5970
+#: gitk:1020 gitk:1035 gitk:5962
msgid "Diff selected -> this"
msgstr "Vergleich gewählte -> diese"
-#: gitk:1022 gitk:1037 gitk:5971
+#: gitk:1022 gitk:1037 gitk:5963
msgid "Make patch"
msgstr "Patch erstellen"
-#: gitk:1023 gitk:6109
+#: gitk:1023 gitk:6101
msgid "Create tag"
msgstr "Markierung erstellen"
-#: gitk:1024 gitk:6206
+#: gitk:1024 gitk:6198
msgid "Write commit to file"
msgstr "Version in Datei schreiben"
-#: gitk:1025 gitk:6260
+#: gitk:1025 gitk:6252
msgid "Create new branch"
msgstr "Neuen Zweig erstellen"
@@ -243,11 +243,11 @@ msgstr "Zweig löschen"
#: gitk:1052
msgid "Highlight this too"
-msgstr ""
+msgstr "Diesen auch hervorheben"
#: gitk:1054
msgid "Highlight this only"
-msgstr ""
+msgstr "Nur diesen hervorheben"
#: gitk:1281
msgid ""
@@ -258,261 +258,271 @@ msgid ""
"\n"
"Use and redistribute under the terms of the GNU General Public License"
msgstr ""
+"\n"
+"Gitk - eine Visualisierung der Git Historie\n"
+"\n"
+"Copyright © 2005-2006 Paul Mackerras\n"
+"\n"
+"Benutzung und Weiterverbreitung gemäß den Bedingungen der GNU General Public "
+"License\n"
+" "
-#: gitk:1290 gitk:1354 gitk:6532
+#: gitk:1289 gitk:1350 gitk:6524
msgid "Close"
msgstr "Schließen"
-#: gitk:1311
+#: gitk:1308
msgid "Gitk key bindings"
-msgstr ""
+msgstr "Gitk Tastaturbelegung"
-#: gitk:1863
+#: gitk:1858
msgid "Gitk view definition"
-msgstr ""
+msgstr "Gitk Ansichten"
-#: gitk:1888
+#: gitk:1882
msgid "Name"
msgstr "Name"
-#: gitk:1891
+#: gitk:1885
msgid "Remember this view"
msgstr "Diese Ansicht speichern"
-#: gitk:1895
+#: gitk:1889
msgid "Commits to include (arguments to git rev-list):"
-msgstr ""
+msgstr "Versionen anzeigen (Argumente von git-rev-list):"
-#: gitk:1901
+#: gitk:1895
msgid "Enter files and directories to include, one per line:"
-msgstr ""
+msgstr "Folgende Dateien und Verzeichnisse anzeigen (eine pro Zeile):"
-#: gitk:1950
+#: gitk:1942
msgid "Error in commit selection arguments:"
-msgstr ""
+msgstr "Fehler in den ausgewählten Versionen:"
-#: gitk:2001 gitk:2087 gitk:2543 gitk:2557 gitk:3740 gitk:8635 gitk:8636
+#: gitk:1993 gitk:2079 gitk:2535 gitk:2549 gitk:3732 gitk:8620 gitk:8621
msgid "None"
msgstr "Keine"
-#: gitk:2491 gitk:4295 gitk:5905 gitk:5920
+#: gitk:2483 gitk:4287 gitk:5897 gitk:5912
msgid "Date"
msgstr "Datum"
-#: gitk:2491 gitk:4295
+#: gitk:2483 gitk:4287
msgid "CDate"
msgstr "Eintragedatum"
-#: gitk:2640 gitk:2645
-msgid "Descendent"
-msgstr ""
+#: gitk:2632 gitk:2637
+msgid "Descendant"
+msgstr "Abkömmling"
-#: gitk:2641
-msgid "Not descendent"
-msgstr ""
+#: gitk:2633
+msgid "Not descendant"
+msgstr "Nicht Abkömmling"
-#: gitk:2648 gitk:2653
+#: gitk:2640 gitk:2645
msgid "Ancestor"
-msgstr ""
+msgstr "Vorgänger"
-#: gitk:2649
+#: gitk:2641
msgid "Not ancestor"
-msgstr ""
+msgstr "Nicht Vorgänger"
-#: gitk:2883
+#: gitk:2875
msgid "Local changes checked in to index but not committed"
msgstr "Lokale Änderungen bereitgestellt, aber nicht eingetragen"
-#: gitk:2913
+#: gitk:2905
msgid "Local uncommitted changes, not checked in to index"
msgstr "Lokale Änderungen, nicht bereitgestellt"
-#: gitk:4264
+#: gitk:4256
msgid "Searching"
msgstr "Suchen"
-#: gitk:4723
+#: gitk:4715
msgid "Tags:"
msgstr "Markierungen:"
-#: gitk:4740 gitk:4746 gitk:5898
+#: gitk:4732 gitk:4738 gitk:5890
msgid "Parent"
msgstr "Eltern"
-#: gitk:4751
+#: gitk:4743
msgid "Child"
msgstr "Kind"
-#: gitk:4760
+#: gitk:4752
msgid "Branch"
msgstr "Zweig"
-#: gitk:4763
+#: gitk:4755
msgid "Follows"
-msgstr ""
+msgstr "Folgt auf"
-#: gitk:4766
+#: gitk:4758
msgid "Precedes"
-msgstr ""
+msgstr "Vorgänger von"
-#: gitk:5048
+#: gitk:5040
msgid "Error getting merge diffs:"
msgstr "Fehler beim Laden des Vergleichs:"
-#: gitk:5725
+#: gitk:5717
msgid "Goto:"
-msgstr ""
+msgstr "Gehe zu:"
-#: gitk:5727
+#: gitk:5719
msgid "SHA1 ID:"
-msgstr ""
+msgstr "SHA1 Kennung:"
-#: gitk:5752
+#: gitk:5744
#, tcl-format
msgid "Short SHA1 id %s is ambiguous"
-msgstr ""
+msgstr "Kurze SHA1-Kennung »%s« ist mehrdeutig"
-#: gitk:5764
+#: gitk:5756
#, tcl-format
msgid "SHA1 id %s is not known"
-msgstr ""
+msgstr "SHA1-Kennung »%s« unbekannt"
-#: gitk:5766
+#: gitk:5758
#, tcl-format
msgid "Tag/Head %s is not known"
-msgstr ""
+msgstr "Markierung/Zweig »%s« ist unbekannt"
-#: gitk:5908
+#: gitk:5900
msgid "Children"
msgstr "Kinder"
-#: gitk:5965
+#: gitk:5957
#, tcl-format
msgid "Reset %s branch to here"
msgstr "Zweig »%s« hierher zurücksetzen"
-#: gitk:5996
+#: gitk:5988
msgid "Top"
msgstr "Oben"
-#: gitk:5997
+#: gitk:5989
msgid "From"
msgstr "Von"
-#: gitk:6002
+#: gitk:5994
msgid "To"
msgstr "bis"
-#: gitk:6025
+#: gitk:6017
msgid "Generate patch"
msgstr "Patch erstellen"
-#: gitk:6027
+#: gitk:6019
msgid "From:"
msgstr "Von:"
-#: gitk:6036
+#: gitk:6028
msgid "To:"
msgstr "bis:"
-#: gitk:6045
+#: gitk:6037
msgid "Reverse"
msgstr "Umgekehrt"
-#: gitk:6047 gitk:6220
+#: gitk:6039 gitk:6212
msgid "Output file:"
-msgstr ""
+msgstr "Ausgabedatei:"
-#: gitk:6053
+#: gitk:6045
msgid "Generate"
msgstr "Erzeugen"
-#: gitk:6089
+#: gitk:6081
msgid "Error creating patch:"
-msgstr ""
+msgstr "Fehler beim Patch erzeugen:"
-#: gitk:6111 gitk:6208 gitk:6262
+#: gitk:6103 gitk:6200 gitk:6254
msgid "ID:"
-msgstr ""
+msgstr "ID:"
-#: gitk:6120
+#: gitk:6112
msgid "Tag name:"
msgstr "Markierungsname:"
-#: gitk:6124 gitk:6271
+#: gitk:6116 gitk:6263
msgid "Create"
msgstr "Erstellen"
-#: gitk:6139
+#: gitk:6131
msgid "No tag name specified"
-msgstr ""
+msgstr "Kein Markierungsname angegeben"
-#: gitk:6143
+#: gitk:6135
#, tcl-format
msgid "Tag \"%s\" already exists"
msgstr "Markierung »%s« existiert bereits."
-#: gitk:6153
+#: gitk:6145
msgid "Error creating tag:"
-msgstr ""
+msgstr "Fehler bei Markierung erstellen:"
-#: gitk:6217
+#: gitk:6209
msgid "Command:"
-msgstr ""
+msgstr "Kommando:"
-#: gitk:6225
+#: gitk:6217
msgid "Write"
msgstr "Schreiben"
-#: gitk:6241
+#: gitk:6233
msgid "Error writing commit:"
-msgstr ""
+msgstr "Fehler beim Version eintragen:"
-#: gitk:6267
+#: gitk:6259
msgid "Name:"
msgstr "Name:"
-#: gitk:6286
+#: gitk:6278
msgid "Please specify a name for the new branch"
-msgstr ""
+msgstr "Bitte geben Sie einen Namen für den neuen Zweig an."
-#: gitk:6315
+#: gitk:6307
#, tcl-format
msgid "Commit %s is already included in branch %s -- really re-apply it?"
msgstr ""
+"Version »%s« ist bereits im Zweig »%s« enthalten -- trotzdem erneut "
+"eintragen?"
-#: gitk:6320
+#: gitk:6312
msgid "Cherry-picking"
msgstr "Version pflücken"
-#: gitk:6332
+#: gitk:6324
msgid "No changes committed"
msgstr "Keine Änderungen eingetragen"
-#: gitk:6355
+#: gitk:6347
msgid "Confirm reset"
msgstr "Zurücksetzen bestätigen"
-#: gitk:6357
+#: gitk:6349
#, tcl-format
msgid "Reset branch %s to %s?"
msgstr "Zweig »%s« auf »%s« zurücksetzen?"
-#: gitk:6361
+#: gitk:6353
msgid "Reset type:"
msgstr "Art des Zurücksetzens:"
-#: gitk:6365
+#: gitk:6357
msgid "Soft: Leave working tree and index untouched"
msgstr "Harmlos: Arbeitskopie und Bereitstellung unverändert"
-#: gitk:6368
+#: gitk:6360
msgid "Mixed: Leave working tree untouched, reset index"
msgstr ""
"Gemischt: Arbeitskopie unverändert,\n"
"Bereitstellung zurückgesetzt"
-#: gitk:6371
+#: gitk:6363
msgid ""
"Hard: Reset working tree and index\n"
"(discard ALL local changes)"
@@ -520,184 +530,196 @@ msgstr ""
"Hart: Arbeitskopie und Bereitstellung\n"
"(Alle lokalen Änderungen werden gelöscht)"
-#: gitk:6387
+#: gitk:6379
msgid "Resetting"
msgstr "Zurücksetzen"
-#: gitk:6444
+#: gitk:6436
msgid "Checking out"
msgstr "Umstellen"
-#: gitk:6474
+#: gitk:6466
msgid "Cannot delete the currently checked-out branch"
-msgstr "Der Zweig, auf den die Arbeitskopie momentan umgestellt ist, kann nicht gelöscht werden."
+msgstr ""
+"Der Zweig, auf den die Arbeitskopie momentan umgestellt ist, kann nicht "
+"gelöscht werden."
-#: gitk:6480
+#: gitk:6472
#, tcl-format
msgid ""
"The commits on branch %s aren't on any other branch.\n"
"Really delete branch %s?"
msgstr ""
+"Die Versionen auf Zweig »%s« existieren auf keinem anderen Zweig.\n"
+"Zweig »%s« trotzdem löschen?"
-#: gitk:6511
+#: gitk:6503
#, tcl-format
msgid "Tags and heads: %s"
-msgstr ""
+msgstr "Markierungen und Zweige: %s"
-#: gitk:6525
+#: gitk:6517
msgid "Filter"
-msgstr ""
+msgstr "Filtern"
-#: gitk:6820
+#: gitk:6811
msgid ""
"Error reading commit topology information; branch and preceding/following "
"tag information will be incomplete."
msgstr ""
+"Fehler beim Lesen der Strukturinformationen; Zweige und Vorgänger/Nachfolger "
+"Informationen werden unvollständig sein."
-#: gitk:7804
+#: gitk:7795
msgid "Tag"
msgstr "Markierung"
-#: gitk:7804
+#: gitk:7795
msgid "Id"
-msgstr ""
+msgstr "Id"
-#: gitk:7844
+#: gitk:7835
msgid "Gitk font chooser"
-msgstr ""
+msgstr "Gitk Schriften wählen"
-#: gitk:7861
+#: gitk:7852
msgid "B"
msgstr "F"
-#: gitk:7864
+#: gitk:7855
msgid "I"
msgstr "K"
-#: gitk:7959
+#: gitk:7948
msgid "Gitk preferences"
msgstr "Gitk Einstellungen"
-#: gitk:7960
+#: gitk:7949
msgid "Commit list display options"
msgstr "Anzeige Versionsliste"
-#: gitk:7964
+#: gitk:7952
msgid "Maximum graph width (lines)"
msgstr "Maximale Graphenbreite (Zeilen)"
-#: gitk:7968
+#: gitk:7956
#, tcl-format
msgid "Maximum graph width (% of pane)"
msgstr "Maximale Graphenbreite (% des Fensters)"
-#: gitk:7973
+#: gitk:7961
msgid "Show local changes"
msgstr "Lokale Änderungen anzeigen"
-#: gitk:7978
+#: gitk:7966
msgid "Diff display options"
msgstr "Anzeige Vergleich"
-#: gitk:7981
+#: gitk:7968
msgid "Tab spacing"
msgstr "Tabulatorbreite"
-#: gitk:7985
+#: gitk:7972
msgid "Display nearby tags"
-msgstr ""
+msgstr "Naheliegende Überschriften anzeigen"
-#: gitk:7990
+#: gitk:7977
msgid "Limit diffs to listed paths"
msgstr "Vergleich nur für angezeigte Pfade"
-#: gitk:7995
+#: gitk:7982
msgid "Colors: press to choose"
msgstr "Farben: Klicken zum Wählen"
-#: gitk:7999
+#: gitk:7985
msgid "Background"
msgstr "Vordergrund"
-#: gitk:8003
+#: gitk:7989
msgid "Foreground"
msgstr "Hintergrund"
-#: gitk:8007
+#: gitk:7993
msgid "Diff: old lines"
msgstr "Vergleich: Alte Zeilen"
-#: gitk:8012
+#: gitk:7998
msgid "Diff: new lines"
msgstr "Vergleich: Neue Zeilen"
-#: gitk:8017
+#: gitk:8003
msgid "Diff: hunk header"
msgstr "Vergleich: Änderungstitel"
-#: gitk:8023
+#: gitk:8009
msgid "Select bg"
msgstr "Hintergrundfarbe Auswählen"
-#: gitk:8027
+#: gitk:8013
msgid "Fonts: press to choose"
msgstr "Schriftart: Klicken zum Wählen"
-#: gitk:8030
+#: gitk:8015
msgid "Main font"
msgstr "Programmschriftart"
-#: gitk:8031
+#: gitk:8016
msgid "Diff display font"
msgstr "Vergleich"
-#: gitk:8032
+#: gitk:8017
msgid "User interface font"
msgstr "Beschriftungen"
-#: gitk:8050
+#: gitk:8033
#, tcl-format
msgid "Gitk: choose color for %s"
msgstr "Gitk: Farbe wählen für %s"
-#: gitk:8431
+#: gitk:8414
msgid ""
"Sorry, gitk cannot run with this version of Tcl/Tk.\n"
" Gitk requires at least Tcl/Tk 8.4."
msgstr ""
+"Gitk läuft nicht mit dieser Version von Tcl/Tk.\n"
+"Gitk benötigt mindestens Tcl/Tk 8.4."
-#: gitk:8516
+#: gitk:8501
msgid "Cannot find a git repository here."
msgstr "Kein Git-Projektarchiv gefunden."
-#: gitk:8520
+#: gitk:8505
#, tcl-format
msgid "Cannot find the git directory \"%s\"."
-msgstr ""
+msgstr "Git-Verzeichnis »%s« wurde nicht gefunden."
-#: gitk:8559
+#: gitk:8544
#, tcl-format
msgid "Ambiguous argument '%s': both revision and filename"
-msgstr ""
+msgstr "Mehrdeutige Angabe »%s«: Sowohl Version als auch Dateiname existiert."
-#: gitk:8571
+#: gitk:8556
msgid "Bad arguments to gitk:"
-msgstr ""
+msgstr "Falsche Kommandozeilen-Parameter für gitk:"
-#: gitk:8583
+#: gitk:8568
msgid "Couldn't get list of unmerged files:"
-msgstr ""
+msgstr "Liste der nicht-zusammengeführten Dateien nicht gefunden:"
-#: gitk:8599
+#: gitk:8584
msgid "No files selected: --merge specified but no files are unmerged."
msgstr ""
+"Keine Dateien ausgewähle: --merge angegeben, es existieren aber keine nicht-"
+"zusammengeführten Dateien."
-#: gitk:8602
+#: gitk:8587
msgid ""
"No files selected: --merge specified but no unmerged files are within file "
"limit."
msgstr ""
+"Keine Dateien ausgewähle: --merge angegeben, aber keine nicht-"
+"zusammengeführten Dateien sind in der Dateiauswahl."
-#: gitk:8661
+#: gitk:8646
msgid "Command line"
msgstr "Kommandozeile"
--
1.5.3.4.206.g58ba4
[-- Attachment #2: 0002-gitk-Update-German-translation.patch.gz --]
[-- Type: application/x-gzip, Size: 5746 bytes --]
^ permalink raw reply related
* [PATCH] gitk: Fix typo in user message.
From: Christian Stimming @ 2008-01-09 21:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
Signed-off-by: Christian Stimming <stimming@tuhh.de>
---
gitk | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index 801a5a9..b3cb8e8 100755
--- a/gitk
+++ b/gitk
@@ -2629,12 +2629,12 @@ proc askrelhighlight {row id} {
if {![info exists selectedline]} return
set isbold 0
- if {$highlight_related eq [mc "Descendent"] ||
- $highlight_related eq [mc "Not descendent"]} {
+ if {$highlight_related eq [mc "Descendant"] ||
+ $highlight_related eq [mc "Not descendant"]} {
if {![info exists descendent($id)]} {
is_descendent $id
}
- if {$descendent($id) == ($highlight_related eq [mc "Descendent"])} {
+ if {$descendent($id) == ($highlight_related eq [mc "Descendant"])} {
set isbold 1
}
} elseif {$highlight_related eq [mc "Ancestor"] ||
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* Re: CRLF problems with Git on Win32
From: Steffen Prohaska @ 2008-01-09 21:03 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Linus Torvalds, J. Bruce Fields, Robin Rosenberg,
Jeff King, Peter Karlsson, Git Mailing List, msysGit
In-Reply-To: <alpine.LSU.1.00.0801092047190.31053-OGWIkrnhIhzN0uC3ymp8PA@public.gmane.org>
On Jan 9, 2008, at 9:50 PM, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 9 Jan 2008, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin-Mmb7MZpHnFY@public.gmane.org> writes:
>>
>>> Junio wrote:
>>>
>>>> Perhaps we can do something similar to core.filemode? Create a
>>>> file
>>>> that we would need to create anyway in "text" mode, and read it
>>>> back
>>>> in "binary" mode to see what stdio did?
>>>
>>> The problem is that MinGW behaves sanely, i.e. it does not output
>>> CRLF
>>> but only LF.
>>
>> Won't that behaviour be viewed rather as "insanely" from majority of
>> Windows users?
>
> I think the truth is that CRLF was a mistake. Nobody wants to take
> the
> blame for it, obviously, but more and more Windows tools just grok
> LF-only
> text.
>
> The question is: what to do with those that cannot grok LF-only
> text. I
> imagine that the best compromise for now would be to have
> crlf=true, with
> poor souls like Steffen having to set the gitattributes accordingly.
I could live with that but unfortunately this alone does not
solve all of the real-world problems happening during cross-
platform development. At least the problem of code copied from
Windows to Unix and committed there should be addressed, too.
Maybe the default on Unix should be crlf=input? I'm wondering
what Linux developer would say about this?
I am against changing the default of msysgit now. First I'd like
to wait how the "crlf=safe" discussion evolves.
Steffen
^ permalink raw reply
* Re: [PATCH] Trim leading / off of paths in git-svn prop_walk
From: Junio C Hamano @ 2008-01-09 20:54 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Kevin Ballard
In-Reply-To: <1199860640-74118-1-git-send-email-kevin@sb.org>
Kevin Ballard <kevin@sb.org> writes:
> prop_walk adds a leading / to all subdirectory paths. Unfortunately
> this causes a problem when the remote repo lives in a subdirectory itself,
> as the leading / causes subsequent PROPFIND calls to be executed on
> the wrong path. Trimming the / before calling the PROPFIND fixes this problem.
>
> Signed-off-by: Kevin Ballard <kevin@sb.org>
Eric, the change is very limited in scope (only the parameter to
ra->get_dir() changes) so I can apply myself, if you agree this
is a trivially correct fix. I just do not know svn-perl
interface well enough to judge.
> All tests passed after this change, but since it seems to only apply
> to WebDAV SVN repos I saw no way to add a new test.
> git-svn.perl | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 3308fe1..d5316eb 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -1858,6 +1858,7 @@ sub rel_path {
> sub prop_walk {
> my ($self, $path, $rev, $sub) = @_;
>
> + $path =~ s#^/##;
> my ($dirent, undef, $props) = $self->ra->get_dir($path, $rev);
> $path =~ s#^/*#/#g;
> my $p = $path;
> --
> 1.5.4.rc2.68.ge708a-dirty
^ permalink raw reply
* Re: git svn fetch segfaults
From: Björn Steinbrink @ 2008-01-09 20:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dennis Schridde, Miklos Vajna, git
In-Reply-To: <7v4pdmiwo4.fsf@gitster.siamese.dyndns.org>
On 2008.01.09 12:14:19 -0800, Junio C Hamano wrote:
> Dennis Schridde <devurandom@gmx.net> writes:
>
> > Am Mittwoch, 9. Januar 2008 01:33:07 schrieb Miklos Vajna:
> >> On Tue, Jan 08, 2008 at 11:25:45PM +0100, Dennis Schridde
> > <devurandom@gmx.net> wrote:
> >> > mkdir org.gna.warzone2100.git
> >> > cd org.gna.warzone2100.git
> >> > git --bare init
> >> > git --bare svn init --use-svnsync-props --stdlayout
> >> > file:///var/svn/warzone2100/
> >> > git --bare svn fetch
> >>
> >> wget http://svn.kynes.de/warzone2100.bz2
> >>
> >> svnadmin create warzone2100 && bzcat warzone2100.bz2 | svnadmin load
> >> warzone2100
> >>
> >> the rest is the same i get a segfault at the very same place.
> >>
> >> > If I do not specify --use-svnsync-prop to "git svn init", it gets past
> >> > r13 in tags/1.10a.
> >>
> >> same.
> >>
> >> > I am using these versions:
> >> > svn, version 1.4.6 (r28521)
> >> > git version 1.5.4.rc2
> >>
> >> $ svn --version
> >> svn, version 1.4.5 (r25188)
> >>
> >> $ git --version
> >> git version 1.5.4.rc2.38.gd6da3
> > Same with git version 1.5.3.7
>
> Has anybody determined which executable is the segfaulting one?
I just tried to, but it's still running, at r600 now.
> If it is svn executable spawned by Perl that runs git-svn, or
> libsvn shared object linked to Perl while running git-svn, I
> suspect testing with different git versions will not be very
> productive.
Oh well, anyway, just for the record:
doener@atjola:~ $ svn --version
svn, version 1.4.4 (r25188)
doener@atjola:~ $ git --version
git version 1.5.4.rc1.11.gd2f82
Björn
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Johannes Schindelin @ 2008-01-09 20:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, J. Bruce Fields, Steffen Prohaska,
Robin Rosenberg, Jeff King, Peter Karlsson, Git Mailing List,
msysGit
In-Reply-To: <7vmyrehhkd.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org>
Hi,
On Wed, 9 Jan 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin-Mmb7MZpHnFY@public.gmane.org> writes:
>
> > Junio wrote:
> >
> >> Perhaps we can do something similar to core.filemode? Create a file
> >> that we would need to create anyway in "text" mode, and read it back
> >> in "binary" mode to see what stdio did?
> >
> > The problem is that MinGW behaves sanely, i.e. it does not output CRLF
> > but only LF.
>
> Won't that behaviour be viewed rather as "insanely" from majority of
> Windows users?
I think the truth is that CRLF was a mistake. Nobody wants to take the
blame for it, obviously, but more and more Windows tools just grok LF-only
text.
The question is: what to do with those that cannot grok LF-only text. I
imagine that the best compromise for now would be to have crlf=true, with
poor souls like Steffen having to set the gitattributes accordingly.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] refer to post-patch lines in whitespace warnings
From: Junio C Hamano @ 2008-01-09 20:42 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0801091046100.13593@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> When I rebase series with bad whitespace, I end up with unhelpful messages
> like:
>
> .dotest/patch:412: trailing whitespace.
> --
> .dotest/patch:446: trailing whitespace.
> --
>
> These line numbers obviously refer to lines in a file that's been removed
> by the time I can do anything about it. It seems to me like the message
> would be more useful if, in the case where it leaves the working tree
> modified with the non-compliant whitespace, it gave this location rather
> than the patch's location (because, even if you have the patch still,
> you'd need to revert it first in order to be able to apply a fixed version
> anyway). Anybody see any problems with this theory?
I realize that I did not answer your primary question in the
previous response.
I think it is fine if you are thinking about _adding_ line
number of postimage (or preimage for that matter) to the warning
output, but I do not think we would want to remove the in-patch
line numbers we currently have and replace them with something
else. I often very much appreciate the fact that these messages
precisely identify the problematic spots in the patch so that I
can go in and fix them in place before applying.
^ permalink raw reply
* Re: [PATCH] - Added recurse command to git submodule
From: Junio C Hamano @ 2008-01-09 20:26 UTC (permalink / raw)
To: Lars Hjemli; +Cc: imyousuf, git, Imran M Yousuf
In-Reply-To: <8c5c35580801090242g3f755814pa56e896d0a8723bb@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
> A possible extension is to specifiy "inter-submodule" paths to the
> init subcommand, i.e. for a possible KDE layout:
> git submodule -r init kdelibs kdelibs/admin
>
> This should then recursively initialize the kdelibs submodule and the
> admin-submodule (in the kdelibs submodule).
Beautiful.
> Btw: from my reading of the code, the git-command specified for
> 'recurse' will be done top-to-bottom: I guess that's what you want for
> something like 'git submodule recurse diff', but not for something
> like 'git submodule recurse commit' (but IMHO the latter one should
> never be executed ;-)
Thanks for raising a very good point. Yes, some commands
inherently wants depth first.
While I agree that making a recursive is a grave usage error
(submodule commit and toplevel commit are logically different
events and even their commit log message should be different, as
they talk about changes in logically different levels) from
project management point of view, I do not think it is something
a tool has to explicitly forbid the users to do. I view it as a
kind of a long rope, a misuse the users can be allowed to
inflict on themselves if they really wanted to.
Also, some commands cannot be made recursive by driving them
from a higher level recursive wrapper. "git submodule recursive
log" would not make much sense, not only because the order of
the log entries are output from different invocations would not
be useful, but because the revision range specifier would need
to be different in different submodules (e.g. library submodules
and application submodule will not share version name namespace,
i.e. "log v1.0..v2.0" is undefined, and worse yet, running "log
v1.0:path/to/sub..v2.0:path/to/sub" in a submodule when running
"log v1.0..v2.0" in the toplevel is not a correct solution
either in general).
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Junio C Hamano @ 2008-01-09 20:25 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, J. Bruce Fields, Steffen Prohaska,
Robin Rosenberg, Jeff King, Peter Karlsson, Git Mailing List,
msysGit
In-Reply-To: <alpine.LSU.1.00.0801091041570.31053@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> IMHO this is really not good. Better do it in the global /etc/gitconfig
> we install _anyway_ (it says core.symlinks=false).
That sounds like a perfect place for a per-platform tweak like
this than in the code, but I wonder if peoples' scripts have
valid use case of GIT_CONFIG to bypass it (git-svn's use of the
variable to access its private data seems to be Ok).
>> Perhaps we can do something similar to core.filemode? Create a file
>> that we would need to create anyway in "text" mode, and read it back in
>> "binary" mode to see what stdio did?
>
> The problem is that MinGW behaves sanely, i.e. it does not output CRLF but
> only LF.
Won't that behaviour be viewed rather as "insanely" from
majority of Windows users?
> But maybe I am the minority here, and we really should default to
> crlf=true on Windows, and provide a way to unset that.
>
> My preference would be to have Peff's -c switch to clone, but
> _additionally_ a way to force a full re-checkout of files (for example
> after "git config core.crlf false").
I have been hoping a better (simpler to use, and somewhat more
importantly harder to misuse by being not overly flexible) way
than that "clone -c" solution, but that is an implementation
issue (I think the tweak rather belongs to init than clone
anyway, and the point of "-c" is that it is not easy to tweak
the way "init" that is used by "clone" behaves).
Switching core.crlf (or gitattributes to change filter -- in
general, "affecting the way convert_to_working_tree() and
convert_to_git() works") can be done for two opposite reasons.
(1) repository is correct and checkout is wrong. This wants
re-checkout.
(2) repository records in a wrong convention by mistake and
needs to be fixed. Re-checkout is obviously a wrong thing
to do, and re-checkin (not necessarily commit, but updating
the index) is necessary.
We need both.
^ permalink raw reply
* Re: [PATCH] Change git-gc documentation to reflect gc.packrefs implementation.
From: Junio C Hamano @ 2008-01-09 20:25 UTC (permalink / raw)
To: Florian La Roche; +Cc: git
In-Reply-To: <20080109160516.GA31535@dudweiler.stuttgart.redhat.com>
Florian La Roche <laroche@redhat.com> writes:
> Adjust git-gc documentation to reflect gc.packrefs implementation.
>
> Adjust git-gc documentation to reflect gc.packrefs implementation.
>
> Signed-off-by: Florian La Roche <laroche@redhat.com>
Thanks.
I rephrased the above (three almost identical lines) to:
56752391a8c0c591853b276e4fa0b45c34ced181 (Make "git gc" pack all
refs by default) changed the default of gc.packrefs to true, to
pack all refs by default in any repository. IOW, the users need
to disable it explicitly if they want to by setting the config
variable, since 1.5.3.
However, we forgot to update the documentation. This fixes it.
and applied.
^ permalink raw reply
* Re: [RFC] refer to post-patch lines in whitespace warnings
From: Junio C Hamano @ 2008-01-09 20:22 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0801091046100.13593@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> When I rebase series with bad whitespace, I end up with unhelpful messages
> like:
>
> .dotest/patch:412: trailing whitespace.
> --
> .dotest/patch:446: trailing whitespace.
> --
>
> These line numbers obviously refer to lines in a file that's been removed
> by the time I can do anything about it.
The message is more appropriate for a workflow to "git apply --check"
first, fix the patchfile and then applying for real.
> ... if, in the case where it leaves the working tree
> modified with the non-compliant whitespace, it gave this location rather
> than the patch's location (because, even if you have the patch still,
> you'd need to revert it first in order to be able to apply a fixed version
> anyway).
In such a case, "git diff" will highlight the non-compliant whitespace.
More problematic is if you used whitespace=warn to let it commit anyway.
You can use "git diff $beginning_of_series..HEAD" the same way
to locate the breakages, but you then need to do "rebase -i" to
fix it up (I personally would run "format-patch", fix the problems in
the patch text, and run "am", instead of "rebase -i", mostly
because I am used to working that way).
^ permalink raw reply
* Re: git svn fetch segfaults
From: Junio C Hamano @ 2008-01-09 20:14 UTC (permalink / raw)
To: Dennis Schridde; +Cc: Miklos Vajna, git
In-Reply-To: <200801091353.44630.devurandom@gmx.net>
Dennis Schridde <devurandom@gmx.net> writes:
> Am Mittwoch, 9. Januar 2008 01:33:07 schrieb Miklos Vajna:
>> On Tue, Jan 08, 2008 at 11:25:45PM +0100, Dennis Schridde
> <devurandom@gmx.net> wrote:
>> > mkdir org.gna.warzone2100.git
>> > cd org.gna.warzone2100.git
>> > git --bare init
>> > git --bare svn init --use-svnsync-props --stdlayout
>> > file:///var/svn/warzone2100/
>> > git --bare svn fetch
>>
>> wget http://svn.kynes.de/warzone2100.bz2
>>
>> svnadmin create warzone2100 && bzcat warzone2100.bz2 | svnadmin load
>> warzone2100
>>
>> the rest is the same i get a segfault at the very same place.
>>
>> > If I do not specify --use-svnsync-prop to "git svn init", it gets past
>> > r13 in tags/1.10a.
>>
>> same.
>>
>> > I am using these versions:
>> > svn, version 1.4.6 (r28521)
>> > git version 1.5.4.rc2
>>
>> $ svn --version
>> svn, version 1.4.5 (r25188)
>>
>> $ git --version
>> git version 1.5.4.rc2.38.gd6da3
> Same with git version 1.5.3.7
Has anybody determined which executable is the segfaulting one?
If it is svn executable spawned by Perl that runs git-svn, or
libsvn shared object linked to Perl while running git-svn, I
suspect testing with different git versions will not be very
productive.
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Dmitry Potapov @ 2008-01-09 19:05 UTC (permalink / raw)
To: Gregory Jefferis
Cc: Steffen Prohaska, Johannes Schindelin, Peter Karlsson,
Git Mailing List, Robin Rosenberg, Jeff King, Linus Torvalds
In-Reply-To: <C3AAB6C3.10C6B%jefferis@gmail.com>
Hi Gregory,
On Wed, Jan 09, 2008 at 05:37:07PM +0000, Gregory Jefferis wrote:
>
> If LF text files checked in on Windows get turned into CRLF files on
> checkout by default then I think plenty of people would be surprised and
> probably unhappy.
LF text cannot be checked in with autocrlf=safe without marking that there
is no CRLF conversation for this file. So, what you describe is impossible.
IOW, you *always* get back what you put in the repository.
> Similarly I think it would be a bad thing if a binary
> file that looked like LF only text got mangled on checkout by LF->CRLF
> conversion - although I agree that it would be possible to recover from this
> situation with a bit of juggling.
Again, you can't do that with autocrlf=safe. Yes, it is possible that
someone else on Unix to put a file like this, but it is a rare event and
easy to recover. So, it is a very small price to pay for cross-platform
projects, and those who use the same platform are not affected at all!
> The only way to prevent collateral damage is to
> consult .gitattributes on checkout (as Dmitry seemed to be assuming above)
Yes, I assumed this. Isn't it how it is implemented now?
static int crlf_to_worktree(const char *path, const char *src, size_t len,
struct strbuf *buf, int action)
{
char *to_free = NULL;
struct text_stat stats;
if ((action == CRLF_BINARY) || (action == CRLF_INPUT) ||
auto_crlf <= 0)
return 0;
If crlf=false for some file then action will be CRLF_BINARY, and
crlf_to_worktree will not convert LF to CRLF. Did I miss somthing?
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] sideband.c: Use xmalloc() instead of variable-sized arrays.
From: Nicolas Pitre @ 2008-01-09 19:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <7vk5mjmo4f.fsf@gitster.siamese.dyndns.org>
On Tue, 8 Jan 2008, Junio C Hamano wrote:
> As an old fashoned git myself, and given the fact that the
> possible prefix and suffix are small number of short constant
> strings, I actually prefer a simpler-and-more-stupid approach.
OK. However I think the following on top of your patch would look
cleaner:
diff --git a/sideband.c b/sideband.c
index 91e462c..b677781 100644
--- a/sideband.c
+++ b/sideband.c
@@ -14,19 +14,24 @@
#define PREFIX "remote:"
+#define ANSI_SUFFIX "\033[K"
+#define DUMB_SUFFIX " "
+
+#define FIX_SIZE 10 /* large enough for any of the above */
+
int recv_sideband(const char *me, int in_stream, int out, int err)
{
unsigned pf = strlen(PREFIX);
unsigned sf;
- char buf[LARGE_PACKET_MAX + 100]; /* for marker slop */
+ char buf[LARGE_PACKET_MAX + 2*FIX_SIZE];
char *suffix, *term;
memcpy(buf, PREFIX, pf);
term = getenv("TERM");
if (term && strcmp(term, "dumb"))
- suffix = "\033[K";
+ suffix = ANSI_SUFFIX;
else
- suffix = " ";
+ suffix = DUMB_SUFFIX;
sf = strlen(suffix);
while (1) {
@@ -67,7 +72,7 @@ int recv_sideband(const char *me, int in_stream, int out, int err)
* line data actually contains something.
*/
if (brk > pf+1 + 1) {
- char save[100]; /* enough slop */
+ char save[FIX_SIZE];
memcpy(save, buf + brk, sf);
buf[brk + sf - 1] = buf[brk - 1];
memcpy(buf + brk - 1, suffix, sf);
^ permalink raw reply related
* Re: CRLF problems with Git on Win32
From: Jan Hudec @ 2008-01-09 18:46 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0801081150010.25629@ds9.cixit.se>
On Tue, Jan 08, 2008 at 11:56:00 +0100, Peter Karlsson wrote:
> Thomas Neumann:
>
> > as a user, I expect a SCM to only modify a file when I have
> > explicitly asked it to do so.
>
> As a user, I exepect things to just work. With RCS/CVS/Subversion, it
> does, because it differentiates between text files (internally encoding
> NLs with "LF", but I couldn't care less what it uses there) and binary
> files (which it doesn't change). With git it currently doesn't since it
> treats everything as binary files.
With subversion you must explicitely enable it to "just" work. Subversion
auto-tags files with specified extensions, when they are added, with
svn:eol property specifying how the file should be converted and than
converts (everywhere) the files to specified line endings. However, AFAIK, it
does not convert anything unless the properties are set and the default
config has the automatic setting *commented out*.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: [EGIT PATCH] Showing commit info like the CVS plugin instead of tooltips.
From: Robin Rosenberg @ 2008-01-09 18:12 UTC (permalink / raw)
To: Roger C. Soares; +Cc: git, Shawn O. Pearce
In-Reply-To: <4784209D.6080100@intelinet.com.br>
onsdagen den 9 januari 2008 skrev Roger C. Soares:
> Hi Robin,
>
> > Looks nice. We probably want this into preferences and I'd still like the
tooltop as an option. I.e. when you turn off
> > the other panes the tooltip should come back. What I'd really want is
the "Press F2"-version, like the javadoc
> > tooltips, but that requires some more work (I guess, maybe only a little
is needed).
> >
> Showing the tooltips when you press F2 makes more sense to me. What I'm
Actually not what I meant. Javadoc tooltips popup as a tooltip. When it is
active you can press F2 to see more information,
copy text etc.
> For the search bar, I would like to make it visible by pressing ctrl-f
> when the history panel has the focus.
You're free to experiment. I'm quite fond of the search field in kmail. It is
a textfield that filters mail on
header fields as I type.
> >> - protected boolean hintShowDiffNow;
> >> + /* private */boolean hintShowDiffNow;
> >>
> > Why? What's wrong plain private?
> >
> This is to improve performance and getting rid of the warning:
> Read access to enclosing field GitHistoryPage.appliedPatches is emulated
> by a synthetic accessor method. Increasing its visibility will improve
> your performance
Ah, should have noticed. That's ok.
I found a bug. When you travel down the histtory using arrow keys all of the
sudden the commit info disappears.
-- robin
^ permalink raw reply
* [PATCH - v2] gitk: fix "Key bindings" message
From: Michele Ballabio @ 2008-01-09 18:16 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
In-Reply-To: <18308.2284.160506.432481@cargo.ozlabs.ibm.com>
Fix string substitution using 'string map'. Now the
"Key bindings" menu is ready for translation.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
On Wednesday 09 January 2008, Paul Mackerras wrote:
> Michele Ballabio writes:
>
> > -"] \
> > +" $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T ] \
>
> Ick. Are you sure you have the right number of instances of $M1T? :)
Yes :^P. I was sure there was a better fix but didn't know where to look at.
> I'd prefer to use [string map].
This patch tries to do so. Is this correct?
> Actually, for translation, it would probably be better to bust up that
> help text into a series of shorter strings, maybe even one per line.
Or split this by "topic": "scrolling", "search", "fonts", "history"...
gitk | 34 +++++++++++++++++-----------------
1 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/gitk b/gitk
index 801a5a9..24796e1 100755
--- a/gitk
+++ b/gitk
@@ -1306,10 +1306,10 @@ proc keys {} {
}
toplevel $w
wm title $w [mc "Gitk key bindings"]
- message $w.m -text [mc "
+ message $w.m -text [ string map "M1T $M1T" [ mc "
Gitk key bindings:
-<$M1T-Q> Quit
+<M1T-Q> Quit
<Home> Move to first commit
<End> Move to last commit
<Up>, p, i Move up one commit
@@ -1318,12 +1318,12 @@ Gitk key bindings:
<Right>, x, l Go forward in history list
<PageUp> Move up one page in commit list
<PageDown> Move down one page in commit list
-<$M1T-Home> Scroll to top of commit list
-<$M1T-End> Scroll to bottom of commit list
-<$M1T-Up> Scroll commit list up one line
-<$M1T-Down> Scroll commit list down one line
-<$M1T-PageUp> Scroll commit list up one page
-<$M1T-PageDown> Scroll commit list down one page
+<M1T-Home> Scroll to top of commit list
+<M1T-End> Scroll to bottom of commit list
+<M1T-Up> Scroll commit list up one line
+<M1T-Down> Scroll commit list down one line
+<M1T-PageUp> Scroll commit list up one page
+<M1T-PageDown> Scroll commit list down one page
<Shift-Up> Find backwards (upwards, later commits)
<Shift-Down> Find forwards (downwards, earlier commits)
<Delete>, b Scroll diff view up one page
@@ -1331,20 +1331,20 @@ Gitk key bindings:
<Space> Scroll diff view down one page
u Scroll diff view up 18 lines
d Scroll diff view down 18 lines
-<$M1T-F> Find
-<$M1T-G> Move to next find hit
+<M1T-F> Find
+<M1T-G> Move to next find hit
<Return> Move to next find hit
/ Move to next find hit, or redo find
? Move to previous find hit
f Scroll diff view to next file
-<$M1T-S> Search for next hit in diff view
-<$M1T-R> Search for previous hit in diff view
-<$M1T-KP+> Increase font size
-<$M1T-plus> Increase font size
-<$M1T-KP-> Decrease font size
-<$M1T-minus> Decrease font size
+<M1T-S> Search for next hit in diff view
+<M1T-R> Search for previous hit in diff view
+<M1T-KP+> Increase font size
+<M1T-plus> Increase font size
+<M1T-KP-> Decrease font size
+<M1T-minus> Decrease font size
<F5> Update
-"] \
+" ] ] \
-justify left -bg white -border 2 -relief groove
pack $w.m -side top -fill both -padx 2 -pady 2
button $w.ok -text [mc "Close"] -command "destroy $w" -default active
--
1.5.3.5
^ permalink raw reply related
* Re: CRLF problems with Git on Win32
From: Gregory Jefferis @ 2008-01-09 17:37 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Steffen Prohaska, Johannes Schindelin, Peter Karlsson,
Git Mailing List, Robin Rosenberg, Jeff King, Linus Torvalds
In-Reply-To: <20080109150310.GC23659@dpotapov.dyndns.org>
On 9/1/08 15:03, "Dmitry Potapov" <dpotapov@gmail.com> wrote:
> On Wed, Jan 09, 2008 at 01:52:59PM +0000, Gregory Jefferis wrote:
>>
>> Re point (1) to be reversible in practice, we need to know who we've munged.
>> Otherwise when gnuming blindly at checkout we might damage some innocent
>> bystander file that only ever had LFs in the first place.
>
> If you work on Windows and you have clrf=safe, you cannot put a text
> file that has only LFs, because naked LF is not allowed. If you want
> to have naked LF in some file, you have to say that explicitly in
> .gitattributes.
>
> If you work on cross platform project, and somebody else put a file with
> bare LFs, which is not text though heauristic wrongly detected it as
> text then you can remove this file from your working directory, correct
> .gitattributes and checkout this file again. The idea of crlf=safe is
> that information is never lost. It is always fully reversible, and if
> you put something into the repostory, you always get back exactly the
> same unless you changed your .gitattributes.
>
>> Re (2) well if we happen to munge a file on checkin that is actually binary,
>> it must be gnumed on the way out otherwise it will be broken for the user.
>
> Of course, it will, because the same heuristic will detect it as text,
> and convert it back. So as long as you stay on the same platform and
> with the same .gitattributes, you always get back exactly what you
> put.
Dmitry, I think all of your comments are correct, BUT, this behaviour as
currently proposed still does not seem to me safe (or perhaps transparent)
enough to be enabled by default on a Windows platform (or for that matter a
Unix one).
If LF text files checked in on Windows get turned into CRLF files on
checkout by default then I think plenty of people would be surprised and
probably unhappy. Similarly I think it would be a bad thing if a binary
file that looked like LF only text got mangled on checkout by LF->CRLF
conversion - although I agree that it would be possible to recover from this
situation with a bit of juggling.
So my view is still that this behaviour would be a useful option when
explicitly enabled by .gitattributes (as opposed to the current auto CRLF
implementation, which could lead to irreversible munging) but that it is not
an appropriate system-wide default. I could however see that sane people
might disagree!
For that matter autocrlf=true,input,safe are all slightly dubious when used
as config vars rather than as attributes for the same collateral damage
reason discussed above. The only way to prevent collateral damage is to
consult .gitattributes on checkout (as Dmitry seemed to be assuming above)
rather than gnuming anything in the repository that looked like LF only
text. Of course even .gitattributes can change over time, so only by
storing a "munged" metadata attribute in the repository could you guarantee
that everything came out as it went in - which I think is a highly desirable
base state.
Greg.
^ permalink raw reply
* [PATCH] Change git-gc documentation to reflect gc.packrefs implementation.
From: Florian La Roche @ 2008-01-09 16:05 UTC (permalink / raw)
To: git, gitster
Adjust git-gc documentation to reflect gc.packrefs implementation.
Adjust git-gc documentation to reflect gc.packrefs implementation.
Signed-off-by: Florian La Roche <laroche@redhat.com>
---
Documentation/git-gc.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index c4354bb..4b2dfef 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -90,9 +90,9 @@ how long records of conflicted merge you have not resolved are
kept. This defaults to 15 days.
The optional configuration variable 'gc.packrefs' determines if
-`git gc` runs `git-pack-refs`. Without the configuration, `git-pack-refs`
-is not run in bare repositories by default, to allow older dumb-transport
-clients fetch from the repository, but this will change in the future.
+`git gc` runs `git-pack-refs`. This can be set to "nobare" to enable
+it within all non-bare repos or it can be set to a boolean value.
+This defaults to true.
The optional configuration variable 'gc.aggressiveWindow' controls how
much time is spent optimizing the delta compression of the objects in
--
1.5.3.7
^ permalink raw reply related
* [RFC] refer to post-patch lines in whitespace warnings
From: Daniel Barkalow @ 2008-01-09 15:57 UTC (permalink / raw)
To: git
When I rebase series with bad whitespace, I end up with unhelpful messages
like:
.dotest/patch:412: trailing whitespace.
--
.dotest/patch:446: trailing whitespace.
--
These line numbers obviously refer to lines in a file that's been removed
by the time I can do anything about it. It seems to me like the message
would be more useful if, in the case where it leaves the working tree
modified with the non-compliant whitespace, it gave this location rather
than the patch's location (because, even if you have the patch still,
you'd need to revert it first in order to be able to apply a fixed version
anyway). Anybody see any problems with this theory?
-Daniel
*This .sig left intentionally blank*
^ 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