* Re: [PATCH] git-send-email: add ~/.authinfo parsing
From: Ted Zlatanov @ 2013-01-31 15:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Michal Nazarewicz, git, Krzysztof Mazur,
Michal Nazarewicz
In-Reply-To: <7v7gmumzo6.fsf@alter.siamese.dyndns.org>
On Wed, 30 Jan 2013 07:57:29 -0800 Junio C Hamano <gitster@pobox.com> wrote:
JCH> Jeff King <peff@peff.net> 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
>> users. I think contrib/mw-to-git even has credential support written in
>> perl, so it would just need to be factored out to Git.pm.
JCH> Yeah, that sounds like a neat idea.
Jeff, is there a way for git-credential to currently support
authinfo/netrc parsing? I assume that's the right way, instead of using
Michal's proposal to parse internally?
I'd like to add that, plus support for the 'string' and "string"
formats, and authinfo.gpg decoding through GPG. I'd write it in Perl,
if there's a choice.
Ted
^ permalink raw reply
* Re: [PATCH 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.
From: Junio C Hamano @ 2013-01-31 15:48 UTC (permalink / raw)
To: Jeff Epler; +Cc: TJ, git
In-Reply-To: <20130131132526.GA10622@unpythonic.net>
Jeff Epler <jepler@unpythonic.net> 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 -m 755 $(DESTDIR)$(man1dir)
> so that $(INSTALL) is not called when the target directory exists
> already.
That can cut both ways, though. If it exists and its permission is
too tight (say 0750), $(INSTALL) -d -m 755 ought to loosen for
others, but with the additional test, it won't be given a chance to
do so.
^ permalink raw reply
* Re: [PATCH 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.
From: Junio C Hamano @ 2013-01-31 15:51 UTC (permalink / raw)
To: TJ; +Cc: git
In-Reply-To: <5109D230.2030101@iam.tj>
TJ <git@iam.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)$(man1dir)
> + $(INSTALL) -m $(INSTALL_MODE_DATA) $(DOC_MAN5) $(DESTDIR)$(man5dir)
> + $(INSTALL) -m $(INSTALL_MODE_DATA) $(DOC_MAN7) $(DESTDIR)$(man7dir)
I'm tempted to suggest
INSTALL_DIR = $(INSTALL) -d -m 755
INSTALL_DATA = $(INSTALL) -m 644
INSTALL_PROGRAM = $(INSTALL) -m 755
The number of lines the patch needs to touch will be the same, but
the resulting lines will not have many $(INSTALL_MODE_BLAH) shouting
at us.
Besides, you would want to differentiate the two kinds of 755 anyway
(I'd prefer INSTALL_PROGRAM to use -m 555 personally, for example).
^ permalink raw reply
* Re: [PATCH 0/2] improve "git branch --contains=<commit> <pattern>"
From: Junio C Hamano @ 2013-01-31 15:53 UTC (permalink / raw)
To: Jeff King; +Cc: Peter Wu, git
In-Reply-To: <20130131064357.GA24660@sigill.intra.peff.net>
Jeff King <peff@peff.net> 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 behavior
> [2/2]: branch: let branch filters imply --list
Thanks. Looks good.
^ permalink raw reply
* Re: [PATCH] push: fix segfault when HEAD points nowhere
From: Junio C Hamano @ 2013-01-31 16:06 UTC (permalink / raw)
To: Fraser Tweedale; +Cc: git
In-Reply-To: <1359634971-79036-1-git-send-email-frase@frase.id.au>
Fraser Tweedale <frase@frase.id.au> 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 <frase@frase.id.au>
> ---
> transport.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/transport.c b/transport.c
> index 9932f40..b9306ef 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -741,7 +741,7 @@ void transport_print_push_status(const char *dest, struct ref *refs,
> n += print_one_push_status(ref, dest, n, porcelain);
> if (ref->status == REF_STATUS_REJECT_NONFASTFORWARD &&
> *nonfastforward != NON_FF_HEAD) {
> - if (!strcmp(head, ref->name))
> + if (head != NULL && !strcmp(head, ref->name))
> *nonfastforward = NON_FF_HEAD;
> else
> *nonfastforward = NON_FF_OTHER;
Wow.
This is a bug that is hard to trigger by just using the software
(you have to be doubly insane to be on an unborn branch and pushing
out a branch that is not the one you are currently on) and one has
to look at the code to hunt for it.
The fix looks correct. Thank you very much for spotting.
^ permalink raw reply
* Re: [PATCH 2/2] branch: let branch filters imply --list
From: Peter Wu @ 2013-01-31 16:13 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130131064611.GB25315@sigill.intra.peff.net>
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
> the `--contains` argument entirely. This is not very
> helpful. There are two reasonable behaviors for git here:
>
> 1. Flag an error; the arguments do not make sense.
>
> 2. Implicitly go into `--list` mode
>
> This patch chooses the latter, as it is more convenient, and
> there should not be any ambiguity with attempting to create
> a branch; using `--contains` and not wanting to list is
> nonsensical.
>
> That leaves the case where an explicit modification option
> like `-d` is given. We already catch the case where
> `--list` is given alongside `-d` and flag an error. With
> this patch, we will also catch the use of `--contains` and
> other filter options alongside `-d`.
>
> Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Peter Wu <lekensteyn@gmail.com>
I have tested this patch on top of 1.8.1.2 and it seems to work.
One note, the following command spits out master without complaining about the
non-existing branch name:
git branch --contains <id> master <non-existant branch name>
(the order of branches doesn't affect the result.)
Regards,
Peter
^ permalink raw reply
* Re: [PATCH 2/3] run-command: Be more informative about what failed
From: Junio C Hamano @ 2013-01-31 16:24 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <1359597666-10108-3-git-send-email-sboyd@codeaurora.org>
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.
> 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.
Thanks.
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> run-command.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/run-command.c b/run-command.c
> index 12d4ddb..016dd05 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -274,6 +274,7 @@ int start_command(struct child_process *cmd)
> int need_in, need_out, need_err;
> int fdin[2], fdout[2], fderr[2];
> int failed_errno = failed_errno;
> + char *str;
>
> /*
> * In case of errors we must keep the promise to close FDs
> @@ -286,6 +287,7 @@ int start_command(struct child_process *cmd)
> failed_errno = errno;
> if (cmd->out > 0)
> close(cmd->out);
> + str = "stdin";
> goto fail_pipe;
> }
> cmd->in = fdin[1];
> @@ -301,6 +303,7 @@ int start_command(struct child_process *cmd)
> close_pair(fdin);
> else if (cmd->in)
> close(cmd->in);
> + str = "stdout";
> goto fail_pipe;
> }
> cmd->out = fdout[0];
> @@ -318,9 +321,10 @@ int start_command(struct child_process *cmd)
> close_pair(fdout);
> else if (cmd->out)
> close(cmd->out);
> + str = "stderr";
> fail_pipe:
> - error("cannot create pipe for %s: %s",
> - cmd->argv[0], strerror(failed_errno));
> + error("cannot create %s pipe for %s: %s",
> + str, cmd->argv[0], strerror(failed_errno));
> errno = failed_errno;
> return -1;
> }
^ permalink raw reply
* Re: [PATCH 0/2] optimizing pack access on "read only" fetch repos
From: Shawn Pearce @ 2013-01-31 16:47 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20130129211932.GA17377@sigill.intra.peff.net>
On Tue, Jan 29, 2013 at 1:19 PM, Jeff King <peff@peff.net> 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 --auto" in it, where nobody
>> passes "-f" to "repack" to cause recomputation of delta.
>>
>> What I was trying to seek was a way to reduce the runtime penalty we
>> pay every time we run git in such a repository.
>>
>> - Object look-up cost will become log2(50*n) from 50*log2(n), which
>> is about 50/log2(50) improvement;
>
> Yes and no. Our heuristic is to look at the last-used pack for an
> object. So assuming we have locality of requests, we should quite often
> get "lucky" and find the object in the first log2 search. Even if we
> don't assume locality, a situation with one large pack and a few small
> packs will have the large one as "last used" more often than the others,
> and it will also have the looked-for object more often than the others
Opening all of those files does impact performance. It depends on how
slow your open(2) syscall is. I know on Mac OS X that its not the
fastest function we get from the C library. Performing ~40 opens to
look through the most recent pack files and finally find the "real"
pack that contains that tag you asked `git show` for isn't that quick.
Some of us also use Git on filesystems that are network based, and
slow compared to local disk Linux ext2/3/4 with gobs of free RAM.
> So I can see how it is something we could potentially optimize, but I
> could also see it being surprisingly not a big deal. I'd be very
> interested to see real measurements, even of something as simple as a
> "master index" which can reference multiple packfiles.
I actually tried this many many years ago. There are threads in the
archive about it. Its slower. We ruled it out.
>> - System resource cost we incur by having to keep 50 file
>> descriptors open and maintaining 50 mmap windows will reduce by
>> 50 fold.
>
> I wonder how measurable that is (and if it matters on Linux versus less
> efficient platforms).
It does matter. We know it has a negative impact on JGit even on Linux
for example. You don't want 300 packs in a repository. 50 might be
tolerable. 300 is not.
^ permalink raw reply
* Re: [PATCH 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.
From: TJ @ 2013-01-31 16:55 UTC (permalink / raw)
To: git
In-Reply-To: <7vtxpxic5l.fsf@alter.siamese.dyndns.org>
On 31/01/13 15:51, Junio C Hamano wrote:
> TJ <git@iam.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)$(man1dir)
>> + $(INSTALL) -m $(INSTALL_MODE_DATA) $(DOC_MAN5) $(DESTDIR)$(man5dir)
>> + $(INSTALL) -m $(INSTALL_MODE_DATA) $(DOC_MAN7) $(DESTDIR)$(man7dir)
>
> I'm tempted to suggest
>
> INSTALL_DIR = $(INSTALL) -d -m 755
> INSTALL_DATA = $(INSTALL) -m 644
> INSTALL_PROGRAM = $(INSTALL) -m 755
>
> The number of lines the patch needs to touch will be the same, but
> the resulting lines will not have many $(INSTALL_MODE_BLAH) shouting
> at us.
I did contemplate that but was concerned it might be seen as interfering unduly with
the tool name/path settings, as opposed to their options.
> Besides, you would want to differentiate the two kinds of 755 anyway
> (I'd prefer INSTALL_PROGRAM to use -m 555 personally, for example).
Yes, I think I lost that one in the mists of sed-land when making the changes :)
I'll revise the patch based on received comments and post the revision tomorrow.
^ permalink raw reply
* Re: [PATCH 2/2] branch: let branch filters imply --list
From: Junio C Hamano @ 2013-01-31 17:02 UTC (permalink / raw)
To: Peter Wu; +Cc: Jeff King, git
In-Reply-To: <1504250.y8BAS4sG2O@al>
Peter Wu <lekensteyn@gmail.com> writes:
> One note, the following command spits out master without complaining about the
> non-existing branch name:
>
> git branch --contains <id> master <non-existant branch name>
>
> (the order of branches doesn't affect the result.)
That is perfectly normal.
What you gave after "--contains <id>" are *not* branch names. They
are patterns against branch names that fits the given criteria (in
this case "--contains <id>") are matched, and the branches that do
not match any of the patterns will not appear in the result.
^ permalink raw reply
* Re: [PATCH 4/6] introduce a commit metapack
From: Shawn Pearce @ 2013-01-31 17:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Duy Nguyen
In-Reply-To: <7vboc6mzpf.fsf@alter.siamese.dyndns.org>
On Wed, Jan 30, 2013 at 7:56 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> 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 argument is that putting it all in the same file makes it
>> more natural for there to be a data dependency.
>
> It is more about the "I am torn on this one" I mentioned earlier.
>
> It would be more "logical" if this weren't tied to a particular
> pack, as the properties of a commit you record in this series do not
> depend on which pack the commit is in, and such a repository-global
> file by definition cannot be inside anybody's .idx.
>
> But if we split the information into separate pieces and store one
> piece per .idx for implementation reasons, it is crazy not to at
> least consider it a longer term goal to put it inside .idx file.
>
> Of course, it is more convenient to store this kind of things in a
> separate file while experimenting and improving the mechanism, but I
> do not think we want to see each packfile in a repository comes with
> 47 auxiliary files with different suffixes 5 years down the road.
Arrrrgggh.
Right now we are in the middle of refactoring the JGit reachability
bitmap implementation to store it into a separate file and get it out
of the .idx file. This work is nearly completed. So this thread is
great timing. :-)
I think Junio is right about not wanting 47 different tiny auxiliary
files for a single pack. We are unlikely to create that many, but
right now there are proposals floating around for at least 2 new
auxiliary files (commit cache and reachability bitmaps). So its not
impossible that another will be discovered in the future.
Junio may be right about the hole in the index file for git-core. I
haven't checked the JGit implementation, but I suspect it does not
have this hole. IIRC JGit consumes the index sections and then expects
the pack trailer SHA-1 to be present immediately after the last table.
This happens because JGit doesn't use mmap() to load the index, it
streams the file into memory and does some reformatting on the tables
to make search faster.
If we are going to change the index to support extension sections and
I have to modify JGit to grok this new format, it needs to be index v3
not index v2. If we are making index v3 we should just put index v3 on
the end of the pack file.
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Ævar Arnfjörð Bjarmason @ 2013-01-31 17:10 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster, Jeff King, Michael Haggerty
In-Reply-To: <1335170284-30768-3-git-send-email-Matthieu.Moy@imag.fr>
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.
> 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: [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
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