* Re: [PATCH/RFC 0/6] commit caching
From: Shawn Pearce @ 2013-01-31 17:14 UTC (permalink / raw)
To: Jeff King; +Cc: git, Duy Nguyen
In-Reply-To: <20130129091434.GA6975@sigill.intra.peff.net>
On Tue, Jan 29, 2013 at 1:14 AM, Jeff King <peff@peff.net> 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 for "git rev-list --all" of
> ~4.2s to ~0.66s.
I have to admit, this is a nice gain. I don't think users often dig
through all commits to the root but I can see how this might improve
git log with a path filter.
> Coupled with using compression level 0 for trees (which do not compress
> well at all, and yield only a 2% increase in size when left
> uncompressed), my "git rev-list --objects --all" time drops from ~40s to
> ~25s.
This uhm.... is nice?
But consider reachability bitmaps. ~40s to ~80ms. :-)
> Perf reveals that we're spending most of the remaining time in
> lookup_object. I've spent a fair bit of time trying to optimize that,
> but with no luck; I think it's fairly close to optimal. The problem is
> just that we call it a very large number of times, since it is the
> mechanism by which we recognize that we have already processed each
> sha1.
Yup. I have also futzed with the one in JGit for quite a while now. I
pull some tricks there like making it a 2 level directory to reduce
the need to find a contiguous array of 8M entries when processing the
Linux kernel, and I try to preallocate the first level table based on
the number of objects in pack-*.idx files. But the bottleneck is
basically the cache lookups and hits, these happen like 100M times on
2M objects, because its every link in nearly every tree.
Reachability bitmaps basically let you skip this. So they go fast. But
I have another that you could try.
If we modified pack-objects' delta compressor for tree objects to only
generate delta instructions at tree record boundaries, a delta-encoded
tree can be processed without inflating the full content of that tree.
Because of the way deltas are created, "most" tree deltas should have
their delta base scanned by the object traversal before the delta is
considered. This means the tree delta just needs to consider the much
smaller records that are inserted into the base. We know these are
different SHA-1s than what was there before, so they are more likely
to be new to the lookup_object table.
So the --objects traversal algorithm can change to get the delta base
SHA-1 and raw tree delta from the pack storage. Perform a
lookup_object on the base to see if it has been scanned. If it has,
just scan the delta insert instructions. If the base has not yet been
scanned, inflate the tree to its normal format and scan the entire
tree.
This is an approximation of what Nico and I were talking about doing
for pack v4. But doesn't require a file format change. :-)
^ permalink raw reply
* "git archve --format=tar" output changed from 1.8.1 to 1.8.2.1
From: Greg KH @ 2013-01-31 17:28 UTC (permalink / raw)
To: Rene Scharfe, Junio C Hamano; +Cc: git, Konstantin Ryabitsev
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 released the 3.0.61 kernel, and it turned out that I
couldn't upload the kernel release because 'git archive' now creates a
binary file that differs from an older version of git.
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 +0100
+++ new_git_archive 2013-01-31 17:32:21.509674417 +0100
@@ -19239998,8 +19239998,8 @@
125943d0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125943e0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125943f0:0000 0000 0000 0000 0000 0000 0000 0000 ................
-12594400:0000 0000 0000 0000 0000 0000 0000 0000 ................
-12594410:0000 0000 0000 0000 0000 0000 0000 0000 ................
+12594400:7765 7374 6272 6964 6765 2d6f 6d61 7033 westbridge-omap3
+12594410:2d70 6e61 6e64 2d68 616c 2f00 0000 0000 -pnand-hal/.....
12594420:0000 0000 0000 0000 0000 0000 0000 0000 ................
12594430:0000 0000 0000 0000 0000 0000 0000 0000 ................
12594440:0000 0000 0000 0000 0000 0000 0000 0000 ................
@@ -19240025,8 +19240025,8 @@
12594580:2f61 7374 6f72 6961 2f61 7263 682f 6172 /astoria/arch/ar
12594590:6d2f 706c 6174 2d6f 6d61 702f 696e 636c m/plat-omap/incl
125945a0:7564 652f 6d61 6368 2f77 6573 7462 7269 ude/mach/westbri
-125945b0:6467 652f 7765 7374 6272 6964 6765 2d6f dge/westbridge-o
-125945c0:6d61 7033 2d70 6e61 6e64 2d68 616c 0000 map3-pnand-hal..
+125945b0:6467 6500 0000 0000 0000 0000 0000 0000 dge.............
+125945c0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125945d0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125945e0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125945f0:0000 0000 0000 0000 0000 0000 0000 0000 ................
Interestingly, the output of uncompressing the tar archives is
identical, so the data is correct, but the binary isn't.
Now keeping binary compatibility of tar archive files isn't really a big
deal, but, the commit to git that causes this seems a bit odd, is it
really needed? Or can we just fix the version of tar with NetBSD
instead? :)
Any ideas?
thanks,
greg k-h
^ permalink raw reply
* Re: "git archve --format=tar" output changed from 1.8.1 to 1.8.2.1
From: Junio C Hamano @ 2013-01-31 17:32 UTC (permalink / raw)
To: Greg KH; +Cc: Rene Scharfe, git, Konstantin Ryabitsev
In-Reply-To: <20130131172805.GC16593@kroah.com>
Greg KH <gregkh@linuxfoundation.org> 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.
>
> A few days ago I released the 3.0.61 kernel, and it turned out that I
> couldn't upload the kernel release because 'git archive' now creates a
> binary file that differs from an older version of git.
> ...
> Now keeping binary compatibility of tar archive files isn't really a big
> deal, but, the commit to git that causes this seems a bit odd, is it
> really needed? Or can we just fix the version of tar with NetBSD
> instead? :)
>
> Any ideas?
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
itself" trick a fall-back mode that says "but if the signature does
not match, then transfer the bulk used to create the signature to
the remote anyway". This fallback can and should of course be
useful for the compressed patch transfer.
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Junio C Hamano @ 2013-01-31 17:35 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Matthieu Moy, git, Jeff King, Michael Haggerty
In-Reply-To: <CACBZZX552fnD+u9Zp-BhqDyYWN+OiyvCyub-xjMZ-_GXCG-vQA@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> On Mon, Apr 23, 2012 at 10:37 AM, Matthieu Moy <Matthieu.Moy@imag.fr> 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 don't think this was a good move for the documentation. Now every
> time I find an old repo with "push.default=tracking" I end up
> wondering what it was a synonym for again, and other users who don't
> know what it does will just assume it's an invalid value or something.
>
> We can't treat existing config values we still support as any other
> deprecated feature. They still exist in files we have no control over,
> and in people's brains who are reading "man git-config" trying to
> remember what it meant.
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.
I think I can be persuaded to apply a patch that mentions 'tracking'
as a side note.
Thanks.
>
>> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
>> ---
>> Feel free to squash into previous one if needed.
>>
>> Documentation/config.txt | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/Documentation/config.txt b/Documentation/config.txt
>> index e38fab1..ddf6043 100644
>> --- a/Documentation/config.txt
>> +++ b/Documentation/config.txt
>> @@ -1693,7 +1693,6 @@ push.default::
>> makes `git push` and `git pull` symmetrical in the sense that `push`
>> will update the same remote ref as the one which is merged by
>> `git pull`.
>> -* `tracking` - deprecated synonym for `upstream`.
>> * `current` - push the current branch to a branch of the same name.
>> +
>> The `current` and `upstream` modes are for those who want to
>> --
>> 1.7.10.234.ge65dd.dirty
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: "git archve --format=tar" output changed from 1.8.1 to 1.8.2.1
From: Greg KH @ 2013-01-31 17:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Rene Scharfe, git, Konstantin Ryabitsev
In-Reply-To: <7vzjzpgswz.fsf@alter.siamese.dyndns.org>
On Thu, Jan 31, 2013 at 09:32:12AM -0800, Junio C Hamano wrote:
> Greg KH <gregkh@linuxfoundation.org> 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.
> >
> > A few days ago I released the 3.0.61 kernel, and it turned out that I
> > couldn't upload the kernel release because 'git archive' now creates a
> > binary file that differs from an older version of git.
> > ...
> > Now keeping binary compatibility of tar archive files isn't really a big
> > deal, but, the commit to git that causes this seems a bit odd, is it
> > really needed? Or can we just fix the version of tar with NetBSD
> > instead? :)
> >
> > Any ideas?
>
> 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
> itself" trick a fall-back mode that says "but if the signature does
> not match, then transfer the bulk used to create the signature to
> the remote anyway". This fallback can and should of course be
> useful for the compressed patch transfer.
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.
thanks,
greg k-h
^ permalink raw reply
* Re: "git archve --format=tar" output changed from 1.8.1 to 1.8.2.1
From: Konstantin Ryabitsev @ 2013-01-31 17:52 UTC (permalink / raw)
To: Greg KH; +Cc: Junio C Hamano, Rene Scharfe, git
In-Reply-To: <20130131174103.GA20111@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]
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 accept compressed archives, so you would be uploading about
80MB instead of 431MB, but that would still be a problem for anyone
releasing large tarballs over unreliable connections. I know you
routinely do 2-3 releases at once, so that would still mean uploading
120-180MB.
I don't have immediate statistics on how many people release using "kup
--tar", but I know that at least you and Linus rely on that exclusively.
Regards,
--
Konstantin Ryabitsev
Systems Administrator
Linux Foundation, kernel.org
Montréal, Québec
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 730 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] run-command: Be more informative about what failed
From: Stephen Boyd @ 2013-01-31 18:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfw1hiami.fsf@alter.siamese.dyndns.org>
On 01/31/13 08:24, 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.
It helped me avoid firing up gdb, but if you don't see much use feel
free to ignore this patch.
>
>> For example, the above error now prints:
>>
>> error: cannot create stderr pipe for gpg: Too many open files
>> error: could not run gpg.
> I'd prefer to see these names spelled out (e.g. "standard error")
> in any case.
Sure, I can do that.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH 1/3] gpg: Close stderr once finished with it in verify_signed_buffer()
From: Stephen Boyd @ 2013-01-31 18:06 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130131055053.GA11912@sigill.intra.peff.net>
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,10 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
> write_in_full(gpg.in, payload, payload_size);
> close(gpg.in);
>
> - if (gpg_output)
> + if (gpg_output) {
> strbuf_read(gpg_output, gpg.err, 0);
> + close(gpg.err);
> + }
> ret = finish_command(&gpg);
>
> unlink_or_warn(path);
>
> But that is a minor nit; either way, the patch looks good to me.
Looks better. I'll resend with this.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* Re: [feature request] git-daemon http connection filtering of client types
From: @ 2013-01-31 18:11 UTC (permalink / raw)
To: kusmabite; +Cc: git
In-Reply-To: <CABPQNSYq-OO0CrEPjEcH5v+OSTqxYfRbdtaoSER3v+dCHzgyUA@mail.gmail.com>
Hey folks,
On 31 January 2013 08:22, Erik Faye-Lund <kusmabite@gmail.com> 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 list through nabble.
oops.. yes, I see it now. I should have spotted that earlier. Sorry
about the list noise.
> The message contains HTML to display the image, and the git mailing
> list rejects HTML messages. So the only ones who should be able to get
> these spam-emails are users who subscribe through nabble. If you
> subscribe through vger instead
> (http://vger.kernel.org/vger-lists.html#git), you should get less
> spam.
I have never subscribed to anything via nabble. ^Zcat blessings | wc -l
> Git-daemon doesn't have an http-feature. You are probably thinking
> about git-http-backend, but that's an CGI; the http-daemon invoking it
> should already be able to filter connections. So, I don't think
> there's anything that needs to be done to be able to block spammers
> from git-servers. Blocking spammers from nabble is a different manner,
> and is something you'll have to take up with the nabble staff.
Agreed.. and I won't waste my time with nabble. I'll just set
procmeil to file new threads from nabble into a "penalty box" for now
and start a whitelist. Perhaps I'll come up with something more
elegant/automated later.
So, I guess my "feature request" is "resolved".
Cheers!
-phil
^ permalink raw reply
* Re: "git archve --format=tar" output changed from 1.8.1 to 1.8.2.1
From: Junio C Hamano @ 2013-01-31 18:16 UTC (permalink / raw)
To: Greg KH; +Cc: Rene Scharfe, git, Konstantin Ryabitsev
In-Reply-To: <20130131174103.GA20111@kroah.com>
Greg KH <gregkh@linuxfoundation.org> 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
>> itself" trick a fall-back mode that says "but if the signature does
>> not match, then transfer the bulk used to create the signature to
>> the remote anyway". This fallback can and should of course be
>> useful for the compressed patch transfer.
>
> 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.
Then how about fixing kup to try both versions of Git? There will
be people who run different versions of Git anyway, and kup should
not be preventing Git from helping people on other platforms, or
improving its output in general.
^ permalink raw reply
* [PATCHv2 1/3] gpg: Close stderr once finished with it in verify_signed_buffer()
From: Stephen Boyd @ 2013-01-31 18:18 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130131055053.GA11912@sigill.intra.peff.net>
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>
---
gpg-interface.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
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,10 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
write_in_full(gpg.in, payload, payload_size);
close(gpg.in);
- if (gpg_output)
+ if (gpg_output) {
strbuf_read(gpg_output, gpg.err, 0);
+ close(gpg.err);
+ }
ret = finish_command(&gpg);
unlink_or_warn(path);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* Re: [PATCH 3/3] gpg: Allow translation of more error messages
From: Jonathan Nieder @ 2013-01-31 18:20 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <1359597666-10108-4-git-send-email-sboyd@codeaurora.org>
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: Jonathan Nieder <jrnieder@gmail.com>
^ permalink raw reply
* Re: "git archve --format=tar" output changed from 1.8.1 to 1.8.2.1
From: René Scharfe @ 2013-01-31 18:33 UTC (permalink / raw)
To: Greg KH; +Cc: Junio C Hamano, git, Konstantin Ryabitsev
In-Reply-To: <20130131172805.GC16593@kroah.com>
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 +0100
> +++ new_git_archive 2013-01-31 17:32:21.509674417 +0100
> @@ -19239998,8 +19239998,8 @@
> 125943d0:0000 0000 0000 0000 0000 0000 0000 0000 ................
> 125943e0:0000 0000 0000 0000 0000 0000 0000 0000 ................
> 125943f0:0000 0000 0000 0000 0000 0000 0000 0000 ................
> -12594400:0000 0000 0000 0000 0000 0000 0000 0000 ................
> -12594410:0000 0000 0000 0000 0000 0000 0000 0000 ................
> +12594400:7765 7374 6272 6964 6765 2d6f 6d61 7033 westbridge-omap3
> +12594410:2d70 6e61 6e64 2d68 616c 2f00 0000 0000 -pnand-hal/.....
> 12594420:0000 0000 0000 0000 0000 0000 0000 0000 ................
> 12594430:0000 0000 0000 0000 0000 0000 0000 0000 ................
> 12594440:0000 0000 0000 0000 0000 0000 0000 0000 ................
> @@ -19240025,8 +19240025,8 @@
> 12594580:2f61 7374 6f72 6961 2f61 7263 682f 6172 /astoria/arch/ar
> 12594590:6d2f 706c 6174 2d6f 6d61 702f 696e 636c m/plat-omap/incl
> 125945a0:7564 652f 6d61 6368 2f77 6573 7462 7269 ude/mach/westbri
> -125945b0:6467 652f 7765 7374 6272 6964 6765 2d6f dge/westbridge-o
> -125945c0:6d61 7033 2d70 6e61 6e64 2d68 616c 0000 map3-pnand-hal..
> +125945b0:6467 6500 0000 0000 0000 0000 0000 0000 dge.............
> +125945c0:0000 0000 0000 0000 0000 0000 0000 0000 ................
> 125945d0:0000 0000 0000 0000 0000 0000 0000 0000 ................
> 125945e0:0000 0000 0000 0000 0000 0000 0000 0000 ................
> 125945f0:0000 0000 0000 0000 0000 0000 0000 0000 ................
This is the only directory in the repository whose path is long enough to
make a difference with the patch, 105 characters in total:
drivers/staging/westbridge/astoria/arch/arm/plat-omap/include/mach/westbridge/westbridge-omap3-pnand-hal/
Five characters less and you wouldn't notice a thing. It contains
"westbridge" thrice, so I think it's cheating just to reach that
length, though. ;-)
> Interestingly, the output of uncompressing the tar archives is
> identical, so the data is correct, but the binary isn't.
The path is split differently between two header fields, that's all.
> Now keeping binary compatibility of tar archive files isn't really a big
> deal, but, the commit to git that causes this seems a bit odd, is it
> really needed? Or can we just fix the version of tar with NetBSD
> instead? :)
Apart from Junio's suggestion, I can't think of a practical solution.
You could downgrade your git to a version before the fix. A downside is
that you won't be able to extract the archive on NetBSD without getting
an error message (but the contents would be intact, except perhaps for
permission bits of the directory above).
You could upgrade the kernel.org version of git, but that might cause the
same problem for other maintainers with long directory paths who in their
repositories who still use git without the fix.
You could make the path shorter. Won't help at all with the release you
just did, of course.
I don't know if other tar implementations freak out when they see an
empty name field. NetBSD's tar might seem a bit too strict here, but
overall I think it's right in complaining.
What makes the commit odd, by the way?
Thanks,
René
^ permalink raw reply
* [PATCH 0/5] Fix msvc build
From: Ramsay Jones @ 2013-01-31 18:26 UTC (permalink / raw)
To: GIT Mailing-list
Cc: Junio C Hamano, Erik Faye-Lund, Jonathan Nieder, Johannes Sixt,
Johannes Schindelin
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 ...
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.
HTH
ATB,
Ramsay Jones
Ramsay Jones (5):
msvc: Fix compilation errors caused by poll.h emulation
msvc: git-daemon: Fix linker "unresolved external" errors
msvc: Fix build by adding missing symbol defines
msvc: test-svn-fe: Fix linker "unresolved external" error
msvc: avoid collisions between "tags" and "TAGS"
compat/msvc.h | 2 ++
compat/vcbuild/include/sys/poll.h | 1 -
compat/vcbuild/include/unistd.h | 3 +++
config.mak.uname | 4 +++-
git-compat-util.h | 3 +++
test-svn-fe.c | 2 +-
6 files changed, 12 insertions(+), 3 deletions(-)
delete mode 100644 compat/vcbuild/include/sys/poll.h
--
1.8.1
^ permalink raw reply
* [PATCH 1/5] msvc: Fix compilation errors caused by poll.h emulation
From: Ramsay Jones @ 2013-01-31 18:28 UTC (permalink / raw)
To: GIT Mailing-list
Cc: Junio C Hamano, Erik Faye-Lund, Jonathan Nieder, Johannes Sixt,
Johannes Schindelin
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).
In order to fix the compilation errors, we use the same solution adopted
in that earlier commit. In particular, we set _WIN32_WINNT to 0x0502
(which would target Windows Server 2003) prior to including the winsock2.h
header file.
Also, we delete the compat/vcbuild/include/sys/poll.h header file, since
it is now redundant and it's presence may cause some confusion.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
compat/vcbuild/include/sys/poll.h | 1 -
git-compat-util.h | 3 +++
2 files changed, 3 insertions(+), 1 deletion(-)
delete mode 100644 compat/vcbuild/include/sys/poll.h
diff --git a/compat/vcbuild/include/sys/poll.h b/compat/vcbuild/include/sys/poll.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/sys/poll.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/git-compat-util.h b/git-compat-util.h
index cc2abee..204cb1e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -86,6 +86,9 @@
#define _SGI_SOURCE 1
#ifdef WIN32 /* Both MinGW and MSVC */
+# if defined (_MSC_VER)
+# define _WIN32_WINNT 0x0502
+# endif
#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
#include <winsock2.h>
#include <windows.h>
--
1.8.1
^ permalink raw reply related
* [PATCH 2/5] msvc: git-daemon: Fix linker "unresolved external" errors
From: Ramsay Jones @ 2013-01-31 18:30 UTC (permalink / raw)
To: GIT Mailing-list
Cc: Junio C Hamano, Erik Faye-Lund, Jonathan Nieder, Johannes Sixt,
Johannes Schindelin
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' versions of these function.
Although the MSVC header <WS2tcpip.h> contains the prototypes for
the inet_pton and inet_ntop functions, they are only visible for
Windows API versions from 0x0600 (Windows Vista) or later. (In
addition, on Windows XP, ws2_32.dll does not export these symbols).
In order to fix the linker errors, we also configure the MSVC build
to use the internal compat versions of these functions by setting
the NO_INET_{PTON,NTOP} build variables.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
config.mak.uname | 2 ++
1 file changed, 2 insertions(+)
diff --git a/config.mak.uname b/config.mak.uname
index bea34f0..7e52f3c 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -344,6 +344,8 @@ ifeq ($(uname_S),Windows)
NO_CURL = YesPlease
NO_PYTHON = YesPlease
BLK_SHA1 = YesPlease
+ NO_INET_PTON = YesPlease
+ NO_INET_NTOP = YesPlease
NO_POSIX_GOODIES = UnfortunatelyYes
NATIVE_CRLF = YesPlease
DEFAULT_HELP_FORMAT = html
--
1.8.1
^ permalink raw reply related
* [PATCH 3/5] msvc: Fix build by adding missing symbol defines
From: Ramsay Jones @ 2013-01-31 18:31 UTC (permalink / raw)
To: GIT Mailing-list
Cc: Junio C Hamano, Erik Faye-Lund, Jonathan Nieder, Johannes Sixt,
Johannes Schindelin
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.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
compat/vcbuild/include/unistd.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/compat/vcbuild/include/unistd.h b/compat/vcbuild/include/unistd.h
index b14fcf9..c65c2cd 100644
--- a/compat/vcbuild/include/unistd.h
+++ b/compat/vcbuild/include/unistd.h
@@ -49,6 +49,9 @@ typedef int64_t off64_t;
#define INTMAX_MAX _I64_MAX
#define UINTMAX_MAX _UI64_MAX
+#define UINT32_MAX 0xffffffff /* 4294967295U */
+
+#define STDIN_FILENO 0
#define STDOUT_FILENO 1
#define STDERR_FILENO 2
--
1.8.1
^ permalink raw reply related
* [PATCH 5/5] msvc: avoid collisions between "tags" and "TAGS"
From: Ramsay Jones @ 2013-01-31 18:33 UTC (permalink / raw)
To: GIT Mailing-list
Cc: Junio C Hamano, Erik Faye-Lund, Jonathan Nieder, Johannes Sixt,
Johannes Schindelin
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 perform an MSVC build, which is usually
executed using MinGW tools, we can also benefit from this capability.
In order to reap the above benefits, we set the ETAGS_TARGET build
variable to ETAGS in the MSVC config block.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
config.mak.uname | 1 +
1 file changed, 1 insertion(+)
diff --git a/config.mak.uname b/config.mak.uname
index bfb8a39..6f60c3f 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -343,6 +343,7 @@ ifeq ($(uname_S),Windows)
NO_CURL = YesPlease
NO_PYTHON = YesPlease
BLK_SHA1 = YesPlease
+ ETAGS_TARGET = ETAGS
NO_INET_PTON = YesPlease
NO_INET_NTOP = YesPlease
NO_POSIX_GOODIES = UnfortunatelyYes
--
1.8.1
^ permalink raw reply related
* [PATCH 4/5] msvc: test-svn-fe: Fix linker "unresolved external" error
From: Ramsay Jones @ 2013-01-31 18:32 UTC (permalink / raw)
To: GIT Mailing-list
Cc: Junio C Hamano, Erik Faye-Lund, Jonathan Nieder, Johannes Sixt,
Johannes Schindelin
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
systems which can't even declare 'unsigned long long' variables,
let alone provide the strtoll() or strtoull() functions. Setting
this build variable does not provide an implementation of these
functions. Rather, it simply allows the compat implementations
of strto{i,u}max() to use strtol() and strtoul() instead.
In order to fix the linker error on systems with NO_STRTOULL set,
currently MSVC and OSF1, we can substitute a call to strtoumax().
However, we can easily provide support for the strtoull() and
strtoll() functions on MSVC, since they are essentially already
available as _strtoui64() and _strtoi64(). This allows us to
remove NO_STRTOULL for MSVC.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
compat/msvc.h | 2 ++
config.mak.uname | 1 -
test-svn-fe.c | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/compat/msvc.h b/compat/msvc.h
index aa4b563..96b6d60 100644
--- a/compat/msvc.h
+++ b/compat/msvc.h
@@ -12,6 +12,8 @@
#define __attribute__(x)
#define strncasecmp _strnicmp
#define ftruncate _chsize
+#define strtoull _strtoui64
+#define strtoll _strtoi64
static __inline int strcasecmp (const char *s1, const char *s2)
{
diff --git a/config.mak.uname b/config.mak.uname
index 7e52f3c..bfb8a39 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -327,7 +327,6 @@ ifeq ($(uname_S),Windows)
# NEEDS_LIBICONV = YesPlease
NO_ICONV = YesPlease
NO_STRTOUMAX = YesPlease
- NO_STRTOULL = YesPlease
NO_MKDTEMP = YesPlease
NO_MKSTEMPS = YesPlease
SNPRINTF_RETURNS_BOGUS = YesPlease
diff --git a/test-svn-fe.c b/test-svn-fe.c
index 0f2d9a4..120ec96 100644
--- a/test-svn-fe.c
+++ b/test-svn-fe.c
@@ -24,7 +24,7 @@ static int apply_delta(int argc, char *argv[])
die_errno("cannot open preimage");
if (buffer_init(&delta, argv[3]))
die_errno("cannot open delta");
- if (svndiff0_apply(&delta, (off_t) strtoull(argv[4], NULL, 0),
+ if (svndiff0_apply(&delta, (off_t) strtoumax(argv[4], NULL, 0),
&preimage_view, stdout))
return 1;
if (buffer_deinit(&preimage))
--
1.8.1
^ permalink raw reply related
* Re: [PATCH v3 00/11] unify appending of sob
From: Brandon Casey @ 2013-01-31 18:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git, pclouds
In-Reply-To: <7vhalylggd.fsf@alter.siamese.dyndns.org>
On Wed, Jan 30, 2013 at 9:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Jonathan Nieder <jrnieder@gmail.com> 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, a
>>> small behavior change when the commit message ends with an
>>> RFC2822-style header with no trailing newline and the possibility of
>>> tightening the pattern in sequencer.c to match the strictness of
>>> format-patch (which could easily wait for a later patch).
>>
>> Thanks for a quick review. I agree that this series is getting very
>> close with your help.
>
> Unless Brandon and/or Jonathan wants to have another chance to
> excise warts from the recorded history by rerolling the entire
> series one more time, I think what we have queued is in a good
> enough shape to merge to 'next' and any further improvement and fix
> can be done incrementally.
>
> OK? Or "stop, I want to reroll"?
>
> I'll wait for a day or two.
Let's hold off so I can do another round. I worked on this last night
and was able to simplify some things nicely. I'll try to finish up
tonight and resubmit.
-Brandon
^ permalink raw reply
* Re: [PATCH 0/5] Fix msvc build
From: Johannes Schindelin @ 2013-01-31 18:57 UTC (permalink / raw)
To: Ramsay Jones
Cc: GIT Mailing-list, Junio C Hamano, Erik Faye-Lund, Jonathan Nieder,
Johannes Sixt
In-Reply-To: <510AB766.4030806@ramsay1.demon.co.uk>
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?
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Jonathan Nieder @ 2013-01-31 19:07 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <7vvcadgss0.fsf@alter.siamese.dyndns.org>
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, 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.
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?
My two cents,
Jonathan
^ permalink raw reply
* Why git-whatchanged shows a commit touching every file, but git-log doesn't?
From: Constantine A. Murenin @ 2013-01-31 19:09 UTC (permalink / raw)
To: git
Hi,
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.
That's the offending commit from 2011-11-26:
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/86d7f5d305c6adaa56ff4582ece9859d73106103
https://github.com/DragonFlyBSD/DragonFlyBSD/commit/86d7f5d305c6adaa56ff4582ece9859d73106103
Since then, with some tools, if you look at file history for any file
anywhere in the repo, you can see that all files were changed on
2011-11-26 with that commit, but it's only shown in some tools, and
not shown in others.
For example, the bogus 2011-11-26 commit is not shown with the following:
* git log sys/sys/sensors.h
* https://github.com/DragonFlyBSD/DragonFlyBSD/commits/master/sys/sys/sensors.h
However, the bogus commit is [erroneously] shown with the following:
% git whatchanged --pretty=%at sys/sys/sensors.h | cat
1322296064
:000000 100644 0000000... 554cfc2... A sys/sys/sensors.h
1191329821
:000000 100644 0000000... 554cfc2... A sys/sys/sensors.h
%
Notice how the file was ]A]dded once again at 1322296064 without ever
being deleted, and that the dst sha1 is the same for both the latest
and the immediately prior revision of the file.
Gitweb, unlike github, would also show the erroneous commit from 2011-11:
http://gitweb.dragonflybsd.org/dragonfly.git/history/HEAD:/sys/sys/sensors.h
Another, more representative example, which shows that src sha1 (field
names are documented in git-diff-tree(1)) is always "0000000..." in
such bogus touch-all commits (even though it makes little sense when
you consider that the files were never deleted and still have the same
dst sha1):
% git whatchanged --pretty=%at sys/sys/sysctl.h | head -9
1322296064
:000000 100644 0000000... 6659977... A sys/sys/sysctl.h
1296826445
:100644 100644 94b8d96... 6659977... M sys/sys/sysctl.h
1292413105
:100644 100644 8c9deaa... 94b8d96... M sys/sys/sysctl.h
%
So, my questions are as follows:
* How was it possible for all these files to be added without first
being deleted in the first place? Was / is it a bug in git (during a
commit) to allow something like that?
* Why do some tools compact such bogus commits out (and hide them from
the user), but some don't?
* Is there a way to make git-whatchanged and gitweb ignore such bogus
commits on files that weren't actually modified, just as git-log and
github already do?
P.S. I've asked this question on
http://stackoverflow.com/q/14632828/1122270, if anyone wants a cookie.
Best regards,
Constantine.
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Jonathan Nieder @ 2013-01-31 19:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <20130131190747.GE27340@google.com>
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.
Jonathan
^ permalink raw reply
* 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
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