* 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
* 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: 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: 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: 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
* 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: 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
* 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
* [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: gitk patch collection pull request
From: Jonathan del Strother @ 2007-10-20 13:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Shawn O. Pearce, git
In-Reply-To: <18201.60047.898077.579869@cargo.ozlabs.ibm.com>
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?
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?
I appreciate I'm not going to convert you - this is an honest question.
^ permalink raw reply
* Re: [PATCH] Deduce exec_path also from calls to git with a relative path
From: David Brown @ 2007-10-20 12:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Scott R Parish, git, spearce, gitster
In-Reply-To: <Pine.LNX.4.64.0710200818410.25221@racer.site>
On Sat, Oct 20, 2007 at 08:21:34AM +0100, Johannes Schindelin wrote:
>For example, when you call "../../hello/world/git", it will not turn
>"../../hello/world" into an absolute path, and use that.
Did you mean "it will turn..."?
David
^ permalink raw reply
* Re: git push bug?
From: Jan Hudec @ 2007-10-20 12:05 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: 'Johannes Schindelin', 'Steffen Prohaska',
'git'
In-Reply-To: <000001c81280$ebc5c5e0$5267a8c0@Jocke>
[-- Attachment #1: Type: text/plain, Size: 2743 bytes --]
On Fri, Oct 19, 2007 at 20:50:29 +0200, Joakim Tjernlund wrote:
> On den 19 oktober 2007 19:25, Johannes Schindelin [mailto:Johannes.Schindelin@gmx.de] wrote:
> > It strikes me as really odd that you would _want_ to create a branch
> > remotely, that has _never_ existed locally.
> It strikes me as really odd that a core developers like yourself
> hasn't tried to justify/explain why push works as it does.
Dscho it rarely kind to newbies.
> As I am trying to convince our dev. group here to move to git instead of subversion, I
> need to learn how git works. Now I have gotten to the push function and I need
> to know what can be done with push and how, pitfalls too. As I go along I find behavior
> that I find odd and report these to the list.
>
> git push <repo> v2.6.23:refs/heads/linus
> will make a tag look like a branch
That's becasue tags come in two flavors -- annotated and unannotated.
Annotated ones don't point to commits directly, but via 'tag' objects, that
contain description and usually signature.
Now git push will simply assign a remote branch whatever value you give it.
You gave it a tag, so it assigned a tag.
> git push <repo> linus:linus
> won't let me create the remote branch linus but
> git push <repo> linus
> will
Because in the former you are not saying whether refs/heads/linus,
refs/tags/linus or something else (the fact that heads and tags are treated
specially by git does not mean refs can't have other subdirectories -- it
can).
On the other hand in the later it resolves the ref locally and uses the same
name remotedly.
> git push <repo> :linus
> OOPS, now I just deleted remote branch linus, no warning
Your commands are quite obvious. No need for warning. (Besides, isn't there
a reflog?)
> git push <repo> linus:refs/head/linus
> creates a branch that is invisible(wont show in git branch -a)
It does not create a branch. It creates a ref with slightly funny name (it's
refs/heads, not refs/head).
^
> git push <repo> linus:refs/heads/newbranch
> creates remote branch newbranch, but you have to know the magic words
> refs/heads/ to do it.
Because you could have wanted a tag. Or a remote. Or something completely
different, maybe because some add-on uses (eg. stgit uses refs/bases and
refs/patches, IIRC).
> Se what I mean?
To me it all looks perfectly consistent. But maybe the documentation should
state more clearly, that push works in terms of arbitrary refs, NOT branches.
Feel free to post a documentation patch (people who just had hard time
finding something out are usually better at explaining it than old-timers who
consider it obvious).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: git push bug?
From: Joakim Tjernlund @ 2007-10-20 11:52 UTC (permalink / raw)
To: 'Steffen Prohaska', 'Johannes Schindelin'; +Cc: 'git'
In-Reply-To: <5513C211-DE33-411C-8EE6-2259B41DC3EA@zib.de>
> -----Original Message-----
> From: Steffen Prohaska [mailto:prohaska@zib.de]
> Sent: den 20 oktober 2007 10:30
> To: Johannes Schindelin
> Cc: Joakim Tjernlund; git
> Subject: Re: git push bug?
>
>
> On Oct 18, 2007, at 11:58 PM, Johannes Schindelin wrote:
>
> >
> > On Thu, 18 Oct 2007, Steffen Prohaska wrote:
> >
> >> On Oct 18, 2007, at 6:21 PM, Johannes Schindelin wrote:
> >>
> >>> On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
> >>>
> >>>> Seems like it is a bit too easy to make mistakes here.
> Why can I
> >>>> delete
> >>>> a branch with :linus but not create one with linus:linus?
> >>>
> >>> I wonder why you bother with the colon at all. Just
> >>>
> >>> git push <remote> linus
> >>>
> >>> and be done with it. The colon is only there to play
> interesting
> >>> games,
> >>> not something as simple as "push this branch" or "push this tag".
> >>
> >> But you need a full refspec starting with 'refs/heads/' if you
> >> want to
> >> create a new branch on the remote side.
> >
> > No. Not if the name is the same on the local side.
>
> You're right. The documentation of git-send-pack says what you're
> saying:
>
> '''
> When one or more <ref> are specified explicitly, it can be either a
> single pattern, or a pair of such pattern separated by a colon
> ":" (this means that a ref name cannot have a colon in it). A single
> pattern <name> is just a shorthand for <name>:<name>
> '''
>
> Here it says that <name> is a shorthand for <name>:<name>.
> An later it states
>
> '''
> If <dst> does not match any remote ref, either
> * it has to start with "refs/"; <dst> is used as the destination
> literally in this case.
> * <src> == <dst> and the ref that matched the <src> must not
> exist in the set of remote refs; the ref matched <src> locally is
> used as the name of the destination.
> '''
>
> If <src> == <dst> then <dst> will be created even if it didn't exist.
>
> I think the current implementation though is a bit different.
> It will created a new branch for a colon-less refspec, that is
>
> git push origin work/topic
>
> will create a new ref on the remote. But
>
> git push origin work/topic:work/topic
>
> will _not_.
>
>
> Until you corrected me, I believed that new branches will never
> be created on the remote side unless a full ref is used. That is
> I expected that only
>
> git push origin refs/heads/work/topic
>
> would work.
>
> I thought this would be another safety net -- kind of a reminder
> not to push the wrong branch by accident.
>
> I still like the idea, but apparently git didn't ever support what
> I thought it would.
>
> Maybe adding some command line flags making the different tasks
> explicit could help:
>
> git push --create origin work/new-topic
> git push --delete origin work/old-topic
> git push --non-standard origin refs/funny/ref
This makes much more sense than the current method, thanks.
Jocke
^ permalink raw reply
* Re: gitk patch collection pull request
From: Paul Mackerras @ 2007-10-20 11:46 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Shawn O. Pearce, git
In-Reply-To: <531A500E-667F-413C-BD20-D23DC817EB72@steelskies.com>
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.
> that are tab indented are generally totally broken unless you have an
> 8 char tab width.
So set your tabs to 8 spaces when looking at it. :)
> 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.
Paul.
^ permalink raw reply
* Re: [PATCH] Allow gitk to start on Cygwin with native Win32 Tcl/Tk
From: Paul Mackerras @ 2007-10-20 11:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20070922050446.GA28467@spearce.org>
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?
Paul.
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-20 11:29 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Federico Mena Quintero, Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <DE4FB702-24E8-421F-8447-04A5C7F7B5D2@zib.de>
Steffen Prohaska wrote:
>
> On Oct 20, 2007, at 10:03 AM, Andreas Ericsson wrote:
>
>>
>> Personally, I can't help but think that the numerous times I've heard "oh
>> gods, that's a lot of commands" should finally mean something. I've
>> started
>> taking a look at which of them one can bundle together. If we can drop
>> the
>> porcelainish commands down to ~30 or so, and hide the plumbing from
>> git-<tab>
>> listings, the initial hurdle people have to jump would be
>> significantly lower.
>
> Maybe we could group commands into more categories?
>
> plumbing: should be hidden from the 'normal' user. Porcelain
> should be sufficient for every standard task.
>
Agreed. /usr/libexec/git/ seems to me to be the ideal spot for
it.
> core porcelain: this is what everyone needs who works in a
> pure git based workflow based on push/pull. You can't use
> git without these commands. But these commands are already
> sufficient to solve most of your tasks.
>
Agreed.
> mail porcelain: the list will probably hate me for this, but
> I think all commands needed to create and send patches per
> mail are not essential. I suspect that I'll _never_ ask
> my colleagues at work to send me a patch by mail. They'll
> always push it to a shared repo.
>
Disagreed, for obvious reasons. Many OSS projects are patch-centric
and developed much like git. OTOH, having to run "git format-patch"
rather than "git-format-patch" probably isn't so hampering that we
can't live with it.
> import/export: Many commands are only used for importing
> from or exporting to other version control systems. Examples
> are git-cvs*, git-svn*. They are not needed once you switched
> to git.
>
But very nifty for incremental imports. I track several CVS repos
that I continuously import. They're also self-explanatory, so
they don't add much to the clutter. Same reasons as above though;
there's no real reason not to invoke them as "git cvsimport" rather
than "git-cvsimport".
> admin: Some commands are not used in a typical workflow. For
> example git-filter-branch or git-fsck have a more admin
> flavor.
>
git-filter-branch could definitely live its life hidden somewhere.
git-fsck probably should stay with the plumbing, as it's used by
other porcelainish programs more often than run directly by the
user.
> There might be more categories. I am not sure because there
> a quite a few commands that I _never_ used and have no clear
> idea about what they do.
>
>
> So here are a few questions:
>
> Could we find a small set of core porcelain commands that
> completely cover a typical workflow? The core section of the
> manual should only refer to those commands. Absolutely no
> plumbing should be needed to tweak things. In principle, a
> typical user should be able to work if _all other_ commands
> except for core porcelain are hidden from his PATH.
>
Note that this is already possible, using a libexec-dir and
passing --exec-dir to the git wrapper. The only thing that isn't
done is deciding what's *definitely* plumbing. Once that's defined,
the makefile can install plumbing to a separate directory and
the /usr/bin/git-<tab> should shrink by roughly half.
> Another section in the manual should describe a workflow based
> on sending patches around. Obviously the mail porcelain is
> needed for this.
>
> ... and so forth.
>
> I don't know if we really want to hide the commands from PATH.
> But maybe we should consider grouping them into subdirectories,
> or provide another way to for the user to focus on the core
> porcelain.
>
Hiding the really core plumbing and getting rid of redundant
programs (git-am, git-apply, git-applypatch, ...) would do wonders,
methinks.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Announcement of Git wikibook
From: Wincent Colaiuta @ 2007-10-20 11:20 UTC (permalink / raw)
To: Ciprian Dorin Craciun; +Cc: Steffen Prohaska, Evan Carroll, git
In-Reply-To: <8e04b5820710200040q76301c58j33e5d0895956b150@mail.gmail.com>
El 20/10/2007, a las 9:40, Ciprian Dorin Craciun escribió:
> 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 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...
But Git already has its own easy-to-edit, official wiki:
http://git.or.cz/gitwiki
Creating a separate wiki book seems like an unnecessary duplication
of effort.
(Obviously, you or anybody else is free to contribute documentation
wherever you want.)
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] gitk: add check for required tcl version >= 8.4
From: Paul Mackerras @ 2007-10-20 11:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Steffen Prohaska
In-Reply-To: <7vlkaplsu1.fsf@gitster.siamese.dyndns.org>
Junio C Hamano writes:
> From: Steffen Prohaska <prohaska@zib.de>
> Date: Fri, 28 Sep 2007 22:57:22 +0200
>
> gitk requires tcl version >= 8.4 to work flawlessly. So let's
> check the tcl version and quit if it's too low.
>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> ---
>
> * I do not have a ready access to older tcl/tk myself, so I
> cannot judge if this is sensible or not. Just forwarding in
> case you missed it.
Thanks for the patch. I have put in something similar using the
package require command, and using show_error to display the error in
a window.
Paul.
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Wincent Colaiuta @ 2007-10-20 11:15 UTC (permalink / raw)
To: Michael Witten; +Cc: Shawn O. Pearce, git
In-Reply-To: <8D972813-2D7F-4D6A-958F-B76E947E7BC3@MIT.EDU>
El 20/10/2007, a las 8:45, Michael Witten escribió:
> On 20 Oct 2007, at 2:36:28 AM, Shawn O. Pearce wrote:
>
>> Today I move the file, then unstage the hunks I'm not sure about,
>> then go back and restage them. Annoying. It really disrupts
>> my workflow.
>
> I know it's against policy, but the proposed change should be set
> as the default at some point, in my opinion.
I think the issue here is that git-mv as it is currently implemented
really conflates two things:
1. Renaming a file in the traditional "mv" sense
2. Staging the entire contents of the file in the index, ready or not
So it's kind of like the command were called git-mv-and-add or git-
rename-and-add. And given that the index as a staging area is such a
central content in Git, users often want to have more control over
what gets added to the index than that; ie. "I really just wanted to
rename the file, and leave the staging of modifications to the
content up to me".
Cheers,
Wincent
^ permalink raw reply
* Re: gitk patch collection pull request
From: Jonathan del Strother @ 2007-10-20 11:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Shawn O. Pearce, git
In-Reply-To: <18200.36704.936554.220173@cargo.ozlabs.ibm.com>
On 19 Oct 2007, at 12:05, Paul Mackerras wrote:
> Shawn O. Pearce writes:
>
>> The following changes since commit
>> 719c2b9d926bf2be4879015e3620d27d32f007b6:
>> Paul Mackerras (1):
>> gitk: Fix bug causing undefined variable error when cherry-
>> picking
>>
>> are available in the git repository at:
>>
>> git://repo.or.cz:/git/spearce.git gitk
>
> OK, but ...
>
>> Jonathan del Strother (2):
>> gitk: Added support for OS X mouse wheel
>> Fixing gitk indentation
>
> This one is bogus. Firstly, it doesn't have "gitk:" at the start of
> the headline (and "Fixing" should be "Fix"). Secondly, the actual
> change itself is bogus. It changes an initial tab to 8 spaces on each
> of 4 lines. I like it the way it is - and if he wanted to change it,
> he should have changed it throughout the file, not just on 4 lines.
> So that change is rejected.
In my defense, most of that file is space indented, and the places
that are tab indented are generally totally broken unless you have an
8 char tab width. It seems to have the whole 'tabs for code
indentation, with space for alignment' rule back-to-front. I can't
follow the logic of that, so didn't feel comfortable changing the
whole file. I probably shouldn't have submitted the second patch - I
initially fixed the weird indentation in my first patch, just so my if-
block didn't look totally weird, but then was told that ought to be 2
separate patches.
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Jeff King @ 2007-10-20 11:06 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Ari Entlich, Michael Witten, git
In-Reply-To: <B6FFD723-83FF-459B-AD00-89DD2A3113DB@wincent.com>
On Sat, Oct 20, 2007 at 01:02:32PM +0200, Wincent Colaiuta wrote:
> Whoops. I think I just inadvertently proposed a feature... my most common
> use of "git-add --interactive" is when I want to stage only specific hunks
> of a particular file, and so instead of typing "git add bar" I want to type
> "git add -i bar" and have it jump straight to the "patch" subcommand (5) for
> that file. Would anyone else find this useful?
Yes, my only use of git-add --interactive is to stage particular patches
from individual files. So I would find that feature useful.
-Peff
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: Wincent Colaiuta @ 2007-10-20 11:02 UTC (permalink / raw)
To: Ari Entlich; +Cc: Michael Witten, Jeff King, git
In-Reply-To: <1192859753.13347.147.camel@g4mdd.entnet>
El 20/10/2007, a las 7:55, Ari Entlich escribió:
>> I'm thinking of occasions where you just want to do something
>> like:
>>
>> git mv --cached foo bar
>> git add --interactive bar
>
> I think it would be the other way around, since the only time this
> change would effect anything is when there are changes still
> waiting to
> be staged.
Well, my point was that sometimes you want to rename a dirty file
*right now* without having your modifications staged in the index
yet, and only later go ahead and stage the hunks (or the whole file)
when they're ready.
Basically, without this feature you have to manually unstage the
stuff that you don't want staged:
[hack on dirty foo]
git mv foo bar
[oops... you just staged unfinished changes]
git reset HEAD bar
[hack until bar is ready]
git add bar
So in order to unstage the stuff that wasn't ready you unstaged the
whole file and had to re-add it later, in which case what was the
point of using "git-mv" in the first place? You may as well have just
done:
[hack on dirty foo]
mv foo bar
[hack until bar is ready]
git rm foo
git add bar
The other alternative is to use git-stash:
[hack on dirty foo]
git stash
git mv foo bar
git stash apply
[hack until bar is ready]
git add bar
So, yes, you can do this with git-stash. It just means that "git-mv --
cached" would be a convenient short-cut.
> Are you talking about REALLY only changing the index?
No, sorry, I didn't make that clear. I meant that "git mv --cached
foo bar" would have the following effect (which if I understand it
correctly is basically what you proposed in your first email):
1. Copying "foo" directly to "bar" (even if dirty).
2. When adding "bar" to the the index add the blob corresponding to
"foo" as it is staged in the index (or at the HEAD if there are no
staged changes).
3. Removing the old file "foo".
The actual mechanics of this don't matter; those are just the
perceived effects. You could get exactly the same perceived effects
by doing it this way:
1. Creating a new file (or overwriting an existing one) named "bar",
whose contents would match those of the file "foo" not as it appears
in the working tree but as it is staged in the index.
2. If "foo" has unstaged changes, they should be applied to "bar" as
well (but not staged).
3. Removing the old file "foo".
> In addition, I don't think giving
> --interactive a filename is meaningful...
Whoops. I think I just inadvertently proposed a feature... my most
common use of "git-add --interactive" is when I want to stage only
specific hunks of a particular file, and so instead of typing "git
add bar" I want to type "git add -i bar" and have it jump straight to
the "patch" subcommand (5) for that file. Would anyone else find this
useful?
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH-resent] gitk: fix in procedure drawcommits
From: Paul Mackerras @ 2007-10-20 10:16 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git, Shawn O. Pearce
In-Reply-To: <200710191544.22228.barra_cuda@katamail.com>
Michele Ballabio writes:
> This patch indroduces a check before unsetting an array element.
introduces
> There's an error that seems to occur in gitk only on
> mutt's imported repo, but I don't know why. This is
> hopefully the right fix.
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?
Paul.
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Steffen Prohaska @ 2007-10-20 10:19 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Federico Mena Quintero, Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <4719B655.90204@op5.se>
On Oct 20, 2007, at 10:03 AM, Andreas Ericsson wrote:
>
> Personally, I can't help but think that the numerous times I've
> heard "oh
> gods, that's a lot of commands" should finally mean something. I've
> started
> taking a look at which of them one can bundle together. If we can
> drop the
> porcelainish commands down to ~30 or so, and hide the plumbing from
> git-<tab>
> listings, the initial hurdle people have to jump would be
> significantly lower.
Maybe we could group commands into more categories?
plumbing: should be hidden from the 'normal' user. Porcelain
should be sufficient for every standard task.
core porcelain: this is what everyone needs who works in a
pure git based workflow based on push/pull. You can't use
git without these commands. But these commands are already
sufficient to solve most of your tasks.
mail porcelain: the list will probably hate me for this, but
I think all commands needed to create and send patches per
mail are not essential. I suspect that I'll _never_ ask
my colleagues at work to send me a patch by mail. They'll
always push it to a shared repo.
import/export: Many commands are only used for importing
from or exporting to other version control systems. Examples
are git-cvs*, git-svn*. They are not needed once you switched
to git.
admin: Some commands are not used in a typical workflow. For
example git-filter-branch or git-fsck have a more admin
flavor.
There might be more categories. I am not sure because there
a quite a few commands that I _never_ used and have no clear
idea about what they do.
So here are a few questions:
Could we find a small set of core porcelain commands that
completely cover a typical workflow? The core section of the
manual should only refer to those commands. Absolutely no
plumbing should be needed to tweak things. In principle, a
typical user should be able to work if _all other_ commands
except for core porcelain are hidden from his PATH.
Another section in the manual should describe a workflow based
on sending patches around. Obviously the mail porcelain is
needed for this.
... and so forth.
I don't know if we really want to hide the commands from PATH.
But maybe we should consider grouping them into subdirectories,
or provide another way to for the user to focus on the core
porcelain.
Steffen
^ permalink raw reply
* Re: git push bug?
From: Steffen Prohaska @ 2007-10-20 8:38 UTC (permalink / raw)
To: Shawn O. Pearce, Lars Hjemli, Johannes Schindelin
Cc: Joakim Tjernlund, Git Mailing List
In-Reply-To: <5513C211-DE33-411C-8EE6-2259B41DC3EA@zib.de>
Shawn,
sp/push-refspec definitely needs more work (see below).
On Oct 20, 2007, at 10:29 AM, Steffen Prohaska wrote:
>
> On Oct 18, 2007, at 11:58 PM, Johannes Schindelin wrote:
>
>>
>> On Thu, 18 Oct 2007, Steffen Prohaska wrote:
>>>
>>> But you need a full refspec starting with 'refs/heads/' if you
>>> want to
>>> create a new branch on the remote side.
>>
>> No. Not if the name is the same on the local side.
>
> You're right. The documentation of git-send-pack says what you're
> saying:
>
> [...]
>
> Until you corrected me, I believed that new branches will never
> be created on the remote side unless a full ref is used. That is
> I expected that only
>
> git push origin refs/heads/work/topic
>
> would work.
>
> I thought this would be another safety net -- kind of a reminder
> not to push the wrong branch by accident.
>
> I still like the idea, but apparently git didn't ever support what
> I thought it would.
And I even fixed the behavior to match my expectation in a patch
which made it to spearce/pu:
d869233c62688742968663c4e8b5ff20a50a5011
push, send-pack: fix test if remote branch exists for colon-less
refspec
A push must fail if the remote ref does not yet exist and the
refspec
does not start with refs/. Remote refs must explicitly be
created with
their full name.
This commit adds some tests and fixes the existence check in
send-pack.
sp/push-refspec definitely needs some more work.
Steffen
^ 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