* Re: Proposal: sharing .git/config
From: Jeff King @ 2013-02-19 15:36 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Ramkumar Ramachandra, Git List
In-Reply-To: <CACsJy8Ch70gZMkT7ScY3R-FNQU4QjtUe8UhoGRzE27cH9mu0HA@mail.gmail.com>
On Tue, Feb 19, 2013 at 05:34:43PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra
> <artagnon@gmail.com> wrote:
> > Hi,
> >
> > I have this itch where I want to share my remotes config between
> > machines. In my fork, I should be able to specify where my upstream
> > sources are, so remotes get set up automatically when I clone. There
> > are also other things in .git/config that would be nice to share, like
> > whether to do a --word-diff (why isn't it a configuration variable
> > yet?) on the repository. The only problem is that I have no clue how
> > to implement this: I'm currently thinking a special remote ref?
>
> If you check out the config file, then include.path should work. You
> could add include.ref to point to a ref, but you need to deal with the
> attached security implications. This has been proposed before (and
> turned down, I think).
Here's the patch:
http://article.gmane.org/gmane.comp.version-control.git/189144
The basic argument against it is that you would _not_ want to do:
$ git config include.ref origin/config
because it's unsafe (you immediately start using config fetched from the
remote, before you even get a chance to inspect it). So the recommended
way to use it is:
$ git config include.ref config
$ git show origin/config ;# make sure it looks reasonable
$ git update-ref refs/config origin/config
[time passes...]
$ git fetch
$ git diff config origin/config ;# inspect changes
$ git update-ref refs/config origin/config
But it was pointed out that you could also just do:
$ git config include.ref upstream-config
$ git show origin/config ;# make sure it looks reasonable
$ git show origin/config >.git/upstream-config
and so forth. There are some ways that a pure ref can be more
convenient (e.g., if you are carrying local changes on top of the
upstream config and want to merge), but ultimately, you can replicate
any include.ref workflow with include.path by adding a "deploy" step
where you copy the file into $GIT_DIR.
-Peff
^ permalink raw reply
* Re: Git Merge 2013 Conference, Berlin
From: Michael J Gruber @ 2013-02-19 15:41 UTC (permalink / raw)
Cc: Scott Chacon, Jeff King, Thomas Rast, git list
In-Reply-To: <51239840.9080605@drmicha.warpmail.net>
Michael J Gruber venit, vidit, dixit 19.02.2013 16:20:
> Scott Chacon venit, vidit, dixit 18.02.2013 22:29:
>> Right now we have:
>>
>> Dev day: 50
>> User day: 295
>> Hack day: 200
>>
>> I'm not sure what the actual turnout will be, but it looks like it's
>> going to be pretty massive. I wanted to go through the Dev day
>> signups and figure out if everyone really belongs there (is an actual
>> contributor to a core git project) but it's basically on the honor
>> system now.
>>
>> If anyone on this list that should be there (Junio, Shawn, etc) wants
>> to attend and would like sponsorship for the flight/lodging, please
>> let me know. We would love to have as many of the core people there
>> as possible. I will also try to record everything and summarize as
>> much as I can after the fact, so if you can't attend it should still
>> be possible to get the general idea of what occurred and was
>> discussed.
>>
>> I'm going to try doing something similar in the SF area in maybe 6-8
>> months from this, assuming it's a success.
>>
>> Scott
>>
>> On Mon, Feb 18, 2013 at 1:17 PM, Jeff King <peff@peff.net> wrote:
>>> On Mon, Feb 18, 2013 at 09:52:34PM +0100, Thomas Rast wrote:
>>>
>>>> Scott Chacon <schacon@gmail.com> writes:
>>>>
>>>>> We're starting off in Berlin, May 9-11th. GitHub has secured
>>>>> conference space at the Radisson Blu Berlin for those days. I have a
>>>>> smaller room for the first day so we can get 30-40 Git implementors
>>>>> together to talk about the future of Git and whatnot.
>>>> [...]
>>>>> http://git-merge.com/
>>>>
>>>> So this has been fairly quiet -- is anyone else coming? :-)
>>>
>>> I am. I think Scott may have actual numbers, but my third-hand
>>> impression was that there have been a lot of signups.
>>>
>>> -Peff
>
> Well, all days are listed as "sold out" on the eventbrite site. Maybe
> it's because eventbrite has "trouble connecting to facebook" because I
> "don't have facebook"?
>
> I do plan to come (unless I'm out due to lack of an eventbrite ticket)
> but will stay with family rather than at the Radisson Blu.
>
> Michael
>
BTW: Is it OK to add that event as an "event" on our Git community page?
Just wanted to ask Scott and Junio before doing it myself.
Michael
^ permalink raw reply
* Re: Git Merge 2013 Conference, Berlin
From: Scott Chacon @ 2013-02-19 15:46 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jeff King, Thomas Rast, git list
In-Reply-To: <51239D45.3000501@drmicha.warpmail.net>
Hey,
On Tue, Feb 19, 2013 at 7:41 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Michael J Gruber venit, vidit, dixit 19.02.2013 16:20:
>> Well, all days are listed as "sold out" on the eventbrite site. Maybe
>> it's because eventbrite has "trouble connecting to facebook" because I
>> "don't have facebook"?
No, it's because 300 people signed up and that's all the venue has
room for. I'm sure we can fit one more if you come.
>>
>> I do plan to come (unless I'm out due to lack of an eventbrite ticket)
>> but will stay with family rather than at the Radisson Blu.
>>
> BTW: Is it OK to add that event as an "event" on our Git community page?
> Just wanted to ask Scott and Junio before doing it myself.
Yes, this is fine.
Scott
^ permalink raw reply
* Can git restrict source files ?
From: Juan Pablo @ 2013-02-19 16:06 UTC (permalink / raw)
To: git@vger.kernel.org
Hi,
I have a question, can i control the access to specific files or folders ?? I need that some developers can't see some source files, thank you very much for your time
Enviado desde mi iPhone
^ permalink raw reply
* Re: Can git restrict source files ?
From: Matthieu Moy @ 2013-02-19 16:17 UTC (permalink / raw)
To: Juan Pablo; +Cc: git@vger.kernel.org
In-Reply-To: <DE551AEA-5C7D-4A2D-8AB4-33195EF351F8@gmail.com>
Juan Pablo <juanpablo8517@gmail.com> writes:
> Hi,
>
> I have a question, can i control the access to specific files or
> folders ?? I need that some developers can't see some source files,
> thank you very much for your time
No, you can't. You can use e.g. gitolite to set up access control for a
branch, but Git needs access to the complete tree.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] shell-prompt: clean up nested if-then
From: Junio C Hamano @ 2013-02-19 16:28 UTC (permalink / raw)
To: Simon Oosthoek
Cc: Martin Erik Werner, Jonathan Nieder, git, trsten,
Felipe Contreras
In-Reply-To: <5123350D.4010802@xs4all.nl>
Simon Oosthoek <s.oosthoek@xs4all.nl> writes:
> I suppose it would be fine if a patch was sent to update the entire
> git-prompt.sh code to be more in line with the Git shell script style...
Please don't. We do not want a "style conversion" for the sole
purpose of conversion, especially when a subsystem is already
internally consistent.
Besides, the git-prompt.sh thing needs to be fairly bash specific so
the usual "Git Porcelain scripts targetted for POSIX/Bourne shells"
rules does not apply there.
> My original gripe was just with doing it in one place while leaving all
> the others unchanged. It makes for messy reading and leads to confusion.
Yes, it is always preferred to match the _local_ convention.
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Junio C Hamano @ 2013-02-19 16:29 UTC (permalink / raw)
To: Thomas Rast
Cc: Ramkumar Ramachandra, Jonathan Nieder, Matthieu Moy, Jeff King,
git, Shawn Pearce, Jakub Narebski, Christian Couder, Pat Thoyts,
Paul Mackerras, Carlos Martín Nieto, Thomas Gummerer,
David Barr, Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <874nh8vgoo.fsf@pctrast.inf.ethz.ch>
Thomas Rast <trast@inf.ethz.ch> writes:
> In defense of Thomas, whose project was mentioned earlier as a prime
> example of something that is "too big":
>
> He's in fact still working on the index-API angle, as part of a thesis
> at university.
That is probably a good indicator that it was too big for a summer
student. It also is good to hear that the topic is being looked at
;-).
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Junio C Hamano @ 2013-02-19 16:32 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Matthieu Moy, Jeff King, Thomas Rast, git, Shawn Pearce,
Jakub Narebski, Christian Couder, Pat Thoyts, Paul Mackerras,
Carlos Martín Nieto, Thomas Gummerer, David Barr,
Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <CALkWK0=zpZ25X_jVBoF77E75kmV38VC+nwtQ6MYA9=UO99HqyQ@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
>> I was conflating between people who add "suggested project" and who
>> act as mentors. I do not think mentors are primarily responsible
>> for bad suggested projects.
>
> Why do mentors pick badly sketched-out projects to mentor? They're
> free to pick anything they want/ propose what they want.
I've had an impression that these Wiki entries were written by
people with names of mentors (who are different from the proposers)
already assigned to them, and if an unfortunate student picked an
unrealistic one, these mentor candidates were too nice to push back
and decline, saying "it is unrealistic", leaving the student and
proposal without any mentor.
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Thomas Rast @ 2013-02-19 16:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramkumar Ramachandra, Jonathan Nieder, Matthieu Moy, Jeff King,
git, Shawn Pearce, Jakub Narebski, Christian Couder, Pat Thoyts,
Paul Mackerras, Carlos Martín Nieto, Thomas Gummerer,
David Barr, Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <7vtxp86zcs.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Thomas Rast <trast@inf.ethz.ch> writes:
>
>> In defense of Thomas, whose project was mentioned earlier as a prime
>> example of something that is "too big":
>>
>> He's in fact still working on the index-API angle, as part of a thesis
>> at university.
>
> That is probably a good indicator that it was too big for a summer
> student. It also is good to hear that the topic is being looked at
> ;-).
Not really: the API angle was never part of the proposal. The timeline
was [1 if you have access]:
24/04 - 01/05: Document the new index format.
02/05 - 11/05: Create a converter of the old index format to the new format.
12/05 - 18/06: Parse the index from disk to the current in-memory format. The
old index format shall still be readable.
19/06 - 09/07: Implement the re-reading of a single record, if the crc32 doesn't
match (Meaning the record has been changed under the reader).
10/07 - 21/07: Map the current internal structure to the new index format.
22/07 - 31/07: Change the current in-memory structure to keep track of the
changed files.
01/08 - 13/08: Write the index to disk in both the old and the new format
depending on the choice of the user and make sure only the changed parts are
really written to disk in the new format.
11/08 - 13/08: Test the new index and profile the gains compared to the old
format.
/* Development work will be a bit slower from 18/06 to 21/07 because at my
* University there are exams in this period. I probably will only be able to
* work half the hours. I'll be back up to full speed after that. */
I think this case is somewhat symptomatic for one possible cause of
dragged-out non-inclusions _after_ GSoC: there's a certain scope creep
caused by striving for the perfect, long-term maintainable code.
The solution IMHO is to _both_ recognize such possibilities for scope
creep, and cut down the proposals to a size where a student has a
reasonable chance of achieving the code quality required for inclusion.
(The latter option has been mentioned a few times, but I wanted to make
people aware that the scope creep is happening, too.)
Footnotes:
[1] http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/tgummerer/1
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCHv2] l10n: de.po: translate 35 new messages
From: Ralf Thielow @ 2013-02-19 16:55 UTC (permalink / raw)
To: trast, git; +Cc: jk, stimming, git, Ralf Thielow
In-Reply-To: <1361211754-5641-1-git-send-email-ralf.thielow@gmail.com>
Translate 35 new messages came from git.pot update
in 9caaf23 (l10n: Update git.pot (35 new, 14 removed
messages)).
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Acked-by: Thomas Rast <trast@inf.ethz.ch>
---
Thanks Thomas and Michael for review.
po/de.po | 142 +++++++++++++++++++++++++++++++--------------------------------
1 file changed, 69 insertions(+), 73 deletions(-)
diff --git a/po/de.po b/po/de.po
index df98a0f..cd2d116 100644
--- a/po/de.po
+++ b/po/de.po
@@ -358,14 +358,14 @@ msgid "gpg failed to sign the data"
msgstr "gpg beim Signieren der Daten fehlgeschlagen"
#: gpg-interface.c:112
-#, fuzzy, c-format
+#, c-format
msgid "could not create temporary file '%s': %s"
-msgstr "konnte Datei '%s' nicht erstellen"
+msgstr "konnte temporäre Datei '%s' nicht erstellen: %s"
#: gpg-interface.c:115
-#, fuzzy, c-format
+#, c-format
msgid "failed writing detached signature to '%s': %s"
-msgstr "Fehler beim Erstellen des Pfades '%s'%s"
+msgstr "Fehler beim Schreiben der Signatur nach '%s': %s"
#: grep.c:1622
#, c-format
@@ -1440,12 +1440,11 @@ msgstr ", hinterher "
#: compat/precompose_utf8.c:58 builtin/clone.c:341
#, c-format
msgid "failed to unlink '%s'"
-msgstr "Konnte '%s' nicht entfernen"
+msgstr "Konnte '%s' nicht entfernen."
#: builtin/add.c:20
-#, fuzzy
msgid "git add [options] [--] <pathspec>..."
-msgstr "git add [Optionen] [--] [<Dateimuster>...]"
+msgstr "git add [Optionen] [--] [<Pfadspezifikation>...]"
#: builtin/add.c:63
#, c-format
@@ -1601,6 +1600,21 @@ msgid ""
"With the current Git version, the command is restricted to the current "
"directory."
msgstr ""
+"Das Verhalten von 'git add %s (oder %s)' ohne ein Pfad-Argument von\n"
+"einem Unterverzeichnis aus wird in Git 2.0 geändert und sollte nicht\n"
+"mehr verwendet werden.\n"
+"Um Dateien des gesamten Projektverzeichnisses hinzuzufügen, führen Sie aus:\n"
+"\n"
+" git add %s :/\n"
+" (oder git add %s :/)\n"
+"\n"
+"Zur Einschränkung auf das aktuelle Verzeichnis führen Sie aus:\n"
+"\n"
+" git add %s .\n"
+" (oder git add %s .)\n"
+"\n"
+"Mit der aktuellen Version von Git ist das Kommando auf das aktuelle\n"
+"Verzeichnis beschränkt."
#: builtin/add.c:381
msgid "-A and -u are mutually incompatible"
@@ -2412,16 +2426,16 @@ msgstr "[%d voraus, %d hinterher]"
#: builtin/branch.c:469
msgid " **** invalid ref ****"
-msgstr ""
+msgstr " **** ungültige Referenz ****"
#: builtin/branch.c:560
msgid "(no branch)"
msgstr "(kein Zweig)"
#: builtin/branch.c:593
-#, fuzzy, c-format
+#, c-format
msgid "object '%s' does not point to a commit"
-msgstr "'%s' zeigt auf keine Version"
+msgstr "Objekt '%s' zeigt auf keine Version"
#: builtin/branch.c:625
msgid "some refs could not be read"
@@ -2571,33 +2585,30 @@ msgid "--column and --verbose are incompatible"
msgstr "Die Optionen --column und --verbose sind inkompatibel."
#: builtin/branch.c:845
-#, fuzzy
msgid "branch name required"
-msgstr "Kein Zweigname spezifiziert"
+msgstr "Zweigname erforderlich"
#: builtin/branch.c:860
-#, fuzzy
msgid "Cannot give description to detached HEAD"
-msgstr "Kann Hauptzweig des externen Projektarchivs nicht bestimmen"
+msgstr "zu losgelöster Zweigspitze (HEAD) kann keine Beschreibung hinterlegt werden"
#: builtin/branch.c:865
-#, fuzzy
msgid "cannot edit description of more than one branch"
-msgstr "bearbeitet die Beschreibung für den Zweig"
+msgstr "Beschreibung von mehr als einem Zweig kann nicht bearbeitet werden"
#: builtin/branch.c:872
-#, fuzzy, c-format
+#, c-format
msgid "No commit on branch '%s' yet."
-msgstr "Kein solcher Zweig '%s'"
+msgstr "Noch keine Version in Zweig '%s'."
#: builtin/branch.c:875
-#, fuzzy, c-format
+#, c-format
msgid "No branch named '%s'."
-msgstr "Ungültiger Zweig-Name: '%s'"
+msgstr "Zweig '%s' nicht vorhanden."
#: builtin/branch.c:888
msgid "too many branches for a rename operation"
-msgstr ""
+msgstr "zu viele Zweige für eine Umbenennen-Operation angegeben"
#: builtin/branch.c:893
#, c-format
@@ -2731,28 +2742,24 @@ msgid "suppress progress reporting"
msgstr "unterdrückt Fortschrittsanzeige"
#: builtin/check-ignore.c:151
-#, fuzzy
msgid "cannot specify pathnames with --stdin"
-msgstr "kann -a nicht mit -d benutzen"
+msgstr "Angabe von Pfadnamen kann nicht gemeinsam mit --stdin verwendet werden"
#: builtin/check-ignore.c:154
msgid "-z only makes sense with --stdin"
-msgstr ""
+msgstr "Die Option -z kann nur mit --stdin verwendet werden."
#: builtin/check-ignore.c:156
-#, fuzzy
msgid "no path specified"
-msgstr "kein externes Projektarchiv angegeben"
+msgstr "kein Pfad angegeben"
#: builtin/check-ignore.c:160
-#, fuzzy
msgid "--quiet is only valid with a single pathname"
-msgstr "verwendet [PATCH n/m] auch mit einzelnem Patch"
+msgstr "Die Option --quiet ist nur mit einem einzelnen Pfadnamen gültig."
#: builtin/check-ignore.c:162
-#, fuzzy
msgid "cannot have both --quiet and --verbose"
-msgstr "Kann den aktuellen Zustand der Bereitstellung nicht speichern"
+msgstr "Die Optionen --quiet und --verbose können nicht gemeinsam verwendet werden."
#: builtin/checkout-index.c:126
msgid "git checkout-index [options] [--] [<file>...]"
@@ -3421,14 +3428,12 @@ msgid "--command must be the first argument"
msgstr "Die Option --command muss an erster Stelle stehen."
#: builtin/commit.c:34
-#, fuzzy
msgid "git commit [options] [--] <pathspec>..."
-msgstr "git commit [Optionen] [--] <Dateimuster>..."
+msgstr "git commit [Optionen] [--] <Pfadspezifikation>..."
#: builtin/commit.c:39
-#, fuzzy
msgid "git status [options] [--] <pathspec>..."
-msgstr "git status [Optionen] [--] <Dateimuster>..."
+msgstr "git status [Optionen] [--] <Pfadspezifikation>..."
#: builtin/commit.c:44
msgid ""
@@ -3604,17 +3609,17 @@ msgstr ""
"und versuchen Sie es erneut.\n"
#: builtin/commit.c:735
-#, fuzzy, c-format
+#, c-format
msgid ""
"Please enter the commit message for your changes. Lines starting\n"
"with '%c' will be ignored, and an empty message aborts the commit.\n"
msgstr ""
"Bitte geben Sie eine Versionsbeschreibung für Ihre Änderungen ein. Zeilen,\n"
-"die mit '#' beginnen, werden ignoriert, und eine leere Versionsbeschreibung\n"
+"die mit '%c' beginnen, werden ignoriert, und eine leere Versionsbeschreibung\n"
"bricht die Eintragung ab.\n"
#: builtin/commit.c:740
-#, fuzzy, c-format
+#, c-format
msgid ""
"Please enter the commit message for your changes. Lines starting\n"
"with '%c' will be kept; you may remove them yourself if you want to.\n"
@@ -3622,7 +3627,7 @@ msgid ""
msgstr ""
"Bitte geben Sie eine Versionsbeschreibung für Ihre Änderungen ein. Zeilen, "
"die\n"
-"mit '#' beginnen, werden beibehalten; wenn Sie möchten, können Sie diese "
+"mit '%c' beginnen, werden beibehalten; wenn Sie möchten, können Sie diese "
"entfernen.\n"
"Eine leere Versionsbeschreibung bricht die Eintragung ab.\n"
@@ -4403,9 +4408,8 @@ msgid "deepen history of shallow clone"
msgstr "vertieft die Historie eines flachen Klon"
#: builtin/fetch.c:86
-#, fuzzy
msgid "convert to a complete repository"
-msgstr "um von einem lokalen Projektarchiv zu klonen"
+msgstr "konvertiert zu einem vollständigen Projektarchiv"
#: builtin/fetch.c:88 builtin/log.c:1119
msgid "dir"
@@ -4561,14 +4565,13 @@ msgid "You need to specify a tag name."
msgstr "Sie müssen den Namen der Markierung angeben."
#: builtin/fetch.c:981
-#, fuzzy
msgid "--depth and --unshallow cannot be used together"
-msgstr "Die Optionen -x und -X können nicht gemeinsam verwendet werden."
+msgstr "Die Optionen --depth und --unshallow können nicht gemeinsam verwendet werden."
#: builtin/fetch.c:983
-#, fuzzy
msgid "--unshallow on a complete repository does not make sense"
-msgstr "Die Option --name-only kann nicht verwendet werden."
+msgstr "Die Option --unshallow kann nicht in einem vollständigen Projektarchiv "
+"verwendet werden."
#: builtin/fetch.c:1002
msgid "fetch --all does not take a repository argument"
@@ -6122,7 +6125,7 @@ msgstr ""
"Zusammenführung abzuschließen.\n"
#: builtin/merge.c:788
-#, fuzzy, c-format
+#, c-format
msgid ""
"Please enter a commit message to explain why this merge is necessary,\n"
"especially if it merges an updated upstream into a topic branch.\n"
@@ -6135,7 +6138,7 @@ msgstr ""
"insbesondere wenn es einen aktualisierten, externen Zweig mit einem Thema-"
"Zweig zusammenführt.\n"
"\n"
-"Zeilen beginnend mit '#' werden ignoriert, und eine leere Beschreibung "
+"Zeilen beginnend mit '%c' werden ignoriert, und eine leere Beschreibung "
"bricht die Eintragung ab.\n"
#: builtin/merge.c:812
@@ -6606,9 +6609,8 @@ msgid "unable to start 'show' for object '%s'"
msgstr "konnte 'show' für Objekt '%s' nicht starten"
#: builtin/notes.c:143
-#, fuzzy
msgid "could not read 'show' output"
-msgstr "Konnte '%s' nicht lesen"
+msgstr "Konnte Ausgabe von 'show' nicht lesen."
#: builtin/notes.c:151
#, c-format
@@ -7213,7 +7215,6 @@ msgstr ""
"für weitere Details."
#: builtin/push.c:224
-#, fuzzy
msgid ""
"Updates were rejected because the remote contains work that you do\n"
"not have locally. This is usually caused by another repository pushing\n"
@@ -7221,18 +7222,18 @@ msgid ""
"'git pull') before pushing again.\n"
"See the 'Note about fast-forwards' in 'git push --help' for details."
msgstr ""
-"Aktualisierungen wurden zurückgewiesen, weil die Spitze Ihres aktuellen\n"
-"Zweiges hinter seinem externen Gegenstück zurückgefallen ist. Führen Sie\n"
-"die externen Änderungen zusammen (z.B. 'git pull') bevor Sie erneut\n"
-"versenden.\n"
+"Aktualisierungen wurden zurückgewiesen, weil das Fernarchiv Versionen enthält,\n"
+"die lokal nicht vorhanden sind. Das wird üblicherweise durch das Versenden von\n"
+"Versionen auf dieselbe Referenz von einem anderen Projektarchiv aus verursacht.\n"
+"Vielleicht müssen Sie die externen Änderungen zusammenzuführen (z.B. 'git pull')\n"
+"bevor Sie erneut versenden.\n"
"Siehe auch die Sektion 'Note about fast-forwards' in 'git push --help'\n"
"für weitere Details."
#: builtin/push.c:231
-#, fuzzy
msgid "Updates were rejected because the tag already exists in the remote."
msgstr ""
-"Aktualisierungen wurden zurückgewiesen, weil die Zielreferenz bereits\n"
+"Aktualisierungen wurden zurückgewiesen, weil die Markierung bereits\n"
"im Fernarchiv existiert."
#: builtin/push.c:234
@@ -7241,6 +7242,9 @@ msgid ""
"or update a remote ref to make it point at a non-commit object,\n"
"without using the '--force' option.\n"
msgstr ""
+"Sie können keine externe Referenz aktualisieren, die auf ein Objekt zeigt,\n"
+"das keine Version ist, oder es auf ein solches Objekt zeigen lassen, ohne\n"
+"die Option '--force' zu verwenden.\n"
#: builtin/push.c:294
#, c-format
@@ -7351,9 +7355,8 @@ msgid "prune locally removed refs"
msgstr "entfernt lokal gelöschte Referenzen"
#: builtin/push.c:439
-#, fuzzy
msgid "bypass pre-push hook"
-msgstr "umgeht \"pre-commit hook\""
+msgstr "umgeht \"pre-push hook\""
#: builtin/push.c:448
msgid "--delete is incompatible with --all, --mirror and --tags"
@@ -8536,20 +8539,18 @@ msgid "could not verify the tag '%s'"
msgstr "Konnte Markierung '%s' nicht verifizieren"
#: builtin/tag.c:249
-#, fuzzy, c-format
+#, c-format
msgid ""
"\n"
"Write a tag message\n"
"Lines starting with '%c' will be ignored.\n"
msgstr ""
"\n"
-"#\n"
-"# Geben Sie eine Markierungsbeschreibung ein.\n"
-"# Zeilen, die mit '#' beginnen, werden ignoriert.\n"
-"#\n"
+"Geben Sie eine Markierungsbeschreibung ein.\n"
+"Zeilen, die mit '%c' beginnen, werden ignoriert.\n"
#: builtin/tag.c:253
-#, fuzzy, c-format
+#, c-format
msgid ""
"\n"
"Write a tag message\n"
@@ -8557,11 +8558,9 @@ msgid ""
"want to.\n"
msgstr ""
"\n"
-"#\n"
-"# Geben Sie eine Markierungsbeschreibung ein.\n"
-"# Zeilen, die mit '#' beginnen, werden behalten; Sie dürfen diese\n"
-"# selbst entfernen wenn Sie möchten.\n"
-"#\n"
+"Geben Sie eine Markierungsbeschreibung ein.\n"
+"Zeilen, die mit '%c' beginnen, werden behalten; Sie dürfen diese\n"
+"selbst entfernen wenn Sie möchten.\n"
#: builtin/tag.c:292
msgid "unable to sign the tag"
@@ -8942,7 +8941,6 @@ msgid "Print lines matching a pattern"
msgstr "Stellt Zeilen dar, die einem Muster entsprechen"
#: common-cmds.h:17
-#, fuzzy
msgid "Create an empty Git repository or reinitialize an existing one"
msgstr ""
"Erstellt ein leeres Git-Projektarchiv oder initialisiert ein bestehendes neu"
@@ -9869,14 +9867,12 @@ msgid "blob"
msgstr "Blob"
#: git-submodule.sh:979
-#, fuzzy
msgid "Submodules changed but not updated:"
-msgstr "# Unterprojekte geändert, aber nicht aktualisiert:"
+msgstr "Unterprojekte geändert, aber nicht aktualisiert:"
#: git-submodule.sh:981
-#, fuzzy
msgid "Submodule changes to be committed:"
-msgstr "# Änderungen in Unterprojekt zum Eintragen:"
+msgstr "Änderungen in Unterprojekt zum Eintragen:"
#: git-submodule.sh:1129
#, sh-format
--
1.8.2.rc0.16.g20a599e
^ permalink raw reply related
* Re: [PATCH] Documentation/githooks: Explain pre-rebase parameters
From: Junio C Hamano @ 2013-02-19 17:05 UTC (permalink / raw)
To: Thomas Rast; +Cc: W. Trevor King, Git
In-Reply-To: <878v6ksars.fsf@pctrast.inf.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
>> "$GIT_DIR/hooks/pre-rebase" ${1+"$@"}
> ...
> IIRC this particular usage was designed to suppress warnings about unset
> variables.
This is an old-timer's habit to work around buggy implementations of
Bourne shells where they failed to expand "$@" to nothing when there
is no parameters, feeding a single empty argument to the command.
By explicitly writing ${1+...}, the construct makes sure that when
we have no parameter (i.e. $1 is unset) we do not even look at "$@".
It is equivalent to "$@" in correctly implemented shells.
^ permalink raw reply
* [PATCH] l10n: de.po: translate 5 new messages
From: Ralf Thielow @ 2013-02-19 17:12 UTC (permalink / raw)
To: trast, jk, stimming; +Cc: git, Ralf Thielow
Translate 5 new messages came from git.pot update in 235537a
(l10n: git.pot: v1.8.2 round 3 (5 new)).
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
---
po/de.po | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/po/de.po b/po/de.po
index ed813ef..c0e5398 100644
--- a/po/de.po
+++ b/po/de.po
@@ -731,7 +731,7 @@ msgstr " %s"
#: parse-options.c:548
msgid "-NUM"
-msgstr ""
+msgstr "-NUM"
#: pathspec.c:83
#, c-format
@@ -1271,9 +1271,9 @@ msgstr ""
"wiederherzustellen)"
#: wt-status.c:879 wt-status.c:896
-#, fuzzy, c-format
+#, c-format
msgid "You are currently rebasing branch '%s' on '%s'."
-msgstr "Sie sind gerade beim Neuaufbau."
+msgstr "Sie sind gerade beim Neuaufbau von Zweig '%s' auf '%s'."
#: wt-status.c:884 wt-status.c:901
msgid "You are currently rebasing."
@@ -1300,10 +1300,11 @@ msgid " (all conflicts fixed: run \"git rebase --continue\")"
msgstr " (alle Konflikte behoben: führen Sie \"git rebase --continue\" aus)"
#: wt-status.c:908
-#, fuzzy, c-format
+#, c-format
msgid ""
"You are currently splitting a commit while rebasing branch '%s' on '%s'."
-msgstr "Sie teilen gerade eine Version während eines Neuaufbaus auf."
+msgstr "Sie teilen gerade eine Version auf, während ein Neuaufbau von Zweig "
+"'%s' auf '%s' im Gange ist."
#: wt-status.c:913
msgid "You are currently splitting a commit during a rebase."
@@ -1316,9 +1317,10 @@ msgstr ""
"continue\" aus)"
#: wt-status.c:920
-#, fuzzy, c-format
+#, c-format
msgid "You are currently editing a commit while rebasing branch '%s' on '%s'."
-msgstr "Sie editieren gerade eine Version während eines Neuaufbaus."
+msgstr "Sie editieren gerade eine Version während eines Neuaufbaus von Zweig "
+"'%s' auf '%s'."
#: wt-status.c:925
msgid "You are currently editing a commit during a rebase."
@@ -1345,9 +1347,9 @@ msgid " (all conflicts fixed: run \"git commit\")"
msgstr " (alle Konflikte behoben: führen Sie \"git commit\" aus)"
#: wt-status.c:958
-#, fuzzy, c-format
+#, c-format
msgid "You are currently bisecting branch '%s'."
-msgstr "Sie sind gerade beim Halbieren."
+msgstr "Sie sind gerade beim Halbieren in Zweig '%s'."
#: wt-status.c:962
msgid "You are currently bisecting."
--
1.8.2.rc0.16.g20a599e
^ permalink raw reply related
* Re: [PATCH 1/4] t/t7502: compare entire commit message with what was expected
From: Junio C Hamano @ 2013-02-19 17:24 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Brandon Casey, git
In-Reply-To: <20130219050813.GC19757@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> The downside (not a new problem, but a downside nonetheless) is that
> it means the test doesn't demonstrate what --cleanup=verbatim --status
> will do.
>
> How about something like this?
Can't we be a bit more robust by not using a hardcoded block of
lines as the "expect" string? You could for example use what you
would see in your editor when "git commit" is run without the "-t"
option to form the expected pattern, no?
In any case, I think (1) a test for 'verbatim with status' is worth
doing, and (2) it would be cleaner to do this as a separate step,
perhaps on top of Brandon's 4-patch series.
>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
>
> diff --git i/t/t7502-commit.sh w/t/t7502-commit.sh
> index cbd7a459..64162fce 100755
> --- i/t/t7502-commit.sh
> +++ w/t/t7502-commit.sh
> @@ -180,15 +180,37 @@ test_expect_success 'verbose respects diff config' '
> test_expect_success 'cleanup commit messages (verbatim option,-t)' '
>
> echo >>negative &&
> - { echo;echo "# text";echo; } >expect &&
> - git commit --cleanup=verbatim -t expect -a &&
> - git cat-file -p HEAD |sed -e "1,/^\$/d" |head -n 3 >actual &&
> + {
> + echo &&
> + echo "# text" &&
> + echo
> + } >template &&
> + {
> + cat template &&
> + cat <<-\EOF &&
> +
> + # Please enter the commit message for your changes. Lines starting
> + # with '\''#'\'' will be kept; you may remove them yourself if you want to.
> + # An empty message aborts the commit.
> + #
> + # Author: A U Thor <author@example.com>
> + #
> + EOF
> + git commit -a --dry-run
> + } >expect &&
> + git commit --cleanup=verbatim -t template -a &&
> + git cat-file -p HEAD |sed -e "1,/^\$/d" >actual &&
> test_cmp expect actual
>
> '
>
> test_expect_success 'cleanup commit messages (verbatim option,-F)' '
>
> + {
> + echo &&
> + echo "# text" &&
> + echo
> + } >expect &&
> echo >>negative &&
> git commit --cleanup=verbatim -F expect -a &&
> git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
^ permalink raw reply
* Re: [PATCH 4/4] Documentation/git-commit.txt: correct a few minor grammatical mistakes
From: Junio C Hamano @ 2013-02-19 17:33 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Brandon Casey, git, Ralf Thielow
In-Reply-To: <20130219072924.GJ19757@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Brandon Casey wrote:
>
>> Hmm, I think the original text was more confusing than I realized. I
>> think we should reorder the cleanup modes, placing "default" last, and
>> then describe default in terms of either strip or whitespace depending
>> on whether an editor will be spawned.
>
> Sounds good to me. :)
Will take 1-3 of the series for now, as the above seems to indicate
that I'll see a quick reroll of 4/4.
Thanks both for patches and review.
^ permalink raw reply
* Re: [PATCH 1/2] t0008: document test_expect_success_multi
From: Junio C Hamano @ 2013-02-19 17:37 UTC (permalink / raw)
To: Adam Spiers; +Cc: git list, Zoltan Klinger
In-Reply-To: <1361282783-1413-1-git-send-email-git@adamspiers.org>
Adam Spiers <git@adamspiers.org> writes:
> test_expect_success_multi() helper function warrants some explanation,
> since at first sight it may seem like generic test framework plumbing,
> but is in fact specific to testing check-ignore, and allows more
> thorough testing of the various output formats without significantly
> increase the size of t0008.
>
> Signed-off-by: Adam Spiers <git@adamspiers.org>
> ---
Good. I vaguely recall saying why I hate these mini-frameworks
invented in individual tests, but with comments like this, they
become much more palatable.
Thanks.
> t/t0008-ignores.sh | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
> index d7df719..ebe7c70 100755
> --- a/t/t0008-ignores.sh
> +++ b/t/t0008-ignores.sh
> @@ -75,6 +75,16 @@ test_check_ignore () {
> stderr_empty_on_success "$expect_code"
> }
>
> +# Runs the same code with 3 different levels of output verbosity,
> +# expecting success each time. Takes advantage of the fact that
> +# check-ignore --verbose output is the same as normal output except
> +# for the extra first column.
> +#
> +# Arguments:
> +# - (optional) prereqs for this test, e.g. 'SYMLINKS'
> +# - test name
> +# - output to expect from -v / --verbose mode
> +# - code to run (should invoke test_check_ignore)
> test_expect_success_multi () {
> prereq=
> if test $# -eq 4
^ permalink raw reply
* Re: [PATCH 2/2] check-ignore.c: fix segfault with '.' argument from repo root
From: Junio C Hamano @ 2013-02-19 17:54 UTC (permalink / raw)
To: Adam Spiers; +Cc: git list, Zoltan Klinger
In-Reply-To: <1361282783-1413-2-git-send-email-git@adamspiers.org>
Adam Spiers <git@adamspiers.org> writes:
> Fix a corner case where check-ignore would segfault when run with the
> '.' argument from the top level of a repository, due to prefix_path()
> converting '.' into the empty string. It doesn't make much sense to
> call check-ignore from the top level with '.' as a parameter, since
> the top-level directory would never typically be ignored, but of
> course it should not segfault in this case.
>
> Signed-off-by: Adam Spiers <git@adamspiers.org>
> ---
Please step back a bit and explain why the original had check for
path[0] in the first place?
If the answer is "the code wanted to special case the question 'is
the top-level excluded?', but used a wrong variable to implement the
check, and this patch is a fix to that", then the proposed commit
log message looks incomplete. The cause of the segv is not that
prefix_path() returns an empty string, but because the function
called inside the "if" block was written without expecting to be fed
the path that refers to the top-level of the working tree, no?
While this change certainly will prevent the "check the top-level"
request to last-exclude-matching-path, I have to wonder if it is a
good idea to force the caller of the l-e-m-p function to even care.
In other words, would it be a cleaner approach to fix the l-e-m-p
function so that the caller can ask "check the top-level" and give a
sensible answer (perhaps the answer may be "nothing matches"), and
remove the "&& path[0]" (or "&& full_path[0]") special case from
this call site?
The last sentence "It doesn't make much sense..." in the proposed
log message would become a good justification for such a special
case at the beginning of l-e-m-p function, I would think.
> builtin/check-ignore.c | 2 +-
> t/t0008-ignores.sh | 5 +++++
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/check-ignore.c b/builtin/check-ignore.c
> index 709535c..b0dd7c2 100644
> --- a/builtin/check-ignore.c
> +++ b/builtin/check-ignore.c
> @@ -89,7 +89,7 @@ static int check_ignore(const char *prefix, const char **pathspec)
> ? strlen(prefix) : 0, path);
> full_path = check_path_for_gitlink(full_path);
> die_if_path_beyond_symlink(full_path, prefix);
> - if (!seen[i] && path[0]) {
> + if (!seen[i] && full_path[0]) {
> exclude = last_exclude_matching_path(&check, full_path,
> -1, &dtype);
> if (exclude) {
> diff --git a/t/t0008-ignores.sh b/t/t0008-ignores.sh
> index ebe7c70..9c1bde1 100755
> --- a/t/t0008-ignores.sh
> +++ b/t/t0008-ignores.sh
> @@ -138,6 +138,7 @@ test_expect_success 'setup' '
> cat <<-\EOF >.gitignore &&
> one
> ignored-*
> + top-level-dir/
> EOF
> for dir in . a
> do
> @@ -177,6 +178,10 @@ test_expect_success 'setup' '
> #
> # test invalid inputs
>
> +test_expect_success_multi '. corner-case' '' '
> + test_check_ignore . 1
> +'
> +
> test_expect_success_multi 'empty command line' '' '
> test_check_ignore "" 128 &&
> stderr_contains "fatal: no path specified"
^ permalink raw reply
* Re: Can git restrict source files ?
From: Ævar Arnfjörð Bjarmason @ 2013-02-19 17:55 UTC (permalink / raw)
To: Juan Pablo; +Cc: git@vger.kernel.org
In-Reply-To: <DE551AEA-5C7D-4A2D-8AB4-33195EF351F8@gmail.com>
On Tue, Feb 19, 2013 at 5:06 PM, Juan Pablo <juanpablo8517@gmail.com> wrote:
> I have a question, can i control the access to specific files or folders ?? I need that some developers can't see some source files, thank you very much for your time
No, but what you can do is to split these up into different
repositories. E.g. where I work we have a puppet.git and a
secrets.git, the latter contains passwords and other secret data, the
former just uses macros to include that and is accessible to everyone.
^ permalink raw reply
* [PATCH v2 4/4] Documentation/git-commit.txt: rework the --cleanup section
From: Brandon Casey @ 2013-02-19 18:14 UTC (permalink / raw)
To: gitster; +Cc: git, jrnieder, ralf.thielow, Brandon Casey
In-Reply-To: <7va9r06we2.fsf@alter.siamese.dyndns.org>
From: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
Ok, here's the updated text. I am not set up to build the documentation,
so I hope someone will test, but looks right to me.
-Brandon
Documentation/git-commit.txt | 28 ++++++++++++++++++----------
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 0eb79cc..992c219 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -172,16 +172,24 @@ OPTIONS
linkgit:git-commit-tree[1].
--cleanup=<mode>::
- This option sets how the commit message is cleaned up.
- The '<mode>' can be one of 'verbatim', 'whitespace', 'strip',
- and 'default'. The 'default' mode will strip leading and
- trailing empty lines and #commentary from the commit message
- only if the message is to be edited. Otherwise only whitespace
- removed. The 'verbatim' mode does not change message at all,
- 'whitespace' removes just leading/trailing whitespace lines
- and 'strip' removes both whitespace and commentary. The default
- can be changed by the 'commit.cleanup' configuration variable
- (see linkgit:git-config[1]).
+ This option determines how the supplied commit message should be
+ cleaned up before committing. The '<mode>' can be `strip`,
+ `whitespace`, `verbatim`, or `default`.
++
+--
+strip::
+ Strip leading and trailing empty lines, trailing whitespace, and
+ #commentary and collapse consecutive empty lines.
+whitespace::
+ Same as `strip` except #commentary is not removed.
+verbatim::
+ Do not change the message at all.
+default::
+ `strip` if the message is to be edited. Otherwise `whitespace`.
+--
++
+ The default can be changed by the 'commit.cleanup' configuration
+ variable (see linkgit:git-config[1]).
-e::
--edit::
--
1.8.1.3.566.gaa39828
^ permalink raw reply related
* [PATCH v2 4/4] Documentation/git-commit.txt: rework the --cleanup section
From: Brandon Casey @ 2013-02-19 18:28 UTC (permalink / raw)
To: gitster; +Cc: git, jrnieder, ralf.thielow, Brandon Casey
In-Reply-To: <7va9r06we2.fsf@alter.siamese.dyndns.org>
From: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
[RESEND] I originally specified Junio's address as gitster@pobox.org.
Ok, here's the updated text. I am not set up to build the documentation,
so I hope someone will test, but looks right to me.
-Brandon
Documentation/git-commit.txt | 28 ++++++++++++++++++----------
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 0eb79cc..992c219 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -172,16 +172,24 @@ OPTIONS
linkgit:git-commit-tree[1].
--cleanup=<mode>::
- This option sets how the commit message is cleaned up.
- The '<mode>' can be one of 'verbatim', 'whitespace', 'strip',
- and 'default'. The 'default' mode will strip leading and
- trailing empty lines and #commentary from the commit message
- only if the message is to be edited. Otherwise only whitespace
- removed. The 'verbatim' mode does not change message at all,
- 'whitespace' removes just leading/trailing whitespace lines
- and 'strip' removes both whitespace and commentary. The default
- can be changed by the 'commit.cleanup' configuration variable
- (see linkgit:git-config[1]).
+ This option determines how the supplied commit message should be
+ cleaned up before committing. The '<mode>' can be `strip`,
+ `whitespace`, `verbatim`, or `default`.
++
+--
+strip::
+ Strip leading and trailing empty lines, trailing whitespace, and
+ #commentary and collapse consecutive empty lines.
+whitespace::
+ Same as `strip` except #commentary is not removed.
+verbatim::
+ Do not change the message at all.
+default::
+ `strip` if the message is to be edited. Otherwise `whitespace`.
+--
++
+ The default can be changed by the 'commit.cleanup' configuration
+ variable (see linkgit:git-config[1]).
-e::
--edit::
--
1.8.1.3.566.gaa39828
^ permalink raw reply related
* [PATCH v2 4/4] Documentation/git-commit.txt: rework the --cleanup section
From: Brandon Casey @ 2013-02-19 18:29 UTC (permalink / raw)
To: gitster; +Cc: git, jrnieder, ralf.thielow, Brandon Casey
In-Reply-To: <7va9r06we2.fsf@alter.siamese.dyndns.org>
From: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
[RESEND] I originally specified Junio's address as gitster@pobox.org.
[RESEND] Sorry, now with the correct address.
Ok, here's the updated text. I am not set up to build the documentation,
so I hope someone will test, but looks right to me.
-Brandon
Documentation/git-commit.txt | 28 ++++++++++++++++++----------
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 0eb79cc..992c219 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -172,16 +172,24 @@ OPTIONS
linkgit:git-commit-tree[1].
--cleanup=<mode>::
- This option sets how the commit message is cleaned up.
- The '<mode>' can be one of 'verbatim', 'whitespace', 'strip',
- and 'default'. The 'default' mode will strip leading and
- trailing empty lines and #commentary from the commit message
- only if the message is to be edited. Otherwise only whitespace
- removed. The 'verbatim' mode does not change message at all,
- 'whitespace' removes just leading/trailing whitespace lines
- and 'strip' removes both whitespace and commentary. The default
- can be changed by the 'commit.cleanup' configuration variable
- (see linkgit:git-config[1]).
+ This option determines how the supplied commit message should be
+ cleaned up before committing. The '<mode>' can be `strip`,
+ `whitespace`, `verbatim`, or `default`.
++
+--
+strip::
+ Strip leading and trailing empty lines, trailing whitespace, and
+ #commentary and collapse consecutive empty lines.
+whitespace::
+ Same as `strip` except #commentary is not removed.
+verbatim::
+ Do not change the message at all.
+default::
+ `strip` if the message is to be edited. Otherwise `whitespace`.
+--
++
+ The default can be changed by the 'commit.cleanup' configuration
+ variable (see linkgit:git-config[1]).
-e::
--edit::
--
1.8.1.3.566.gaa39828
^ permalink raw reply related
* Re: [PATCH v4 1/3] user-manual: Reorganize the reroll sections, adding 'git rebase -i'
From: Junio C Hamano @ 2013-02-19 18:47 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git, Jonathan Nieder
In-Reply-To: <e9f8a25c05f9cfe89c6bcbefb69f40cd629f9925.1361267945.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> I think this interface is often more convenient than extended cherry
> picking or using 'git format-patch'. In fact, I removed the
> cherry-pick section entirely. The entry-level suggestions for
> rerolling are now:
>
> 1. git commit --amend
> 2. git format-patch origin
> git reset --hard origin
> ...edit and reorder patches...
> git am *.patch
> 3. git rebase -i origin
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
Thanks.
> +Sometimes you want to edit a commit deeper in your history. One
> +approach is to use `git format-patch` to create a series of patches,
> +then reset the state to before the patches:
>
> -------------------------------------------------
> +$ git format-patch origin
> +$ git reset --hard origin
> -------------------------------------------------
Technically speaking, this does not "reset to before the patches".
You would need "git reset --hard $(git merge-base origin HEAD)" or
something like that.
I think this is fine as-is in the flow of text, where we haven't
taught the readers the use of merge-base to find the fork point.
^ permalink raw reply
* Re: [PATCH v4 1/3] user-manual: Reorganize the reroll sections, adding 'git rebase -i'
From: W. Trevor King @ 2013-02-19 18:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git, Jonathan Nieder
In-Reply-To: <7vwqu45efr.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]
On Tue, Feb 19, 2013 at 10:47:04AM -0800, Junio C Hamano wrote:
> "W. Trevor King" <wking@tremily.us> writes:
> > +Sometimes you want to edit a commit deeper in your history. One
> > +approach is to use `git format-patch` to create a series of patches,
> > +then reset the state to before the patches:
> >
> > -------------------------------------------------
> > +$ git format-patch origin
> > +$ git reset --hard origin
> > -------------------------------------------------
>
> Technically speaking, this does not "reset to before the patches".
> You would need "git reset --hard $(git merge-base origin HEAD)" or
> something like that.
They'll be fine if they haven't fetched since they started their
branch ;).
It does look like I've got an extra comma an a missing “and”. What
about:
…create series of patches and then reset…
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Feature idea : notes to track status of a commit, which remotes it is shared to
From: Junio C Hamano @ 2013-02-19 18:55 UTC (permalink / raw)
To: Thomas Rast; +Cc: Mildred Ki'Lya, git
In-Reply-To: <87bobgtxvk.fsf@pctrast.inf.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Mildred Ki'Lya <mildred-ml@mildred.fr> writes:
>
>> The idea is to basically track automatically (in notes, either in the
>> notes namespace or in another namespace) which repository/remote
>> contains a commit. When doing git log, we'd see lines with each
>> commit, something like:
>>
>> commit b044e6d0f1a1782820b052348ab0db314e2db3ca
>> Author: Myself <myself@localhost.localdomain>
>> Date: Tue Nov 20 16:46:38 2012 +0100
>>
>> This is the commit description
>>
>> Published on:
>> origin
>> git@git.host.com:pub/repo.git
>
> The problem here is that doing this in notes is unreliable: you'd have
> to identify all places where the set of "publishes" can change for any
> commit, and update them there.
Unreliable you can fix with effort.
But I think a bigger problem is that it is a pointless "false
economy" to attempt to record and try to maintain this note for each
and every commit.
When you push out a tip of the branch to a new location, you would
have to update notes to all commits from that tip down to where in
the history to record that new location? To the root? Also your
upstream may fetch from your published place and you may fetch it
back (you will notice that now the commit appears in your 'origin').
Would you do the traversal and update all notes?
It is both much easier and cheaper to compute this on demand as you
pointed out.
^ permalink raw reply
* Re: [PATCH/RFC] clone: suggest index version 4 when the index is bigger than 512 KiB
From: Junio C Hamano @ 2013-02-19 18:59 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git
In-Reply-To: <loom.20130219T113730-546@post.gmane.org>
Thomas Ackermann <th.acker@arcor.de> writes:
> Is V4 really recommended for general use?
If you stick to C-git, I do not think there is any reason to avoid
it. It is already a mature technology, the difference between 2 and
4 are so trivial that it is very unlikely for a latent bug to be
hiding in corner cases.
It is a different matter if various reimplementations already
support the format. You can try it out, and if you find that other
tools based on reimplementations of Git you use do not understand
the format, you can safely go back with
git update-index --index-version 2
after you upgraded to version 4.
^ permalink raw reply
* Re: [PATCH 2/2] check-ignore.c: fix segfault with '.' argument from repo root
From: Adam Spiers @ 2013-02-19 19:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list, Zoltan Klinger
In-Reply-To: <7v1ucc6vgd.fsf@alter.siamese.dyndns.org>
On Tue, Feb 19, 2013 at 5:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Adam Spiers <git@adamspiers.org> writes:
>
>> Fix a corner case where check-ignore would segfault when run with the
>> '.' argument from the top level of a repository, due to prefix_path()
>> converting '.' into the empty string. It doesn't make much sense to
>> call check-ignore from the top level with '.' as a parameter, since
>> the top-level directory would never typically be ignored, but of
>> course it should not segfault in this case.
>>
>> Signed-off-by: Adam Spiers <git@adamspiers.org>
>> ---
>
> Please step back a bit and explain why the original had check for
> path[0] in the first place?
I can't remember to be honest.
> If the answer is "the code wanted to special case the question 'is
> the top-level excluded?',
Yes, I think that's the most likely explanation. Maybe it got missed
in a variable renaming refactoring.
> but used a wrong variable to implement the
> check, and this patch is a fix to that", then the proposed commit
> log message looks incomplete. The cause of the segv is not that
> prefix_path() returns an empty string, but because the function
> called inside the "if" block was written without expecting to be fed
> the path that refers to the top-level of the working tree, no?
>
> While this change certainly will prevent the "check the top-level"
> request to last-exclude-matching-path, I have to wonder if it is a
> good idea to force the caller of the l-e-m-p function to even care.
>
> In other words, would it be a cleaner approach to fix the l-e-m-p
> function so that the caller can ask "check the top-level" and give a
> sensible answer (perhaps the answer may be "nothing matches"), and
> remove the "&& path[0]" (or "&& full_path[0]") special case from
> this call site?
Yes, that did cross my mind. I also wondered whether hash_name()
should do stricter input validation, but I guess that could have an
impact on performance.
> The last sentence "It doesn't make much sense..." in the proposed
> log message would become a good justification for such a special
> case at the beginning of l-e-m-p function, I would think.
Fair enough. I'll reply to this with a new version.[0]
[0] I wish there was a clean way to include the new version inline,
but as I've noted before, there doesn't seem to be:
http://article.gmane.org/gmane.comp.version-control.git/146110
^ 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