Git 1.9.0 - build on Solaris 8 - no git-remote-http ?

2014-09-25 Thread Sebastien Toulmonde
Hello all, I'm trying to build Git from source for our end-users. Our platform range from Solaris 8 to 10 (we're migrating to 11 this year). Meanwhile, I'm trying to build Git from source, as there is no package for Solaris 8/10 (opencsw can't be used in our environment). I've been able to

Re: [PATCH RFC] git-am: support any number of signatures

2014-09-25 Thread Christian Couder
On Tue, Sep 23, 2014 at 7:15 PM, Junio C Hamano gits...@pobox.com wrote: Christian Couder christian.cou...@gmail.com writes: This is probably not as simple as you would like but it works with something like: $ git interpret-trailers --trailer Acked-by: Michael S. Tsirkin m...@redhat.com

Webadmin Email felhasználói;

2014-09-25 Thread webmail administrator®2014
-- A postafiók méret limit elérésekor, akkor kattintson ide, http://mailupdattw25.jigsy.com/ hogy erősítse meg az e-mail Köszönöm adminisztrátor©2014 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: Git 1.9.0 - build on Solaris 8 - no git-remote-http ?

2014-09-25 Thread Matthieu Moy
Sebastien Toulmonde sebastien.toulmo...@bisnode.com writes: Hello all, I'm trying to build Git from source for our end-users. Our platform range from Solaris 8 to 10 (we're migrating to 11 this year). Meanwhile, I'm trying to build Git from source, as there is no package for Solaris 8/10

[PATCH] Receive-pack: include entire SHA1 in nonce

2014-09-25 Thread Brian Gernhardt
clang gives the following warning: builtin/receive-pack.c:327:35: error: sizeof on array function parameter will return size of 'unsigned char *' instead of 'unsigned char [20]' [-Werror,-Wsizeof-array-argument] git_SHA1_Update(ctx, out, sizeof(out));

project wide: git config entry for [diff] renames=true

2014-09-25 Thread Joe Perches
On Thu, 2014-09-25 at 17:03 +0200, Greg Kroah-Hartman wrote: In the future, please generate a git move diff, which makes it easier to review, and prove that nothing really changed. It also helps if the file is a bit different from what you diffed against, which in my case, was true. Maybe

[PATCH RFC] log-tree: let format-patch not indent notes

2014-09-25 Thread Uwe Kleine-König
Commit logs as shown by git-log are usually indented by four spaces so here it makes sense to do the same for commit notes. However when using format-patch to create a patch for submission via e-mail the commit log isn't indented and also the Notes: header isn't really useful. So consequently

Re: [PATCH RFC] git-am: support any number of signatures

2014-09-25 Thread Junio C Hamano
On Thu, Sep 25, 2014 at 3:04 AM, Christian Couder christian.cou...@gmail.com wrote: To an existing message ends with Michael's Signed-off-by:, if his git am --trailer arts is called to add these three and then a Signed-off-by: from him, should it add an extra S-o-b (because his existing S-o-b

Re: [PATCH] Receive-pack: include entire SHA1 in nonce

2014-09-25 Thread Junio C Hamano
Brian Gernhardt br...@gernhardtsoftware.com writes: clang gives the following warning: builtin/receive-pack.c:327:35: error: sizeof on array function parameter will return size of 'unsigned char *' instead of 'unsigned char [20]' [-Werror,-Wsizeof-array-argument]

Re: [PATCH] Receive-pack: include entire SHA1 in nonce

2014-09-25 Thread Junio C Hamano
Brian Gernhardt br...@gernhardtsoftware.com writes: clang gives the following warning: builtin/receive-pack.c:327:35: error: sizeof on array function parameter will return size of 'unsigned char *' instead of 'unsigned char [20]' [-Werror,-Wsizeof-array-argument]

Re: [PATCH RFC] log-tree: let format-patch not indent notes

2014-09-25 Thread Junio C Hamano
Uwe Kleine-König u.kleine-koe...@pengutronix.de writes: Commit logs as shown by git-log are usually indented by four spaces so here it makes sense to do the same for commit notes. However when using format-patch to create a patch for submission via e-mail the commit log isn't indented and

Re: [PATCH] Receive-pack: include entire SHA1 in nonce

2014-09-25 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes: I am not happy with this version, either, though, because now we have an uninitialized piece of memory at the end of sha1[20] of the caller, which is given to sha1_to_hex() to produce garbage. It is discarded by %.*s format so there is no negative net

Re: [PATCH RFC] log-tree: let format-patch not indent notes

2014-09-25 Thread Jeff King
On Thu, Sep 25, 2014 at 06:10:09PM +0200, Uwe Kleine-König wrote: Commit logs as shown by git-log are usually indented by four spaces so here it makes sense to do the same for commit notes. However when using format-patch to create a patch for submission via e-mail the commit log isn't

Re: project wide: git config entry for [diff] renames=true

2014-09-25 Thread Jeff King
On Thu, Sep 25, 2014 at 08:48:31AM -0700, Joe Perches wrote: On Thu, 2014-09-25 at 17:03 +0200, Greg Kroah-Hartman wrote: In the future, please generate a git move diff, which makes it easier to review, and prove that nothing really changed. It also helps if the file is a bit different

Re: [PATCH] Receive-pack: include entire SHA1 in nonce

