Re: [PATCH] Rename {git- => git}remote-helpers.txt

On Thu, Jan 31, 2013 at 09:37:51PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > What was the original rationale for the "gitfoo" form? Was it just to > > visually distinguish command manpages from non-command manpages? I can't > > remember the origins now. > > b27a23e (Documentation:

Re: Segmentation fault with latest git (070c57df)

On Fri, Feb 01, 2013 at 01:36:38AM -0500, Jeff King wrote: > On Thu, Jan 31, 2013 at 05:40:02PM -0800, Junio C Hamano wrote: > > > 허종만 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 > > > clea

Re: Segmentation fault with latest git (070c57df)

On Fri, Feb 01, 2013 at 01:36:38AM -0500, Jeff King wrote: > It seems like building each object file should depend on its dependency > file (but only when COMPUTE_HEADER_DEPENDENCIES is on, of course), since > otherwise we cannot know if we have the right dependencies or not. > > Something like t

Re: Segmentation fault with latest git (070c57df)

On Thu, Jan 31, 2013 at 05:40:02PM -0800, Junio C Hamano wrote: > 허종만 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.

Re: [PATCH 1/3] git-am: record full index line in the patch used while rebasing

On Thu, Jan 31, 2013 at 8:32 PM, Junio C Hamano wrote: > 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 use

thomas sabo jewellery are popular among people

Here I want to share you my happiness. Yesterday I have received my thomas sabo uk which I ordered a few days ago. The one I bought is made with Neon Yellow elastic with three lovely charms. So cute and fashionable these Thomas Sabo Bracelets they are. By wearing these bracelets can make us gracefu

links of london friendship bracelet is very current

The links of london sale has forever tried its best to bargain the customers a balance of present and sole private mode couple necklaces for lovers in the world. All crop was packed with people who like the flavor of life consistently. These offer

Re: [PATCH] fix some clang warnings

Jeff King writes: > It seems a little weird to me that clang defines __GNUC__, but I > assume there are good reasons for it. The thing is that "gcc" is as much a language dialect these days as it is a compiler implementation, and many other compilers, including clang, explicitly try to implement

Re: [PATCH 1/2] docs: clarify git-branch --list behavior

Jeff King writes: > Thanks. No matter how many times I proofread a doc change, I always > manage to slip an error into the final version. I think everybody shares that trait. > Hooray for many eyes. Indeed. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a mess

Re: [PATCH] Rename {git- => git}remote-helpers.txt

Jeff King writes: > What was the original rationale for the "gitfoo" form? Was it just to > visually distinguish command manpages from non-command manpages? I can't > remember the origins now. b27a23e (Documentation: convert tutorials to man pages, 2008-05-24) turns "tutorial.txt" into "gittutor

Re: [PATCH 1/2] docs: clarify git-branch --list behavior

On Thu, Jan 31, 2013 at 04:37:01PM -0800, Junio C Hamano wrote: > Eric Sunshine writes: > > > On Thu, Jan 31, 2013 at 1:45 AM, Jeff King 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

Re: [PATCH] Rename {git- => git}remote-helpers.txt

On Thu, Jan 31, 2013 at 03:04:55PM -0800, Jonathan Nieder wrote: > 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 d

[PATCH 3/3] apply: diagnose incomplete submodule object name better

"git am -3" uses this function to build a tree that records how the preimage the patch was created from would have looked like. An abbreviated object name on the index line is ordinarily sufficient for us to figure out the object name the preimage tree would have contained, but a change to a submo

[PATCH 2/3] apply: simplify build_fake_ancestor()

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

[PATCH 0/3] rebasing changes that update submodules

"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

[PATCH 1/3] git-am: record full index line in the patch used while rebasing

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" optio

Re: "sha1 information is lacking or useless" when rebasing with a submodule pointer conflict

Heiko Voigt 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.

Re: Segmentation fault with latest git (070c57df)

허종만 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. -- To unsubscribe from this list:

Re: Re: Segmentation fault with latest git (070c57df)

