* [PATCH 1/2] git-gui: Add more terms to glossary.
From: Christian Stimming @ 2007-10-20 13:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, git
In-Reply-To: <20071010060328.GO2137@spearce.org>
---
Based on git-gui.git's master.
po/glossary/git-gui-glossary.pot | 8 ++++++--
po/glossary/git-gui-glossary.txt | 3 ++-
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/po/glossary/git-gui-glossary.pot b/po/glossary/git-gui-glossary.pot
index a2e5c73..48af803 100644
--- a/po/glossary/git-gui-glossary.pot
+++ b/po/glossary/git-gui-glossary.pot
@@ -6,7 +6,7 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
-"POT-Creation-Date: 2007-10-05 22:30+0200\n"
+"POT-Creation-Date: 2007-10-19 21:43+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
@@ -86,7 +86,7 @@ msgstr ""
msgid "message"
msgstr ""
-#. ""
+#. "Deletes all stale tracking branches under <name>. These stale branches have already been removed from the remote repository referenced by <name>, but are still locally available in 'remotes/<name>'."
msgid "prune"
msgstr ""
@@ -102,6 +102,10 @@ msgstr ""
msgid "redo"
msgstr ""
+#. "An other repository ('remote'). One might have a set of remotes whose branches one tracks."
+msgid "remote"
+msgstr ""
+
#. "A collection of refs (?) together with an object database containing all objects which are reachable from the refs... (oops, you've lost me here. Again, please an explanation for mere mortals?)"
msgid "repository"
msgstr ""
diff --git a/po/glossary/git-gui-glossary.txt b/po/glossary/git-gui-glossary.txt
index b53740d..500d0a0 100644
--- a/po/glossary/git-gui-glossary.txt
+++ b/po/glossary/git-gui-glossary.txt
@@ -16,10 +16,11 @@
"merge [noun]" "A successful merge results in the creation of a new commit representing the result of the merge."
"merge [verb]" "To bring the contents of another branch into the current branch."
"message" ""
-"prune" ""
+"prune" "Deletes all stale tracking branches under <name>. These stale branches have already been removed from the remote repository referenced by <name>, but are still locally available in 'remotes/<name>'."
"pull" "Pulling a branch means to fetch it and merge it."
"push" "Pushing a branch means to get the branch's head ref from a remote repository, and ... (well, can someone please explain it for mere mortals?)"
"redo" ""
+"remote" "An other repository ('remote'). One might have a set of remotes whose branches one tracks."
"repository" "A collection of refs (?) together with an object database containing all objects which are reachable from the refs... (oops, you've lost me here. Again, please an explanation for mere mortals?)"
"reset" ""
"revert" ""
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* Re: [PATCH 2/2] git-gui: Update German translation
From: Christian Stimming @ 2007-10-20 13:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, git
In-Reply-To: <200710201530.53483.stimming@tuhh.de>
---
Updated German glossary and German translation. Based on git-gui.git's master.
po/de.po | 444 +++++++++++++++++++++++++++--------------------------
po/glossary/de.po | 14 +-
2 files changed, 238 insertions(+), 220 deletions(-)
diff --git a/po/de.po b/po/de.po
index 4ba2fbe..3df30ed 100644
--- a/po/de.po
+++ b/po/de.po
@@ -7,41 +7,41 @@ msgid ""
msgstr ""
"Project-Id-Version: git-gui\n"
"Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2007-10-10 04:04-0400\n"
-"PO-Revision-Date: 2007-10-05 22:27+0200\n"
+"POT-Creation-Date: 2007-10-19 21:10+0200\n"
+"PO-Revision-Date: 2007-10-20 15:28+0200\n"
"Last-Translator: Christian Stimming <stimming@tuhh.de>\n"
"Language-Team: German\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
-#: git-gui.sh:41 git-gui.sh:634 git-gui.sh:648 git-gui.sh:661 git-gui.sh:744
-#: git-gui.sh:763
+#: git-gui.sh:41 git-gui.sh:590 git-gui.sh:604 git-gui.sh:617 git-gui.sh:700
+#: git-gui.sh:719
msgid "git-gui: fatal error"
msgstr "git-gui: Programmfehler"
-#: git-gui.sh:595
+#: git-gui.sh:551
#, tcl-format
msgid "Invalid font specified in %s:"
msgstr "Ungültige Zeichensatz-Angabe in %s:"
-#: git-gui.sh:620
+#: git-gui.sh:576
msgid "Main Font"
msgstr "Programmschriftart"
-#: git-gui.sh:621
+#: git-gui.sh:577
msgid "Diff/Console Font"
msgstr "Vergleich-Schriftart"
-#: git-gui.sh:635
+#: git-gui.sh:591
msgid "Cannot find git in PATH."
msgstr "Git kann im PATH nicht gefunden werden."
-#: git-gui.sh:662
+#: git-gui.sh:618
msgid "Cannot parse Git version string:"
msgstr "Git Versionsangabe kann nicht erkannt werden:"
-#: git-gui.sh:680
+#: git-gui.sh:636
#, tcl-format
msgid ""
"Git version cannot be determined.\n"
@@ -60,81 +60,81 @@ msgstr ""
"\n"
"Soll angenommen werden, »%s« sei Version 1.5.0?\n"
-#: git-gui.sh:853
+#: git-gui.sh:874
msgid "Git directory not found:"
msgstr "Git-Verzeichnis nicht gefunden:"
-#: git-gui.sh:860
+#: git-gui.sh:881
msgid "Cannot move to top of working directory:"
msgstr ""
"Es konnte nicht in das oberste Verzeichnis der Arbeitskopie gewechselt "
"werden:"
-#: git-gui.sh:867
+#: git-gui.sh:888
msgid "Cannot use funny .git directory:"
msgstr "Unerwartete Struktur des .git Verzeichnis:"
-#: git-gui.sh:872
+#: git-gui.sh:893
msgid "No working directory"
msgstr "Kein Arbeitsverzeichnis"
-#: git-gui.sh:1019
+#: git-gui.sh:1040
msgid "Refreshing file status..."
msgstr "Dateistatus aktualisieren..."
-#: git-gui.sh:1084
+#: git-gui.sh:1105
msgid "Scanning for modified files ..."
msgstr "Nach geänderten Dateien suchen..."
-#: git-gui.sh:1259 lib/browser.tcl:245
+#: git-gui.sh:1280 lib/browser.tcl:245
msgid "Ready."
msgstr "Bereit."
-#: git-gui.sh:1525
+#: git-gui.sh:1546
msgid "Unmodified"
msgstr "Unverändert"
-#: git-gui.sh:1527
+#: git-gui.sh:1548
msgid "Modified, not staged"
msgstr "Verändert, nicht bereitgestellt"
-#: git-gui.sh:1528 git-gui.sh:1533
+#: git-gui.sh:1549 git-gui.sh:1554
msgid "Staged for commit"
msgstr "Bereitgestellt zum Eintragen"
-#: git-gui.sh:1529 git-gui.sh:1534
+#: git-gui.sh:1550 git-gui.sh:1555
msgid "Portions staged for commit"
msgstr "Teilweise bereitgestellt zum Eintragen"
-#: git-gui.sh:1530 git-gui.sh:1535
+#: git-gui.sh:1551 git-gui.sh:1556
msgid "Staged for commit, missing"
msgstr "Bereitgestellt zum Eintragen, fehlend"
-#: git-gui.sh:1532
+#: git-gui.sh:1553
msgid "Untracked, not staged"
msgstr "Nicht unter Versionskontrolle, nicht bereitgestellt"
-#: git-gui.sh:1537
+#: git-gui.sh:1558
msgid "Missing"
msgstr "Fehlend"
-#: git-gui.sh:1538
+#: git-gui.sh:1559
msgid "Staged for removal"
msgstr "Bereitgestellt zum Löschen"
-#: git-gui.sh:1539
+#: git-gui.sh:1560
msgid "Staged for removal, still present"
msgstr "Bereitgestellt zum Löschen, trotzdem vorhanden"
-#: git-gui.sh:1541 git-gui.sh:1542 git-gui.sh:1543 git-gui.sh:1544
+#: git-gui.sh:1562 git-gui.sh:1563 git-gui.sh:1564 git-gui.sh:1565
msgid "Requires merge resolution"
msgstr "Konfliktauflösung nötig"
-#: git-gui.sh:1579
+#: git-gui.sh:1600
msgid "Starting gitk... please wait..."
msgstr "Gitk wird gestartet... bitte warten."
-#: git-gui.sh:1588
+#: git-gui.sh:1609
#, tcl-format
msgid ""
"Unable to start gitk:\n"
@@ -145,297 +145,295 @@ msgstr ""
"\n"
"%s existiert nicht"
-#: git-gui.sh:1788 lib/choose_repository.tcl:32
+#: git-gui.sh:1809 lib/choose_repository.tcl:35
msgid "Repository"
msgstr "Projektarchiv"
-#: git-gui.sh:1789
+#: git-gui.sh:1810
msgid "Edit"
msgstr "Bearbeiten"
-#: git-gui.sh:1791 lib/choose_rev.tcl:560
+#: git-gui.sh:1812 lib/choose_rev.tcl:560
msgid "Branch"
msgstr "Zweig"
-#: git-gui.sh:1794 lib/choose_rev.tcl:547
+#: git-gui.sh:1815 lib/choose_rev.tcl:547
msgid "Commit@@noun"
msgstr "Version"
-#: git-gui.sh:1797 lib/merge.tcl:121 lib/merge.tcl:150 lib/merge.tcl:168
+#: git-gui.sh:1818 lib/merge.tcl:121 lib/merge.tcl:150 lib/merge.tcl:168
msgid "Merge"
msgstr "Zusammenführen"
-#: git-gui.sh:1798 lib/choose_rev.tcl:556
+#: git-gui.sh:1819 lib/choose_rev.tcl:556
msgid "Remote"
-msgstr "Gegenseite"
+msgstr "Andere Archive"
-#: git-gui.sh:1807
+#: git-gui.sh:1828
msgid "Browse Current Branch's Files"
msgstr "Aktuellen Zweig durchblättern"
-#: git-gui.sh:1811
+#: git-gui.sh:1832
msgid "Browse Branch Files..."
msgstr "Einen Zweig durchblättern..."
-#: git-gui.sh:1816
+#: git-gui.sh:1837
msgid "Visualize Current Branch's History"
msgstr "Aktuellen Zweig darstellen"
-#: git-gui.sh:1820
+#: git-gui.sh:1841
msgid "Visualize All Branch History"
msgstr "Alle Zweige darstellen"
-#: git-gui.sh:1827
+#: git-gui.sh:1848
#, tcl-format
msgid "Browse %s's Files"
msgstr "Zweig »%s« durchblättern"
-#: git-gui.sh:1829
+#: git-gui.sh:1850
#, tcl-format
msgid "Visualize %s's History"
msgstr "Historie von »%s« darstellen"
-#: git-gui.sh:1834 lib/database.tcl:27 lib/database.tcl:67
+#: git-gui.sh:1855 lib/database.tcl:27 lib/database.tcl:67
msgid "Database Statistics"
msgstr "Datenbankstatistik"
-#: git-gui.sh:1837 lib/database.tcl:34
+#: git-gui.sh:1858 lib/database.tcl:34
msgid "Compress Database"
msgstr "Datenbank komprimieren"
-#: git-gui.sh:1840
+#: git-gui.sh:1861
msgid "Verify Database"
msgstr "Datenbank überprüfen"
-#: git-gui.sh:1847 git-gui.sh:1851 git-gui.sh:1855 lib/shortcut.tcl:9
-#: lib/shortcut.tcl:45 lib/shortcut.tcl:84
+#: git-gui.sh:1868 git-gui.sh:1872 git-gui.sh:1876 lib/shortcut.tcl:7
+#: lib/shortcut.tcl:39 lib/shortcut.tcl:71
msgid "Create Desktop Icon"
msgstr "Desktop-Icon erstellen"
-#: git-gui.sh:1860 lib/choose_repository.tcl:36 lib/choose_repository.tcl:95
+#: git-gui.sh:1881 lib/choose_repository.tcl:176 lib/choose_repository.tcl:184
msgid "Quit"
msgstr "Beenden"
-#: git-gui.sh:1867
+#: git-gui.sh:1888
msgid "Undo"
msgstr "Rückgängig"
-#: git-gui.sh:1870
+#: git-gui.sh:1891
msgid "Redo"
msgstr "Wiederholen"
-#: git-gui.sh:1874 git-gui.sh:2366
+#: git-gui.sh:1895 git-gui.sh:2388
msgid "Cut"
msgstr "Ausschneiden"
-#: git-gui.sh:1877 git-gui.sh:2369 git-gui.sh:2440 git-gui.sh:2512
+#: git-gui.sh:1898 git-gui.sh:2391 git-gui.sh:2462 git-gui.sh:2534
#: lib/console.tcl:67
msgid "Copy"
msgstr "Kopieren"
-#: git-gui.sh:1880 git-gui.sh:2372
+#: git-gui.sh:1901 git-gui.sh:2394
msgid "Paste"
msgstr "Einfügen"
-#: git-gui.sh:1883 git-gui.sh:2375 lib/branch_delete.tcl:26
+#: git-gui.sh:1904 git-gui.sh:2397 lib/branch_delete.tcl:26
#: lib/remote_branch_delete.tcl:38
msgid "Delete"
msgstr "Löschen"
-#: git-gui.sh:1887 git-gui.sh:2379 git-gui.sh:2516 lib/console.tcl:69
+#: git-gui.sh:1908 git-gui.sh:2401 git-gui.sh:2538 lib/console.tcl:69
msgid "Select All"
msgstr "Alle auswählen"
-#: git-gui.sh:1896
+#: git-gui.sh:1917
msgid "Create..."
msgstr "Erstellen..."
-#: git-gui.sh:1902
+#: git-gui.sh:1923
msgid "Checkout..."
msgstr "Umstellen..."
-#: git-gui.sh:1908
+#: git-gui.sh:1929
msgid "Rename..."
msgstr "Umbenennen..."
-#: git-gui.sh:1913 git-gui.sh:2012
+#: git-gui.sh:1934 git-gui.sh:2033
msgid "Delete..."
msgstr "Löschen..."
-#: git-gui.sh:1918
+#: git-gui.sh:1939
msgid "Reset..."
msgstr "Zurücksetzen..."
-#: git-gui.sh:1930 git-gui.sh:2313
+#: git-gui.sh:1951 git-gui.sh:2335
msgid "New Commit"
msgstr "Neue Version"
-#: git-gui.sh:1938 git-gui.sh:2320
+#: git-gui.sh:1959 git-gui.sh:2342
msgid "Amend Last Commit"
msgstr "Letzte Version nachbessern"
-#: git-gui.sh:1947 git-gui.sh:2280 lib/remote_branch_delete.tcl:99
+#: git-gui.sh:1968 git-gui.sh:2302 lib/remote_branch_delete.tcl:99
msgid "Rescan"
msgstr "Neu laden"
-#: git-gui.sh:1953
+#: git-gui.sh:1974
msgid "Stage To Commit"
msgstr "Zum Eintragen bereitstellen"
-#: git-gui.sh:1958
+#: git-gui.sh:1979
msgid "Stage Changed Files To Commit"
msgstr "Geänderte Dateien zum Eintragen bereitstellen"
-#: git-gui.sh:1964
+#: git-gui.sh:1985
msgid "Unstage From Commit"
msgstr "Aus der Bereitstellung herausnehmen"
-#: git-gui.sh:1969 lib/index.tcl:352
+#: git-gui.sh:1990 lib/index.tcl:352
msgid "Revert Changes"
msgstr "Änderungen revidieren"
-#: git-gui.sh:1976 git-gui.sh:2292 git-gui.sh:2390
+#: git-gui.sh:1997 git-gui.sh:2314 git-gui.sh:2412
msgid "Sign Off"
msgstr "Abzeichnen"
-#: git-gui.sh:1980 git-gui.sh:2296
+#: git-gui.sh:2001 git-gui.sh:2318
msgid "Commit@@verb"
msgstr "Eintragen"
-#: git-gui.sh:1991
+#: git-gui.sh:2012
msgid "Local Merge..."
msgstr "Lokales Zusammenführen..."
-#: git-gui.sh:1996
+#: git-gui.sh:2017
msgid "Abort Merge..."
msgstr "Zusammenführen abbrechen..."
-#: git-gui.sh:2008
+#: git-gui.sh:2029
msgid "Push..."
-msgstr "Ausliefern..."
+msgstr "Versenden..."
-#: git-gui.sh:2019 lib/choose_repository.tcl:41
+#: git-gui.sh:2040 lib/choose_repository.tcl:40
msgid "Apple"
msgstr "Apple"
-#: git-gui.sh:2022 git-gui.sh:2044 lib/about.tcl:13
-#: lib/choose_repository.tcl:44 lib/choose_repository.tcl:50
+#: git-gui.sh:2043 git-gui.sh:2065 lib/about.tcl:13
+#: lib/choose_repository.tcl:43 lib/choose_repository.tcl:49
#, tcl-format
msgid "About %s"
msgstr "Über %s"
-#: git-gui.sh:2026
+#: git-gui.sh:2047
msgid "Preferences..."
-msgstr ""
+msgstr "Einstellungen..."
-#: git-gui.sh:2034 git-gui.sh:2558
+#: git-gui.sh:2055 git-gui.sh:2580
msgid "Options..."
msgstr "Optionen..."
-#: git-gui.sh:2040 lib/choose_repository.tcl:47
+#: git-gui.sh:2061 lib/choose_repository.tcl:46
msgid "Help"
msgstr "Hilfe"
-#: git-gui.sh:2081
+#: git-gui.sh:2102
msgid "Online Documentation"
msgstr "Online-Dokumentation"
-#: git-gui.sh:2165
+#: git-gui.sh:2186
#, tcl-format
msgid "fatal: cannot stat path %s: No such file or directory"
msgstr ""
-#: git-gui.sh:2198
+#: git-gui.sh:2219
msgid "Current Branch:"
msgstr "Aktueller Zweig:"
-#: git-gui.sh:2219
-#, fuzzy
+#: git-gui.sh:2240
msgid "Staged Changes (Will Commit)"
-msgstr "Bereitgestellte Änderungen (werden eingetragen)"
+msgstr "Bereitgestellte Änderungen (zum Eintragen)"
-#: git-gui.sh:2239
-#, fuzzy
+#: git-gui.sh:2259
msgid "Unstaged Changes"
-msgstr "Geänderte bereitstellen"
+msgstr "Nicht bereitgestellte Änderungen"
-#: git-gui.sh:2286
+#: git-gui.sh:2308
msgid "Stage Changed"
-msgstr "Geänderte bereitstellen"
+msgstr "Alles bereitstellen"
-#: git-gui.sh:2302 lib/transport.tcl:93 lib/transport.tcl:182
+#: git-gui.sh:2324 lib/transport.tcl:93 lib/transport.tcl:182
msgid "Push"
-msgstr "Ausliefern"
+msgstr "Versenden"
-#: git-gui.sh:2332
+#: git-gui.sh:2354
msgid "Initial Commit Message:"
-msgstr "Beschreibung der ersten Version:"
+msgstr "Erste Versionsbeschreibung:"
-#: git-gui.sh:2333
+#: git-gui.sh:2355
msgid "Amended Commit Message:"
-msgstr "Beschreibung der nachgebesserten Version:"
+msgstr "Nachgebesserte Versionsbeschreibung:"
-#: git-gui.sh:2334
+#: git-gui.sh:2356
msgid "Amended Initial Commit Message:"
-msgstr "Beschreibung der nachgebesserten ersten Version:"
+msgstr "Nachgebesserte erste Versionsbeschreibung:"
-#: git-gui.sh:2335
+#: git-gui.sh:2357
msgid "Amended Merge Commit Message:"
-msgstr "Beschreibung der nachgebesserten Zusammenführungs-Version:"
+msgstr "Nachgebesserte Zusammenführungs-Versionsbeschreibung:"
-#: git-gui.sh:2336
+#: git-gui.sh:2358
msgid "Merge Commit Message:"
-msgstr "Beschreibung der Zusammenführungs-Version:"
+msgstr "Zusammenführungs-Versionsbeschreibung:"
-#: git-gui.sh:2337
+#: git-gui.sh:2359
msgid "Commit Message:"
msgstr "Versionsbeschreibung:"
-#: git-gui.sh:2382 git-gui.sh:2520 lib/console.tcl:71
+#: git-gui.sh:2404 git-gui.sh:2542 lib/console.tcl:71
msgid "Copy All"
msgstr "Alle kopieren"
-#: git-gui.sh:2406 lib/blame.tcl:104
+#: git-gui.sh:2428 lib/blame.tcl:104
msgid "File:"
msgstr "Datei:"
-#: git-gui.sh:2508
+#: git-gui.sh:2530
msgid "Refresh"
msgstr "Aktualisieren"
-#: git-gui.sh:2529
+#: git-gui.sh:2551
msgid "Apply/Reverse Hunk"
msgstr "Änderung anwenden/umkehren"
-#: git-gui.sh:2535
+#: git-gui.sh:2557
msgid "Decrease Font Size"
msgstr "Schriftgröße verkleinern"
-#: git-gui.sh:2539
+#: git-gui.sh:2561
msgid "Increase Font Size"
msgstr "Schriftgröße vergrößern"
-#: git-gui.sh:2544
+#: git-gui.sh:2566
msgid "Show Less Context"
msgstr "Weniger Kontext anzeigen"
-#: git-gui.sh:2551
+#: git-gui.sh:2573
msgid "Show More Context"
msgstr "Mehr Kontext anzeigen"
-#: git-gui.sh:2565
+#: git-gui.sh:2587
msgid "Unstage Hunk From Commit"
msgstr "Aus der Bereitstellung herausnehmen"
-#: git-gui.sh:2567
+#: git-gui.sh:2589
msgid "Stage Hunk For Commit"
msgstr "In die Bereitstellung hinzufügen"
-#: git-gui.sh:2586
+#: git-gui.sh:2608
msgid "Initializing..."
msgstr "Initialisieren..."
-#: git-gui.sh:2677
+#: git-gui.sh:2699
#, tcl-format
msgid ""
"Possible environment issues exist.\n"
@@ -446,14 +444,14 @@ msgid ""
"\n"
msgstr ""
-#: git-gui.sh:2707
+#: git-gui.sh:2729
msgid ""
"\n"
"This is due to a known issue with the\n"
"Tcl binary distributed by Cygwin."
msgstr ""
-#: git-gui.sh:2712
+#: git-gui.sh:2734
#, tcl-format
msgid ""
"\n"
@@ -515,11 +513,11 @@ msgstr "Eintragender:"
#: lib/blame.tcl:796
msgid "Original File:"
-msgstr ""
+msgstr "Ursprüngliche Datei:"
#: lib/blame.tcl:910
msgid "Originally By:"
-msgstr ""
+msgstr "Ursprünglich von:"
#: lib/blame.tcl:916
msgid "In File:"
@@ -527,7 +525,7 @@ msgstr "In Datei:"
#: lib/blame.tcl:921
msgid "Copied Or Moved Here By:"
-msgstr ""
+msgstr "Kopiert oder verschoben durch:"
#: lib/branch_checkout.tcl:14 lib/branch_checkout.tcl:19
msgid "Checkout Branch"
@@ -568,7 +566,7 @@ msgstr "Zweig erstellen"
msgid "Create New Branch"
msgstr "Neuen Zweig erstellen"
-#: lib/branch_create.tcl:31 lib/choose_repository.tcl:199
+#: lib/branch_create.tcl:31 lib/choose_repository.tcl:375
msgid "Create"
msgstr "Erstellen"
@@ -615,7 +613,7 @@ msgstr "Bitte wählen Sie einen Übernahmezweig."
#: lib/branch_create.tcl:140
#, tcl-format
msgid "Tracking branch %s is not a branch in the remote repository."
-msgstr "Übernahmezweig »%s« ist kein Zweig im Projektarchiv der Gegenseite."
+msgstr "Übernahmezweig »%s« ist kein Zweig im anderen Projektarchiv."
#: lib/branch_create.tcl:153 lib/branch_rename.tcl:86
msgid "Please supply a branch name."
@@ -721,9 +719,9 @@ msgstr "[Nach oben]"
msgid "Browse Branch Files"
msgstr "Dateien des Zweigs durchblättern"
-#: lib/browser.tcl:277 lib/choose_repository.tcl:215
-#: lib/choose_repository.tcl:305 lib/choose_repository.tcl:315
-#: lib/choose_repository.tcl:811
+#: lib/browser.tcl:277 lib/choose_repository.tcl:391
+#: lib/choose_repository.tcl:482 lib/choose_repository.tcl:492
+#: lib/choose_repository.tcl:989
msgid "Browse"
msgstr "Blättern"
@@ -889,209 +887,225 @@ msgstr ""
"Dies ist ein Beispieltext.\n"
"Wenn Ihnen dieser Text gefällt, sollten Sie diese Schriftart wählen."
-#: lib/choose_repository.tcl:25
+#: lib/choose_repository.tcl:27
msgid "Git Gui"
msgstr "Git Gui"
-#: lib/choose_repository.tcl:69 lib/choose_repository.tcl:204
+#: lib/choose_repository.tcl:80 lib/choose_repository.tcl:380
msgid "Create New Repository"
msgstr "Neues Projektarchiv"
-#: lib/choose_repository.tcl:74 lib/choose_repository.tcl:291
+#: lib/choose_repository.tcl:86
+msgid "New..."
+msgstr "Neu..."
+
+#: lib/choose_repository.tcl:93 lib/choose_repository.tcl:468
msgid "Clone Existing Repository"
msgstr "Projektarchiv kopieren"
-#: lib/choose_repository.tcl:79 lib/choose_repository.tcl:800
+#: lib/choose_repository.tcl:99
+msgid "Clone..."
+msgstr "Kopieren..."
+
+#: lib/choose_repository.tcl:106 lib/choose_repository.tcl:978
msgid "Open Existing Repository"
msgstr "Projektarchiv öffnen"
-#: lib/choose_repository.tcl:91
-msgid "Next >"
-msgstr "Weiter >"
+#: lib/choose_repository.tcl:112
+msgid "Open..."
+msgstr "Öffnen..."
+
+#: lib/choose_repository.tcl:125
+msgid "Recent Repositories"
+msgstr "Zuletzt benutzte Projektarchive"
-#: lib/choose_repository.tcl:152
+#: lib/choose_repository.tcl:131
+msgid "Open Recent Repository:"
+msgstr "Zuletzt benutztes Projektarchiv öffnen:"
+
+#: lib/choose_repository.tcl:294
#, tcl-format
msgid "Location %s already exists."
msgstr "Projektarchiv »%s« existiert bereits."
-#: lib/choose_repository.tcl:158 lib/choose_repository.tcl:165
-#: lib/choose_repository.tcl:172
+#: lib/choose_repository.tcl:300 lib/choose_repository.tcl:307
+#: lib/choose_repository.tcl:314
#, tcl-format
msgid "Failed to create repository %s:"
msgstr "Projektarchiv »%s« konnte nicht erstellt werden:"
-#: lib/choose_repository.tcl:209 lib/choose_repository.tcl:309
+#: lib/choose_repository.tcl:385 lib/choose_repository.tcl:486
msgid "Directory:"
msgstr "Verzeichnis:"
-#: lib/choose_repository.tcl:238 lib/choose_repository.tcl:363
-#: lib/choose_repository.tcl:834
+#: lib/choose_repository.tcl:415 lib/choose_repository.tcl:544
+#: lib/choose_repository.tcl:1013
msgid "Git Repository"
msgstr "Git Projektarchiv"
-#: lib/choose_repository.tcl:253 lib/choose_repository.tcl:260
+#: lib/choose_repository.tcl:430 lib/choose_repository.tcl:437
#, tcl-format
msgid "Directory %s already exists."
msgstr "Verzeichnis »%s« existiert bereits."
-#: lib/choose_repository.tcl:265
+#: lib/choose_repository.tcl:442
#, tcl-format
msgid "File %s already exists."
msgstr "Datei »%s« existiert bereits."
-#: lib/choose_repository.tcl:286
+#: lib/choose_repository.tcl:463
msgid "Clone"
msgstr "Kopieren"
-#: lib/choose_repository.tcl:299
+#: lib/choose_repository.tcl:476
msgid "URL:"
msgstr "URL:"
-#: lib/choose_repository.tcl:319
+#: lib/choose_repository.tcl:496
msgid "Clone Type:"
msgstr "Art der Kopie:"
-#: lib/choose_repository.tcl:325
+#: lib/choose_repository.tcl:502
msgid "Standard (Fast, Semi-Redundant, Hardlinks)"
-msgstr ""
+msgstr "Standard (schnell, teilweise redundant, Hardlinks)"
-#: lib/choose_repository.tcl:331
+#: lib/choose_repository.tcl:508
msgid "Full Copy (Slower, Redundant Backup)"
-msgstr ""
+msgstr "Alles kopieren (langsamer, volle Redundanz)"
-#: lib/choose_repository.tcl:337
+#: lib/choose_repository.tcl:514
msgid "Shared (Fastest, Not Recommended, No Backup)"
-msgstr ""
+msgstr "Verknüpft (schnell, nicht empfohlen, kein Backup)"
-#: lib/choose_repository.tcl:369 lib/choose_repository.tcl:418
-#: lib/choose_repository.tcl:560 lib/choose_repository.tcl:630
-#: lib/choose_repository.tcl:840 lib/choose_repository.tcl:848
+#: lib/choose_repository.tcl:550 lib/choose_repository.tcl:597
+#: lib/choose_repository.tcl:738 lib/choose_repository.tcl:808
+#: lib/choose_repository.tcl:1019 lib/choose_repository.tcl:1027
#, tcl-format
msgid "Not a Git repository: %s"
msgstr "Kein Git-Projektarchiv in »%s« gefunden."
-#: lib/choose_repository.tcl:405
+#: lib/choose_repository.tcl:586
msgid "Standard only available for local repository."
-msgstr ""
+msgstr "Standard ist nur für lokale Projektarchive verfügbar."
-#: lib/choose_repository.tcl:409
+#: lib/choose_repository.tcl:590
msgid "Shared only available for local repository."
-msgstr ""
+msgstr "Verknüpft ist nur für lokale Projektarchive verfügbar."
-#: lib/choose_repository.tcl:439
+#: lib/choose_repository.tcl:617
msgid "Failed to configure origin"
msgstr ""
-#: lib/choose_repository.tcl:451
+#: lib/choose_repository.tcl:629
msgid "Counting objects"
msgstr ""
-#: lib/choose_repository.tcl:452
+#: lib/choose_repository.tcl:630
msgid "buckets"
msgstr ""
-#: lib/choose_repository.tcl:476
+#: lib/choose_repository.tcl:654
#, tcl-format
msgid "Unable to copy objects/info/alternates: %s"
msgstr ""
-#: lib/choose_repository.tcl:512
+#: lib/choose_repository.tcl:690
#, tcl-format
msgid "Nothing to clone from %s."
msgstr "Von »%s« konnte nichts kopiert werden."
-#: lib/choose_repository.tcl:514 lib/choose_repository.tcl:728
-#: lib/choose_repository.tcl:740
+#: lib/choose_repository.tcl:692 lib/choose_repository.tcl:906
+#: lib/choose_repository.tcl:918
msgid "The 'master' branch has not been initialized."
msgstr ""
-#: lib/choose_repository.tcl:527
+#: lib/choose_repository.tcl:705
msgid "Hardlinks are unavailable. Falling back to copying."
msgstr ""
-#: lib/choose_repository.tcl:539
+#: lib/choose_repository.tcl:717
#, tcl-format
msgid "Cloning from %s"
msgstr "Kopieren von »%s«"
-#: lib/choose_repository.tcl:570
+#: lib/choose_repository.tcl:748
msgid "Copying objects"
msgstr "Objektdatenbank kopieren"
-#: lib/choose_repository.tcl:571
+#: lib/choose_repository.tcl:749
msgid "KiB"
msgstr "KB"
-#: lib/choose_repository.tcl:595
+#: lib/choose_repository.tcl:773
#, tcl-format
msgid "Unable to copy object: %s"
msgstr "Objekt kann nicht kopiert werden: %s"
-#: lib/choose_repository.tcl:605
+#: lib/choose_repository.tcl:783
msgid "Linking objects"
msgstr "Objekte verlinken"
-#: lib/choose_repository.tcl:606
+#: lib/choose_repository.tcl:784
msgid "objects"
msgstr "Objekte"
-#: lib/choose_repository.tcl:614
+#: lib/choose_repository.tcl:792
#, tcl-format
msgid "Unable to hardlink object: %s"
msgstr "Objekt kann nicht hartverlinkt werden: %s"
-#: lib/choose_repository.tcl:669
+#: lib/choose_repository.tcl:847
msgid "Cannot fetch branches and objects. See console output for details."
msgstr ""
-#: lib/choose_repository.tcl:680
+#: lib/choose_repository.tcl:858
msgid "Cannot fetch tags. See console output for details."
msgstr ""
-#: lib/choose_repository.tcl:704
+#: lib/choose_repository.tcl:882
msgid "Cannot determine HEAD. See console output for details."
msgstr ""
-#: lib/choose_repository.tcl:713
+#: lib/choose_repository.tcl:891
#, tcl-format
msgid "Unable to cleanup %s"
msgstr ""
-#: lib/choose_repository.tcl:719
+#: lib/choose_repository.tcl:897
msgid "Clone failed."
msgstr "Kopieren fehlgeschlagen."
-#: lib/choose_repository.tcl:726
+#: lib/choose_repository.tcl:904
msgid "No default branch obtained."
msgstr ""
-#: lib/choose_repository.tcl:737
+#: lib/choose_repository.tcl:915
#, tcl-format
msgid "Cannot resolve %s as a commit."
msgstr ""
-#: lib/choose_repository.tcl:749
+#: lib/choose_repository.tcl:927
msgid "Creating working directory"
msgstr "Arbeitskopie erstellen"
-#: lib/choose_repository.tcl:750 lib/index.tcl:15 lib/index.tcl:80
+#: lib/choose_repository.tcl:928 lib/index.tcl:15 lib/index.tcl:80
#: lib/index.tcl:149
msgid "files"
msgstr "Dateien"
-#: lib/choose_repository.tcl:779
+#: lib/choose_repository.tcl:957
msgid "Initial file checkout failed."
msgstr ""
-#: lib/choose_repository.tcl:795
+#: lib/choose_repository.tcl:973
msgid "Open"
msgstr "Öffnen"
-#: lib/choose_repository.tcl:805
+#: lib/choose_repository.tcl:983
msgid "Repository:"
msgstr "Projektarchiv:"
-#: lib/choose_repository.tcl:854
+#: lib/choose_repository.tcl:1033
#, tcl-format
msgid "Failed to open repository %s:"
msgstr "Projektarchiv »%s« konnte nicht geöffnet werden."
@@ -1326,7 +1340,7 @@ msgstr "Festplattenplatz von komprimierten Objekten"
#: lib/database.tcl:48
msgid "Packed objects waiting for pruning"
-msgstr "Komprimierte Objekte, die zum Löschen vorgesehen sind"
+msgstr "Komprimierte Objekte, die zum Entfernen vorgesehen sind"
#: lib/database.tcl:49
msgid "Garbage files"
@@ -1644,7 +1658,7 @@ msgstr "Auf Dateiänderungsdatum verlassen"
#: lib/option.tcl:111
msgid "Prune Tracking Branches During Fetch"
-msgstr "Übernahmezweige löschen während Anforderung"
+msgstr "Übernahmezweige entfernen während Anforderung"
#: lib/option.tcl:112
msgid "Match Tracking Branches"
@@ -1673,30 +1687,15 @@ msgstr "pt."
#: lib/option.tcl:200
msgid "Preferences"
-msgstr ""
+msgstr "Einstellungen"
#: lib/option.tcl:235
msgid "Failed to completely save options:"
msgstr "Optionen konnten nicht gespeichert werden:"
-#: lib/remote.tcl:165
-#, fuzzy
-msgid "Prune from"
-msgstr "Löschen von »%s«"
-
-#: lib/remote.tcl:170
-#, fuzzy
-msgid "Fetch from"
-msgstr "Von »%s« anfordern"
-
-#: lib/remote.tcl:213
-#, fuzzy
-msgid "Push to"
-msgstr "Nach »%s« ausliefern"
-
#: lib/remote_branch_delete.tcl:29 lib/remote_branch_delete.tcl:34
msgid "Delete Remote Branch"
-msgstr "Zweig im Projektarchiv der Gegenseite löschen"
+msgstr "Zweig im anderen Projektarchiv löschen"
#: lib/remote_branch_delete.tcl:47
msgid "From Repository"
@@ -1704,7 +1703,7 @@ msgstr "Von Projektarchiv"
#: lib/remote_branch_delete.tcl:50 lib/transport.tcl:123
msgid "Remote:"
-msgstr "Gegenseite:"
+msgstr "Anderes Archiv:"
#: lib/remote_branch_delete.tcl:66 lib/transport.tcl:138
msgid "Arbitrary URL:"
@@ -1780,11 +1779,23 @@ msgstr "Kein Projektarchiv ausgewählt."
msgid "Scanning %s..."
msgstr "»%s« laden..."
-#: lib/shortcut.tcl:26 lib/shortcut.tcl:74
-msgid "Cannot write script:"
-msgstr "Fehler beim Schreiben des Scripts:"
+#: lib/remote.tcl:165
+msgid "Prune from"
+msgstr "Entfernen von"
+
+#: lib/remote.tcl:170
+msgid "Fetch from"
+msgstr "Anfordern von"
+
+#: lib/remote.tcl:213
+msgid "Push to"
+msgstr "Versenden nach"
+
+#: lib/shortcut.tcl:20 lib/shortcut.tcl:61
+msgid "Cannot write shortcut:"
+msgstr "Fehler beim Schreiben der Verknüpfung:"
-#: lib/shortcut.tcl:149
+#: lib/shortcut.tcl:136
msgid "Cannot write icon:"
msgstr "Fehler beim Erstellen des Icons:"
@@ -1806,31 +1817,31 @@ msgstr "Neue Änderungen von »%s« holen"
#: lib/transport.tcl:18
#, tcl-format
msgid "remote prune %s"
-msgstr ""
+msgstr "Entfernen von »%s« im anderen Archiv"
#: lib/transport.tcl:19
#, tcl-format
msgid "Pruning tracking branches deleted from %s"
-msgstr "Übernahmezweige löschen, die in »%s« gelöscht wurden"
+msgstr "Übernahmezweige entfernen, die in »%s« gelöscht wurden"
#: lib/transport.tcl:25 lib/transport.tcl:71
#, tcl-format
msgid "push %s"
-msgstr "»%s« ausliefern..."
+msgstr "»%s« versenden..."
#: lib/transport.tcl:26
#, tcl-format
msgid "Pushing changes to %s"
-msgstr "Änderungen nach »%s« ausliefern"
+msgstr "Änderungen nach »%s« versenden"
#: lib/transport.tcl:72
#, tcl-format
msgid "Pushing %s %s to %s"
-msgstr "%s %s nach %s ausliefern"
+msgstr "%s %s nach %s versenden"
#: lib/transport.tcl:89
msgid "Push Branches"
-msgstr "Zweige ausliefern"
+msgstr "Zweige versenden"
#: lib/transport.tcl:103
msgid "Source Branches"
@@ -1857,6 +1868,9 @@ msgstr "Kompaktes Datenformat benutzen (für langsame Netzverbindungen)"
msgid "Include tags"
msgstr "Mit Markierungen übertragen"
+#~ msgid "Next >"
+#~ msgstr "Weiter >"
+
#~ msgid "Fetch"
#~ msgstr "Anfordern"
diff --git a/po/glossary/de.po b/po/glossary/de.po
index 054cf4d..c94786c 100644
--- a/po/glossary/de.po
+++ b/po/glossary/de.po
@@ -6,8 +6,8 @@
msgid ""
msgstr ""
"Project-Id-Version: git-gui glossary\n"
-"POT-Creation-Date: 2007-10-05 22:30+0200\n"
-"PO-Revision-Date: 2007-10-05 22:32+0200\n"
+"POT-Creation-Date: 2007-10-19 21:43+0200\n"
+"PO-Revision-Date: 2007-10-20 15:24+0200\n"
"Last-Translator: Christian Stimming <stimming@tuhh.de>\n"
"Language-Team: German \n"
"MIME-Version: 1.0\n"
@@ -108,9 +108,9 @@ msgstr "zusammenführen"
msgid "message"
msgstr "Beschreibung (Meldung?, Nachricht?; Source Safe: Kommentar)"
-#. ""
+#. "Deletes all stale tracking branches under <name>. These stale branches have already been removed from the remote repository referenced by <name>, but are still locally available in 'remotes/<name>'."
msgid "prune"
-msgstr "löschen"
+msgstr "entfernen"
#. "Pulling a branch means to fetch it and merge it."
msgid "pull"
@@ -118,12 +118,16 @@ msgstr "übernehmen (ziehen?)"
#. "Pushing a branch means to get the branch's head ref from a remote repository, and ... (well, can someone please explain it for mere mortals?)"
msgid "push"
-msgstr "ausliefern (hochladen? verschicken? schieben?)"
+msgstr "versenden (ausliefern? hochladen? verschicken? schieben?)"
#. ""
msgid "redo"
msgstr "wiederholen"
+#. "An other repository ('remote'). One might have a set of remotes whose branches one tracks."
+msgid "remote"
+msgstr "Andere Archive (Gegenseite?, Entfernte?, Server?)"
+
#. "A collection of refs (?) together with an object database containing all objects which are reachable from the refs... (oops, you've lost me here. Again, please an explanation for mere mortals?)"
msgid "repository"
msgstr "Projektarchiv"
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* Re: Fourth incarnation of the msysGit herald
From: Jan Hudec @ 2007-10-20 13:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: msysgit, git
In-Reply-To: <Pine.LNX.4.64.0710200024460.25221@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]
On Sat, Oct 20, 2007 at 00:25:49 +0100, Johannes Schindelin wrote:
> git gui
> =======
>
> git gui is a really nice program, and as I often said, I consider it
> more porcelain than a gui, since it uses the git core directly, instead
> of wrapping around porcelain commands.
>
> The user experience I had with git gui made me think that this should
> be the primary interface Windows users should be confronted with, not
> the command line.
>
> The major problem we had in msysGit is that git-gui was to be launched
> from the Start Menu, or a QuickLaunch icon. This is in contrast to
> the shell, where you usually start git gui in a working directory.
It would be nice to install an entry in the explorer menu to run git-gui in
a selected directory. It can be done by just writing something like to the
registry (completely untested -- I just looked it up on the internet):
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell\Git Gui]
@="Git Gui"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell\Git Gui\command]
@="git --git-dir=%L gui"
(The directory is passed in %L, but git --git-gui="dir" gui seems to work, at
least on Linux. It needs absolute path, but you'll have that.)
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* How can I access remote branches in a cloned repository on my local machine?
From: Erich Ocean @ 2007-10-20 13:15 UTC (permalink / raw)
To: git
Our developer group has a shared git repository at git@git.
1kstudios.lan:dev.
Each developer has established their own local repository by running:
git clone git@git.1kstudios.lan:dev
git config remote.origin.push master:refs/remotes/<username>/master
Each developer then does a `git pull` to update their master branch,
merges their changes from their local topic branches, and then does
`git push` to make the results available at git@git.1kstudios.lan:dev.
As the integrator, I have then been ssh'ing into the git@git.
1kstudios.lan machine, cd'ing to "dev" and doing:
git merge <username>/master
to incorporate their changes after running `git diff` to see what the
changes are.
My own development repository is set up identically to the other
developers.
What I would like to do now is clone the git@git.1kstudios.lan:dev
repository on my local machine a second time, checkout a <username>/
master branch in that repository, and then use BBEdit's graphical
diff to visually see the changes between my own repository and what
another developer has pushed to the shared repository. I'll then
merge them into my own developer repository and push that to the
shared repository for the rest of the developers to pull from, so no
longer will I merge by ssh'ing into the machine with the shared
repository.
The problem is, when I clone git@git.1kstudios.lan:dev, the various
<username>/master's aren't there. I have tried a bunch of different
ways, but they all give me errors. For example:
> logan-2:~ ocean$ git clone git@git.1kstudios.lan:dev commiters
> Initialized empty Git repository in /Users/ocean/commiters/.git/
> git@git.1kstudios.lan's password:
> remote: Generating pack...
> remote: Done counting 7029 objects.
> remote: Deltifying 7029 objects...
> remote: 100% (7029/7029) done
> Indexing 7029 objects...
> remote: Total 7029 (delta 3334), reused 2456 (delta 1154)
> 100% (7029/7029) done
> Resolving 3334 deltas...
> 100% (3334/3334) done
> Checking 3864 files out...
> 100% (3864/3864) done
> logan-2:~ ocean$ cd commiters
> logan-2:~/commiters ocean$ git branch
> * masterlogan-2:~/commiters ocean$ git checkout -b jchumley/master
jchumley
> git checkout: updating paths is incompatible with switching
branches/forcing
How can I access remote branches in a cloned repository on my local
machine?
Thanks!
Erich
^ permalink raw reply
* Re: On Tabs and Spaces
From: Robin Rosenberg @ 2007-10-20 13:54 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <634393B0-734A-4884-93E3-42F7D3CB157F@mit.edu>
[-- Attachment #1: Type: text/plain, Size: 2947 bytes --]
tisdag 16 oktober 2007 skrev Michael Witten:
> What are the rules about tabs and spaces in source code?
>
> I'm having a terrible time with formatting,
> especially in the perl scripts; there is a
> mix of spaces and tabs.
>
> from what I can deduce, single tabs are used
> to introduce the equivalent of 8 spaces while
> 4 explicit spaces are used for half a tab.
A looong time ago I worked with a system that did not have *this* problem.
The code had a straight left margin. No indent. The code was initially written
just after the origin of time_t (content, not name) and that it was written
on punched cards probably explains the left margin, efter all you can indent
the cards if you like to.
I "accidentally" did indent code once, but only once, since I got a lot of
complains from others about not following coding standards. My solution was
to write a Brief macro to indent the code before working on it and undent
before submitting my work to test. We never had a discussion on tabs vs
spaces.
Btw, some of that code was "logically" indented 22 levels. I'm still amazed
att those long sheets of code people annotated with pencil to discover the
logical structure.
So it is possble to simply not care about tabs and spaces, except where
there is a syntactic difference.
Fast-formward twenty years and back to the topic.
I think it is ok to start or end a *big* series of changes with a re-format
patch, iff the series already introduces a *lot* of changes.
In the previously submitted and rejected patch to cvsexportcommit this
was not the case, I rewrote it heavily and that would have been a window
for for reformatting, but I didn't see a need, probably because I used emacs
and probably the original author too. Now I realize the file *is* actually
indented inconsistently. Add to that that I am responsible for some of it.
Next person to do any major work on it should submit a fix-indentation patch
very much like the one MIchael did. The problem with reviewing such patches
still exists, it is not possible to just read such patches, one has to apply
them and verify them with other tools.
I've been through enough many bracket and indentation discussions to see that
it really doesn't matter as much what style is used as long as the same style
is used throughout a whole source file. There are some coding styles that
works bad with the patch/apply style submitting code, but those are not an
issue here.
As for TAB size. The most authoritative read "stupid") programs on the issue,
i.e. cat (unix) and type (dos/windows) agree that tab stops are located at
every eight position starting (8,16 etc).
Attached is an updated version of a script I've been using lately to clean up
commits. First it only removed trailing whitespace, but after this thread I
changed it to (try to) tabify changes. Should we use such scripts more
actively to root out inconsistencies a patch at a time?
-- robin
[-- Attachment #2: washammend --]
[-- Type: application/x-shellscript, Size: 636 bytes --]
[-- Attachment #3: washtrailing --]
[-- Type: application/x-shellscript, Size: 535 bytes --]
^ permalink raw reply
* Re: How can I access remote branches in a cloned repository on my local machine?
From: Julian Phillips @ 2007-10-20 13:53 UTC (permalink / raw)
To: Erich Ocean; +Cc: git
In-Reply-To: <05B1B470-1C86-40E6-9E33-968809414537@atlasocean.com>
On Sat, 20 Oct 2007, Erich Ocean wrote:
> Our developer group has a shared git repository at git@git.1kstudios.lan:dev.
>
> Each developer has established their own local repository by running:
>
> git clone git@git.1kstudios.lan:dev
> git config remote.origin.push master:refs/remotes/<username>/master
>
> Each developer then does a `git pull` to update their master branch, merges
> their changes from their local topic branches, and then does `git push` to
> make the results available at git@git.1kstudios.lan:dev.
>
> As the integrator, I have then been ssh'ing into the git@git.1kstudios.lan
> machine, cd'ing to "dev" and doing:
>
> git merge <username>/master
>
> to incorporate their changes after running `git diff` to see what the changes
> are.
>
> My own development repository is set up identically to the other developers.
>
> What I would like to do now is clone the git@git.1kstudios.lan:dev repository
> on my local machine a second time, checkout a <username>/master branch in
> that repository, and then use BBEdit's graphical diff to visually see the
> changes between my own repository and what another developer has pushed to
> the shared repository. I'll then merge them into my own developer repository
> and push that to the shared repository for the rest of the developers to pull
> from, so no longer will I merge by ssh'ing into the machine with the shared
> repository.
>
> The problem is, when I clone git@git.1kstudios.lan:dev, the various
> <username>/master's aren't there. I have tried a bunch of different ways, but
> they all give me errors. For example:
The default fetch refspec doesn't include the remotes - after all, you
normally don't want the origin for your origin ...
> How can I access remote branches in a cloned repository on my local machine?
Try something like:
git config remote.origin.fetch +refs/remotes/*:+refs/remotes/*
git fetch
--
Julian
---
No matter how cynical you get, it's impossible to keep up.
^ permalink raw reply
* Re: How can I access remote branches in a cloned repository on my local machine?
From: Julian Phillips @ 2007-10-20 13:56 UTC (permalink / raw)
To: Erich Ocean; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710201449340.8248@beast.quantumfyre.co.uk>
On Sat, 20 Oct 2007, Julian Phillips wrote:
>> The problem is, when I clone git@git.1kstudios.lan:dev, the various
>> <username>/master's aren't there. I have tried a bunch of different ways,
>> but they all give me errors. For example:
>
> The default fetch refspec doesn't include the remotes - after all, you
> normally don't want the origin for your origin ...
>
>> How can I access remote branches in a cloned repository on my local
>> machine?
>
> Try something like:
>
> git config remote.origin.fetch +refs/remotes/*:+refs/remotes/*
sorry, that should have been:
git config remote.origin.fetch +refs/remotes/*:refs/remotes/*
> git fetch
--
Julian
---
"The National Association of Theater Concessionaires reported that in
1986, 60% of all candy sold in movie theaters was sold to Roger Ebert."
-- D. Letterman
^ permalink raw reply
* Re: [PATCH 3/3] git-cvsexportcommit.perl: git-apply no longer needs --binary
From: Robin Rosenberg @ 2007-10-20 13:59 UTC (permalink / raw)
To: Michael Witten; +Cc: Shawn O. Pearce, git
In-Reply-To: <862396DD-A3EA-4850-8AE8-9E765C7FF0F2@MIT.EDU>
onsdag 17 oktober 2007 skrev Michael Witten:
>
> On 16 Oct 2007, at 9:11:48 PM, Shawn O. Pearce wrote:
>
> > Sorry, but I have to say I agree with Robin here. The tab patch
> > is large, ugly, and provides relatively little value in comparsion.
> >
> > The first rule of git development typically is "any change is bad".
> > Because anything that is already written can be assumed to already
> > be tested and in use by someone. Breaking that is bad, as then
> > they have a bad experience with git.
>
> OK. I understand.
>
> This was really preparation for a more substantial addition
> that I hope to make.
That might warrant fixing the tabs, *then*. It is nice to know that this
debate did not scare you awya from submitting patches.
> I'll just have to change one line at a time with every substantial
> patch!
Exactly :)
I wrote some more in a commet on the On tabs and spaces thread.
-- robin
^ permalink raw reply
* Re: How can I access remote branches in a cloned repository on my local machine?
From: Jan Hudec @ 2007-10-20 14:09 UTC (permalink / raw)
To: Erich Ocean; +Cc: git
In-Reply-To: <05B1B470-1C86-40E6-9E33-968809414537@atlasocean.com>
[-- Attachment #1: Type: text/plain, Size: 2851 bytes --]
On Sat, Oct 20, 2007 at 06:15:21 -0700, Erich Ocean wrote:
> Our developer group has a shared git repository at
> git@git.1kstudios.lan:dev.
>
> Each developer has established their own local repository by running:
>
> git clone git@git.1kstudios.lan:dev
> git config remote.origin.push master:refs/remotes/<username>/master
The paths on server are refs/remotes/<userame>/master.
It's more common to publish (push to public or shared repository) to
refs/heads. The refs/remotes namespace is normally only used when fetching.
There's nothing in git saying you can't do it your way, but there are things
that make the common way more convenient.
> Each developer then does a `git pull` to update their master branch, merges
> their changes from their local topic branches, and then does `git push` to
> make the results available at git@git.1kstudios.lan:dev.
>
> As the integrator, I have then been ssh'ing into the git@git.1kstudios.lan
> machine, cd'ing to "dev" and doing:
>
> git merge <username>/master
Yes, because locally refs/remotes is searched when looking for unqualified
ref. But if you checked that out, git would complain it's not a branch and
created a detached head.
> to incorporate their changes after running `git diff` to see what the
> changes are.
>
> My own development repository is set up identically to the other
> developers.
>
> What I would like to do now is clone the git@git.1kstudios.lan:dev
> repository on my local machine a second time, checkout a <username>/master
> branch in that repository, and then use BBEdit's graphical diff to visually
> see the changes between my own repository and what another developer has
> pushed to the shared repository. I'll then merge them into my own developer
> repository and push that to the shared repository for the rest of the
> developers to pull from, so no longer will I merge by ssh'ing into the
> machine with the shared repository.
>
> The problem is, when I clone git@git.1kstudios.lan:dev, the various
> <username>/master's aren't there. I have tried a bunch of different ways,
> but they all give me errors. For example:
By default clone only compies refs from refs/heads to refs/remotes/origin and
from refs/tags to refs/tags.
You have two options here:
- Move the branches on server to refs/heads. Then the various
<username>/master will be visible locally as origin/<username>/master
(qualified names refs/remotes/origin/<username>/master -- you can of
course call the remote differently if you want).
- Add +refs/remotes/*:refs/remotes/origin/* to remote.origin.fetch config
key in your local repository (I am not sure it will work properly with
multiple source patterns with the same destination pattern, though).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [Solved] How can I access remote branches in a cloned repository on my local machine?
From: Erich Ocean @ 2007-10-20 14:18 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0710201455540.8248@beast.quantumfyre.co.uk>
Per Julian Phillips' suggestion:
> logan-2:~ ocean$ cd commiters/
> logan-2:~/commiters ocean$ git config remote.origin.fetch +refs/
remotes/*:refs/remotes/*
> logan-2:~/commiters ocean$ git fetch
> git@git.1kstudios.lan's password:
> * refs/remotes/eocean/master: storing remote branch 'eocean/
master' of git@git.1kstudios.lan:dev
> commit: 06b4b2e
> * refs/remotes/gt/master: storing remote branch 'gt/master' of
git@git.1kstudios.lan:dev
> commit: 889a585
> * refs/remotes/jchumley/master: storing remote branch 'jchumley/
master' of git@git.1kstudios.lan:dev
> commit: 18cead3
> logan-2:~/commiters ocean$ git branch
> +refs/remotes/eocean/master
> +refs/remotes/gt/master
> +refs/remotes/jchumley/master
> * master
> logan-2:~/commiters ocean$ git checkout +refs/remotes/jchumley/
master
> Switched to branch "+refs/remotes/jchumley/master"
Best, Erich
On Oct 20, 2007, at 6:56 AM, Julian Phillips wrote:
> On Sat, 20 Oct 2007, Julian Phillips wrote:
>
>>> The problem is, when I clone git@git.1kstudios.lan:dev, the various
>>> <username>/master's aren't there. I have tried a bunch of
>>> different ways,
>>> but they all give me errors. For example:
>>
>> The default fetch refspec doesn't include the remotes - after all,
>> you normally don't want the origin for your origin ...
>>
>>> How can I access remote branches in a cloned repository on my local
>>> machine?
>>
>> Try something like:
>>
>> git config remote.origin.fetch +refs/remotes/*:+refs/remotes/*
>
> sorry, that should have been:
> git config remote.origin.fetch +refs/remotes/*:refs/remotes/*
>
>> git fetch
>
> --
> Julian
>
> ---
> "The National Association of Theater Concessionaires reported that in
> 1986, 60% of all candy sold in movie theaters was sold to Roger
> Ebert."
> -- D. Letterman
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* git-p4 pull request
From: Simon Hausmann @ 2007-10-20 15:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Chris Pettitt
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
Hi,
The following changes since commit 7840ce6cb24a9d65152d45e08f5d7cf7dc97a2e3:
Shawn O. Pearce (1):
Merge branch 'maint'
are available in the git repository at:
git://repo.or.cz/git/git-p4.git git-p4
Chris Pettitt (1):
git-p4 support for perforce renames.
Simon Hausmann (1):
git-p4: When skipping a patch as part of "git-p4 submit" make sure we
correctly revert to the previous state of the files using "p4 revert".
contrib/fast-import/git-p4 | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
These changes fit nicely into master I would say.
Thanks,
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: gitk patch collection pull request
From: Jan Hudec @ 2007-10-20 15:32 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Paul Mackerras, Shawn O. Pearce, git
In-Reply-To: <B3349B61-995B-42D0-B777-CEA618943848@steelskies.com>
[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]
On Sat, Oct 20, 2007 at 14:00:20 +0100, Jonathan del Strother wrote:
>
> On 20 Oct 2007, at 12:46, Paul Mackerras wrote:
>
>> Jonathan del Strother writes:
>>
>>> In my defense, most of that file is space indented, and the places
>>
>> Only the lines that are indented 1 level start with spaces. Any line
>> that is indented 2 or more levels should start with a tab.
>
>>> It seems to have the whole 'tabs for code
>>> indentation, with space for alignment' rule back-to-front.
>>
>> I don't recall signing up to that rule. :) I use 4-column indentation
>> and 8-column tabs, and my editor (emacs) handles it all automatically
>> for me.
>
>
> Ugh... I don't usually get involved in tab/space wars, but I'm curious...
> why on earth would you choose this style?
Because that's default behaviour of both emacs and vi when you set
indentation different from tabstop. Actually most of GNU software, whether it
uses the GNU standard indent of 2, or more, uses tabs for any indents
over 8. Probably even most unix software uses this.
Actually, even if the indent is 8, function arguments are often aligned under
the open parenthesis and a tabs + spaces combination is normally used for
that as well (because, again, that's what most editors will by default do!).
> With space indentation you can make sure that everyone sees the indentation
> as it was intended. With tab indentation, you save space, add semantic
> meaning, and let people control how wide they want their indents to appear.
> This approach seems to take the worst parts of each and combine them.
> What's the benefit?
Tab stops are every 8 characters. No more, no less. Ever. This makes the text
with whatever formating you want the shortest.
> I appreciate I'm not going to convert you - this is an honest question.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH-resent] gitk: fix in procedure drawcommits
From: Michele Ballabio @ 2007-10-20 16:02 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Shawn O. Pearce, pdmef
In-Reply-To: <18201.54648.707559.480169@cargo.ozlabs.ibm.com>
[Rocco Rutte added on CC:, since he wrote the hg-fast-export scripts]
On Saturday 20 October 2007, Paul Mackerras wrote:
> Well no. I'd rather understand why this is happening, in case the
> error indicates that I'm not handling a corner case correctly. Can
> you make a copy of the repo that triggers the bug available to me?
IIRC, I just cloned mutt's hg repo:
hg clone http://dev.mutt.org/hg/mutt
then imported it in git with the scripts at
http://repo.or.cz/w/fast-export.git
with
hg-fast-export.sh -r ../mutt
After that, I've done the usual maintenance repack.
Then, running gitk and keeping pressed pgdown triggers that
"Error: can't unset..."
window.
Uh-oh. I think I just found the issue. That's probably a bug
somewhere in the import (either fast-export or fast-import or
the original repo, I don't know), so I'm not sure if gitk
should be patched, but since the resulting repo seems correct
as far as git is concerned (i.e. git fsck --full --strict
doesn't complain), I guess something should be done.
Here is the culprit (or so I think). One of the guilty commits is:
commit a3b4383d69e0754346578c85ba8ff7c05bd88705
tree 1bf99cd22abe97c59f8c0b7ad6b8244f0854b8af
parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
author Brendan Cully <brendan@kublai.com> 1179646159 -0700
committer Brendan Cully <brendan@kublai.com> 1179646159 -0700
Forget SMTP password if authentication fails.
Thanks to Gregory Shapiro for the initial patch (I've moved the reset
from smtp_auth_sasl up to smtp_auth, and used the account API
instead of twiddling account bits by hand). Closes #2872.
This commit (and many others) has two parents, but the two parents
have the same hash. So gitk tries to unset the same variable twice,
hence the error. At this point, the fix for gitk should be either to
check if the parents have the same hash when reading the commit or
avoiding to unset two times the same variable.
This explanation makes sense to me, now the problem is: have I messed
up the import myself, the scripts/commands used are to blame, or is
it entirely the original repo's fault?
Since I've redone the import and the error remains, I guess
that's not my fault :)
^ permalink raw reply
* RE: git push bug?
From: Joakim Tjernlund @ 2007-10-20 17:38 UTC (permalink / raw)
To: spearce, 'Steffen Prohaska'; +Cc: 'git'
In-Reply-To: <20071019002451.GQ14735@spearce.org>
> -----Original Message-----
> From: spearce@spearce.org [mailto:spearce@spearce.org]
> Sent: den 19 oktober 2007 02:25
> To: Steffen Prohaska
> Cc: joakim.tjernlund@transmode.se; git
> Subject: Re: git push bug?
>
> Steffen Prohaska <prohaska@zib.de> wrote:
> > On Oct 18, 2007, at 4:50 PM, Joakim Tjernlund wrote:
> > >
> > ># > git push ssh://devsrv/var/git/os2kernel.git linus:refs/linus
> ...
> > >error: refusing to create funny ref 'refs/linus' locally
> > >ng refs/linus funny refname
> > >error: failed to push to 'ssh://devsrv/var/git/os2kernel.git'
> ...
> > You may need to cleanup though. I'm not sure if the remote side
> > already created 'refs/linus'. The error message only indicates that
> > locally git refused to create the "funny refname".
>
> Cute. The error message "error: refusing to create .. locally"
> is actually coming from the remote site. Locally here is
> actually remotely. We *really* should change that. Its l.169 of
> receive-pack.c, which is only running on the remote side. :)
>
> Anyone game to improve that error message? Should be a pretty
> simple patch. One of the may low-hanging fruits in Git.
Just gave it a try, using git sendmail. Hopefully it will
reach the list :)
^ permalink raw reply
* RE: [PATCH] Fix receive-pack error msg.
From: Joakim Tjernlund @ 2007-10-20 17:44 UTC (permalink / raw)
To: git
In-Reply-To: <1192901822-20431-1-git-send-email-Joakim.Tjernlund@transmode.se>
ehh, git sendmail didn't send the whole commit msg, just the subject.
Trying again.
> -----Original Message-----
> From: Joackim Tjernlund [mailto:jocke@gentoo-jocke]
> Sent: den 20 oktober 2007 19:37
> To: git@vger.kernel.org
> Cc: Joakim Tjernlund
> Subject: [PATCH] Fix receive-pack error msg.
>
>
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> ---
> receive-pack.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/receive-pack.c b/receive-pack.c
> index d3c422b..1521d0b 100644
> --- a/receive-pack.c
> +++ b/receive-pack.c
> @@ -166,7 +166,7 @@ static const char *update(struct command *cmd)
> struct ref_lock *lock;
>
> if (!prefixcmp(name, "refs/") && check_ref_format(name + 5)) {
> - error("refusing to create funny ref '%s'
> locally", name);
> + error("refusing to create funny ref '%s'
> remotely", name);
> return "funny refname";
> }
>
> --
> 1.5.3.4
>
>
^ permalink raw reply
* Re: [msysGit] Re: Fourth incarnation of the msysGit herald
From: Steffen Prohaska @ 2007-10-20 18:04 UTC (permalink / raw)
To: Jan Hudec; +Cc: Johannes Schindelin, msysgit, git
In-Reply-To: <20071020133359.GB19521@efreet.light.src>
On Oct 20, 2007, at 3:33 PM, Jan Hudec wrote:
> On Sat, Oct 20, 2007 at 00:25:49 +0100, Johannes Schindelin wrote:
>> git gui
>> =======
>>
>> git gui is a really nice program, and as I often said, I consider it
>> more porcelain than a gui, since it uses the git core directly,
>> instead
>> of wrapping around porcelain commands.
>>
>> The user experience I had with git gui made me think that this should
>> be the primary interface Windows users should be confronted with, not
>> the command line.
>>
>> The major problem we had in msysGit is that git-gui was to be
>> launched
>> from the Start Menu, or a QuickLaunch icon. This is in contrast to
>> the shell, where you usually start git gui in a working directory.
>
> It would be nice to install an entry in the explorer menu to run
> git-gui in
> a selected directory. It can be done by just writing something like
> to the
> registry (completely untested -- I just looked it up on the internet):
What you propose is already there!
Did you try the most recent setup?
http://msysgit.googlecode.com/files/Git-1.5.3-preview20071019.exe
Steffen
^ permalink raw reply
* Re: [msysGit] Re: Fourth incarnation of the msysGit herald
From: Jan Hudec @ 2007-10-20 18:19 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Schindelin, msysgit, git
In-Reply-To: <A24982F6-40B2-4897-904E-99A135EC9D41@zib.de>
[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]
On Sat, Oct 20, 2007 at 20:04:20 +0200, Steffen Prohaska wrote:
>
> On Oct 20, 2007, at 3:33 PM, Jan Hudec wrote:
>
>> On Sat, Oct 20, 2007 at 00:25:49 +0100, Johannes Schindelin wrote:
>>> git gui
>>> =======
>>>
>>> git gui is a really nice program, and as I often said, I consider it
>>> more porcelain than a gui, since it uses the git core directly, instead
>>> of wrapping around porcelain commands.
>>>
>>> The user experience I had with git gui made me think that this should
>>> be the primary interface Windows users should be confronted with, not
>>> the command line.
>>>
>>> The major problem we had in msysGit is that git-gui was to be launched
>>> from the Start Menu, or a QuickLaunch icon. This is in contrast to
>>> the shell, where you usually start git gui in a working directory.
>>
>> It would be nice to install an entry in the explorer menu to run git-gui
>> in
>> a selected directory. It can be done by just writing something like to the
>> registry (completely untested -- I just looked it up on the internet):
>
> What you propose is already there!
Nice. Thanks. Unfortunately I didn't yet have time to try out, and I didn't
see it mentioned.
> Did you try the most recent setup?
>
> http://msysgit.googlecode.com/files/Git-1.5.3-preview20071019.exe
No; I don't have loosedows here (at home), so I'll have to try it at work
when I have a little time. I certainly will.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 09/14] Use the asyncronous function infrastructure in builtin-fetch-pack.c.
From: Johannes Sixt @ 2007-10-20 18:22 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
In-Reply-To: <20071020025352.GA6569@spearce.org>
On Saturday 20 October 2007 04:53, Shawn O. Pearce wrote:
> > diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
> > index 871b704..51d8a32 100644
> > --- a/builtin-fetch-pack.c
> > +++ b/builtin-fetch-pack.c
> > @@ -457,42 +457,37 @@ static int everything_local(struct ref **refs, int
> > nr_match, char **match) return retval;
> > }
> >
> > -static pid_t setup_sideband(int fd[2], int xd[2])
> > +static int sideband_demux(int fd, void *data)
> > {
> > - pid_t side_pid;
> > + int *xd = data;
> >
> > + close(xd[1]);
>
> If this is a threaded start_async() system this close is going
> to impact the caller.
Yes, I noticed this, too. I think that a solution calls for a member .in of
struct async analogous to .in of struct child_process.
How do we continue from here? Could you park the series in pu so that I don't
have to resend if it turns out that the fix is just another followup patch
(which is how I'd prefer to solve the issue)? Then I tell you no or go after
I have it tested on mingw.git.
-- Hannes
^ permalink raw reply
* Re: [PATCH-resent] gitk: fix in procedure drawcommits
From: Jan Hudec @ 2007-10-20 18:35 UTC (permalink / raw)
To: Michele Ballabio; +Cc: Paul Mackerras, git, Shawn O. Pearce, pdmef
In-Reply-To: <200710201802.48111.barra_cuda@katamail.com>
[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]
On Sat, Oct 20, 2007 at 18:02:47 +0200, Michele Ballabio wrote:
> IIRC, I just cloned mutt's hg repo:
> hg clone http://dev.mutt.org/hg/mutt
> then imported it in git with the scripts at
> http://repo.or.cz/w/fast-export.git
> with
> hg-fast-export.sh -r ../mutt
> [...]
>
> Here is the culprit (or so I think). One of the guilty commits is:
>
> commit a3b4383d69e0754346578c85ba8ff7c05bd88705
> tree 1bf99cd22abe97c59f8c0b7ad6b8244f0854b8af
> parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
> parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
> author Brendan Cully <brendan@kublai.com> 1179646159 -0700
> committer Brendan Cully <brendan@kublai.com> 1179646159 -0700
>
> Forget SMTP password if authentication fails.
> Thanks to Gregory Shapiro for the initial patch (I've moved the reset
> from smtp_auth_sasl up to smtp_auth, and used the account API
> instead of twiddling account bits by hand). Closes #2872.
Judging from the symptoms, I would suspect hg-fast-export. Either mercurial
sometimes stores two same hashes instead of the hash and 0 (in which case
hg-fast-import should probably be ready to deal with it), or hg-fast-import
does something wrong when it sees the 0 parent.
> This commit (and many others) has two parents, but the two parents
> have the same hash. So gitk tries to unset the same variable twice,
> hence the error. At this point, the fix for gitk should be either to
> check if the parents have the same hash when reading the commit or
> avoiding to unset two times the same variable.
>
> This explanation makes sense to me, now the problem is: have I messed
> up the import myself, the scripts/commands used are to blame, or is
> it entirely the original repo's fault?
>
> Since I've redone the import and the error remains, I guess
> that's not my fault :)
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Allow gitk to start on Cygwin with native Win32 Tcl/Tk
From: Mark Levedahl @ 2007-10-20 18:47 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <18201.59649.800748.780690@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Shawn O. Pearce writes:
>
>
>> Yes, I admit this is an odd patch. I can certainly carry it in
>> my own tree (I already carry some other patches) but I wonder if
>> we shouldn't include it as some users may actually try to do this,
>> just like I did. Latest git-gui `master` already has changes to its
>> Makefile and shell startup boilerplate to handle this weird case.
>>
>
> Why do you need to change gitk itself? If you're going to modify it
> with sed, why can't you change the $0 on the 3rd line to the installed
> path of the gitk script?
>
>
While gitk is most likely installed as /usr/bin/gitk in Cygwin's
filespace, that could resolve to anything in the Windows file system. It
might be c:\cygwin\usr\bin\gitk, but could also be "d:\Documents and
Settings\Bill\Programs\cygwin\usr\bin\gitk" depending upon who installed
it and with what options. Both are seen as /usr/bin/gitk by Cygwin.
Thus, Shawn is correct in using cygpath to resolve the name.
Also, as Cygwin's tcl/tk package is bound to the port of the insight
debugger to Cygwin, and that project is stuck for years on 8.4.1, this
patch (or something like it) may be the only way to allow gitk to access
a more recent version on Cygwin in the foreseeable future. So, I think
this is a good idea.
Mark
^ permalink raw reply
* [PATCH] Mention split command in git-add manpage
From: Bram Schoenmakers @ 2007-10-20 19:15 UTC (permalink / raw)
To: git, gitster
Hello,
A little patch for the git-add manpage which mentions the 's' option for
splitting hunks in git-add -i mode.
---
Documentation/git-add.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 2fe7355..032957a 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -210,6 +210,7 @@ patch::
k - do not decide on this hunk now, and view the previous
undecided hunk
K - do not decide on this hunk now, and view the previous hunk
+ s - split large hunks at context lines in the middle
+
After deciding the fate for all hunks, if there is any hunk
that was chosen, the index is updated with the selected hunks.
--
1.5.2.5
Kind regards,
--
Bram Schoenmakers
You can contact me directly on ICQ with #153817629
^ permalink raw reply related
* Re: [PATCH] Deduce exec_path also from calls to git with a relative path
From: Johannes Schindelin @ 2007-10-20 21:31 UTC (permalink / raw)
To: Scott R Parish; +Cc: git, spearce, gitster
In-Reply-To: <1192868006.v2.fusewebmail-240137@f>
Hi,
On Sat, 20 Oct 2007, Scott R Parish wrote:
> Wow, that sure cleaned up nicely! :)
Heh.
BTW I did not mean to discourage you... Rather, I wanted to show you that
this list is a wonderful place to learn, as I did, do, and will do many
times here. (Just to clarify, since somebody said that I am usually not
nice to newbies... cannot understand that at all ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: Announcement of Git wikibook
From: Johannes Schindelin @ 2007-10-20 21:34 UTC (permalink / raw)
To: Ciprian Dorin Craciun; +Cc: Steffen Prohaska, Evan Carroll, git
In-Reply-To: <8e04b5820710200040q76301c58j33e5d0895956b150@mail.gmail.com>
Hi,
[please do not top post]
On Sat, 20 Oct 2007, Ciprian Dorin Craciun wrote:
> There is nothing wrong with either of the two approaches. They
> could both coexist but address different needs:
> -- the manual should be more oriented on technical issues and
> addresses only the most recent versions;
The problem: it is not just "the manual". It is the "user manual".
> -- the book should be more user-oriented, and more general,
> explaining how source management should be addressed by using git, and
> maybe make comparisons with may other versioning systems. Also the
> book could relate to many versions -- both old and new.
>
> Also I would note that the wiki book is more easy to edit... If
> you spot errors or want to add something you just go and edit it and
> the effect is immediate. But in contrast sending patches involves some
> overhead...
I am torn. On one side I like the Wiki approach. On the other hand, the
Wiki will get less review by git oldtimers, whereas the patches to
user-manual are usually reviewed as thoroughly as the code patches.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Jari Aalto @ 2007-10-20 22:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710202126430.25221@racer.site>
* Sat 2007-10-20 Johannes Schindelin <Johannes.Schindelin@gmx.de> INBOX
> Hi,
>
> On Sat, 20 Oct 2007, Jari Aalto wrote:
>
>> - commented out call to list_common_cmds_help()
>
> If you're really sure that this is desired, do not comment it out. Delete
> it.
I'm sure.
There is no point of reminding *every* time you make a typo during
writing the commands. It fills half of the screen and obscures the
previous commands that were running. It's much more polite and elegant
in shorted form.
Jari
New patch follows.
--
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply
* [PATCH] Fix diffcore-break total breakage
From: Linus Torvalds @ 2007-10-20 19:31 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano, Shawn O. Pearce
Ok, so on the kernel list, some people noticed that "git log --follow"
doesn't work too well with some files in the x86 merge, because a lot of
files got renamed in very special ways.
In particular, there was a pattern of doing single commits with renames
that looked basically like
- rename "filename.h" -> "filename_64.h"
- create new "filename.c" that includes "filename_32.h" or
"filename_64.h" depending on whether we're 32-bit or 64-bit.
which was preparatory for smushing the two trees together.
Now, there's two issues here:
- "filename.c" *remained*. Yes, it was a rename, but there was a new file
created with the old name in the same commit. This was important,
because we wanted each commit to compile properly, so that it was
bisectable, so splitting the rename into one commit and the "create
helper file" into another was *not* an option.
So we need to break associations where the contents change too much.
Fine. We have the -B flag for that. When we break things up, then the
rename detection will be able to figure out whether there are better
alternatives.
- "git log --follow" didn't with with -B.
Now, the second case was really simple: we use a different "diffopt"
structure for the rename detection than the basic one (which we use for
showing the diffs). So that second case is trivially fixed by a trivial
one-liner that just copies the break_opt values from the "real" diffopts
to the one used for rename following. So now "git log -B --follow" works
fine:
diff --git a/tree-diff.c b/tree-diff.c
index 26bdbdd..7c261fd 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -319,6 +319,7 @@ static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, co
diff_opts.detect_rename = DIFF_DETECT_RENAME;
diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT;
diff_opts.single_follow = opt->paths[0];
+ diff_opts.break_opt = opt->break_opt;
paths[0] = NULL;
diff_tree_setup_paths(paths, &diff_opts);
if (diff_setup_done(&diff_opts) < 0)
however, the end result does *not* work. Because our diffcore-break.c
logic is totally bogus!
In particular:
- it used to do
if (base_size < MINIMUM_BREAK_SIZE)
return 0; /* we do not break too small filepair */
which basically says "don't bother to break small files". But that
"base_size" is the *smaller* of the two sizes, which means that if some
large file was rewritten into one that just includes another file, we
would look at the (small) result, and decide that it's smaller than the
break size, so it cannot be worth it to break it up! Even if the other
side was ten times bigger and looked *nothing* like the samell file!
That's clearly bogus. I replaced "base_size" with "max_size", so that
we compare the *bigger* of the filepair with the break size.
- It calculated a "merge_score", which was the score needed to merge it
back together if nothing else wanted it. But even if it was *so*
different that we would never want to merge it back, we wouldn't
consider it a break! That makes no sense. So I added
if (*merge_score_p > break_score)
return 1;
to make it clear that if we wouldn't want to merge it at the end, it
was *definitely* a break.
- It compared the whole "extent of damage", counting all inserts and
deletes, but it based this score on the "base_size", and generated the
damage score with
delta_size = src_removed + literal_added;
damage_score = delta_size * MAX_SCORE / base_size;
but that makes no sense either, since quite often, this will result in
a number that is *bigger* than MAX_SCORE! Why? Because base_size is
(again) the smaller of the two files we compare, and when you start out
from a small file and add a lot (or start out from a large file and
remove a lot), the base_size is going to be much smaller than the
damage!
Again, the fix was to replace "base_size" with "max_size", at which
point the damage actually becomes a sane percentage of the whole.
With these changes in place, not only does "git log -B --follow" work for
the case that triggered this in the first place, ie now
git log -B --follow arch/x86/kernel/vmlinux_64.lds.S
actually gives reasonable resulys. But I also wanted to verify it in
general, by doing a full-history
git log --stat -B -C
on my kernel tree with the old code and the new code.
There's some tweaking to be done, but generally, the new code generates
much better results wrt breaking up files (and then finding better rename
candidates). Here's a few examples of the "--stat" output:
- This:
include/asm-x86/Kbuild | 2 -
include/asm-x86/debugreg.h | 79 +++++++++++++++++++++++++++++++++++------
include/asm-x86/debugreg_32.h | 64 ---------------------------------
include/asm-x86/debugreg_64.h | 65 ---------------------------------
4 files changed, 68 insertions(+), 142 deletions(-)
Becomes:
include/asm-x86/Kbuild | 2 -
include/asm-x86/{debugreg_64.h => debugreg.h} | 9 +++-
include/asm-x86/debugreg_32.h | 64 -------------------------
3 files changed, 7 insertions(+), 68 deletions(-)
- This:
include/asm-x86/bug.h | 41 +++++++++++++++++++++++++++++++++++++++--
include/asm-x86/bug_32.h | 37 -------------------------------------
include/asm-x86/bug_64.h | 34 ----------------------------------
3 files changed, 39 insertions(+), 73 deletions(-)
Becomes
include/asm-x86/{bug_64.h => bug.h} | 20 +++++++++++++-----
include/asm-x86/bug_32.h | 37 -----------------------------------
2 files changed, 14 insertions(+), 43 deletions(-)
Now, in some other cases, it does actually turn a rename into a real
"delete+create" pair, and then the diff is usually bigger, so truth in
advertizing: it doesn't always generate a nicer diff. But for what -B was
meant for, I think this is a big improvement, and I suspect those cases
where it generates a bigger diff are tweakable.
So I think this diff fixes a real bug, but we might still want to tweak
the default values and perhaps the exact rules for when a break happens.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
Hmm? At least the "should_break()" tests seem to make some amount of sense
now, I think.
Linus
----
diffcore-break.c | 11 +++++++----
tree-diff.c | 1 +
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/diffcore-break.c b/diffcore-break.c
index ae8a7d0..c71a226 100644
--- a/diffcore-break.c
+++ b/diffcore-break.c
@@ -45,8 +45,8 @@ static int should_break(struct diff_filespec *src,
* The value we return is 1 if we want the pair to be broken,
* or 0 if we do not.
*/
- unsigned long delta_size, base_size, src_copied, literal_added,
- src_removed;
+ unsigned long delta_size, base_size, max_size;
+ unsigned long src_copied, literal_added, src_removed;
*merge_score_p = 0; /* assume no deletion --- "do not break"
* is the default.
@@ -63,7 +63,8 @@ static int should_break(struct diff_filespec *src,
return 0; /* error but caught downstream */
base_size = ((src->size < dst->size) ? src->size : dst->size);
- if (base_size < MINIMUM_BREAK_SIZE)
+ max_size = ((src->size > dst->size) ? src->size : dst->size);
+ if (max_size < MINIMUM_BREAK_SIZE)
return 0; /* we do not break too small filepair */
if (diffcore_count_changes(src, dst,
@@ -89,12 +90,14 @@ static int should_break(struct diff_filespec *src,
* less than the minimum, after rename/copy runs.
*/
*merge_score_p = (int)(src_removed * MAX_SCORE / src->size);
+ if (*merge_score_p > break_score)
+ return 1;
/* Extent of damage, which counts both inserts and
* deletes.
*/
delta_size = src_removed + literal_added;
- if (delta_size * MAX_SCORE / base_size < break_score)
+ if (delta_size * MAX_SCORE / max_size < break_score)
return 0;
/* If you removed a lot without adding new material, that is
diff --git a/tree-diff.c b/tree-diff.c
index 26bdbdd..7c261fd 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -319,6 +319,7 @@ static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, co
diff_opts.detect_rename = DIFF_DETECT_RENAME;
diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT;
diff_opts.single_follow = opt->paths[0];
+ diff_opts.break_opt = opt->break_opt;
paths[0] = NULL;
diff_tree_setup_paths(paths, &diff_opts);
if (diff_setup_done(&diff_opts) < 0)
^ permalink raw reply related
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