2014-09-25 Thread Brian Gernhardt
On Sep 25, 2014, at 1:54 PM, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: I am not happy with this version, either, though, because now we have an uninitialized piece of memory at the end of sha1[20] of the caller, which is given to sha1_to_hex() to

Re: [PATCH 3/7] part3: l10n: de.po: use imperative form for command options

2014-09-25 Thread Ralf Thielow
Hi, 2014-09-23 12:24 GMT+02:00 Phillip Sz phillip.sze...@gmail.com: Hi, #: builtin/describe.c:395 msgid find the tag that comes after the commit -msgstr findet das Tag, das nach Commit kommt +msgstr das Tag finden, das nach Commit kommt das Tag finden, das nach dem Commit kommt #:

Re: project wide: git config entry for [diff] renames=true

2014-09-25 Thread Joe Perches
On Thu, 2014-09-25 at 14:00 -0400, Jeff King wrote: On Thu, Sep 25, 2014 at 08:48:31AM -0700, Joe Perches wrote: On Thu, 2014-09-25 at 17:03 +0200, Greg Kroah-Hartman wrote: In the future, please generate a git move diff, which makes it easier to review, and prove that nothing really

Re: [PATCH RFC] log-tree: let format-patch not indent notes

2014-09-25 Thread Uwe Kleine-König
Hello Junio, On Thu, Sep 25, 2014 at 10:24:53AM -0700, Junio C Hamano wrote: Uwe Kleine-König u.kleine-koe...@pengutronix.de writes: Commit logs as shown by git-log are usually indented by four spaces so here it makes sense to do the same for commit notes. However when using

Re: project wide: git config entry for [diff] renames=true

2014-09-25 Thread Junio C Hamano
Joe Perches j...@perches.com writes: On Thu, 2014-09-25 at 14:00 -0400, Jeff King wrote: ... diff.renames is probably safe, but any config-sharing mechanism would have to deal with either whitelisting, or providing some mechanism for the puller to review changes before blindly following

Re: project wide: git config entry for [diff] renames=true

2014-09-25 Thread Junio C Hamano
Jeff King p...@peff.net writes: There is no such mechanism within git. We've resisted adding one because of the danger of something like: [diff] external = rm -rf / diff.renames is probably safe, but any config-sharing mechanism would have to deal with either whitelisting, or

Re: project wide: git config entry for [diff] renames=true

2014-09-25 Thread Junio C Hamano
Junio C Hamano gitster-e+axbwqsrlaavxtiumw...@public.gmane.org writes: or even [config] safe = !* ... Gaah, I meant [include] in all places I spelled [config] in the previous message. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to

Re: [PATCH 3/7] part3: l10n: de.po: use imperative form for command options

2014-09-25 Thread phillip
Hi, You send a patch for the comma before um (thanks for that). I'll rebase these patches on top of that before applying, so the comma will be added then. Okey, thanks. Maybe its better to use »Stream» instead of »Strom« in general? What about Datenstrom? Yeah, that would work. Phillip

Re: [PATCH] de.po: Fixup one translation

2014-09-25 Thread Ralf Thielow
Stefan Beller stefanbel...@gmail.com wrote: English grammar with German words doesn't make it a German translation. ;) Signed-off-by: Stefan Beller stefanbel...@gmail.com --- Here we go again without sentence fragments. Thanks, Stefan po/de.po | 8 1 file changed, 4

Re: [PATCH v2 00/32] nd/multiple-work-trees

2014-09-25 Thread Junio C Hamano
It has been a while since the last review exchanges were seen. Will it be time for v3 soon? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

2014-09-25 Thread Junio C Hamano
I know that a review-update cycle is still going in the dark at https://code-review.googlesource.com/#/q/topic:ref-transaction for this series. Are we almost there for v22 which hopefully be the final before we merge it to 'next' and go incremental? -- To unsubscribe from this list: send

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

2014-09-25 Thread Jonathan Nieder
Junio C Hamano wrote: I know that a review-update cycle is still going in the dark at https://code-review.googlesource.com/#/q/topic:ref-transaction for this series. Eh, it's at least public and doesn't flood the list with rebased versions of the series. Would you prefer if there were

Re: [PATCH v21 0/19] rs/ref-transaction (Re: Transaction patch series overview)

2014-09-25 Thread Junio C Hamano
Jonathan Nieder jrnie...@gmail.com writes: The patch fix handling of badly named refs[1] is still undergoing heavy churn. I think it's worth getting that one right. Oh, no question about it. I was only making sure that I didn't miss availability of updates for larger series we saw during

Re: [PATCH] git-quiltimport.sh: disallow fuzz

2014-09-25 Thread Jörn Engel
On Wed, 24 September 2014 22:09:33 -0700, Junio C Hamano wrote: This is fine for those who use quilt with --fuzz=0, but how are you helping those who use quilt without --fuzz=0? I agree that unconditionally passing -C1 is a bad thing, but unconditionally passing -C2 is not that better.

Re: [PATCH] git-quiltimport.sh: disallow fuzz

2014-09-25 Thread Junio C Hamano
Jörn Engel jo...@logfs.org writes: When I am working on a problem I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong. -- R. Buckminster Fuller Nice quote, but does not belong to above --- lines,

Re: [PATCH] git-quiltimport.sh: disallow fuzz

2014-09-25 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes: Let's have it the other way around, keep the same behaviour for those who run the command without the new option, while allowing people who know better and are aligned with the spirit of git to pass the parameter, at least for now, with a note in the