* Re: [PATCH 0/5] Fix msvc build
From: Junio C Hamano @ 2013-01-31 19:28 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Ramsay Jones, GIT Mailing-list, Erik Faye-Lund, Jonathan Nieder,
Johannes Sixt
In-Reply-To: <alpine.DEB.1.00.1301311956470.32206@s15462909.onlinehome-server.info>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi Ramsay,
>
> On Thu, 31 Jan 2013, Ramsay Jones wrote:
>
>> As I mentioned recently, while discussing a cygwin specific patch
>> (see "Version 1.8.1 does not compile on Cygwin 1.7.14" thread), the
>> MSVC build is broken for me.
>>
>> The first 4 patches fix the MSVC build for me. The final patch is
>> not really related to fixing the build, but it removed some make
>> warnings which were quite irritating ...
>
> Thanks!
>
>> Note that I used the Makefile, with the Visual C++ 2008 command line
>> compiler on Windows XP (SP3), to build a vanilla git on MinGW. I'm not
>> subscribed to the msysgit mailing list, nor do I follow the msysgit fork
>> of git, so these patches may conflict with commits in their repository.
>
> Maybe you can Cc: the patch series to msysgit@googlegroups.com
> nevertheless?
OK. The only thing I can say about these patches is that none of
them would affect my boxes would exercise, so I'll wait until I get
a final-for-application re-send from mysgit folks, preferrably with
their Acked-by: lines.
Thanks.
^ permalink raw reply
* Re: Why git-whatchanged shows a commit touching every file, but git-log doesn't?
From: Jonathan Nieder @ 2013-01-31 19:34 UTC (permalink / raw)
To: Constantine A. Murenin; +Cc: git
In-Reply-To: <CAPKkNb49FUgLxZxHmQJoqccQ1XVcFYbYF8kYDp0+Y27cmi56fg@mail.gmail.com>
Hi Constantine,
Constantine A. Murenin wrote:
> DragonFly BSD uses git as its SCM, with one single repository and
> branch for both the kernel and the whole userland.
>
> On 2011-11-26 (1322296064), someone did a commit that somehow touched
> every single file in the repository, even though most of the files
> were not modified one bit.
"gitk --simplify-by-decoration" might provide some insight.
In the dragonfly history, it seems that imports of a packages typically
proceed in two steps:
1. First, the upstream code is imported as a new "initial commit"
with no history:
cd ~/src
git init gcc-4.7.2-import
cd gcc-4.7.2-import
tar -xf /path/to/gcc-4.7.2
mkdir contrib
mv gcc-4.7.2 contrib/gcc-4.7
git add .
git commit -m 'Import gcc-4.7.2 to new vendor branch'
2. Next, that code is incorporated into dragonfly.
cd ~/src/dragonfly
git fetch ../gcc-4.7.2-import master:refs/heads/vendor/GCC47
git merge vendor/GCC47
rm -fr ../gcc-4.7.2-import
Unfortunately in the commit you mentioned, someone made a mistake.
Instead of importing a single new upstream package, the author
imported the entire dragonfly tree as a new vendor branch. Oops.
The effects might be counterintuitive:
* tools like "git blame" and path-limited "git log" get a choice:
when looking at the merge that pulled in a copy of dragonfly into
the existing dragonfly codebase, either parent is an equally
sensible from blame's point of view as an explanation of the origin
of this code. I think both prefer the first parent here, making them
happen to produce the "right" result.
* tools like "git show" that describe what change a commit made
get a choice: when looking at a parentless commit, the diff that
brings a project into existence may or may not be interesting,
depending on the situation.
See
http://thread.gmane.org/gmane.comp.version-control.git/182571/focus=182577
for more about that.
But at its heart, this is just an instance of "lie when creating your
history and history-mining tools will lie back to you." :)
Hoping that clarifies a little,
Jonathan
^ permalink raw reply
* Re: [PATCH] git-send-email: add ~/.authinfo parsing
From: Jeff King @ 2013-01-31 19:38 UTC (permalink / raw)
To: Ted Zlatanov
Cc: Junio C Hamano, Michal Nazarewicz, git, Krzysztof Mazur,
Michal Nazarewicz
In-Reply-To: <87pq0l5qbc.fsf@lifelogs.com>
On Thu, Jan 31, 2013 at 10:23:51AM -0500, Ted Zlatanov wrote:
> Jeff, is there a way for git-credential to currently support
> authinfo/netrc parsing? I assume that's the right way, instead of using
> Michal's proposal to parse internally?
>
> I'd like to add that, plus support for the 'string' and "string"
> formats, and authinfo.gpg decoding through GPG. I'd write it in Perl,
> if there's a choice.
Yes, you could write a credential helper that understands netrc and
friends; git talks to the helpers over a socket, so there is no problem
with writing it in Perl. See Documentation/technical/api-credentials.txt
for an overview, or the sample implementation in credential-store.c for a
simple example.
-Peff
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Junio C Hamano @ 2013-01-31 19:41 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <20130131190747.GE27340@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Junio C Hamano wrote:
>
>> Wow, that's a blast from the past.
>>
>> I tend to agree that deprecating and removing are quite different,
>> but a simple "revert" of the change would not be good, either. We
>> still would want to _discourage_ its use.
>
> Hm, I was about to try adding a line in that vein, like
>
> * `tracking` - deprecated synonym for `upstream`.
>
> Imagine my surprise when I saw that that is what you just said
> would be no good:
>
> [...]
>>>> `git pull`.
>>>> -* `tracking` - deprecated synonym for `upstream`.
>>>> * `current` - push the current branch to a branch of the same name.
>
> I really do think that including `tracking` in the same list would be
> valuable. When I look over a friend's .gitconfig file to help track
> down a problem she is running into, it is helpful if I can find the
> meaning of each item in a straightforward way.
While I agree we would need a way for you to easily find `tracking`
mentioned near that point, listing it as if it is a proper part of
the same list of possibilities is not the only way to do so.
The enumeration is used by two different audiences. For those who
want to _learn_ what possibilities are available to them (i.e. they
are not going from `tracking` to what it means, but going in the
opposite direction), it should be unmistakingly clear that
`tracking` is not a part of the choices they should make. I do not
think the following list created by a simple "revert" makes it clear.
* `nothing` - do not push anything.
* `matching` - push all branches having the same name in both ends.
* `upstream` - push the current branch to ...
* `simple` - like `upstream`, but refuses to ...
* `tracking` - deprecated synonym for `upstream`.
* `current` - push the current branch to a branch of the same name.
When scanning, most people will scan lines to see there are 6
choices without reading anything after '-' first, and then start
reading the item that sounds plausible for them without necessarily
reading the others. That will imprint the word `tracking` in the
context of choosing how to push, especially when that is not what
they end up using.
That is why I tend to prefer how check-ref-format documentation
describes --print:
--normalize::
Normalize 'refname' by removing any leading slash (`/`)
characters and collapsing runs of adjacent slashes between
name components into a single slash. Iff the normalized
refname is valid then print it to standard output and exit
with a status of 0. (`--print` is a deprecated way to spell
`--normalize`.)
When you are going from `tracking` to what it means, you have \C-s
(if you are viewing in Emacs) or '/' (if you are using less)
available.
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Jonathan Nieder @ 2013-01-31 19:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <7vip6dgmx2.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> That is why I tend to prefer how check-ref-format documentation
> describes --print:
>
> --normalize::
> Normalize 'refname' by removing any leading slash (`/`)
> characters and collapsing runs of adjacent slashes between
> name components into a single slash. Iff the normalized
> refname is valid then print it to standard output and exit
> with a status of 0. (`--print` is a deprecated way to spell
> `--normalize`.)
That works because, as you mention, the usual way to look up an option
in manpages is to search for "--print", including the two minus signs.
Unfortunately an analagous approach in gitconfig(5) would be seriously
broken, because searching for "tracking" (no minus signs) is going to
hit many false positives. I do not think such a change would be an
improvement.
Meanwhile I believe the prominent words "deprecated synonym" already
make it completely obvious that when I write a new config file, I should
use the modern option, unless I am trying to write a config file that
also works with older versions of git. In the latter case (which
unfortunately is not too uncommon), hiding the option is not going to
make my life easier. What would allow me to make an informed choice
is mentioning what version of git *introduced* the new name of the
option:
- `tracking` - deprecated old name for `upstream`, used by git
versions before 1.7.4.2. Don't use this.
Also I do not think anyone claimed we are removing "tracking" from the
documentation in order to stop people from using it. The rationale
when the patch was proposed is that it makes the documentation easier
to read. I agree with that rationale, with the caveat Avar mentioned.
There is a simple fix: just simplify the behavior being explained as
well, by biting the bullet and dropping the "tracking" synonym after a
suitable period in which it produces a warning.
In the meantime, the documentation is valuable, and pretending that
"tracking" does not exist for everyone who does not confusedly reread
the docs a few times is just a way to lie to ourselves and make users'
lives more difficult. Is that really the intent?
Jonathan
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Junio C Hamano @ 2013-01-31 19:58 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <20130131191105.GF27340@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Jonathan Nieder wrote:
>
>> Is the problem that "deprecated" is not precise enough? For example,
>> would it make sense to say "deprecated synonym for `upstream`. Will
>> be dropped in git 2.1" or something like that?
>
> Also, if we plan to remove support soon, we should start warning when
> this setting is encountered so people know to update their
> configuration.
I do not think this even needs to be removed.
We deprecate something for one of two reasons. One is when it was a
bad idea to support it, and we would want to remove the support
eventually. This needs a migration plan.
The other is when there are better ways available but we do not want
to break the old way. We still do not want to encourage the old way
to new users.
The change from 'upstream' from 'tracking' is the latter. The
wording will confuse new users when they want to learn what
'tracking' as a concept is, and it is better spelt 'upstream'. But
the breakage is not serious enough to warrant forcing an old timer
who can explain these two concepts to newbies when needed to update
his configuration files he is not planning to show to newbies.
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Junio C Hamano @ 2013-01-31 20:01 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <20130131195712.GH27340@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Junio C Hamano wrote:
>
>> That is why I tend to prefer how check-ref-format documentation
>> describes --print:
>>
>> --normalize::
>> Normalize 'refname' by removing any leading slash (`/`)
>> characters and collapsing runs of adjacent slashes between
>> name components into a single slash. Iff the normalized
>> refname is valid then print it to standard output and exit
>> with a status of 0. (`--print` is a deprecated way to spell
>> `--normalize`.)
>
> That works because, as you mention, the usual way to look up an option
> in manpages is to search for "--print", including the two minus signs.
>
> Unfortunately an analagous approach in gitconfig(5) would be seriously
> broken, because searching for "tracking" (no minus signs) is going to
> hit many false positives. I do not think such a change would be an
> improvement.
I thought your example was that you saw "pull.default = tracking"
and wondering what it is. Why do you need global search for
"tracking", not just near pull.default is described, in the first
place?
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Jonathan Nieder @ 2013-01-31 20:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <7vip6dgmx2.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> For those who
> want to _learn_ what possibilities are available to them (i.e. they
> are not going from `tracking` to what it means, but going in the
> opposite direction), it should be unmistakingly clear that
> `tracking` is not a part of the choices they should make.
Until pre-1.7.4 versions of git fall out of use, I don't agree that
the above is true. :(
> I do not
> think the following list created by a simple "revert" makes it clear.
>
> * `nothing` - do not push anything.
> * `matching` - push all branches having the same name in both ends.
> * `upstream` - push the current branch to ...
> * `simple` - like `upstream`, but refuses to ...
> * `tracking` - deprecated synonym for `upstream`.
> * `current` - push the current branch to a branch of the same name.
How about the following?
* `nothing` - ...
* `matching` - ...
* `upstream` - ...
* `simple` - ...
* `current` - ...
For compatibility with ancient config files, the following synonym
is also supported. Don't use it.
* `tracking` - old name for `upstream`
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Matthieu Moy @ 2013-01-31 20:08 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Ævar Arnfjörð Bjarmason, git,
Jeff King, Michael Haggerty
In-Reply-To: <20130131200434.GI27340@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> How about the following?
>
> * `nothing` - ...
> * `matching` - ...
> * `upstream` - ...
> * `simple` - ...
> * `current` - ...
>
> For compatibility with ancient config files, the following synonym
> is also supported. Don't use it.
>
> * `tracking` - old name for `upstream`
Sounds good to me.
I'm the author of the removal patch, but the patch was just part of a
larger serie explaining push.default, the idea of cleaning up the
obsolete alias came in the discussion and I did it, but I'm fine with
reintroducing it in the doc (as long as it does not disturb new users
too much).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Jonathan Nieder @ 2013-01-31 20:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <7va9rpgm06.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> That works because, as you mention, the usual way to look up an option
>> in manpages is to search for "--print", including the two minus signs.
>>
>> Unfortunately an analagous approach in gitconfig(5) would be seriously
>> broken, because searching for "tracking" (no minus signs) is going to
>> hit many false positives. I do not think such a change would be an
>> improvement.
>
> I thought your example was that you saw "pull.default = tracking"
> and wondering what it is. Why do you need global search for
> "tracking", not just near pull.default is described, in the first
> place?
Because the UI for local searches in web browsers and man pagers is
seriously lacking. Or, because people have bad habits and do not
take apppropriate advantage of search in small subsections of a
document. All I know is that I have seen myself and others doing
searches analagous to "--print" and not seen searches analagous to
"tracking".
Am I really the only one that doesn't see the "--print" change as
hiding an option and sees burying "tracking" in the text as
qualitatively different?
Jonathan
^ permalink raw reply
* [PATCH] gitremote-helpers.txt: rename from git-remote-helpers.txt
From: John Keeping @ 2013-01-31 20:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Max Horn, Matthieu Moy
In-Reply-To: <7vfw1ijtz2.fsf@alter.siamese.dyndns.org>
When looking up a topic via "git help <topic>", git-help prepends "git-"
to topics that are the names of commands (either builtin or found on the
path) and "git" (no hyphen) to any other topic name.
"git-remote-helpers" is not the name of a command, so "git help
remote-helpers" looks for "gitremote-helpers" and does not find it.
Fix this by renaming "git-remote-helpers.txt" to
"gitremote-helpers.txt".
Signed-off-by: John Keeping <john@keeping.me.uk>
---
On Wed, Jan 30, 2013 at 12:28:49PM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
> >
> > Does this mean that "git-remote-helpers.txt" should lose the first
> > hyphen or is help.c not being clever enough in some way?
>
> I think it is the former. "git help tutorial" works exactly the
> same way.
This is the patch to rename it to "gitremote-helpers.txt".
Would we want to do something to avoid breaking links to the existing
document as well?
Documentation/git-remote-testgit.txt | 2 +-
Documentation/{git-remote-helpers.txt => gitremote-helpers.txt} | 6 +++---
Documentation/urls.txt | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
rename Documentation/{git-remote-helpers.txt => gitremote-helpers.txt} (99%)
diff --git a/Documentation/git-remote-testgit.txt b/Documentation/git-remote-testgit.txt
index 612a625..f791d73 100644
--- a/Documentation/git-remote-testgit.txt
+++ b/Documentation/git-remote-testgit.txt
@@ -23,7 +23,7 @@ The best way to learn more is to read the comments and source code in
SEE ALSO
--------
-linkgit:git-remote-helpers[1]
+linkgit:gitremote-helpers[1]
GIT
---
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/gitremote-helpers.txt
similarity index 99%
rename from Documentation/git-remote-helpers.txt
rename to Documentation/gitremote-helpers.txt
index e36fdcb..0c91aba 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/gitremote-helpers.txt
@@ -1,9 +1,9 @@
-git-remote-helpers(1)
-=====================
+gitremote-helpers(1)
+====================
NAME
----
-git-remote-helpers - Helper programs to interact with remote repositories
+gitremote-helpers - Helper programs to interact with remote repositories
SYNOPSIS
--------
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 539c0a0..3ca122f 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -55,7 +55,7 @@ may be used:
where <address> may be a path, a server and path, or an arbitrary
URL-like string recognized by the specific remote helper being
-invoked. See linkgit:git-remote-helpers[1] for details.
+invoked. See linkgit:gitremote-helpers[1] for details.
If there are a large number of similarly-named remote repositories and
you want to use a different format for them (such that the URLs you
--
1.8.1.1
^ permalink raw reply related
* Re: [PATCH] gitremote-helpers.txt: rename from git-remote-helpers.txt
From: Matthieu Moy @ 2013-01-31 20:18 UTC (permalink / raw)
To: John Keeping; +Cc: git, Junio C Hamano, Max Horn
In-Reply-To: <fc96ae61bb64ce19e856d7a1624e2130c99afd47.1359662569.git.john@keeping.me.uk>
John Keeping <john@keeping.me.uk> writes:
> Would we want to do something to avoid breaking links to the existing
> document as well?
That would be nice to add a new git-remote-helpers.txt saying "document
has moved, see linkgit:gitremote-helpers.txt[1], so that HTML links to
http://git-scm.com/docs/git-remote-helpers and friends do not get
broken, yes.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Junio C Hamano @ 2013-01-31 20:21 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <20130131200434.GI27340@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Junio C Hamano wrote:
>
>> For those who
>> want to _learn_ what possibilities are available to them (i.e. they
>> are not going from `tracking` to what it means, but going in the
>> opposite direction), it should be unmistakingly clear that
>> `tracking` is not a part of the choices they should make.
>
> Until pre-1.7.4 versions of git fall out of use, I don't agree that
> the above is true. :(
The documentation ships with the version that the above is true. We
are not making an update to documentation that comes with ancient
versions.
>> I do not
>> think the following list created by a simple "revert" makes it clear.
>>
>> * `nothing` - do not push anything.
>> * `matching` - push all branches having the same name in both ends.
>> * `upstream` - push the current branch to ...
>> * `simple` - like `upstream`, but refuses to ...
>> * `tracking` - deprecated synonym for `upstream`.
>> * `current` - push the current branch to a branch of the same name.
>
> How about the following?
>
> * `nothing` - ...
> * `matching` - ...
> * `upstream` - ...
> * `simple` - ...
> * `current` - ...
>
> For compatibility with ancient config files, the following synonym
> is also supported. Don't use it.
>
> * `tracking` - old name for `upstream`
Didn't I say I am fine to mention it "as a side note" in the
original message you started responding to?
^ permalink raw reply
* Re: [PATCH] gitremote-helpers.txt: rename from git-remote-helpers.txt
From: Junio C Hamano @ 2013-01-31 20:36 UTC (permalink / raw)
To: Matthieu Moy; +Cc: John Keeping, git, Max Horn
In-Reply-To: <vpqpq0lw1ge.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> John Keeping <john@keeping.me.uk> writes:
>
>> Would we want to do something to avoid breaking links to the existing
>> document as well?
>
> That would be nice to add a new git-remote-helpers.txt saying "document
> has moved, see linkgit:gitremote-helpers.txt[1], so that HTML links to
> http://git-scm.com/docs/git-remote-helpers and friends do not get
> broken, yes.
Yeah, John's patch fixes internal links, but this will make links
from other sites stale. Adding to our installation rule to put a
handcrafted HTML page that says "The document moved here; please let
the owners of the referring site to know so that they can update the
link you clicked to get here" would be appropriate, I think.
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Philip Oakley @ 2013-01-31 20:41 UTC (permalink / raw)
To: Jonathan Nieder, Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <20130131200434.GI27340@google.com>
From: "Jonathan Nieder" <jrnieder@gmail.com>
Sent: Thursday, January 31, 2013 8:04 PM
> Junio C Hamano wrote:
>
>> For those who
>> want to _learn_ what possibilities are available to them (i.e. they
>> are not going from `tracking` to what it means, but going in the
>> opposite direction), it should be unmistakingly clear that
>> `tracking` is not a part of the choices they should make.
>
> Until pre-1.7.4 versions of git fall out of use, I don't agree that
> the above is true. :(
>
>
>> I do not
>> think the following list created by a simple "revert" makes it clear.
>>
>> * `nothing` - do not push anything.
>> * `matching` - push all branches having the same name in both
>> ends.
>> * `upstream` - push the current branch to ...
>> * `simple` - like `upstream`, but refuses to ...
>> * `tracking` - deprecated synonym for `upstream`.
>From a simple user perspective, I'd simply place it, in brackets and at
the end of the list.
e.g. [* `tracking` - deprecated synonym for `upstream`.]
The leading bracket makes it obvious that it's different, and that the
description needs to be read, rather than folk simply re-using a half
remembered option, gleaned from an old blog.
However formatting the leading bracket may not be as easy as the plain
text version.
>> * `current` - push the current branch to a branch of the same
>> name.
>
> How about the following?
>
> * `nothing` - ...
> * `matching` - ...
> * `upstream` - ...
> * `simple` - ...
> * `current` - ...
>
> For compatibility with ancient config files, the following synonym
> is also supported. Don't use it.
>
> * `tracking` - old name for `upstream`
? s/old/deprecated/ or s/old/outdated/ for those who don't understand
the jargon.
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Junio C Hamano @ 2013-01-31 20:42 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <20130131201144.GJ27340@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Am I really the only one that doesn't see the "--print" change as
> hiding an option and sees burying "tracking" in the text as
> qualitatively different?
Sorry, but I do not understand the question.
We are hiding/burying the "--print" option to make it clear that it
is not a member with the same footing as others belonging to the
group of options to the command. It is accepted, but there is no
reason for the user to choose it over --normalize.
We want to make sure that "tracking" does not appear as if it is a
member of the pull.default set with equal rights as others. It is
accepted, but there is no reason for the user to choose it over
"upstream".
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Junio C Hamano @ 2013-01-31 20:44 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <7vwqutf5jv.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> Am I really the only one that doesn't see the "--print" change as
>> hiding an option and sees burying "tracking" in the text as
>> qualitatively different?
>
> Sorry, but I do not understand the question.
>
> We are hiding/burying the "--print" option to make it clear that it
> is not a member with the same footing as others belonging to the
> group of options to the command. It is accepted, but there is no
> reason for the user to choose it over --normalize.
>
> We want to make sure that "tracking" does not appear as if it is a
> member of the pull.default set with equal rights as others. It is
> accepted, but there is no reason for the user to choose it over
> "upstream".
Now I re-read the proposed update, I think it is an improvement over
a straight revert in that it makes it clear that 'tracking' does not
belong, but I still think it is better to make it a sidenote to the
'upstream'. It makes the connection between the two stronger.
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Junio C Hamano @ 2013-01-31 20:50 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <7v622dgl2o.fsf@alter.siamese.dyndns.org>
How about doing it this way? I do not think anything that is
deprecated even deserves a separate section and "do not use it!"
heading.
-- >8 --
When looking at a configuration file edited long time ago, a user
may find 'pull.default = tracking' and wonder what it means.
Instead of not mentioning it, add it to the description in a way
that makes it clear that users have no reason to add new uses of it
preferring over 'upstream'.
Documentation/config.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d7ec507..8441050 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1795,7 +1795,8 @@ push.default::
+
This is currently the default, but Git 2.0 will change the default
to `simple`.
-* `upstream` - push the current branch to its upstream branch.
+* `upstream` - push the current branch to its upstream branch
+ (`tracking` is a deprecated synonym for this).
With this, `git push` will update the same remote ref as the one which
is merged by `git pull`, making `push` and `pull` symmetrical.
See "branch.<name>.merge" for how to configure the upstream branch.
^ permalink raw reply related
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Jonathan Nieder @ 2013-01-31 21:00 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <7vobg5f55t.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> How about doing it this way?
[...]
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1795,7 +1795,8 @@ push.default::
> +
> This is currently the default, but Git 2.0 will change the default
> to `simple`.
> -* `upstream` - push the current branch to its upstream branch.
> +* `upstream` - push the current branch to its upstream branch
> + (`tracking` is a deprecated synonym for this).
I have already explained that I believe this is a bad idea and why and
proposed an alternative. I take it that either we are
miscommunicating or we fundamentally disagree about the role of
documentation. :(
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Jonathan Nieder @ 2013-01-31 21:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <7v622dgl2o.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Junio C Hamano wrote:
>>> For those who
>>> want to _learn_ what possibilities are available to them (i.e. they
>>> are not going from `tracking` to what it means, but going in the
>>> opposite direction), it should be unmistakingly clear that
>>> `tracking` is not a part of the choices they should make.
>>
>> Until pre-1.7.4 versions of git fall out of use, I don't agree that
>> the above is true. :(
>
> The documentation ships with the version that the above is true. We
> are not making an update to documentation that comes with ancient
> versions.
Part of the context that I should have mentioned but didn't is that it
is common to put $HOME on a shared filesystem.
[...]
>> How about the following?
>>
>> * `nothing` - ...
>> * `matching` - ...
>> * `upstream` - ...
>> * `simple` - ...
>> * `current` - ...
>>
>> For compatibility with ancient config files, the following synonym
>> is also supported. Don't use it.
>>
>> * `tracking` - old name for `upstream`
>
> Didn't I say I am fine to mention it "as a side note" in the
> original message you started responding to?
Yes, I understood what you were proposing and I directly disagreed
with it and explained why.
The above is something like a compromise --- more precisely, it is an
attempt to do something better than a straight revert and to
understand whether it would address your objection. Clearly it
doesn't. I don't understand why.
Perhaps the "Don't use it" is over the top and that is your complaint?
It's true that if I were writing it without your objection in mind, I
wouldn't have included that sentence. It was written on the
assumption that you want to discourage people from using the
"tracking" synonym --- I am not personally convinced that that is
worth discouraging at all, but it's fine with me if the consensus is
to do so.
Jonathan
^ permalink raw reply
* [PATCH] Rename {git- => git}remote-helpers.txt
From: John Keeping @ 2013-01-31 21:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Matthieu Moy, Max Horn, John Keeping
In-Reply-To: <7v1ud1gke7.fsf@alter.siamese.dyndns.org>
When looking up a topic via "git help <topic>", git-help prepends "git-"
to topics that are the names of commands (either builtin or found on the
path) and "git" (no hyphen) to any other topic name.
"git-remote-helpers" is not the name of a command, so "git help
remote-helpers" looks for "gitremote-helpers" and does not find it.
Fix this by renaming "git-remote-helpers.txt" to
"gitremote-helpers.txt".
Signed-off-by: John Keeping <john@keeping.me.uk>
---
Changes since v1:
- add gitremote-helpers.txt to the Makefile since it is no longer caught
by git-*.txt.
- add a simple git-remote-helpers.html to help people following links to
the old name.
Documentation/.gitignore | 1 +
Documentation/Makefile | 4 +-
Documentation/git-remote-helpers.html | 55 ++++++++++++++++++++++
Documentation/git-remote-testgit.txt | 2 +-
...it-remote-helpers.txt => gitremote-helpers.txt} | 6 +--
Documentation/urls.txt | 2 +-
6 files changed, 63 insertions(+), 7 deletions(-)
create mode 100644 Documentation/git-remote-helpers.html
rename Documentation/{git-remote-helpers.txt => gitremote-helpers.txt} (99%)
diff --git a/Documentation/.gitignore b/Documentation/.gitignore
index 2c8b2d6..5f479b8 100644
--- a/Documentation/.gitignore
+++ b/Documentation/.gitignore
@@ -1,5 +1,6 @@
*.xml
*.html
+!git-remote-helpers.html
*.[1-8]
*.made
*.texi
diff --git a/Documentation/Makefile b/Documentation/Makefile
index fe6709c..4ccb828 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,7 +1,7 @@
MAN1_TXT= \
$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
$(wildcard git-*.txt)) \
- gitk.txt gitweb.txt git.txt
+ gitk.txt gitweb.txt git.txt gitremote-helpers.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 \
@@ -13,7 +13,7 @@ MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT))
-DOC_HTML=$(MAN_HTML)
+DOC_HTML=$(MAN_HTML) git-remote-helpers.html
ARTICLES = howto-index
ARTICLES += everyday
diff --git a/Documentation/git-remote-helpers.html b/Documentation/git-remote-helpers.html
new file mode 100644
index 0000000..0c5ec27
--- /dev/null
+++ b/Documentation/git-remote-helpers.html
@@ -0,0 +1,55 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
+ "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
+<head>
+<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
+<title>git-remote-helpers(1) - Document Moved</title>
+<style type="text/css">
+/* Cut-down styles from asciidoc.css. */
+
+/* Default font. */
+body {
+ font-family: Georgia,serif;
+}
+
+/* Title font. */
+h1 {
+ font-family: Arial,Helvetica,sans-serif;
+}
+
+body {
+ margin: 1em 5% 1em 5%;
+}
+
+a {
+ color: blue;
+ text-decoration: underline;
+}
+a:visited {
+ color: fuchsia;
+}
+
+h1, h2, h3, h4, h5, h6 {
+ color: #527bbd;
+ margin-top: 1.2em;
+ margin-bottom: 0.5em;
+ line-height: 1.3;
+}
+
+</style>
+</head>
+<body class="manpage">
+<div id="header">
+<h1>
+Document Moved
+</h1>
+</div>
+
+<p>This document is now called <a
+href="gitremote-helpers.html">gitremote-helpers</a>.</p>
+
+<p>Please let the owners of the referring site know so that they can update the
+link you clicked to get here.</p>
+
+</body>
+</html>
diff --git a/Documentation/git-remote-testgit.txt b/Documentation/git-remote-testgit.txt
index 612a625..f791d73 100644
--- a/Documentation/git-remote-testgit.txt
+++ b/Documentation/git-remote-testgit.txt
@@ -23,7 +23,7 @@ The best way to learn more is to read the comments and source code in
SEE ALSO
--------
-linkgit:git-remote-helpers[1]
+linkgit:gitremote-helpers[1]
GIT
---
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/gitremote-helpers.txt
similarity index 99%
rename from Documentation/git-remote-helpers.txt
rename to Documentation/gitremote-helpers.txt
index e36fdcb..0c91aba 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/gitremote-helpers.txt
@@ -1,9 +1,9 @@
-git-remote-helpers(1)
-=====================
+gitremote-helpers(1)
+====================
NAME
----
-git-remote-helpers - Helper programs to interact with remote repositories
+gitremote-helpers - Helper programs to interact with remote repositories
SYNOPSIS
--------
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 539c0a0..3ca122f 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -55,7 +55,7 @@ may be used:
where <address> may be a path, a server and path, or an arbitrary
URL-like string recognized by the specific remote helper being
-invoked. See linkgit:git-remote-helpers[1] for details.
+invoked. See linkgit:gitremote-helpers[1] for details.
If there are a large number of similarly-named remote repositories and
you want to use a different format for them (such that the URLs you
--
1.8.1.1
^ permalink raw reply related
* [PATCH] Verify Content-Type from smart HTTP servers
From: Junio C Hamano @ 2013-01-31 22:09 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
Before parsing a suspected smart-HTTP response verify the returned
Content-Type matches the standard. This protects a client from
attempting to process a payload that smells like a smart-HTTP
server response.
JGit has been doing this check on all responses since the dawn of
time. I mistakenly failed to include it in git-core when smart HTTP
was introduced. At the time I didn't know how to get the Content-Type
from libcurl. I punted, meant to circle back and fix this, and just
plain forgot about it.
Signed-off-by: Shawn Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* The original was picked up by majordomo taboo rules; resending
after minor style fix.
Was there a report of an attempted attack by malicious server or
something that triggered this, or is this just a "common sense
thing to do" in general?
http-push.c | 4 ++--
http.c | 31 ++++++++++++++++++++++---------
http.h | 2 +-
remote-curl.c | 15 +++++++++++----
t/lib-httpd.sh | 1 +
t/lib-httpd/apache.conf | 4 ++++
t/lib-httpd/broken-smart-http.sh | 11 +++++++++++
t/t5551-http-fetch.sh | 6 ++++++
8 files changed, 58 insertions(+), 16 deletions(-)
create mode 100755 t/lib-httpd/broken-smart-http.sh
diff --git a/http-push.c b/http-push.c
index 8701c12..ba45b7b 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1560,7 +1560,7 @@ static int remote_exists(const char *path)
sprintf(url, "%s%s", repo->url, path);
- switch (http_get_strbuf(url, NULL, 0)) {
+ switch (http_get_strbuf(url, NULL, NULL, 0)) {
case HTTP_OK:
ret = 1;
break;
@@ -1584,7 +1584,7 @@ static void fetch_symref(const char *path, char **symref, unsigned char *sha1)
url = xmalloc(strlen(repo->url) + strlen(path) + 1);
sprintf(url, "%s%s", repo->url, path);
- if (http_get_strbuf(url, &buffer, 0) != HTTP_OK)
+ if (http_get_strbuf(url, NULL, &buffer, 0) != HTTP_OK)
die("Couldn't get %s for remote symref\n%s", url,
curl_errorstr);
free(url);
diff --git a/http.c b/http.c
index 44f3525..d868d8b 100644
--- a/http.c
+++ b/http.c
@@ -788,7 +788,8 @@ int handle_curl_result(struct slot_results *results)
#define HTTP_REQUEST_STRBUF 0
#define HTTP_REQUEST_FILE 1
-static int http_request(const char *url, void *result, int target, int options)
+static int http_request(const char *url, struct strbuf *type,
+ void *result, int target, int options)
{
struct active_request_slot *slot;
struct slot_results results;
@@ -838,24 +839,36 @@ static int http_request(const char *url, void *result, int target, int options)
ret = HTTP_START_FAILED;
}
+ if (type) {
+ char *t;
+ curl_easy_getinfo(slot->curl, CURLINFO_CONTENT_TYPE, &t);
+ if (t)
+ strbuf_addstr(type, t);
+ }
+
curl_slist_free_all(headers);
strbuf_release(&buf);
return ret;
}
-static int http_request_reauth(const char *url, void *result, int target,
+static int http_request_reauth(const char *url,
+ struct strbuf *type,
+ void *result, int target,
int options)
{
- int ret = http_request(url, result, target, options);
+ int ret = http_request(url, type, result, target, options);
if (ret != HTTP_REAUTH)
return ret;
- return http_request(url, result, target, options);
+ return http_request(url, type, result, target, options);
}
-int http_get_strbuf(const char *url, struct strbuf *result, int options)
+int http_get_strbuf(const char *url,
+ struct strbuf *type,
+ struct strbuf *result, int options)
{
- return http_request_reauth(url, result, HTTP_REQUEST_STRBUF, options);
+ return http_request_reauth(url, type, result,
+ HTTP_REQUEST_STRBUF, options);
}
/*
@@ -878,7 +891,7 @@ static int http_get_file(const char *url, const char *filename, int options)
goto cleanup;
}
- ret = http_request_reauth(url, result, HTTP_REQUEST_FILE, options);
+ ret = http_request_reauth(url, NULL, result, HTTP_REQUEST_FILE, options);
fclose(result);
if ((ret == HTTP_OK) && move_temp_to_file(tmpfile.buf, filename))
@@ -904,7 +917,7 @@ int http_fetch_ref(const char *base, struct ref *ref)
int ret = -1;
url = quote_ref_url(base, ref->name);
- if (http_get_strbuf(url, &buffer, HTTP_NO_CACHE) == HTTP_OK) {
+ if (http_get_strbuf(url, NULL, &buffer, HTTP_NO_CACHE) == HTTP_OK) {
strbuf_rtrim(&buffer);
if (buffer.len == 40)
ret = get_sha1_hex(buffer.buf, ref->old_sha1);
@@ -997,7 +1010,7 @@ int http_get_info_packs(const char *base_url, struct packed_git **packs_head)
strbuf_addstr(&buf, "objects/info/packs");
url = strbuf_detach(&buf, NULL);
- ret = http_get_strbuf(url, &buf, HTTP_NO_CACHE);
+ ret = http_get_strbuf(url, NULL, &buf, HTTP_NO_CACHE);
if (ret != HTTP_OK)
goto cleanup;
diff --git a/http.h b/http.h
index 0a80d30..25d1931 100644
--- a/http.h
+++ b/http.h
@@ -132,7 +132,7 @@ extern char *get_remote_object_url(const char *url, const char *hex,
*
* If the result pointer is NULL, a HTTP HEAD request is made instead of GET.
*/
-int http_get_strbuf(const char *url, struct strbuf *result, int options);
+int http_get_strbuf(const char *url, struct strbuf *content_type, struct strbuf *result, int options);
/*
* Prints an error message using error() containing url and curl_errorstr,
diff --git a/remote-curl.c b/remote-curl.c
index 9a8b123..e6f3b63 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -92,6 +92,8 @@ static void free_discovery(struct discovery *d)
static struct discovery* discover_refs(const char *service)
{
+ struct strbuf exp = STRBUF_INIT;
+ struct strbuf type = STRBUF_INIT;
struct strbuf buffer = STRBUF_INIT;
struct discovery *last = last_discovery;
char *refs_url;
@@ -113,7 +115,7 @@ static struct discovery* discover_refs(const char *service)
}
refs_url = strbuf_detach(&buffer, NULL);
- http_ret = http_get_strbuf(refs_url, &buffer, HTTP_NO_CACHE);
+ http_ret = http_get_strbuf(refs_url, &type, &buffer, HTTP_NO_CACHE);
switch (http_ret) {
case HTTP_OK:
break;
@@ -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);
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')
strbuf_setlen(&buffer, buffer.len - 1);
+ strbuf_reset(&exp);
strbuf_addf(&exp, "# service=%s", service);
if (strbuf_cmp(&exp, &buffer))
die("invalid server response; got '%s'", buffer.buf);
@@ -160,6 +165,8 @@ static struct discovery* discover_refs(const char *service)
}
free(refs_url);
+ strbuf_release(&exp);
+ strbuf_release(&type);
strbuf_release(&buffer);
last_discovery = last;
return last;
diff --git a/t/lib-httpd.sh b/t/lib-httpd.sh
index 02f442b..895b925 100644
--- a/t/lib-httpd.sh
+++ b/t/lib-httpd.sh
@@ -80,6 +80,7 @@ fi
prepare_httpd() {
mkdir -p "$HTTPD_DOCUMENT_ROOT_PATH"
cp "$TEST_PATH"/passwd "$HTTPD_ROOT_PATH"
+ cp "$TEST_PATH"/broken-smart-http.sh "$HTTPD_ROOT_PATH"
ln -s "$LIB_HTTPD_MODULE_PATH" "$HTTPD_ROOT_PATH/modules"
diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
index fe76e84..938b4cf 100644
--- a/t/lib-httpd/apache.conf
+++ b/t/lib-httpd/apache.conf
@@ -62,9 +62,13 @@ Alias /auth/dumb/ www/auth/dumb/
SetEnv GIT_COMMITTER_EMAIL custom@example.com
</LocationMatch>
ScriptAliasMatch /smart_*[^/]*/(.*) ${GIT_EXEC_PATH}/git-http-backend/$1
+ScriptAlias /broken_smart/ broken-smart-http.sh/
<Directory ${GIT_EXEC_PATH}>
Options FollowSymlinks
</Directory>
+<Files broken-smart-http.sh>
+ Options ExecCGI
+</Files>
<Files ${GIT_EXEC_PATH}/git-http-backend>
Options ExecCGI
</Files>
diff --git a/t/lib-httpd/broken-smart-http.sh b/t/lib-httpd/broken-smart-http.sh
new file mode 100755
index 0000000..f7ebfff
--- /dev/null
+++ b/t/lib-httpd/broken-smart-http.sh
@@ -0,0 +1,11 @@
+#!/bin/sh
+printf "Content-Type: text/%s\n" "html"
+echo
+printf "%s\n" "001e# service=git-upload-pack"
+printf "%s" "0000"
+printf "%s%c%s%s\n" \
+ "00a58681d9f286a48b08f37b3a095330da16689e3693 HEAD" \
+ 0 \
+ " include-tag multi_ack_detailed multi_ack ofs-delta" \
+ " side-band side-band-64k thin-pack no-progress shallow no-done "
+printf "%s" "0000"
diff --git a/t/t5551-http-fetch.sh b/t/t5551-http-fetch.sh
index c5cd2e3..cb95b95 100755
--- a/t/t5551-http-fetch.sh
+++ b/t/t5551-http-fetch.sh
@@ -157,6 +157,12 @@ test_expect_success 'GIT_SMART_HTTP can disable smart http' '
test_must_fail git fetch)
'
+test_expect_success 'invalid Content-Type rejected' '
+ echo "fatal: invalid content-type text/html" >expect
+ test_must_fail git clone $HTTPD_URL/broken_smart/repo.git 2>actual
+ test_cmp expect actual
+'
+
test -n "$GIT_TEST_LONG" && test_set_prereq EXPENSIVE
test_expect_success EXPENSIVE 'create 50,000 tags in the repo' '
--
1.8.1.2.605.gb99210a
^ permalink raw reply related
* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: Junio C Hamano @ 2013-01-31 22:13 UTC (permalink / raw)
To: John Keeping; +Cc: git, Matthieu Moy, Max Horn
In-Reply-To: <3f26b82599aa2a45897d345c851fab4751c55810.1359669205.git.john@keeping.me.uk>
John Keeping <john@keeping.me.uk> writes:
> When looking up a topic via "git help <topic>", git-help prepends "git-"
> to topics that are the names of commands (either builtin or found on the
> path) and "git" (no hyphen) to any other topic name.
>
> "git-remote-helpers" is not the name of a command, so "git help
> remote-helpers" looks for "gitremote-helpers" and does not find it.
>
> Fix this by renaming "git-remote-helpers.txt" to
> "gitremote-helpers.txt".
>
> Signed-off-by: John Keeping <john@keeping.me.uk>
>
> ---
> Changes since v1:
>
> - add gitremote-helpers.txt to the Makefile since it is no longer caught
> by git-*.txt.
>
> - add a simple git-remote-helpers.html to help people following links to
> the old name.
Doesn't "make clean" remove the placeholder file?
> Documentation/.gitignore | 1 +
> Documentation/Makefile | 4 +-
> Documentation/git-remote-helpers.html | 55 ++++++++++++++++++++++
> Documentation/git-remote-testgit.txt | 2 +-
> ...it-remote-helpers.txt => gitremote-helpers.txt} | 6 +--
> Documentation/urls.txt | 2 +-
> 6 files changed, 63 insertions(+), 7 deletions(-)
> create mode 100644 Documentation/git-remote-helpers.html
> rename Documentation/{git-remote-helpers.txt => gitremote-helpers.txt} (99%)
>
> diff --git a/Documentation/.gitignore b/Documentation/.gitignore
> index 2c8b2d6..5f479b8 100644
> --- a/Documentation/.gitignore
> +++ b/Documentation/.gitignore
> @@ -1,5 +1,6 @@
> *.xml
> *.html
> +!git-remote-helpers.html
> *.[1-8]
> *.made
> *.texi
> diff --git a/Documentation/Makefile b/Documentation/Makefile
> index fe6709c..4ccb828 100644
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -1,7 +1,7 @@
> MAN1_TXT= \
> $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
> $(wildcard git-*.txt)) \
> - gitk.txt gitweb.txt git.txt
> + gitk.txt gitweb.txt git.txt gitremote-helpers.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 \
> @@ -13,7 +13,7 @@ MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
> MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
> MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT))
>
> -DOC_HTML=$(MAN_HTML)
> +DOC_HTML=$(MAN_HTML) git-remote-helpers.html
>
> ARTICLES = howto-index
> ARTICLES += everyday
> diff --git a/Documentation/git-remote-helpers.html b/Documentation/git-remote-helpers.html
> new file mode 100644
> index 0000000..0c5ec27
> --- /dev/null
> +++ b/Documentation/git-remote-helpers.html
> @@ -0,0 +1,55 @@
> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
> + "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
> +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
> +<head>
> +<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
> +<title>git-remote-helpers(1) - Document Moved</title>
> +<style type="text/css">
> +/* Cut-down styles from asciidoc.css. */
> +
> +/* Default font. */
> +body {
> + font-family: Georgia,serif;
> +}
> +
> +/* Title font. */
> +h1 {
> + font-family: Arial,Helvetica,sans-serif;
> +}
> +
> +body {
> + margin: 1em 5% 1em 5%;
> +}
> +
> +a {
> + color: blue;
> + text-decoration: underline;
> +}
> +a:visited {
> + color: fuchsia;
> +}
> +
> +h1, h2, h3, h4, h5, h6 {
> + color: #527bbd;
> + margin-top: 1.2em;
> + margin-bottom: 0.5em;
> + line-height: 1.3;
> +}
> +
> +</style>
> +</head>
> +<body class="manpage">
> +<div id="header">
> +<h1>
> +Document Moved
> +</h1>
> +</div>
> +
> +<p>This document is now called <a
> +href="gitremote-helpers.html">gitremote-helpers</a>.</p>
> +
> +<p>Please let the owners of the referring site know so that they can update the
> +link you clicked to get here.</p>
> +
> +</body>
> +</html>
> diff --git a/Documentation/git-remote-testgit.txt b/Documentation/git-remote-testgit.txt
> index 612a625..f791d73 100644
> --- a/Documentation/git-remote-testgit.txt
> +++ b/Documentation/git-remote-testgit.txt
> @@ -23,7 +23,7 @@ The best way to learn more is to read the comments and source code in
>
> SEE ALSO
> --------
> -linkgit:git-remote-helpers[1]
> +linkgit:gitremote-helpers[1]
>
> GIT
> ---
> diff --git a/Documentation/git-remote-helpers.txt b/Documentation/gitremote-helpers.txt
> similarity index 99%
> rename from Documentation/git-remote-helpers.txt
> rename to Documentation/gitremote-helpers.txt
> index e36fdcb..0c91aba 100644
> --- a/Documentation/git-remote-helpers.txt
> +++ b/Documentation/gitremote-helpers.txt
> @@ -1,9 +1,9 @@
> -git-remote-helpers(1)
> -=====================
> +gitremote-helpers(1)
> +====================
>
> NAME
> ----
> -git-remote-helpers - Helper programs to interact with remote repositories
> +gitremote-helpers - Helper programs to interact with remote repositories
>
> SYNOPSIS
> --------
> diff --git a/Documentation/urls.txt b/Documentation/urls.txt
> index 539c0a0..3ca122f 100644
> --- a/Documentation/urls.txt
> +++ b/Documentation/urls.txt
> @@ -55,7 +55,7 @@ may be used:
>
> where <address> may be a path, a server and path, or an arbitrary
> URL-like string recognized by the specific remote helper being
> -invoked. See linkgit:git-remote-helpers[1] for details.
> +invoked. See linkgit:gitremote-helpers[1] for details.
>
> If there are a large number of similarly-named remote repositories and
> you want to use a different format for them (such that the URLs you
^ permalink raw reply
* Re: [PATCH] gitremote-helpers.txt: rename from git-remote-helpers.txt
From: Tomas Carnecky @ 2013-01-31 22:28 UTC (permalink / raw)
To: John Keeping, git; +Cc: Junio C Hamano, Max Horn, Matthieu Moy
In-Reply-To: <fc96ae61bb64ce19e856d7a1624e2130c99afd47.1359662569.git.john@keeping.me.uk>
On Thu, 31 Jan 2013 20:08:14 +0000, John Keeping <john@keeping.me.uk> wrote:
> This is the patch to rename it to "gitremote-helpers.txt".
>
> Documentation/{git-remote-helpers.txt => gitremote-helpers.txt} | 6 +++---
It feels somewhat weird to have 'git-remote' but 'gitremote-helpers'.
^ permalink raw reply
* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: John Keeping @ 2013-01-31 22:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthieu Moy, Max Horn
In-Reply-To: <7vy5f9dmrt.fsf@alter.siamese.dyndns.org>
On Thu, Jan 31, 2013 at 02:13:10PM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
>
> > When looking up a topic via "git help <topic>", git-help prepends "git-"
> > to topics that are the names of commands (either builtin or found on the
> > path) and "git" (no hyphen) to any other topic name.
> >
> > "git-remote-helpers" is not the name of a command, so "git help
> > remote-helpers" looks for "gitremote-helpers" and does not find it.
> >
> > Fix this by renaming "git-remote-helpers.txt" to
> > "gitremote-helpers.txt".
> >
> > Signed-off-by: John Keeping <john@keeping.me.uk>
> >
> > ---
> > Changes since v1:
> >
> > - add gitremote-helpers.txt to the Makefile since it is no longer caught
> > by git-*.txt.
> >
> > - add a simple git-remote-helpers.html to help people following links to
> > the old name.
>
> Doesn't "make clean" remove the placeholder file?
Yes. Should I change it to "git-remote-helpers.html.in" and then copy
it into place? That seems like the simplest answer and means that
"*.html" will continue to refer only to generated files.
John
^ 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