> [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 somethin

Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'

Jonathan Nieder 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 upstrea

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://.

Jonathan Nieder writes: > Junio C Hamano wrote: >> Jonathan Nieder 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

Re: Aw: Re: [PATCH v3 3/6] Change 'git' to 'Git' whenever the whole system is referred to #2

Thomas Ackermann 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

Re: [PATCH 1/2] docs: clarify git-branch --list behavior

Eric Sunshine writes: > On Thu, Jan 31, 2013 at 1:45 AM, Jeff King 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 liste

Re: [PATCH 1/2] docs: clarify git-branch --list behavior

On Thu, Jan 31, 2013 at 1:45 AM, Jeff King 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 b

Re: [PATCH 2/3] run-command: Be more informative about what failed

Jeff King 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 t

Re: [PATCH] Rename {git- => git}remote-helpers.txt

John Keeping writes: > On Thu, Jan 31, 2013 at 02:43:20PM -0800, Junio C Hamano wrote: >> John Keeping 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 re

Re: [PATCH] Rename {git- => git}remote-helpers.txt

Junio C Hamano wrote: > Jonathan Nieder 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 he

Re: [PATCH] Rename {git- => git}remote-helpers.txt

Jonathan Nieder 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",

Re: [PATCH] Rename {git- => git}remote-helpers.txt

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 make

Re: [PATCH] Rename {git- => git}remote-helpers.txt

On Thu, Jan 31, 2013 at 02:43:20PM -0800, Junio C Hamano wrote: > John Keeping 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. >

Re: [PATCH] Rename {git- => git}remote-helpers.txt

Jeff King 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

Re: [PATCH] gitremote-helpers.txt: rename from git-remote-helpers.txt

Tomas Carnecky writes: > On Thu, 31 Jan 2013 20:08:14 +, John Keeping 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-helper

Re: [PATCH] Rename {git- => git}remote-helpers.txt

John Keeping 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 g

Re: [PATCHv2 1/3] gpg: Close stderr once finished with it in verify_signed_buffer()

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

Re: [PATCH] Verify Content-Type from smart HTTP servers

On Thu, Jan 31, 2013 at 1:59 PM, Junio C Hamano wrote: > Shawn Pearce 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 respon

Re: [PATCH 2/3] run-command: Be more informative about what failed

On Thu, Jan 31, 2013 at 08:24:21AM -0800, Junio C Hamano wrote: > Stephen Boyd 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

Re: [PATCH] Rename {git- => git}remote-helpers.txt

On Thu, Jan 31, 2013 at 09:59:50PM +, John Keeping wrote: > When looking up a topic via "git help ", 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 n

Re: [PATCH] Rename {git- => git}remote-helpers.txt

On Thu, Jan 31, 2013 at 02:13:10PM -0800, Junio C Hamano wrote: > John Keeping writes: > > > When looking up a topic via "git help ", 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. > >

Re: [PATCH] gitremote-helpers.txt: rename from git-remote-helpers.txt

On Thu, 31 Jan 2013 20:08:14 +, John Keeping 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'. -- To unsubscribe from this l

Re: [PATCH] Rename {git- => git}remote-helpers.txt

John Keeping writes: > When looking up a topic via "git help ", 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-h

[PATCH] Verify Content-Type from smart HTTP servers

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 fail

[PATCH] Rename {git- => git}remote-helpers.txt

When looking up a topic via "git help ", 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-helpe

Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'

Junio C Hamano wrote: > Jonathan Nieder 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

Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'

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 br

Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'

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

Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'

Junio C Hamano writes: > Jonathan Nieder 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 "--pri

Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'

Jonathan Nieder 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 i

Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'

From: "Jonathan Nieder" 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 opposit

Re: [PATCH] gitremote-helpers.txt: rename from git-remote-helpers.txt

Matthieu Moy writes: > John Keeping 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:

Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'

Jonathan Nieder 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 u

Re: [PATCH] gitremote-helpers.txt: rename from git-remote-helpers.txt

John Keeping 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-helpe

[PATCH] gitremote-helpers.txt: rename from git-remote-helpers.txt

When looking up a topic via "git help ", 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-helpe

Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'

Junio C Hamano wrote: > Jonathan Nieder 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 searc

Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'

Jonathan Nieder 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. > > * `t

Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'

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 > `tracki

Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'

Jonathan Nieder 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 ad

Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'

Jonathan Nieder 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 sho

Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'

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 >

Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'

Jonathan Nieder 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 t

Re: [PATCH] git-send-email: add ~/.authinfo parsing

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'

Re: Why git-whatchanged shows a commit touching every file, but git-log doesn't?

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

Re: [PATCH 0/5] Fix msvc build

Johannes Schindelin 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 MS

Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'

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

Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'

Hi, 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

Re: [PATCH 0/5] Fix msvc build

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

Re: [PATCH v3 00/11] unify appending of sob

On Wed, Jan 30, 2013 at 9:37 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Jonathan Nieder writes: >> >>> Brandon Casey wrote: >>> Round 3. >>> >>> Thanks for a pleasant read. My only remaining observations are >>> cosmetic, except for a portability question in Duy's test script,

[PATCH 5/5] msvc: avoid collisions between "tags" and "TAGS"

Commit 2f769195 ("MinGW: avoid collisions between "tags" and "TAGS", 28-09-2010) enabled MinGW to use an ETAGS file in order to avoid filename collisions on (Windows) case insensitive filesystems. In addition, this prevents 'make' from issuing several warning messages. When using the Makefile to

[PATCH 4/5] msvc: test-svn-fe: Fix linker "unresolved external" error

In particular, while linking test-svn-fe.exe, the linker complains that the external symbol _strtoull is unresolved. A call to this function was added in commit ddcc8c5b ("vcs-svn: skeleton of an svn delta parser", 25-12-2010). The NO_STRTOULL build variable attempts to provide support to old syst

[PATCH 3/5] msvc: Fix build by adding missing symbol defines

In particular, remote-testsvn.c fails to compile with two undeclared identifier errors relating to the 'UINT32_MAX' and 'STDIN_FILENO' symbols. In order to fix the compilation errors, we add appropriate definitions for the UINT32_MAX and STDIN_FILENO constants to an msvc compat header file. Sign

[PATCH 2/5] msvc: git-daemon: Fix linker "unresolved external" errors

In particular, while linking git-daemon.exe, the linker complains that the external symbols _inet_pton and _inet_ntop are unresolved. Commit a666b472 ("daemon: opt-out on features that require posix", 04-11-2010) addressed this problem for MinGW by configuring the use of the internal 'compat' vers

[PATCH 1/5] msvc: Fix compilation errors caused by poll.h emulation

Commit 0f77dea9 ("mingw: move poll out of sys-folder", 24-10-2011), along with other commits in the 'ef/mingw-upload-archive' branch (see commit 7406aa20), effectively reintroduced the same problem addressed by commit 56fb3ddc ("msvc: Fix compilation errors in compat/win32/sys/poll.c", 04-12-2010)

[PATCH 0/5] Fix msvc build

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 war

Re: "git archve --format=tar" output changed from 1.8.1 to 1.8.2.1

Am 31.01.2013 18:28, schrieb Greg KH: > I tracked this down to commit 22f0dcd9634a818a0c83f23ea1a48f2d620c0546 > (archive-tar: split long paths more carefully). The diff of a hex dump > of the tar archives shows the following difference: > > --- old_git_archive 2013-01-31 17:31:24.466343388 +01

Re: [PATCH 3/3] gpg: Allow translation of more error messages

Stephen Boyd wrote: > Mark these strings for translation so that error messages are > printed in the user's language of choice. Yeah. Other error messages in this file are already translated, so it's oddly inconsistent. Assuming this passes tests with GETTEXT_POISON=YesPlease, Reviewed-by: Jona

[PATCHv2 1/3] gpg: Close stderr once finished with it in verify_signed_buffer()

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

Re: "git archve --format=tar" output changed from 1.8.1 to 1.8.2.1

Greg KH writes: > On Thu, Jan 31, 2013 at 09:32:12AM -0800, Junio C Hamano wrote: > >> How about fixing kup to teach the "let's cheat and let the other end >> run 'git archive', if the resulting archive and GPG signature >> locally created does match, we do not have to transfer the tarball >> its

Re: [feature request] git-daemon http connection filtering of client types

Hey folks, On 31 January 2013 08:22, Erik Faye-Lund wrote: > > This isn't a running instance of git-daemon, it's a web front-end for > the mailing list. It seems nabble allows image-attachments, and that's > what you're seeing; an attached image to a spam-email that was sent to > the git-mailing

Re: [PATCH 1/3] gpg: Close stderr once finished with it in verify_signed_buffer()

On 01/30/13 21:50, Jeff King wrote: > > The strbuf_read above will read to EOF, so it should be equivalent (and > IMHO slightly more readable) to do: > > diff --git a/gpg-interface.c b/gpg-interface.c > index 0863c61..5f142f6 100644 > --- a/gpg-interface.c > +++ b/gpg-interface.c > @@ -130,8 +130,1

Re: [PATCH 2/3] run-command: Be more informative about what failed

On 01/31/13 08:24, Junio C Hamano wrote: > Stephen Boyd 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'

Re: "git archve --format=tar" output changed from 1.8.1 to 1.8.2.1

On 31/01/13 12:41 PM, Greg KH wrote: > Ugh, uploading a 431Mb file, over a flaky wireless connection (I end up > doing lots of kernel releases while traveling), would be a horrible > change. I'd rather just keep using the same older version of git that > kernel.org is running instead. Well, we do

Re: "git archve --format=tar" output changed from 1.8.1 to 1.8.2.1

On Thu, Jan 31, 2013 at 09:32:12AM -0800, Junio C Hamano wrote: > Greg KH writes: > > > The way we upload the Linux kernel to kernel.org involves creating a tar > > archive, signing the archive, and then just uploading the signature. > > The server then checks out the repo based on the tag, gener

Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'

Ævar Arnfjörð Bjarmason writes: > On Mon, Apr 23, 2012 at 10:37 AM, Matthieu Moy wrote: >> It's been deprecated since 53c4031 (Johan Herland, Wed Feb 16 2011, >> push.default: Rename 'tracking' to 'upstream'), so it's OK to remove it >> from documentation (even though it's still supported) to ma

Re: "git archve --format=tar" output changed from 1.8.1 to 1.8.2.1

Greg KH writes: > The way we upload the Linux kernel to kernel.org involves creating a tar > archive, signing the archive, and then just uploading the signature. > The server then checks out the repo based on the tag, generates the tar > archive and checks the signature to make sure they match. >

"git archve --format=tar" output changed from 1.8.1 to 1.8.2.1

Hi, The way we upload the Linux kernel to kernel.org involves creating a tar archive, signing the archive, and then just uploading the signature. The server then checks out the repo based on the tag, generates the tar archive and checks the signature to make sure they match. A few days ago I rele

Re: [PATCH/RFC 0/6] commit caching

On Tue, Jan 29, 2013 at 1:14 AM, Jeff King wrote: > This is the cleaned-up version of the commit caching patches I mentioned > here: > > http://article.gmane.org/gmane.comp.version-control.git/212329 ... > The short of it is that for an extra 31M of disk > space (~4%), I get a warm-cache speedup

Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'

On Mon, Apr 23, 2012 at 10:37 AM, Matthieu Moy wrote: > It's been deprecated since 53c4031 (Johan Herland, Wed Feb 16 2011, > push.default: Rename 'tracking' to 'upstream'), so it's OK to remove it > from documentation (even though it's still supported) to make the > explanations more readable. I

Re: [PATCH 4/6] introduce a commit metapack

On Wed, Jan 30, 2013 at 7:56 AM, Junio C Hamano wrote: > Jeff King writes: > >>>From this: >> >>> Then it will be very natural for the extension data that store the >>> commit metainfo to name objects in the pack the .idx file describes >>> by the offset in the SHA-1 table. >> >> I guess your arg

Re: [PATCH 2/2] branch: let branch filters imply --list

Peter Wu writes: > One note, the following command spits out master without complaining about > the > non-existing branch name: > > git branch --contains master > > (the order of branches doesn't affect the result.) That is perfectly normal. What you gave after "--contains " are *not* b

Re: [PATCH 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.

On 31/01/13 15:51, Junio C Hamano wrote: > TJ writes: > >> +$(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man1dir) >> +$(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man5dir) >> +$(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man7dir) >> +$(INSTALL) -m

Re: [PATCH 0/2] optimizing pack access on "read only" fetch repos

On Tue, Jan 29, 2013 at 1:19 PM, Jeff King wrote: > On Tue, Jan 29, 2013 at 07:58:01AM -0800, Junio C Hamano wrote: > >> The point is not about space. Disk is cheap, and it is not making >> it any worse than what happens to your target audience, that is a >> fetch-only repository with only "gc --

Re: [PATCH 2/3] run-command: Be more informative about what failed

Stephen Boyd 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 t

Re: [PATCH 2/2] branch: let branch filters imply --list

On Thursday 31 January 2013 01:46:11 Jeff King wrote: > Currently, a branch filter like `--contains`, `--merged`, or > `--no-merged` is ignored when we are not in listing mode. > For example: > > git branch --contains=foo bar > > will create the branch "bar" from the current HEAD, ignoring > th

Re: [PATCH] push: fix segfault when HEAD points nowhere

Fraser Tweedale writes: > When reporting the outcome of a push, a segfault occurs if HEAD does > not point somewhere. Check that HEAD points somewhere before trying > to strcmp it. > > Signed-off-by: Fraser Tweedale > --- > transport.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >

Re: [PATCH 0/2] improve "git branch --contains= "

Jeff King writes: > That being said, we could be much more helpful. It seems like --contains > should imply listing mode, since it is nonsensical in other modes. The > second patch below adjusts that, and makes the command above do what you > expect. > > [1/2]: docs: clarify git-branch --list b

Re: [PATCH 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.

TJ writes: > + $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man1dir) > + $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man5dir) > + $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man7dir) > + $(INSTALL) -m $(INSTALL_MODE_DATA) $(DOC_MAN1) $(DESTDIR)$(

Re: [PATCH 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.

Jeff Epler writes: > I was not familiar with this behavior of 'install -d' that it tries to change > the mode of an existing directory, but GNU coreutils 8.12.197-032bb > certainly behaves as TJ reports. > > As a possible alternative, what about > [ -d $(DESTDIR)$(main1dir) ] || $(INSTALL) -d

Re: [PATCH] git-send-email: add ~/.authinfo parsing

On Wed, 30 Jan 2013 07:57:29 -0800 Junio C Hamano wrote: JCH> Jeff King writes: >> But it would probably make sense for send-email to support the existing >> git-credential subsystem, so that it can take advantage of secure >> system-specific storage. And that is where we should be pointing new

Re: [PATCH 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.

I was not familiar with this behavior of 'install -d' that it tries to change the mode of an existing directory, but GNU coreutils 8.12.197-032bb certainly behaves as TJ reports. As a possible alternative, what about [ -d $(DESTDIR)$(main1dir) ] || $(INSTALL) -d -m 755 $(DESTDIR)$(man1dir) so

Re: [feature request] git-daemon http connection filtering of client types

On Thu, Jan 31, 2013 at 1:46 PM, wrote: > Hey folks, > > When I checked for false positives in my spam this morning, I spotted > an interesting malformed img link at the top of a spam message. > > {snip} >> >> >> Employ a medal tiffany bracelet

[PATCH] push: fix segfault when HEAD points nowhere

When reporting the outcome of a push, a segfault occurs if HEAD does not point somewhere. Check that HEAD points somewhere before trying to strcmp it. Signed-off-by: Fraser Tweedale --- transport.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/transport.c b/transport.c ind

  1   2   >