* 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
* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: Jeff King @ 2013-01-31 22:33 UTC (permalink / raw)
To: John Keeping; +Cc: git, Junio C Hamano, Matthieu Moy, Max Horn
In-Reply-To: <3f26b82599aa2a45897d345c851fab4751c55810.1359669205.git.john@keeping.me.uk>
On Thu, Jan 31, 2013 at 09:59:50PM +0000, John Keeping wrote:
> 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".
Maybe it is just me, but the fact that accessing the manpage is now:
man gitremote-helpers
feels weird to me. I know it technically follows our syntactic rules,
but having the lack of dash be significant between "git" and "remote",
but then having a dash later makes it hard on the eyes.
Would it make more sense to just call it "gitremotehelpers", and then
access it as:
git help remotehelpers
or
man gitremotehelpers
?
That has it its own ugliness (two words run together), but at least my
version of man will accept arbitrary capitalization, allowing:
git help remoteHelpers
and
man gitremoteHelpers
I dunno.
-Peff
^ permalink raw reply
* Re: [PATCH 2/3] run-command: Be more informative about what failed
From: Jeff King @ 2013-01-31 22:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Boyd, git
In-Reply-To: <7vfw1hiami.fsf@alter.siamese.dyndns.org>
On Thu, Jan 31, 2013 at 08:24:21AM -0800, Junio C Hamano wrote:
> Stephen Boyd <sboyd@codeaurora.org> writes:
>
> > While debugging an error with verify_signed_buffer() the error
> > messages from run-command weren't very useful:
> >
> > error: cannot create pipe for gpg: Too many open files
> > error: could not run gpg.
> >
> > because they didn't indicate *which* pipe couldn't be created.
>
> For the message emitted here with your update (or without for that
> matter) to be useful, it has to hold that there is a single leaker,
> that leaker fails in this codepath, and that there is nobody else
> involved. Otherwise, you may be able to tell that one caller could
> not create its stdin, but the reason it couldn't may be because
> somebody else consumed all the available file descriptors.
>
> I am not opposed to this change per-se, but I am not sure that
> saying "stdin" etc. makes the message more useful for the purpose of
> debugging.
Yeah, I had the same feeling. All that failed is pipe(), which does not
have anything to do with what we are going to use the pipe for. So it
gives some context, perhaps, but does not necessarily tell us anything
useful.
But it is not much code, and sometimes it is surprising what information
can be helpful when debugging, so like you, I am not opposed, just
doubtful.
-Peff
^ permalink raw reply
* Re: [PATCH] Verify Content-Type from smart HTTP servers
From: Shawn Pearce @ 2013-01-31 22:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd2wlf1zf.fsf@alter.siamese.dyndns.org>
On Thu, Jan 31, 2013 at 1:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
>> 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>
>> ---
>
> Sounds sensible. Was there a report of attack attempts by malicious
> servers or something, or is it just a general "common sense" thing?
Common-sense cleanup.
I had a report a while ago about JGit not working with the Git servers
at Codeplex. This failure was caused by their HTTP servers returning
an invalid Content-Type, making JGit refuse to continue parsing. This
has since been fixed, I verified this morning that Codeplex is
returning the correct Content-Type.
^ permalink raw reply
* Re: [PATCHv2 1/3] gpg: Close stderr once finished with it in verify_signed_buffer()
From: Jeff King @ 2013-01-31 22:37 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <1359656320-4434-1-git-send-email-sboyd@codeaurora.org>
On Thu, Jan 31, 2013 at 10:18:40AM -0800, Stephen Boyd wrote:
> Failing to close the stderr pipe in verify_signed_buffer() causes
> git to run out of file descriptors if there are many calls to
> verify_signed_buffer(). An easy way to trigger this is to run
>
> git log --show-signature --merges | grep "key"
>
> on the linux kernel git repo. Eventually it will fail with
>
> error: cannot create pipe for gpg: Too many open files
> error: could not run gpg.
>
> Close the stderr pipe so that this can't happen.
>
> Suggested-by: Jeff King <peff@peff.net>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Thanks, looks good to me (obviously :) ). The rest of the series looks
fine, too, with the caveat I mentioned on 2/3. Thanks for fixing this.
-Peff
^ permalink raw reply
* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: Junio C Hamano @ 2013-01-31 22:43 UTC (permalink / raw)
To: John Keeping; +Cc: git, Matthieu Moy, Max Horn
In-Reply-To: <20130131222817.GP1342@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> 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.
I'd like to see if we can have a way to keep its look as the default
css gets updated without maintainance burden.
How about using AsciiDoc instead of "cp", perhaps like this on top
of your patch?
Documentation/.gitignore | 1 -
Documentation/Makefile | 9 +++++-
Documentation/git-remote-helpers.txto | 26 +++++++++++++++++
Documentation/git-remote-helpers.html | 55 -----------------------------------
4 files changed, 34 insertions(+), 57 deletions(-)
diff --git a/Documentation/.gitignore b/Documentation/.gitignore
index 4685378..d62aebd 100644
--- a/Documentation/.gitignore
+++ b/Documentation/.gitignore
@@ -1,6 +1,5 @@
*.xml
*.html
-!git-remote-helpers.html
*.[1-8]
*.made
*.texi
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 13e0098..fa2f9f9 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -13,7 +13,8 @@ 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) git-remote-helpers.html
+OBSOLETE_HTML = git-remote-helpers.html
+DOC_HTML=$(MAN_HTML) $(OBSOLETE_HTML)
ARTICLES = howto-index
ARTICLES += everyday
@@ -261,6 +262,12 @@ $(MAN_HTML): %.html : %.txt asciidoc.conf
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \
mv $@+ $@
+$(OBSOLETE_HTML): %.html : %.txto asciidoc.conf
+ $(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
+ $(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
+ $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \
+ mv $@+ $@
+
manpage-base-url.xsl: manpage-base-url.xsl.in
sed "s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|" $< > $@
diff --git a/Documentation/git-remote-helpers.txto b/Documentation/git-remote-helpers.txto
new file mode 100644
index 0000000..a966013
--- /dev/null
+++ b/Documentation/git-remote-helpers.txto
@@ -0,0 +1,25 @@
+git-remote-helpers(1)
+=====================
+
+NAME
+----
+git-remote-helpers - obsoleted page
+
+SYNOPSIS
+--------
+See linkgit:gitremote-helpers[1].
+
+DESCRIPTION
+-----------
+This document has been moved to linkgit:gitremote-helpers[1].
+
+Please let the owners of the referring site know so that they can update the
+link you clicked to get here.
+
+SEE ALSO
+--------
+linkgit:gitremote-helpers[1]
+
+GIT
+---
+No longer a part of the linkgit:git[1] suite
diff --git a/Documentation/git-remote-helpers.html b/Documentation/git-remote-helpers.html
deleted file mode 100644
index 0c5ec27..0000000
--- a/Documentation/git-remote-helpers.html
+++ /dev/null
@@ -1,55 +0,0 @@
-<!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>
^ permalink raw reply related
* Re: [PATCH] gitremote-helpers.txt: rename from git-remote-helpers.txt
From: Junio C Hamano @ 2013-01-31 22:45 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: John Keeping, git, Max Horn, Matthieu Moy
In-Reply-To: <1359671290-ner-7089@calvin>
Tomas Carnecky <tomas.carnecky@gmail.com> writes:
> 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'.
But the remote helpers are not helpers to "git remote" (which is
essentially a glorified wrapper around "git config -l remote.*").
^ permalink raw reply
* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: Junio C Hamano @ 2013-01-31 22:48 UTC (permalink / raw)
To: Jeff King; +Cc: John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130131223305.GB21729@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Maybe it is just me, but the fact that accessing the manpage is now:
>
> man gitremote-helpers
>
> feels weird to me.
It feels equally weird to say "man gitremotehelpers" (or in general
"man git-thing" or "man gitconcept"), to me. I gave up and switched
to "git help remote-helpers" some time ago. "git help remotehelpers"
feels like a small regression.
> I dunno.
Me neither.
^ permalink raw reply
* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: John Keeping @ 2013-01-31 22:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthieu Moy, Max Horn
In-Reply-To: <7vtxpxdldj.fsf@alter.siamese.dyndns.org>
On Thu, Jan 31, 2013 at 02:43:20PM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
>
> > 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.
>
> I'd like to see if we can have a way to keep its look as the default
> css gets updated without maintainance burden.
>
> How about using AsciiDoc instead of "cp", perhaps like this on top
> of your patch?
I tried AsciiDoc first but didn't like the output. I think putting "See
gitremote-helpers" in the synopsis is the magic I was missing. This
looks good to me.
John
^ permalink raw reply
* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: Jonathan Nieder @ 2013-01-31 23:04 UTC (permalink / raw)
To: Jeff King; +Cc: John Keeping, git, Junio C Hamano, Matthieu Moy, Max Horn
In-Reply-To: <20130131223305.GB21729@sigill.intra.peff.net>
Jeff King wrote:
> Maybe it is just me, but the fact that accessing the manpage is now:
>
> man gitremote-helpers
>
> feels weird to me. I know it technically follows our syntactic rules,
> but having the lack of dash be significant between "git" and "remote",
> but then having a dash later makes it hard on the eyes.
Yes. I have thought for years that it should be git-remote-helpers,
that "git help" should be tweaked to look for that, and that the
existing gitrepository-layout and friends should be replaced with
redirects.
I didn't say anything (except a random comment once on #git) because I
can't promise to have time soon to work on it. Might try anyway.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: Junio C Hamano @ 2013-01-31 23:11 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Jeff King, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130131230455.GN27340@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Jeff King wrote:
>
>> Maybe it is just me, but the fact that accessing the manpage is now:
>>
>> man gitremote-helpers
>>
>> feels weird to me. I know it technically follows our syntactic rules,
>> but having the lack of dash be significant between "git" and "remote",
>> but then having a dash later makes it hard on the eyes.
>
> Yes. I have thought for years that it should be git-remote-helpers,
> that "git help" should be tweaked to look for that, and that the
> existing gitrepository-layout and friends should be replaced with
> redirects.
Because of the "git help" look up rules, we cannot have two pages
that only differ at the dash (or absense of it) immediately after
'git'; e.g. one about the concept of 'frotz' in the context of Git,
i.e. "man gitfrotz", and the other about the subcommand to perform
'frotz', i.e. "man git-frotz". The way to refer to these two pages
are both "git help frotz".
The simplest way forward may be to teach "git help" to try both
paths? But some people configure "git help -w" to refer to remote
site, so it won't be access(path, F_OK). Sigh...
^ permalink raw reply
* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: Jonathan Nieder @ 2013-01-31 23:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <7vhalxdk2q.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Yes. I have thought for years that it should be git-remote-helpers,
>> that "git help" should be tweaked to look for that, and that the
>> existing gitrepository-layout and friends should be replaced with
>> redirects.
>
> Because of the "git help" look up rules, we cannot have two pages
> that only differ at the dash (or absense of it) immediately after
> 'git'; e.g. one about the concept of 'frotz' in the context of Git,
> i.e. "man gitfrotz", and the other about the subcommand to perform
> 'frotz', i.e. "man git-frotz". The way to refer to these two pages
> are both "git help frotz".
Exactly. Hence the disambiguating dash-versus-nondash convention buys
us nothing.
^ permalink raw reply
* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: Junio C Hamano @ 2013-01-31 23:49 UTC (permalink / raw)
To: John Keeping; +Cc: git, Matthieu Moy, Max Horn
In-Reply-To: <20130131225620.GQ1342@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> On Thu, Jan 31, 2013 at 02:43:20PM -0800, Junio C Hamano wrote:
>> John Keeping <john@keeping.me.uk> writes:
>>
>> > 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.
>>
>> I'd like to see if we can have a way to keep its look as the default
>> css gets updated without maintainance burden.
>>
>> How about using AsciiDoc instead of "cp", perhaps like this on top
>> of your patch?
>
> I tried AsciiDoc first but didn't like the output. I think putting "See
> gitremote-helpers" in the synopsis is the magic I was missing. This
> looks good to me.
Actually I didn't mean "take this patch, it works". I've queued a
slightly different version and will push it out as part of 'pu'
later.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/3] run-command: Be more informative about what failed
From: Junio C Hamano @ 2013-01-31 23:57 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Jeff King
In-Reply-To: <20130131223559.GC21729@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> But it is not much code, and sometimes it is surprising what information
> can be helpful when debugging, so like you, I am not opposed, just
> doubtful.
Yes, exactly my feeling.
Perhaps I should just amend the 'stdin' and friends away without
asking Stephen to reroll. In the other two I did not see any
issues. I've queued all three of them including this one but as
separate topics.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] docs: clarify git-branch --list behavior
From: Eric Sunshine @ 2013-02-01 0:20 UTC (permalink / raw)
To: Jeff King; +Cc: Peter Wu, git
In-Reply-To: <20130131064545.GA25315@sigill.intra.peff.net>
On Thu, Jan 31, 2013 at 1:45 AM, Jeff King <peff@peff.net> wrote:
> +If `--list` is given, or if there are no non-option arguments, existing
> +branches are listed; the current branch will be highlighted with an
> +asterisk. Option `-r` causes the remote-tracking branches to be listed,
> +and option `-a` shows both local and remote branches. If a `<pattern>`
> +is given, it is used as a shell wildcard to restrict the output to
> +matching branches. If multiple patterns are given, a branch is shown if
> +any it is matched by any of the patterns.
s/if any it is/if it is/
-- ES
^ permalink raw reply
* Re: [PATCH 1/2] docs: clarify git-branch --list behavior
From: Junio C Hamano @ 2013-02-01 0:37 UTC (permalink / raw)
To: Eric Sunshine; +Cc: Jeff King, Peter Wu, git
In-Reply-To: <CAPig+cT21Fx6BaD=1jT7KSBZSZkWu-A-0U+QsM2qO8g5gki=YQ@mail.gmail.com>
Eric Sunshine <sunshine@sunshineco.com> writes:
> On Thu, Jan 31, 2013 at 1:45 AM, Jeff King <peff@peff.net> wrote:
>> +If `--list` is given, or if there are no non-option arguments, existing
>> +branches are listed; the current branch will be highlighted with an
>> +asterisk. Option `-r` causes the remote-tracking branches to be listed,
>> +and option `-a` shows both local and remote branches. If a `<pattern>`
>> +is given, it is used as a shell wildcard to restrict the output to
>> +matching branches. If multiple patterns are given, a branch is shown if
>> +any it is matched by any of the patterns.
>
> s/if any it is/if it is/
Thanks; I'll squash this in. Peff, no need to resend.
Documentation/git-branch.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 01aa87f..2635dee 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -28,7 +28,7 @@ asterisk. Option `-r` causes the remote-tracking branches to be listed,
and option `-a` shows both local and remote branches. If a `<pattern>`
is given, it is used as a shell wildcard to restrict the output to
matching branches. If multiple patterns are given, a branch is shown if
-any it is matched by any of the patterns. Note that when providing a
+it matches any of the patterns. Note that when providing a
`<pattern>`, you must use `--list`; otherwise the command is interpreted
as branch creation.
^ permalink raw reply related
* 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 0:46 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git, davvid
In-Reply-To: <50804391.814945.1358931502165.JavaMail.ngmail@webmail07.arcor-online.net>
Thomas Ackermann <th.acker@arcor.de> writes:
> >
>> Thomas, I do not want to see many rounds of entire rerolls of this
>> series on the list (nobody will look at the whole series multiple
>> times with fine toothed comb). I do not think you want to do that
>> either. Can you collect remaining fixups like David's message, turn
>> them into patch form when you have collected enough to be reviewed
>> in one sitting (say, a patchfile at around 200 lines), and send them
>> over to the list to apply on top of the tree of that commit?
>>
> Sure!
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.
Thanks.
^ permalink raw reply
* Re: [PATCH] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
From: Junio C Hamano @ 2013-02-01 0:58 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Bryan Turner, git, Andrej E Baranov
In-Reply-To: <20130131012853.GD15680@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Junio C Hamano wrote:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>>> Odd. "https://www.gravatar.com/" also seems to work. I've put in a
>>> technical support query to find out what the Gravatar admins prefer.
>>
>> Thanks; will hold onto Andrej's patch until we hear what the story
>> is.
>
> Good news: a kind person from Automattic answered that
> www.gravatar.com should work fine over SSL, both now and in the
> future, and promised to add updating documentation to their todo list.
>
> Thanks for your help and patience.
I'll merge Andrej's topic to 'next' in the next integration cycle.
The fix should hit 'master' no later than the beginning of next
week.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Junio C Hamano @ 2013-02-01 1:15 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <20130131210002.GK27340@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> [...]
>> --- 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. :(
Whatever.
For tonight, I'll queue this version on 'pu' primarily because I do
not want to think about it anymore today and because I do not want
to see us forget that we have to fix this in some way, and this was
the only one that I can simply "git am" on this topic. It is not
because I want to say "this is the version we are going to use,
stfu!" This topic does not even deserve such inter-developer
tension, IMHO.
doc: mention tracking for pull.default
When looking at a configuration file edited long time ago, a user
may find 'pull.default = tracking' and wonder what it means, but
earlier we stopped mentioning this value, even though the code still
support it and more importantly, we have no intention to force old
timers to update their configuration files.
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', by not listing it as a separate item on
the same footing as other values but as a deprecated synonym of the
'upstream' in its description.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* Re: Re: Segmentation fault with latest git (070c57df)
From: 허종만 @ 2013-02-01 1:31 UTC (permalink / raw)
To: Jeff King, Thomas Rast; +Cc: git, Antoine Pelisse
>
[snip]
> Good point. Unfortunately, I can't get either yours or mine to fail,
> neither with a recent version of gcc nor with gcc-4.1. But I can't
> convince git to fail, either. The only gcc-4.1 I have is Debian's
> 4.1.3 release, which is not quite what the OP has.
>
> > Or perhaps something in the build process went wrong, and fetch.c didn't
> > get the memo about the new field in the struct. Depending on stack
> > layout, the next variable might be the 'int i' right before the
> > 'string_list list' in the code, which could explain the value of 1.
>
> Yeah, that would make sense to me with respect to the behavior we are
> seeing, but that part of the Makefile should be pretty simple and
> bug-free, I'd think (and from the original report, it seems like he was
> able to reproduce it well enough to bisect). Still, trying a "make clean
> && make" might be worth it just to rule that out.
>
> Puzzled...
>
> -Peff
Hi, all,
Thomas's test code also returns "cmp is 0".
But "make clean && make" fixes my issue.
Sorry for the noise I made.
But usually when I build upstream Linux kernel, I don't do "make clean" after git pull..
I didn't expect that I needed "make clean" for git build. Thanks you guys.
Best regards,
Jongman Heo.
^ permalink raw reply
* Re: Segmentation fault with latest git (070c57df)
From: Junio C Hamano @ 2013-02-01 1:40 UTC (permalink / raw)
To: jongman.heo; +Cc: Jeff King, Thomas Rast, git, Antoine Pelisse
In-Reply-To: <15540714.372461359682286477.JavaMail.weblogic@epml08>
허종만 <jongman.heo@samsung.com> writes:
> But usually when I build upstream Linux kernel, I don't do "make
> clean" after git pull.. I didn't expect that I needed "make
> clean" for git build.
We don't expect anybody need "make clean", either. There is
something wrong in the dependency.
^ permalink raw reply
* Re: "sha1 information is lacking or useless" when rebasing with a submodule pointer conflict
From: Junio C Hamano @ 2013-02-01 4:01 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Michael Sims, git, Jens Lehmann, Martin von Zweigbergk
In-Reply-To: <20130130224904.GB1053@book.hvoigt.net>
Heiko Voigt <hvoigt@hvoigt.net> writes:
> Maybe Martin or Junio immediately see whats going wrong here? I would
> need to further dig into the git-am code to find out how to fix it.
Thanks. I think the minimum fix is this, but there are some nits to
pick around this area as well.
diff --git b/git-am.sh a/git-am.sh
index b4d95f5..202130f 100755
--- b/git-am.sh
+++ a/git-am.sh
@@ -664,7 +664,7 @@ do
sed -e '1,/^$/d' >"$dotest/msg-clean"
echo "$commit" >"$dotest/original-commit"
get_author_ident_from_commit "$commit" >"$dotest/author-script"
- git diff-tree --root --binary "$commit" >"$dotest/patch"
+ git diff-tree --root --binary --full-index "$commit" >"$dotest/patch"
else
git mailinfo $keep $no_inbody_headers $scissors $utf8 "$dotest/msg" "$dotest/patch" \
<"$dotest/$msgnum" >"$dotest/info" ||
^ permalink raw reply related
* [PATCH 0/3] rebasing changes that update submodules
From: Junio C Hamano @ 2013-02-01 4:32 UTC (permalink / raw)
To: git; +Cc: Heiko Voigt, Martin von Zweigbergk
In-Reply-To: <20130130224904.GB1053@book.hvoigt.net>
"git rebase" used to use "format-patch --full-index" to generate a
series of patches and let "git am --rebase" reconstruct a fake
preimage tree by reading the object names from the "index" lines.
With a230949 (am --rebasing: get patch body from commit, not from
mailbox, 2012-06-26), we switched to use "diff-tree", but forgot
that without "--full-index", the information generated on the
"index" line is insufficient to recreate a preimage tree that
contains a submodule.
The first one is the real fix to this issue.
The other two falls into the niceties category; they are to issue a
better error messge when the machinery is fed an abbreviated object
name on the "index" line for a submodule.
Junio C Hamano (3):
git-am: record full index line in the patch used while rebasing
apply: simplify build_fake_ancestor()
apply: diagnose incomplete submodule object name better
builtin/apply.c | 30 ++++++++++++++++--------------
git-am.sh | 2 +-
t/t7402-submodule-rebase.sh | 30 ++++++++++++++++++++++++++++--
3 files changed, 45 insertions(+), 17 deletions(-)
--
1.8.1.2.612.g09f4be5
^ permalink raw reply
* [PATCH 1/3] git-am: record full index line in the patch used while rebasing
From: Junio C Hamano @ 2013-02-01 4:32 UTC (permalink / raw)
To: git; +Cc: Heiko Voigt, Martin von Zweigbergk
In-Reply-To: <1359693125-22357-1-git-send-email-gitster@pobox.com>
Earlier, a230949 (am --rebasing: get patch body from commit, not
from mailbox, 2012-06-26) learned to regenerate patch body from the
commit object while rebasing, instead of reading from the rebase-am
front-end. While doing so, it used "git diff-tree" but without
giving it the "--full-index" option.
This does not matter for in-repository objects; during rebasing, any
abbreviated object name should uniquely identify them.
But we may be rebasing a commit that contains a change to a gitlink,
in which case we usually should not have the object (it names a
commit in the submodule). A full object name is necessary to later
reconstruct a fake ancestor index for them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-am.sh | 2 +-
t/t7402-submodule-rebase.sh | 30 ++++++++++++++++++++++++++++--
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index c682d34..0e0a096 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -664,7 +664,7 @@ do
sed -e '1,/^$/d' >"$dotest/msg-clean"
echo "$commit" >"$dotest/original-commit"
get_author_ident_from_commit "$commit" >"$dotest/author-script"
- git diff-tree --root --binary "$commit" >"$dotest/patch"
+ git diff-tree --root --binary --full-index "$commit" >"$dotest/patch"
else
git mailinfo $keep $no_inbody_headers $scissors $utf8 "$dotest/msg" "$dotest/patch" \
<"$dotest/$msgnum" >"$dotest/info" ||
diff --git a/t/t7402-submodule-rebase.sh b/t/t7402-submodule-rebase.sh
index f919c8d..8e32f19 100755
--- a/t/t7402-submodule-rebase.sh
+++ b/t/t7402-submodule-rebase.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2008 Johannes Schindelin
#
-test_description='Test rebasing and stashing with dirty submodules'
+test_description='Test rebasing, stashing, etc. with submodules'
. ./test-lib.sh
@@ -20,7 +20,8 @@ test_expect_success setup '
echo second line >> file &&
(cd submodule && git pull) &&
test_tick &&
- git commit -m file-and-submodule -a
+ git commit -m file-and-submodule -a &&
+ git branch added-submodule
'
@@ -89,4 +90,29 @@ test_expect_success 'stash with a dirty submodule' '
'
+test_expect_success 'rebasing submodule that should conflict' '
+ git reset --hard &&
+ git checkout added-submodule &&
+ git add submodule &&
+ test_tick &&
+ git commit -m third &&
+ (
+ cd submodule &&
+ git commit --allow-empty -m extra
+ ) &&
+ git add submodule &&
+ test_tick &&
+ git commit -m fourth &&
+
+ test_must_fail git rebase --onto HEAD^^ HEAD^ HEAD^0 &&
+ git ls-files -s submodule >actual &&
+ (
+ cd submodule &&
+ echo "160000 $(git rev-parse HEAD^) 1 submodule" &&
+ echo "160000 $(git rev-parse HEAD^^) 2 submodule" &&
+ echo "160000 $(git rev-parse HEAD) 3 submodule"
+ ) >expect &&
+ test_cmp expect actual
+'
+
test_done
--
1.8.1.2.612.g09f4be5
^ permalink raw reply related
* [PATCH 2/3] apply: simplify build_fake_ancestor()
From: Junio C Hamano @ 2013-02-01 4:32 UTC (permalink / raw)
To: git; +Cc: Heiko Voigt, Martin von Zweigbergk
In-Reply-To: <1359693125-22357-1-git-send-email-gitster@pobox.com>
The local variable sha1_ptr in the build_fake_ancestor() function
used to either point at the null_sha1[] (if the ancestor did not
have the path) or at sha1[] (if we read the object name into the
local array), but 7a98869 (apply: get rid of --index-info in favor
of --build-fake-ancestor, 2007-09-17) made the "missing in the
ancestor" case unnecessary, hence sha1_ptr, when used, always points
at the local array.
Get rid of the unneeded variable, and restructure the if/else
cascade a bit to make it easier to read. There should be no
behaviour change.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/apply.c | 26 ++++++++++++--------------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index 156b3ce..a1db7b4 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3598,7 +3598,6 @@ static void build_fake_ancestor(struct patch *list, const char *filename)
* worth showing the new sha1 prefix, but until then...
*/
for (patch = list; patch; patch = patch->next) {
- const unsigned char *sha1_ptr;
unsigned char sha1[20];
struct cache_entry *ce;
const char *name;
@@ -3606,20 +3605,19 @@ static void build_fake_ancestor(struct patch *list, const char *filename)
name = patch->old_name ? patch->old_name : patch->new_name;
if (0 < patch->is_new)
continue;
- else if (get_sha1_blob(patch->old_sha1_prefix, sha1))
- /* git diff has no index line for mode/type changes */
- if (!patch->lines_added && !patch->lines_deleted) {
- if (get_current_sha1(patch->old_name, sha1))
- die("mode change for %s, which is not "
- "in current HEAD", name);
- sha1_ptr = sha1;
- } else
- die("sha1 information is lacking or useless "
- "(%s).", name);
- else
- sha1_ptr = sha1;
- ce = make_cache_entry(patch->old_mode, sha1_ptr, name, 0, 0);
+ if (!get_sha1_blob(patch->old_sha1_prefix, sha1)) {
+ ; /* ok */
+ } else if (!patch->lines_added && !patch->lines_deleted) {
+ /* mode-only change: update the current */
+ if (get_current_sha1(patch->old_name, sha1))
+ die("mode change for %s, which is not "
+ "in current HEAD", name);
+ } else
+ die("sha1 information is lacking or useless "
+ "(%s).", name);
+
+ ce = make_cache_entry(patch->old_mode, sha1, name, 0, 0);
if (!ce)
die(_("make_cache_entry failed for path '%s'"), name);
if (add_index_entry(&result, ce, ADD_CACHE_OK_TO_ADD))
--
1.8.1.2.612.g09f4be5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox