* Re: [PATCH] Verify Content-Type from smart HTTP servers
From: Junio C Hamano @ 2013-02-01 18:09 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, git
In-Reply-To: <20130201085248.GA30644@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Should this be "From:" Shawn? The tone of the message and the S-O-B
> order makes it look like it.
Yes. I should have left that line when edited the format-patch
output in my MUA to say I was resending something that vger rejected
and people did not see after tweaking the patch to slip their taboo
list.
>> @@ -133,16 +135,19 @@ static struct discovery* discover_refs(const char *service)
>> last->buf = last->buf_alloc;
>>
>> if (maybe_smart && 5 <= last->len && last->buf[4] == '#') {
>> - /* smart HTTP response; validate that the service
>> + /*
>> + * smart HTTP response; validate that the service
>> * pkt-line matches our request.
>> */
>> - struct strbuf exp = STRBUF_INIT;
>> -
>> + strbuf_addf(&exp, "application/x-%s-advertisement", service);
>> + if (strbuf_cmp(&exp, &type))
>> + die("invalid content-type %s", type.buf);
>
> Hmm. I wondered if it is possible for a non-smart server to send us down
> this code path, which would now complain of the bogus content-type.
> Something like an info/refs file with:
>
> # 1
> # the comment above is meaningless, but puts a "#" at position 4.
>
> But I note that we would already die in the next line:
>
>> if (packet_get_line(&buffer, &last->buf, &last->len) <= 0)
>> die("%s has invalid packet header", refs_url);
>
> so I do not think the patch makes anything worse. However, should we
> take this opportunity to make the "did we get a smart response" test
> more robust? That is, should we actually be checking the content-type
> in the outer conditional, and going down the smart code-path if it is
> application/x-%s-advertisement, and otherwise treating the result as
> dumb?
Does the outer caller that switches between dumb and smart actually
know what service type it is requesting (I am not familiar with the
callchain involved)? Even if it doesn't, it may still make sense.
> As a side note, should we (can we) care about the content-type for dumb
> http? It should probably be text/plain or application/octet-stream, but
> I would not be surprised if we get a variety of random junk in the real
> world, though.
The design objective of dumb http protocol was to allow working with
any dumb bit transfer thing, so I'd prefer to keep it lenient and
allow application/x-git-loose-object-file and somesuch.
Thanks.
^ permalink raw reply
* [PATCH 4/6] Fix places where 'Git' should be 'git
From: Thomas Ackermann @ 2013-02-01 18:10 UTC (permalink / raw)
To: gitster, th.acker; +Cc: git, davvid
In-Reply-To: <210945773.1090030.1359741840305.JavaMail.ngmail@webmail18.arcor-online.net>
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
Documentation/git-p4.txt | 4 ++--
Documentation/git-remote-fd.txt | 2 +-
Documentation/gittutorial.txt | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index 1d1b020..3417cb3 100644
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@ -334,11 +334,11 @@ configuration file. This allows future 'git p4 submit' commands to
work properly; the submit command looks only at the variable and does
not have a command-line option.
-The full syntax for a p4 view is documented in 'p4 help views'. 'Git p4'
+The full syntax for a p4 view is documented in 'p4 help views'. 'git p4'
knows only a subset of the view syntax. It understands multi-line
mappings, overlays with '+', exclusions with '-' and double-quotes
around whitespace. Of the possible wildcards, 'git p4' only handles
-'...', and only when it is at the end of the path. 'Git p4' will complain
+'...', and only when it is at the end of the path. 'git p4' will complain
if it encounters an unhandled wildcard.
Bugs in the implementation of overlap mappings exist. If multiple depot
diff --git a/Documentation/git-remote-fd.txt b/Documentation/git-remote-fd.txt
index 9bfe12c..933c2ad 100644
--- a/Documentation/git-remote-fd.txt
+++ b/Documentation/git-remote-fd.txt
@@ -12,7 +12,7 @@ SYNOPSIS
DESCRIPTION
-----------
This helper uses specified file descriptors to connect to a remote Git server.
-This is not meant for end users but for programs and scripts calling Git
+This is not meant for end users but for programs and scripts calling git
fetch, push or archive.
If only <infd> is given, it is assumed to be a bidirectional socket connected
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index 6091988..8262196 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -462,7 +462,7 @@ Exploring history
Git history is represented as a series of interrelated commits. We
have already seen that the 'git log' command can list those commits.
-Note that first line of each Git log entry also gives a name for the
+Note that first line of each git log entry also gives a name for the
commit:
-------------------------------------
--
1.8.0.msysgit.0
---
Thomas
^ permalink raw reply related
* [PATCH 5/6] Add a description for 'gitfile' to glossary
From: Thomas Ackermann @ 2013-02-01 18:11 UTC (permalink / raw)
To: gitster, th.acker; +Cc: git, davvid
In-Reply-To: <210945773.1090030.1359741840305.JavaMail.ngmail@webmail18.arcor-online.net>
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
Documentation/glossary-content.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
index 7c15bc0..ddf2f66 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -149,6 +149,9 @@ to point at the new commit.
[[def_git_archive]]Git archive::
Synonym for <<def_repository,repository>> (for arch people).
+[[def_gitfile]]gitfile::
+ A `.git` file which points to a `$GIT_DIR` (used for Git submodules).
+
[[def_grafts]]grafts::
Grafts enables two otherwise different lines of development to be joined
together by recording fake ancestry information for commits. This way
--
1.8.0.msysgit.0
---
Thomas
^ permalink raw reply related
* [PATCH 6/6] Use consistent links for User Manual and Everyday Git; Fix a quoting error
From: Thomas Ackermann @ 2013-02-01 18:12 UTC (permalink / raw)
To: gitster, th.acker; +Cc: git, davvid
In-Reply-To: <210945773.1090030.1359741840305.JavaMail.ngmail@webmail18.arcor-online.net>
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
Documentation/git.txt | 2 +-
Documentation/gitcore-tutorial.txt | 6 +++---
Documentation/gittutorial-2.txt | 2 +-
Documentation/gittutorial.txt | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index c431ba2..c5f6845 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -23,7 +23,7 @@ and full access to internals.
See linkgit:gittutorial[7] to get started, then see
link:everyday.html[Everyday Git] for a useful minimum set of
-commands. The link:user-manual.html[Git User's Manual] has a more
+commands. The link:user-manual.html[The Git User's Manual] has a more
in-depth introduction.
After you mastered the basic concepts, you can come back to this
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 59c1c17..88e9839 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -17,7 +17,7 @@ work with a Git repository.
If you just need to use Git as a revision control system you may prefer
to start with "A Tutorial Introduction to Git" (linkgit:gittutorial[7]) or
-link:user-manual.html[the Git User Manual].
+link:user-manual.html[The Git User's Manual].
However, an understanding of these low-level tools can be helpful if
you want to understand Git's internals.
@@ -568,8 +568,8 @@ can explore on your own.
[NOTE]
Most likely, you are not directly using the core
-Git Plumbing commands, but using Porcelain such as 'git add', `git-rm'
-and `git-commit'.
+Git Plumbing commands, but using Porcelain such as 'git add', 'git rm'
+and 'git commit'.
Tagging a version
diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt
index 94c906e..2db4ea3 100644
--- a/Documentation/gittutorial-2.txt
+++ b/Documentation/gittutorial-2.txt
@@ -406,7 +406,7 @@ pages for any of the git commands; one good place to start would be
with the commands mentioned in link:everyday.html[Everyday Git]. You
should be able to find any unknown jargon in linkgit:gitglossary[7].
-The link:user-manual.html[Git User's Manual] provides a more
+The link:user-manual.html[The Git User's Manual] provides a more
comprehensive introduction to Git.
linkgit:gitcvs-migration[7] explains how to
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index 8262196..e63fd9f 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -656,7 +656,7 @@ digressions that may be interesting at this point are:
* linkgit:gitworkflows[7]: Gives an overview of recommended
workflows.
- * link:everyday.html[Everyday Git with 20 Commands Or So]
+ * link:everyday.html[Everyday Git]
* linkgit:gitcvs-migration[7]: Git for CVS users.
--
1.8.0.msysgit.0
---
Thomas
^ permalink raw reply related
* Re: Aw: Re: Aw: Re: [PATCH v3 3/6] Change 'git' to 'Git' whenever the whole system is referred to #2
From: Junio C Hamano @ 2013-02-01 18:37 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git, davvid
In-Reply-To: <210945773.1090030.1359741840305.JavaMail.ngmail@webmail18.arcor-online.net>
Thomas Ackermann <th.acker@arcor.de> writes:
> >
>> I think we have waited long enough and as far as I recall we didn't
>> see any reports of misconversion or forgotten conversion, so I'll
>> squash the fixes parked on the topic branch, whose tip is at
>> bfb8e1eb6375afb (fixup! Change 'git' to 'Git' whenever the whole
>> system is referred to #4, 2013-01-22), and merge the result to
>> 'next' sometime tomorrow.
>
> Here are my final fixups on top of bfb8e1eb6375afb:
> I morphed the remarks from Junio and David into patch form and
> also did the reverse check for wrong usage of 'Git' instead of 'git'.
> While doing the later I also noticed some small glitches and fixed them.
> Squash at your will.
Thanks.
> [PATCH 1/6] fixup! fixup! Change 'git' to 'Git' whenever the whole system is referred to #2
> [PATCH 2/6] fixup! fixup! fixup! Change 'git' to 'Git' whenever the whole system is referred to #1
> [PATCH 3/6] fixup! Documentation: avoid poor-man's small caps
> [PATCH 4/6] Fix places where 'Git' should be 'git
> [PATCH 5/6] Add a description for 'gitfile' to glossary
> [PATCH 6/6] Use consistent links for User Manual and Everyday Git; Fix a quoting error
^ permalink raw reply
* Re: [PATCH 5/6] Add a description for 'gitfile' to glossary
From: Junio C Hamano @ 2013-02-01 18:41 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git, davvid
In-Reply-To: <274664435.1090127.1359742284591.JavaMail.ngmail@webmail18.arcor-online.net>
Thomas Ackermann <th.acker@arcor.de> writes:
> Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
> ---
> Documentation/glossary-content.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
> index 7c15bc0..ddf2f66 100644
> --- a/Documentation/glossary-content.txt
> +++ b/Documentation/glossary-content.txt
> @@ -149,6 +149,9 @@ to point at the new commit.
> [[def_git_archive]]Git archive::
> Synonym for <<def_repository,repository>> (for arch people).
>
> +[[def_gitfile]]gitfile::
> + A `.git` file which points to a `$GIT_DIR` (used for Git submodules).
> +
It is more like 'used by' ;-) People are free to write their
Porcelain system that uses this mechanism.
> [[def_grafts]]grafts::
> Grafts enables two otherwise different lines of development to be joined
> together by recording fake ancestry information for commits. This way
^ permalink raw reply
* [PATCH] l10n: de.po: translate "revision" consistently as "Revision"
From: Ralf Thielow @ 2013-02-01 18:42 UTC (permalink / raw)
To: trast, jojo; +Cc: git, jk, stimming, Ralf Thielow
In-Reply-To: <1359398014-3325-2-git-send-email-ralf.thielow@gmail.com>
In the current German translation, the word "revision" was
translated as both "Version" (translation of "commit") and
"Revision". Since a revision in Git is not necessarily a
commit, we should not translate it with the same word in
order to give the user an idea that it's not necessarily
the same. After this commit, "revision" is consistently
translated as "Revision".
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
---
This replaces a patch [1] earlier sent to the list.
I've also updated the glossary [2] of the German translation.
[1]
http://article.gmane.org/gmane.comp.version-control.git/214852
[2]
https://github.com/ralfth/git-po-de/wiki/Glossary
po/de.po | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/po/de.po b/po/de.po
index ed8330a..0a94b4b 100644
--- a/po/de.po
+++ b/po/de.po
@@ -4438,7 +4438,7 @@ msgid ""
msgstr ""
"Kein externes Projektarchiv angegeben. Bitte geben Sie entweder eine URL\n"
"oder den Namen des externen Archivs an, von welchem neue\n"
-"Versionen angefordert werden sollen."
+"Revisionen angefordert werden sollen."
#: builtin/fetch.c:932
msgid "You need to specify a tag name."
@@ -4623,7 +4623,7 @@ msgstr ""
#: builtin/grep.c:22
msgid "git grep [options] [-e] <pattern> [<rev>...] [[--] <path>...]"
-msgstr "git grep [Optionen] [-e] <Muster> [<Version>...] [[--] <Pfad>...]"
+msgstr "git grep [Optionen] [-e] <Muster> [<Revision>...] [[--] <Pfad>...]"
#: builtin/grep.c:217
#, c-format
@@ -5501,7 +5501,7 @@ msgstr "ungültiges in-reply-to: %s"
#: builtin/log.c:913
msgid "git format-patch [options] [<since> | <revision range>]"
-msgstr "git format-patch [Optionen] [<seit> | <Versionsbereich>]"
+msgstr "git format-patch [Optionen] [<seit> | <Revisionsbereich>]"
#: builtin/log.c:958
msgid "Two output directories?"
@@ -6193,7 +6193,7 @@ msgstr "findet Vorfahren für eine einzelne n-Wege-Zusammenführung"
#: builtin/merge-base.c:100
msgid "list revs not reachable from others"
-msgstr "listet Revisionen auf, die nicht durch Andere erreichbar sind"
+msgstr "listet Versionen auf, die nicht durch Andere erreichbar sind"
#: builtin/merge-base.c:102
msgid "is the first one ancestor of the other?"
@@ -7952,7 +7952,7 @@ msgstr "'%s' Zurücksetzung ist in einem bloßen Projektarchiv nicht erlaubt"
#: builtin/reset.c:333
#, c-format
msgid "Could not reset index file to revision '%s'."
-msgstr "Konnte Bereitstellungsdatei nicht zu Version '%s' zurücksetzen."
+msgstr "Konnte Bereitstellungsdatei nicht zu Revision '%s' zurücksetzen."
#: builtin/reset.c:339
msgid "Unstaged changes after reset:"
@@ -9053,7 +9053,7 @@ msgstr "nicht erkannte Option: '$arg'"
#: git-bisect.sh:99
#, sh-format
msgid "'$arg' does not appear to be a valid revision"
-msgstr "'$arg' scheint keine gültige Version zu sein"
+msgstr "'$arg' scheint keine gültige Revision zu sein"
#: git-bisect.sh:117
msgid "Bad HEAD - I need a HEAD"
@@ -9116,7 +9116,7 @@ msgid ""
"You need to give me at least one good and one bad revisions.\n"
"(You can use \"git bisect bad\" and \"git bisect good\" for that.)"
msgstr ""
-"Sie müssen mindestens eine korrekte und eine fehlerhafte Version angeben.\n"
+"Sie müssen mindestens eine korrekte und eine fehlerhafte Revision angeben.\n"
"(Sie können dafür \"git bisect bad\" und \"git bisect good\" benutzen.)"
#: git-bisect.sh:292
@@ -9126,7 +9126,7 @@ msgid ""
"(You can use \"git bisect bad\" and \"git bisect good\" for that.)"
msgstr ""
"Sie müssen mit \"git bisect start\" beginnen.\n"
-"Danach müssen Sie mindestens eine korrekte und eine fehlerhafte Version "
+"Danach müssen Sie mindestens eine korrekte und eine fehlerhafte Revision "
"angeben.\n"
"(Sie können dafür \"git bisect bad\" und \"git bisect good\" benutzen.)"
@@ -9650,7 +9650,7 @@ msgstr ""
#: git-submodule.sh:662
#, sh-format
msgid "Unable to find current revision in submodule path '$sm_path'"
-msgstr "Konnte aktuelle Version in Unterprojekt-Pfad '$sm_path' nicht finden"
+msgstr "Konnte aktuelle Revision in Unterprojekt-Pfad '$sm_path' nicht finden"
#: git-submodule.sh:671 git-submodule.sh:695
#, sh-format
--
1.8.1.2.623.g7d3a2ef
^ permalink raw reply related
* Re: [PATCH 6/6] Use consistent links for User Manual and Everyday Git; Fix a quoting error
From: Junio C Hamano @ 2013-02-01 18:43 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git, davvid
In-Reply-To: <549641245.1090170.1359742373184.JavaMail.ngmail@webmail18.arcor-online.net>
Thomas Ackermann <th.acker@arcor.de> writes:
> Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
> ---
> Documentation/git.txt | 2 +-
> Documentation/gitcore-tutorial.txt | 6 +++---
> Documentation/gittutorial-2.txt | 2 +-
> Documentation/gittutorial.txt | 2 +-
> 4 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/git.txt b/Documentation/git.txt
> index c431ba2..c5f6845 100644
> --- a/Documentation/git.txt
> +++ b/Documentation/git.txt
> @@ -23,7 +23,7 @@ and full access to internals.
>
> See linkgit:gittutorial[7] to get started, then see
> link:everyday.html[Everyday Git] for a useful minimum set of
> -commands. The link:user-manual.html[Git User's Manual] has a more
> +commands. The link:user-manual.html[The Git User's Manual] has a more
> in-depth introduction.
Thanks.
^ permalink raw reply
* Re: [PATCH 3/6] fixup! Documentation: avoid poor-man's small caps
From: Junio C Hamano @ 2013-02-01 18:44 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git, davvid
In-Reply-To: <544568068.1090092.1359742136040.JavaMail.ngmail@webmail18.arcor-online.net>
Thomas Ackermann <th.acker@arcor.de> writes:
> Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
> ---
I think this deserves to be a separate patch in the series, that
says "StGit is the right spelling of the system, not StGIT",
referring to https://gna.org/projects/stgit/ or somewhere, in the
log message.
Will massage the above in; no need to resend.
Thanks.
> Documentation/git-tools.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt
> index 338986a..ad8b823 100644
> --- a/Documentation/git-tools.txt
> +++ b/Documentation/git-tools.txt
> @@ -29,7 +29,7 @@ Alternative/Augmentative Porcelains
> - *pg* (http://www.spearce.org/category/projects/scm/pg/)
>
> pg is a shell script wrapper around Git to help the user manage a set of
> - patches to files. pg is somewhat like quilt or StGIT, but it does have a
> + patches to files. pg is somewhat like quilt or StGit, but it does have a
> slightly different feature set.
>
>
> @@ -60,7 +60,7 @@ History Viewers
>
> - *qgit* (http://digilander.libero.it/mcostalba/)
>
> - QGit is a git/StGIT GUI viewer built on Qt/C++. QGit could be used
> + QGit is a git/StGit GUI viewer built on Qt/C++. QGit could be used
> to browse history and directory tree, view annotated files, commit
> changes cherry picking single files or applying patches.
> Currently it is the fastest and most feature rich among the Git
^ permalink raw reply
* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: Junio C Hamano @ 2013-02-01 18:52 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan Nieder, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201073352.GB970@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Right. So we have some that must be "gitfoo", and others that do not
> care. If we turned "githooks" into "git-hooks" and removed the "is it a
> command?" magic from "git help", then "git help hooks" would still find
> hooks. And likewise, "git help gitignore" would still find "gitignore".
> But you could no longer say "git help ignore" to find "gitignore".
Which I think is a good thing ;-)
> Which personally I am OK with. It is not a sensible thing to ask for;
> the concept is not "ignore", but rather "the gitignore file".
Yes, exactly.
> 4. Replace the rename "gitfoo" above with a "see git-foo..." pointer.
> Users of "git help foo" would not ever see this, but people who
> have trained their fingers to type "man gitfoo" would, along with
> anybody following an outdated HTML link.
>
> 5. Update internal references to "linkgit:gitfoo" to point to
> "git-foo".
>
> Hmm. That really does not seem so bad. The biggest downside is the
> people who have to see the redirect made in step 4.
Yeah, I see that a show-stopper in the whole sequence.
This is one of the "if we had perfect knowledge we would have
designed it this way, and we could still migrate our current system
to that ideal, but it is dubious the difference between the current
system and the ideal will outweigh the cost of migration" moment,
isn't it?
^ permalink raw reply
* Re: [PATCH] Verify Content-Type from smart HTTP servers
From: Jeff King @ 2013-02-01 18:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7vip6bc3e1.fsf@alter.siamese.dyndns.org>
On Fri, Feb 01, 2013 at 10:09:26AM -0800, Junio C Hamano wrote:
> > so I do not think the patch makes anything worse. However, should we
> > take this opportunity to make the "did we get a smart response" test
> > more robust? That is, should we actually be checking the content-type
> > in the outer conditional, and going down the smart code-path if it is
> > application/x-%s-advertisement, and otherwise treating the result as
> > dumb?
>
> Does the outer caller that switches between dumb and smart actually
> know what service type it is requesting (I am not familiar with the
> callchain involved)? Even if it doesn't, it may still make sense.
I was specifically thinking of this (on top of your patch):
diff --git a/remote-curl.c b/remote-curl.c
index e6f3b63..63680a8 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -134,14 +134,12 @@ static struct discovery* discover_refs(const char *service)
last->buf_alloc = strbuf_detach(&buffer, &last->len);
last->buf = last->buf_alloc;
- if (maybe_smart && 5 <= last->len && last->buf[4] == '#') {
+ strbuf_addf(&exp, "application/x-%s-advertisement", service);
+ if (maybe_smart && !strbuf_cmp(&exp, &type)) {
/*
* smart HTTP response; validate that the service
* pkt-line matches our request.
*/
- strbuf_addf(&exp, "application/x-%s-advertisement", service);
- if (strbuf_cmp(&exp, &type))
- die("invalid content-type %s", type.buf);
if (packet_get_line(&buffer, &last->buf, &last->len) <= 0)
die("%s has invalid packet header", refs_url);
if (buffer.len && buffer.buf[buffer.len - 1] == '\n')
To just follow the dumb path if we don't get the content-type we expect.
We may want to keep the '#' format check in addition (packet_get_line
will check it and die, anyway, but we may want to drop back to
considering it dumb, just to protect against a badly configured dumb
server which uses our mime type, but I do not think it likely).
> > As a side note, should we (can we) care about the content-type for dumb
> > http? It should probably be text/plain or application/octet-stream, but
> > I would not be surprised if we get a variety of random junk in the real
> > world, though.
>
> The design objective of dumb http protocol was to allow working with
> any dumb bit transfer thing, so I'd prefer to keep it lenient and
> allow application/x-git-loose-object-file and somesuch.
Yeah, I do not think it really buys us anything in practice, and we have
no way of knowing what kind of crap is in the wild. Not worth it.
-Peff
^ permalink raw reply related
* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: Jeff King @ 2013-02-01 19:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <7vr4kzamt7.fsf@alter.siamese.dyndns.org>
On Fri, Feb 01, 2013 at 10:52:52AM -0800, Junio C Hamano wrote:
> > 4. Replace the rename "gitfoo" above with a "see git-foo..." pointer.
> > Users of "git help foo" would not ever see this, but people who
> > have trained their fingers to type "man gitfoo" would, along with
> > anybody following an outdated HTML link.
> >
> > 5. Update internal references to "linkgit:gitfoo" to point to
> > "git-foo".
> >
> > Hmm. That really does not seem so bad. The biggest downside is the
> > people who have to see the redirect made in step 4.
>
> Yeah, I see that a show-stopper in the whole sequence.
>
> This is one of the "if we had perfect knowledge we would have
> designed it this way, and we could still migrate our current system
> to that ideal, but it is dubious the difference between the current
> system and the ideal will outweigh the cost of migration" moment,
> isn't it?
Yeah, perhaps. I did the patch series just to see what the effort would
be like. But at this point I am fine if we drop it (it sounded like
Jonathan was in favor of this direction, so maybe he wants to make a
final argument).
-Peff
^ permalink raw reply
* Re: [PATCH] rebase --preserve-merges keeps empty merge commits
From: Martin von Zweigbergk @ 2013-02-01 19:15 UTC (permalink / raw)
To: Phil Hord; +Cc: git, phil.hord, Neil Horman, Junio C Hamano
In-Reply-To: <1358023561-26773-1-git-send-email-hordp@cisco.com>
I'm working on a re-roll of
http://thread.gmane.org/gmane.comp.version-control.git/205796
and finally got around to including test cases for what you fixed in
this patch. I want to make sure I'm testing what you fixed here. See
questions below.
On Sat, Jan 12, 2013 at 12:46 PM, Phil Hord <hordp@cisco.com> wrote:
> Since 90e1818f9a (git-rebase: add keep_empty flag, 2012-04-20)
> 'git rebase --preserve-merges' fails to preserve empty merge commits
> unless --keep-empty is also specified. Merge commits should be
> preserved in order to preserve the structure of the rebased graph,
> even if the merge commit does not introduce changes to the parent.
>
> Teach rebase not to drop merge commits only because they are empty.
Consider a history like
# a---b---c
# \ \
# d---l
# \
# e
# \
# C
where 'l' is tree-same with 'd' and 'C' introduces the same change as 'c'.
My test case runs 'git rebase -p e l' and expects the result to look like
# a---b---c
# \ \
# d \
# \ \
# e---l
> A special case which is not handled by this change is for a merge commit
> whose parents are now the same commit because all the previous different
> parents have been dropped as a result of this rebase or some previous
> operation.
And for this case, the test case runs 'git rebase -p C l'. Is that
what you meant here?
Before your patch, git would just say "Nothing to do" and after your
patch, we get
# a---b---c
# \ \
# d \
# \ \
# e \
# \ \
# C---l
As you say, your patch doesn't try to handle this case, but at least
the new behavior seems better. I think we would ideally want the
recreated 'l' to have only 'C' as parent in this case. Does that make
sense?
Martin
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/Makefile: clean up MAN*_TXT lists
From: Jonathan Nieder @ 2013-02-01 19:20 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201082650.GA25783@sigill.intra.peff.net>
Jeff King wrote:
> We keep a list of the various files that end up as man1,
> man5, etc. Let's break these single-line lists into sorted
> multi-line lists, which makes diffs that touch them much
> easier to read.
Independentally of the rest of the series, I think this is a good
cleanup.
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -1,13 +1,28 @@ MAN7_TXT += gitcredentials.txt
> -MAN1_TXT= \
> - $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
> - $(wildcard git-*.txt)) \
> - gitk.txt gitweb.txt git.txt
> +MAN1_TXT += git.txt
> +MAN1_TXT += gitk.txt
> +MAN1_TXT += gitweb.txt
> +
If the user happens to have MAN[157]_TXT set in the environment, this
would be affected by that. How about:
# Guard against environment variables
MAN1_TXT =
MAN5_TXT =
MAN7_TXT =
MAN1_TXT += ...
...
?
With that change,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
^ permalink raw reply
* Re: [PATCH 2/2] docs: convert "concept" manpages to git-*
From: Jonathan Nieder @ 2013-02-01 19:25 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201082744.GB25783@sigill.intra.peff.net>
Jeff King wrote:
> Let's just call everything git-*, which is simpler. This
> patch renames the documentation files, updates the Makefile
> to find them, and updates internal linkgit references to the
> pages. It updates builtin/help.c so that users of "git help
> foo" will not even notice the difference.
>
> Users of external html links, or users who have trained
> their fingers to type "man gitfoo" will notice the missing
> pages. This patch does not install a "this page has moved"
> placeholder, but that can easily be done on top.
Thanks for writing this.
I think this one should wait until someone (perhaps me) takes care of
the redirects. Ideally in addition to simple "this place has moved"
HTML placeholders and manpages using the .so macro, a makefile target
to generate redirect directives for your apache configuration might
make sense.
In the meantime, having "man gitrepository-layout" is not the worst
wart in the world.
Cheers,
Jonathan
^ permalink raw reply
* Re: [PATCH 5/6] Add a description for 'gitfile' to glossary
From: Junio C Hamano @ 2013-02-01 19:26 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git, davvid, Lars Hjemli, Jens Lehmann
In-Reply-To: <7v4nhvc1vv.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Thomas Ackermann <th.acker@arcor.de> writes:
>
>> Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
>> ---
>> Documentation/glossary-content.txt | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
>> index 7c15bc0..ddf2f66 100644
>> --- a/Documentation/glossary-content.txt
>> +++ b/Documentation/glossary-content.txt
>> @@ -149,6 +149,9 @@ to point at the new commit.
>> [[def_git_archive]]Git archive::
>> Synonym for <<def_repository,repository>> (for arch people).
>>
>> +[[def_gitfile]]gitfile::
>> + A `.git` file which points to a `$GIT_DIR` (used for Git submodules).
>> +
>
> It is more like 'used by' ;-) People are free to write their
> Porcelain system that uses this mechanism.
The series merged at e2e2def (Merge branch 'lh/git-file', 2008-05-05)
added a mention of this to repository-layout and the readers can see
how it is interpreted by Git, but I doubt that anything explains why
you may want to use it in the documentation.
How about saying something like this here in the glossary:
A plain file `.git` at the root of a working tree that
points at the directory that is the real repository.
And then as a separate patch, in gitrepository-layout.txt (eek---see
the other thread), we can do something like this:
Documentation/gitrepository-layout.txt | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt
index 9f62886..473c6a0 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/gitrepository-layout.txt
@@ -12,12 +12,24 @@ $GIT_DIR/*
DESCRIPTION
-----------
-You may find these things in your git repository (`.git`
-directory for a repository associated with your working tree, or
-`<project>.git` directory for a public 'bare' repository. It is
-also possible to have a working tree where `.git` is a plain
-ASCII file containing `gitdir: <path>`, i.e. the path to the
-real git repository).
+A Git repository comes in two different flavours:
+
+ * a `.git` directory at the root of the working tree;
+
+ * a `<project>.git` directory that is a 'bare' repository
+ (i.e. without its own working tree), that is typically used for
+ exchanging histories with others by pushing into it and fetching
+ from it.
+
+*Note*: Also you can have a plain text file `.git` at the root of
+your working tree, containing `gitdir: <path>` to point at the real
+directory that has the repository. This mechanism is often used for
+a working tree of a submodule checkout, to allow you in the
+containing superproject to `git checkout` a branch that does not
+have the submodule. The `checkout` has to remove the entire
+submodule working tree, without losing the submodule repository.
+
+These things may exist in a Git repository.
objects::
Object store associated with this repository. Usually
^ permalink raw reply related
* [PATCH] mergetools: Enable tortoisemerge to handle filenames with
From: Sven Strickroth @ 2013-02-01 19:33 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, David Aguilar, Sebastian Schuberth, Jeff King
In-Reply-To: <7vzjzuwm7s.fsf@alter.siamese.dyndns.org>
spaces with TortoiseGitMerge
TortoiseGitMerge, unlike TortoiseMerge, can be told to handle paths
with spaces in them by using -option "$FILE" (not -option:"$FILE",
which does not work for such paths) syntax. Both do not have a fully
posix compatible cli parameter parser, however, TortoiseGitMerge was
modified in order to handle filenames with spaces correctly. The
"-key value" form was choosen because this way no escaping for
quotes within quotes is necessary; see
https://github.com/msysgit/msysgit/issues/57
Signed-off-by: Sven Strickroth <email@cs-ware.de>
Reported-by: Sebastian Schuberth <sschuberth@gmail.com>
---
mergetools/tortoisemerge | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/mergetools/tortoisemerge b/mergetools/tortoisemerge
index 8476afa..3b89f1c 100644
--- a/mergetools/tortoisemerge
+++ b/mergetools/tortoisemerge
@@ -6,9 +6,17 @@ merge_cmd () {
if $base_present
then
touch "$BACKUP"
- "$merge_tool_path" \
- -base:"$BASE" -mine:"$LOCAL" \
- -theirs:"$REMOTE" -merged:"$MERGED"
+ basename="$(basename "$merge_tool_path" .exe)"
+ if test "$basename" = "tortoisegitmerge"
+ then
+ "$merge_tool_path" \
+ -base "$BASE" -mine "$LOCAL" \
+ -theirs "$REMOTE" -merged "$MERGED"
+ else
+ "$merge_tool_path" \
+ -base:"$BASE" -mine:"$LOCAL" \
+ -theirs:"$REMOTE" -merged:"$MERGED"
+ fi
check_unchanged
else
echo "$merge_tool_path cannot be used without a base" 1>&2
--
Best regards,
Sven Strickroth
PGP key id F5A9D4C4 @ any key-server
^ permalink raw reply related
* Re: [PATCH 1/2] Documentation/Makefile: clean up MAN*_TXT lists
From: Junio C Hamano @ 2013-02-01 19:38 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Jeff King, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201192010.GA12368@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
>> --- a/Documentation/Makefile
>> +++ b/Documentation/Makefile
>> @@ -1,13 +1,28 @@ MAN7_TXT += gitcredentials.txt
>> -MAN1_TXT= \
>> - $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
>> - $(wildcard git-*.txt)) \
>> - gitk.txt gitweb.txt git.txt
>> +MAN1_TXT += git.txt
>> +MAN1_TXT += gitk.txt
>> +MAN1_TXT += gitweb.txt
>> +
>
> If the user happens to have MAN[157]_TXT set in the environment, this
> would be affected by that. How about:
>
> # Guard against environment variables
> MAN1_TXT =
> MAN5_TXT =
> MAN7_TXT =
>
> MAN1_TXT += ...
> ...
>
> With that change,
> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Sounds sensible. Let's go in that direction.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/Makefile: clean up MAN*_TXT lists
From: Jeff King @ 2013-02-01 19:38 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201192010.GA12368@google.com>
On Fri, Feb 01, 2013 at 11:20:10AM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > We keep a list of the various files that end up as man1,
> > man5, etc. Let's break these single-line lists into sorted
> > multi-line lists, which makes diffs that touch them much
> > easier to read.
>
> Independentally of the rest of the series, I think this is a good
> cleanup.
Yeah, I'd agree.
> > --- a/Documentation/Makefile
> > +++ b/Documentation/Makefile
> > @@ -1,13 +1,28 @@ MAN7_TXT += gitcredentials.txt
> > -MAN1_TXT= \
> > - $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
> > - $(wildcard git-*.txt)) \
> > - gitk.txt gitweb.txt git.txt
> > +MAN1_TXT += git.txt
> > +MAN1_TXT += gitk.txt
> > +MAN1_TXT += gitweb.txt
> > +
>
> If the user happens to have MAN[157]_TXT set in the environment, this
> would be affected by that. How about:
>
> # Guard against environment variables
> MAN1_TXT =
> MAN5_TXT =
> MAN7_TXT =
>
> MAN1_TXT += ...
> ...
>
> ?
Sure, not that likely, but no reason not to be careful. I notice the
rest of the file uses the:
FOO = first
FOO += second
...
pattern, though I prefer the style you showed myself.
Junio, do you want to apply the patch below? I guess it conflicts with
John's gitremote-helper.txt tweak, though.
-- >8 --
Subject: [PATCH] Documentation/Makefile: clean up MAN*_TXT lists
We keep a list of the various files that end up as man1,
man5, etc. Let's break these single-line lists into sorted
multi-line lists, which makes diffs that touch them much
easier to read.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/Makefile | 33 ++++++++++++++++++++++++---------
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 971977b..8e7939f 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,13 +1,28 @@ MAN7_TXT += gitcredentials.txt
-MAN1_TXT= \
- $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
- $(wildcard git-*.txt)) \
- gitk.txt gitweb.txt git.txt
-MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \
- gitrepository-layout.txt gitweb.conf.txt
-MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \
- gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \
- gitdiffcore.txt gitnamespaces.txt gitrevisions.txt gitworkflows.txt
+MAN1_TXT += $(filter-out \
+ $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
+ $(wildcard git-*.txt))
+MAN1_TXT += git.txt
+MAN1_TXT += gitk.txt
+MAN1_TXT += gitweb.txt
+
+MAN5_TXT += gitattributes.txt
+MAN5_TXT += githooks.txt
+MAN5_TXT += gitignore.txt
+MAN5_TXT += gitmodules.txt
+MAN5_TXT += gitrepository-layout.txt
+MAN5_TXT += gitweb.conf.txt
+
+MAN7_TXT += gitcli.txt
+MAN7_TXT += gitcore-tutorial.txt
MAN7_TXT += gitcredentials.txt
+MAN7_TXT += gitcvs-migration.txt
+MAN7_TXT += gitdiffcore.txt
+MAN7_TXT += gitglossary.txt
+MAN7_TXT += gitnamespaces.txt
+MAN7_TXT += gitrevisions.txt
+MAN7_TXT += gittutorial-2.txt
+MAN7_TXT += gittutorial.txt
+MAN7_TXT += gitworkflows.txt
MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
--
1.8.1.2.11.g1a2f572
^ permalink raw reply related
* Re: [PATCH 1/2] Documentation/Makefile: clean up MAN*_TXT lists
From: Jeff King @ 2013-02-01 19:41 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201193851.GA24588@sigill.intra.peff.net>
On Fri, Feb 01, 2013 at 02:38:51PM -0500, Jeff King wrote:
> Junio, do you want to apply the patch below? I guess it conflicts with
> John's gitremote-helper.txt tweak, though.
Argh, it would help if I actually ran "git commit", and/or looked at
what I was sending out. Here it is with the actual change.
-- >8 --
Subject: [PATCH] Documentation/Makefile: clean up MAN*_TXT lists
We keep a list of the various files that end up as man1,
man5, etc. Let's break these single-line lists into sorted
multi-line lists, which makes diffs that touch them much
easier to read.
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/Makefile | 38 +++++++++++++++++++++++++++++---------
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 971977b..5d22e0e 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,13 +1,33 @@ MAN7_TXT += gitcredentials.txt
-MAN1_TXT= \
- $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
- $(wildcard git-*.txt)) \
- gitk.txt gitweb.txt git.txt
-MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \
- gitrepository-layout.txt gitweb.conf.txt
-MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \
- gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \
- gitdiffcore.txt gitnamespaces.txt gitrevisions.txt gitworkflows.txt
+# Guard against environment variables
+MAN1_TXT =
+MAN5_TXT =
+MAN7_TXT =
+
+MAN1_TXT += $(filter-out \
+ $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
+ $(wildcard git-*.txt))
+MAN1_TXT += git.txt
+MAN1_TXT += gitk.txt
+MAN1_TXT += gitweb.txt
+
+MAN5_TXT += gitattributes.txt
+MAN5_TXT += githooks.txt
+MAN5_TXT += gitignore.txt
+MAN5_TXT += gitmodules.txt
+MAN5_TXT += gitrepository-layout.txt
+MAN5_TXT += gitweb.conf.txt
+
+MAN7_TXT += gitcli.txt
+MAN7_TXT += gitcore-tutorial.txt
MAN7_TXT += gitcredentials.txt
+MAN7_TXT += gitcvs-migration.txt
+MAN7_TXT += gitdiffcore.txt
+MAN7_TXT += gitglossary.txt
+MAN7_TXT += gitnamespaces.txt
+MAN7_TXT += gitrevisions.txt
+MAN7_TXT += gittutorial-2.txt
+MAN7_TXT += gittutorial.txt
+MAN7_TXT += gitworkflows.txt
MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
--
1.8.1.2.11.g1a2f572
^ permalink raw reply related
* Re: [PATCH 2/6] fixup! fixup! fixup! Change 'git' to 'Git' whenever the whole system is referred to #1
From: Jonathan Nieder @ 2013-02-01 19:43 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: gitster, git, davvid, Fredrik Gustafsson, Jens Lehmann
In-Reply-To: <242116275.1090080.1359742076320.JavaMail.ngmail@webmail18.arcor-online.net>
Hi,
Thomas Ackermann wrote:
> Found by Junio:
> Change git-dir to $GIT_DIR and git-file to gitfile.
>
> Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
> ---
> Documentation/git-rev-parse.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
> index c743469..14386ed 100644
> --- a/Documentation/git-rev-parse.txt
> +++ b/Documentation/git-rev-parse.txt
> @@ -187,9 +187,9 @@ print a message to stderr and exit with nonzero status.
> Flags and parameters to be parsed.
>
> --resolve-git-dir <path>::
> - Check if <path> is a valid git-dir or a git-file pointing to a valid
> - git-dir. If <path> is a valid git-dir the resolved path to git-dir will
> - be printed.
> + Check if <path> is a valid `$GIT_DIR` or a gitfile pointing to a valid
> + `$GIT_DIR`. If <path> is a valid `$GIT_DIR` the resolved path to `$GIT_DIR`
> + will be printed.
Hm, I don't find the old or the new version very easy to understand. Perhaps the
idea is something like this?
Check if <path> is a valid git repository (.git or <project>.git
directory) or "gitdir:" file. If <path> is a "gitdir:" file
then the resolved path to the corresponding real git repository
will be printed.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH 5/6] Add a description for 'gitfile' to glossary
From: Jonathan Nieder @ 2013-02-01 19:46 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Ackermann, git, davvid, Lars Hjemli, Jens Lehmann,
Fredrik Gustafsson
In-Reply-To: <7vlib7al90.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> How about saying something like this here in the glossary:
>
> A plain file `.git` at the root of a working tree that
> points at the directory that is the real repository.
>
> And then as a separate patch, in gitrepository-layout.txt (eek---see
> the other thread), we can do something like this:
>
> Documentation/gitrepository-layout.txt | 24 ++++++++++++++++++------
> 1 file changed, 18 insertions(+), 6 deletions(-)
Looks correct and very readable. Thanks.
Jonathan
(patch left unsnipped for reference)
> diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt
> index 9f62886..473c6a0 100644
> --- a/Documentation/gitrepository-layout.txt
> +++ b/Documentation/gitrepository-layout.txt
> @@ -12,12 +12,24 @@ $GIT_DIR/*
> DESCRIPTION
> -----------
>
> -You may find these things in your git repository (`.git`
> -directory for a repository associated with your working tree, or
> -`<project>.git` directory for a public 'bare' repository. It is
> -also possible to have a working tree where `.git` is a plain
> -ASCII file containing `gitdir: <path>`, i.e. the path to the
> -real git repository).
> +A Git repository comes in two different flavours:
> +
> + * a `.git` directory at the root of the working tree;
> +
> + * a `<project>.git` directory that is a 'bare' repository
> + (i.e. without its own working tree), that is typically used for
> + exchanging histories with others by pushing into it and fetching
> + from it.
> +
> +*Note*: Also you can have a plain text file `.git` at the root of
> +your working tree, containing `gitdir: <path>` to point at the real
> +directory that has the repository. This mechanism is often used for
> +a working tree of a submodule checkout, to allow you in the
> +containing superproject to `git checkout` a branch that does not
> +have the submodule. The `checkout` has to remove the entire
> +submodule working tree, without losing the submodule repository.
> +
> +These things may exist in a Git repository.
>
> objects::
> Object store associated with this repository. Usually
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/6] Use consistent links for User Manual and Everyday Git; Fix a quoting error
From: Jonathan Nieder @ 2013-02-01 19:51 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: gitster, git, davvid
In-Reply-To: <549641245.1090170.1359742373184.JavaMail.ngmail@webmail18.arcor-online.net>
Thomas Ackermann wrote:
> --- a/Documentation/git.txt
> +++ b/Documentation/git.txt
> @@ -23,7 +23,7 @@ and full access to internals.
>
> See linkgit:gittutorial[7] to get started, then see
> link:everyday.html[Everyday Git] for a useful minimum set of
> -commands. The link:user-manual.html[Git User's Manual] has a more
> +commands. The link:user-manual.html[The Git User's Manual] has a more
> in-depth introduction.
In the rendered version, this looks like:
The The Git User's Manual[1] has a more in-depth introduction.
Presumably the first "The" should be dropped from either the link or
the surrounding text.
[...]
> --- a/Documentation/gitcore-tutorial.txt
> +++ b/Documentation/gitcore-tutorial.txt
> @@ -17,7 +17,7 @@ work with a Git repository.
>
> If you just need to use Git as a revision control system you may prefer
> to start with "A Tutorial Introduction to Git" (linkgit:gittutorial[7]) or
> -link:user-manual.html[the Git User Manual].
> +link:user-manual.html[The Git User's Manual].
This comes out as
... you may prefer to start with "A Tutorial Instruction to Git"
(gittutorial(7)) or The Git User's Manual[1].
The capital 'T' in "The" looks a bit strange, but a lowercase 't' in
the corresponding footnote would also look strange. We can't have
everything, I guess.
A possible fix would be to drop the "The" from the link. The way you
have it here also seems fine.
[...]
> --- a/Documentation/gittutorial-2.txt
> +++ b/Documentation/gittutorial-2.txt
> @@ -406,7 +406,7 @@ pages for any of the git commands; one good place to start would be
> with the commands mentioned in link:everyday.html[Everyday Git]. You
> should be able to find any unknown jargon in linkgit:gitglossary[7].
>
> -The link:user-manual.html[Git User's Manual] provides a more
> +The link:user-manual.html[The Git User's Manual] provides a more
> comprehensive introduction to Git.
Doubled 'The'.
[...]
> --- a/Documentation/gittutorial.txt
> +++ b/Documentation/gittutorial.txt
> @@ -656,7 +656,7 @@ digressions that may be interesting at this point are:
> * linkgit:gitworkflows[7]: Gives an overview of recommended
> workflows.
>
> - * link:everyday.html[Everyday Git with 20 Commands Or So]
> + * link:everyday.html[Everyday Git]
Isn't the old title more informative?
Thanks and hope that helps,
Jonathan
^ permalink raw reply
* Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with
From: Sebastian Schuberth @ 2013-02-01 20:07 UTC (permalink / raw)
To: Sven Strickroth; +Cc: git, Junio C Hamano, David Aguilar, Jeff King
In-Reply-To: <510C1872.3090304@tu-clausthal.de>
On Fri, Feb 1, 2013 at 8:33 PM, Sven Strickroth
<sven.strickroth@tu-clausthal.de> wrote:
> TortoiseGitMerge, unlike TortoiseMerge, can be told to handle paths
> with spaces in them by using -option "$FILE" (not -option:"$FILE",
> which does not work for such paths) syntax. Both do not have a fully
> posix compatible cli parameter parser, however, TortoiseGitMerge was
> modified in order to handle filenames with spaces correctly. The
> "-key value" form was choosen because this way no escaping for
> quotes within quotes is necessary; see
> https://github.com/msysgit/msysgit/issues/57
The commit message still does not mention MSYS path mangling at all,
which probably is why the reasoning of this patch was not yet fully
understood. I'd recommend something like the following:
mergetools: Teach tortoisemerge about TortoiseGitMerge
TortoiseGitMerge is an improved version of TortoiseMerge specifically
for use with Git on Windows. Due to MSYS path mangling [1], the ":"
after the "base" etc. arguments to TortoiseMerge caused to whole
argument instead of just the file name to be quoted in case of file
names with spaces. So TortoiseMerge was passed
"-base:new file.txt"
instead of
-base:"new file.txt"
(including the quotes). To work around this, TortoiseGitMerge does not
require the ":" after the arguments anymore which fixes handling file
names with spaces.
[1] http://www.mingw.org/wiki/Posix_path_conversion
--
Sebastian Schuberth
^ permalink raw reply
* Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with
From: Junio C Hamano @ 2013-02-01 20:15 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: Sven Strickroth, git, David Aguilar, Jeff King
In-Reply-To: <CAHGBnuNpHtfnD6D+sji6e1yp2x6iLxjAbawwO6USF2iWW17nuQ@mail.gmail.com>
Sebastian Schuberth <sschuberth@gmail.com> writes:
> The commit message still does not mention MSYS path mangling at all,
> which probably is why the reasoning of this patch was not yet fully
> understood.
Ahh, you are very right. I didn't realize that was what this funny
"with colon, with SP" business was about.
> I'd recommend something like the following:
>
> mergetools: Teach tortoisemerge about TortoiseGitMerge
>
> TortoiseGitMerge is an improved version of TortoiseMerge specifically
> for use with Git on Windows. Due to MSYS path mangling [1], the ":"
> after the "base" etc. arguments to TortoiseMerge caused to whole
> argument instead of just the file name to be quoted in case of file
> names with spaces. So TortoiseMerge was passed
>
> "-base:new file.txt"
>
> instead of
>
> -base:"new file.txt"
>
> (including the quotes). To work around this, TortoiseGitMerge does not
> require the ":" after the arguments anymore which fixes handling file
> names with spaces.
>
> [1] http://www.mingw.org/wiki/Posix_path_conversion
Sven?
^ 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