Re: Re: Re: Segmentation fault with latest git (070c57df)
It's almost like the compiler is getting the initializer wrong. It's a long shot, but I wonder if the presence of the bitfield could be triggering a compiler bug (or there is a subtle C rule about bitfield initializations that I do not know). Just for the sake of my sanity, what does the following program output for you? Hi, just cmp is 0 is printed. $ gcc --version gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Best regards, Jongman Heo.
Re: Segmentation fault with latest git (070c57df)
Jeff King p...@peff.net writes:
On Thu, Jan 31, 2013 at 07:27:04AM +, Jongman Heo wrote:
FYI, gdb backtrace and valgrind output attached below, Thanks.
Thanks, that's helpful.
#4 0x0812bda0 in string_list_insert (list=0xbfffe7c0,
string=0x821ec3c refs/remotes/origin/HEAD) at string-list.c:57
#5 0x08071838 in add_existing (refname=0x821ec3c
refs/remotes/origin/HEAD,
sha1=0x821ec14 \a\fW\337B\352N\255\314C\320Em\021E`\022C,
incomplete sequence \303, flag=1, cbdata=0xbfffe7c0)
at builtin/fetch.c:570
So we are inserting the string from add_existing, which gets the list
from a callback parameter. Which comes from...
#13 0x0807390a in do_fetch (remote=value optimized out, argc=0,
argv=0xbfffe9f8) at builtin/fetch.c:699
...here, which does this:
struct string_list existing_refs = STRING_LIST_INIT_NODUP;
[...]
for_each_ref(add_existing, existing_refs);
And yet we get:
==2195== Conditional jump or move depends on uninitialised value(s)
==2195==at 0x812B41F: get_entry_index (string-list.c:10)
==2195==by 0x812BD5F: string_list_insert_at_index (string-list.c:33)
==2195==by 0x812BD9F: string_list_insert (string-list.c:57)
==2195==by 0x8071837: add_existing (fetch.c:570)
==2195==by 0x810AF96: do_one_ref (refs.c:525)
==2195==by 0x810BB20: do_for_each_ref_in_dir (refs.c:551)
==2195==by 0x810BD34: do_for_each_ref_in_dirs (refs.c:623)
==2195==by 0x810BC8D: do_for_each_ref_in_dirs (refs.c:597)
==2195==by 0x810C303: do_for_each_ref (refs.c:1295)
==2195==by 0x810C63A: for_each_ref (refs.c:1343)
==2195==by 0x8073909: fetch_one (fetch.c:699)
==2195==by 0x8074250: cmd_fetch (fetch.c:992)
which seems odd. cmp should be initialized to NULL, and then we never
touch it (and even if we did, it wouldn't be unitialized, but rather
have the value we put in it).
It's almost like the compiler is getting the initializer wrong. It's a
long shot, but I wonder if the presence of the bitfield could be
triggering a compiler bug (or there is a subtle C rule about bitfield
initializations that I do not know). Just for the sake of my sanity,
what does the following program output for you?
-- 8 --
#include stdio.h
#include stdlib.h
typedef int (*compare_fn)(const char *, const char *);
struct foo {
char **items;
unsigned int nr, alloc;
unsigned int bitfield:1;
compare_fn cmp;
};
int main(void)
{
struct foo f = { NULL, 0, 0, 0 };
printf(cmp is %lu\n, (unsigned long)f.cmp);
return 0;
}
I doubt that would help because that stack region would be 0 anyway due
to kernel initialization of new pages. You'd have to somehow trample
over it first, like below.
Or perhaps something in the build process went wrong, and fetch.c didn't
get the memo about the new field in the struct. Depending on stack
layout, the next variable might be the 'int i' right before the
'string_list list' in the code, which could explain the value of 1.
8
#include stdio.h
#include stdlib.h
#include string.h
typedef int (*compare_fn)(const char *, const char *);
struct foo {
char **items;
unsigned int nr, alloc;
unsigned int bitfield:1;
compare_fn cmp;
};
void scramble()
{
char foo[256];
memset(foo, 0x42, 256);
}
void init()
{
struct foo f = { NULL, 0, 0, 0 };
printf(cmp is %lu\n, (unsigned long)f.cmp);
}
int main(void)
{
scramble();
init();
return 0;
}
--
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: Segmentation fault with latest git (070c57df)
On Thu, Jan 31, 2013 at 09:42:07AM +0100, Thomas Rast wrote:
int main(void)
{
struct foo f = { NULL, 0, 0, 0 };
printf(cmp is %lu\n, (unsigned long)f.cmp);
return 0;
}
I doubt that would help because that stack region would be 0 anyway due
to kernel initialization of new pages. You'd have to somehow trample
over it first, like below.
Good point. Unfortunately, I can't get either yours or mine to fail,
neither with a recent version of gcc nor with gcc-4.1. But I can't
convince git to fail, either. The only gcc-4.1 I have is Debian's
4.1.3 release, which is not quite what the OP has.
Or perhaps something in the build process went wrong, and fetch.c didn't
get the memo about the new field in the struct. Depending on stack
layout, the next variable might be the 'int i' right before the
'string_list list' in the code, which could explain the value of 1.
Yeah, that would make sense to me with respect to the behavior we are
seeing, but that part of the Makefile should be pretty simple and
bug-free, I'd think (and from the original report, it seems like he was
able to reproduce it well enough to bisect). Still, trying a make clean
make might be worth it just to rule that out.
Puzzled...
-Peff
--
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: How to identify the users?
On 01/31/2013 12:23 PM, Scott Yan wrote: Sitaram: It seems I must host my central repo on Gitolite first... There is no must but yes it is a decent solution and can, in principle, do the kind of checking you want if you set it up to do that. Please note that I don't use that mode and, as my rant would have indicated, I don't think it's a smart thing to do. I don't know Gitolite much, but you are right, maybe I should use Gitolite as my git server. I'll find more documents about gitolite these days, can you give me some suggestion which tutorial should I read? Thanks! ps: my OS is windows. Try http://therightstuff.de/CommentView,guid,b969ea4d-8d2c-42af-9806-de3631f4df68.aspx I normally don't mention blog posts (favouring instead the official documentation) but Windows is an exception. Hence the link. Good luck. -- 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 4/6] introduce a commit metapack
On Wed, Jan 30, 2013 at 09:16:29PM +0700, Duy Nguyen wrote:
Perhaps we could store abbrev sha-1 instead of full sha-1. Nice
space/time trade-off.
Following the on-disk format experiment yesterday, I changed the
format to:
- a list a _short_ SHA-1 of cached commits
- a list of cache entries, each (5 uint32_t) consists of:
- uint32_t for the index in .idx sha-1 table to get full SHA-1 of
the commit
- uint32_t for timestamp
- uint32_t for tree, 1st and 2nd parents for the index in .idx
table
The length of SHA-1 is chosen to be able to unambiguously identify any
cached commits. Full SHA-1 check is done after to catch false
positives. For linux-2.6, SHA-1 length is 6 bytes, git and many
moderate-sized projects are 4 bytes. So it's 26 bytes per commit for
linux-2.6.git, or 8MB .commits file. Not as good as revindex approach
(5.5MB) but way better than the current one (27MB). And still good
enough for caching 2 parents unconditionally.
Performance seems to improve a tiny bit, probably because of more
compact search space: 0.6s with my patch vs 0.7s without (vs 3.4s
without cache).
-- 8 --
diff --git a/cache.h b/cache.h
index 1f96f65..8048d5b 100644
--- a/cache.h
+++ b/cache.h
@@ -1069,6 +1069,7 @@ extern struct packed_git *add_packed_git(const char *,
int, int);
extern const unsigned char *nth_packed_object_sha1(struct packed_git *,
uint32_t);
extern off_t nth_packed_object_offset(const struct packed_git *, uint32_t);
extern off_t find_pack_entry_one(const unsigned char *, struct packed_git *);
+extern int find_pack_entry_pos(const unsigned char *, struct packed_git *);
extern int is_pack_valid(struct packed_git *);
extern void *unpack_entry(struct packed_git *, off_t, enum object_type *,
unsigned long *);
extern unsigned long unpack_object_header_buffer(const unsigned char *buf,
unsigned long len, enum object_type *type, unsigned long *sizep);
diff --git a/commit-metapack.c b/commit-metapack.c
index 2c19f48..c984b8e 100644
--- a/commit-metapack.c
+++ b/commit-metapack.c
@@ -4,11 +4,21 @@
#include commit.h
#include sha1-lookup.h
+struct commit_entry {
+ uint32_t commit;/* nth_packed_object_sha1 to get own SHA-1 */
+ uint32_t timestamp;
+ uint32_t tree; /* nth_packed_object_sha1 to get tree SHA-1 */
+ uint32_t parent1; /* nth_packed_object_sha1 to get 1st parent SHA-1 */
+ uint32_t parent2; /* nth_packed_object_sha1 to get 2nd parent SHA-1 */
+};
+
struct commit_metapack {
struct metapack mp;
uint32_t nr;
+ uint32_t abbrev_len;
+ struct packed_git *pack;
unsigned char *index;
- unsigned char *data;
+ struct commit_entry *data;
struct commit_metapack *next;
};
static struct commit_metapack *commit_metapacks;
@@ -41,20 +51,23 @@ static struct commit_metapack *alloc_commit_metapack(struct
packed_git *pack)
}
memcpy(it-nr, it-mp.data, 4);
it-nr = ntohl(it-nr);
+ memcpy(it-abbrev_len, it-mp.data + 4, 4);
+ it-abbrev_len = ntohl(it-abbrev_len);
+ it-pack = pack;
/*
-* We need 84 bytes for each entry: sha1(20), date(4), tree(20),
-* parents(40).
+* We need 20+abbrev_len bytes for each entry: abbrev sha-1,
+* date(4), tree index(4), parent indexes(8).
*/
- if (it-mp.len (84 * it-nr + 4)) {
+ if (it-mp.len ((sizeof(*it-data) + it-abbrev_len) * it-nr + 8)) {
warning(commit metapack for '%s' is truncated,
pack-pack_name);
metapack_close(it-mp);
free(it);
return NULL;
}
- it-index = it-mp.data + 4;
- it-data = it-index + 20 * it-nr;
+ it-index = it-mp.data + 8;
+ it-data = (struct commit_entry*)(it-index + it-abbrev_len * it-nr);
return it;
}
@@ -83,29 +96,51 @@ static void prepare_commit_metapacks(void)
int commit_metapack(unsigned char *sha1,
uint32_t *timestamp,
- unsigned char **tree,
- unsigned char **parent1,
- unsigned char **parent2)
+ const unsigned char **tree,
+ const unsigned char **parent1,
+ const unsigned char **parent2)
{
struct commit_metapack *p;
prepare_commit_metapacks();
for (p = commit_metapacks; p; p = p-next) {
- unsigned char *data;
- int pos = sha1_entry_pos(p-index, 20, 0, 0, p-nr, p-nr,
sha1);
+ struct commit_entry *data;
+ uint32_t p1, p2;
+ unsigned lo, hi, mi;
+ int pos;
+
+ /* sha1_entry_pos does not work with abbreviated sha-1 */
+ lo = 0;
+ hi = p-nr;
+ pos = -1;
+ do {
+ unsigned mi = (lo + hi) / 2;
+ int cmp = memcmp(p-index + mi * p-abbrev_len, sha1,
p-abbrev_len);
+
+
[feature request] git-daemon http connection filtering of client types
Hey folks,
When I checked for false positives in my spam this morning, I spotted
an interesting malformed img link at the top of a spam message.
{snip}
http://git.{snip}.n2.nabble.com/file/{snip}/t3.jpg
Employ a medal tiffany bracelet {snip} a is
{snip}
So, apparently git-daemon's http features are being used by spammers.
In most cases, spam filters will correctly identify this junk.
I wonder if there is a better way... In my mental sandbox, git-daemon
http could have a set of deny/allow rules for incoming connection
client types.
e.g.:
git: allow
git-http: allow
thunderbird: deny
outlook express: replace linked file with rickroll.jpg
and so on.. An out-of-the-box install probably should default to
allow all to keep backward compatibility.
While I'd love a chance to hack something out, I sadly doubt I'll ever
have the time for it. Perhaps there is a student hacker looking for a
project.
Cheers!
-phil
p.s. appologies to anyone who now has Astley's song stuck in their
head. This was not intentional.
--
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
[PATCH] push: fix segfault when HEAD points nowhere
When reporting the outcome of a push, a segfault occurs if HEAD does
not point somewhere. Check that HEAD points somewhere before trying
to strcmp it.
Signed-off-by: Fraser Tweedale fr...@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;
--
1.8.1.1
--
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: [feature request] git-daemon http connection filtering of client types
On Thu, Jan 31, 2013 at 1:46 PM, porpen+...@gmail.com wrote:
Hey folks,
When I checked for false positives in my spam this morning, I spotted
an interesting malformed img link at the top of a spam message.
{snip}
http://git.{snip}.n2.nabble.com/file/{snip}/t3.jpg
Employ a medal tiffany bracelet {snip} a is
{snip}
So, apparently git-daemon's http features are being used by spammers.
Not at all. You appear to be referring to the message from
http://git.661346.n2.nabble.com/tiffany-bracelet-On-your-Significant-other-td7575440.html
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.
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.
In most cases, spam filters will correctly identify this junk.
I wonder if there is a better way... In my mental sandbox, git-daemon
http could have a set of deny/allow rules for incoming connection
client types.
e.g.:
git: allow
git-http: allow
thunderbird: deny
outlook express: replace linked file with rickroll.jpg
and so on.. An out-of-the-box install probably should default to
allow all to keep backward compatibility.
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.
--
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 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.
I was not familiar with this behavior of 'install -d' that it tries to change the mode of an existing directory, but GNU coreutils 8.12.197-032bb certainly behaves as TJ reports. As a possible alternative, what about [ -d $(DESTDIR)$(main1dir) ] || $(INSTALL) -d -m 755 $(DESTDIR)$(man1dir) so that $(INSTALL) is not called when the target directory exists already. Jeff -- 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] git-send-email: add ~/.authinfo parsing
On Wed, 30 Jan 2013 07:57:29 -0800 Junio C Hamano gits...@pobox.com wrote: JCH Jeff King p...@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 -- 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 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.
Jeff Epler jep...@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. -- 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 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.
TJ g...@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). -- 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 0/2] improve git branch --contains=commit pattern
Jeff King p...@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. -- 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] push: fix segfault when HEAD points nowhere
Fraser Tweedale fr...@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 fr...@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.
--
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 2/2] branch: let branch filters imply --list
On Thursday 31 January 2013 01:46:11 Jeff King wrote: Currently, a branch filter like `--contains`, `--merged`, or `--no-merged` is ignored when we are not in listing mode. For example: git branch --contains=foo bar will create the branch bar from the current HEAD, ignoring 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 p...@peff.net Tested-by: Peter Wu lekenst...@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 -- 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 2/3] run-command: Be more informative about what failed
Stephen Boyd sb...@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 sb...@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; } -- 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 0/2] optimizing pack access on read only fetch repos
On Tue, Jan 29, 2013 at 1:19 PM, Jeff King p...@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. -- 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 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.
On 31/01/13 15:51, Junio C Hamano wrote: TJ g...@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. -- 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 2/2] branch: let branch filters imply --list
Peter Wu lekenst...@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. -- 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 4/6] introduce a commit metapack
On Wed, Jan 30, 2013 at 7:56 AM, Junio C Hamano gits...@pobox.com wrote: Jeff King p...@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. Agggh. 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. -- 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 2/7] Undocument deprecated alias 'push.default=tracking'
On Mon, Apr 23, 2012 at 10:37 AM, Matthieu Moy matthieu@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@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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/RFC 0/6] commit caching
On Tue, Jan 29, 2013 at 1:14 AM, Jeff King p...@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. :-) -- 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
git archve --format=tar output changed from 1.8.1 to 1.8.2.1
Hi, The way we upload the Linux kernel to kernel.org involves creating a tar archive, signing the archive, and then just uploading the signature. The server then checks out the repo based on the tag, generates the tar archive and checks the signature to make sure they match. A few days ago I 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: 125943e0: 125943f0: -12594400: -12594410: +12594400:7765 7374 6272 6964 6765 2d6f 6d61 7033 westbridge-omap3 +12594410:2d70 6e61 6e64 2d68 616c 2f00 -pnand-hal/. 12594420: 12594430: 12594440: @@ -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 map3-pnand-hal.. +125945b0:6467 6500 dge. +125945c0: 125945d0: 125945e0: 125945f0: 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 -- 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: git archve --format=tar output changed from 1.8.1 to 1.8.2.1
Greg KH gre...@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. -- 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 2/7] Undocument deprecated alias 'push.default=tracking'
Ævar Arnfjörð Bjarmason ava...@gmail.com writes: On Mon, Apr 23, 2012 at 10:37 AM, Matthieu Moy matthieu@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@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: git archve --format=tar output changed from 1.8.1 to 1.8.2.1
On Thu, Jan 31, 2013 at 09:32:12AM -0800, Junio C Hamano wrote: Greg KH gre...@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 -- 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: git archve --format=tar output changed from 1.8.1 to 1.8.2.1
On 31/01/13 12:41 PM, Greg KH wrote: Ugh, uploading a 431Mb file, over a flaky wireless connection (I end up doing lots of kernel releases while traveling), would be a horrible change. I'd rather just keep using the same older version of git that kernel.org is running instead. Well, we do 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 signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/3] run-command: Be more informative about what failed
On 01/31/13 08:24, Junio C Hamano wrote: Stephen Boyd sb...@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 -- 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 1/3] gpg: Close stderr once finished with it in verify_signed_buffer()
On 01/30/13 21:50, Jeff King wrote:
The strbuf_read above will read to EOF, so it should be equivalent (and
IMHO slightly more readable) to do:
diff --git a/gpg-interface.c b/gpg-interface.c
index 0863c61..5f142f6 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -130,8 +130,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
--
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: [feature request] git-daemon http connection filtering of client types
Hey folks, On 31 January 2013 08:22, Erik Faye-Lund kusmab...@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 -- 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
[PATCHv2 1/3] gpg: Close stderr once finished with it in verify_signed_buffer()
Failing to close the stderr pipe in verify_signed_buffer() causes
git to run out of file descriptors if there are many calls to
verify_signed_buffer(). An easy way to trigger this is to run
git log --show-signature --merges | grep key
on the linux kernel git repo. Eventually it will fail with
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 p...@peff.net
Signed-off-by: Stephen Boyd sb...@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
--
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 3/3] gpg: Allow translation of more error messages
Stephen Boyd wrote: Mark these strings for translation so that error messages are printed in the user's language of choice. Yeah. Other error messages in this file are already translated, so it's oddly inconsistent. Assuming this passes tests with GETTEXT_POISON=YesPlease, Reviewed-by: Jonathan Nieder jrnie...@gmail.com -- 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: git archve --format=tar output changed from 1.8.1 to 1.8.2.1
Am 31.01.2013 18:28, schrieb Greg KH: I tracked this down to commit 22f0dcd9634a818a0c83f23ea1a48f2d620c0546 (archive-tar: split long paths more carefully). The diff of a hex dump of the tar archives shows the following difference: --- old_git_archive 2013-01-31 17:31:24.466343388 +0100 +++ new_git_archive 2013-01-31 17:32:21.509674417 +0100 @@ -19239998,8 +19239998,8 @@ 125943d0: 125943e0: 125943f0: -12594400: -12594410: +12594400:7765 7374 6272 6964 6765 2d6f 6d61 7033 westbridge-omap3 +12594410:2d70 6e61 6e64 2d68 616c 2f00 -pnand-hal/. 12594420: 12594430: 12594440: @@ -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 map3-pnand-hal.. +125945b0:6467 6500 dge. +125945c0: 125945d0: 125945e0: 125945f0: 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é -- 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
[PATCH 0/5] Fix msvc build
As I mentioned recently, while discussing a cygwin specific patch (see Version 1.8.1 does not compile on Cygwin 1.7.14 thread), the MSVC build is broken for me. The first 4 patches fix the MSVC build for me. The final patch is not really related to fixing the build, but it removed some make 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 -- 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
[PATCH 1/5] msvc: Fix compilation errors caused by poll.h emulation
Commit 0f77dea9 (mingw: move poll out of sys-folder, 24-10-2011), along with other commits in the 'ef/mingw-upload-archive' branch (see commit 7406aa20), effectively reintroduced the same problem addressed by commit 56fb3ddc (msvc: Fix compilation errors in compat/win32/sys/poll.c, 04-12-2010). 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 ram...@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..000 --- 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 -- 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
[PATCH 2/5] msvc: git-daemon: Fix linker unresolved external errors
In particular, while linking git-daemon.exe, the linker complains
that the external symbols _inet_pton and _inet_ntop are unresolved.
Commit a666b472 (daemon: opt-out on features that require posix,
04-11-2010) addressed this problem for MinGW by configuring the
use of the internal 'compat' 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 ram...@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
--
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
[PATCH 3/5] msvc: Fix build by adding missing symbol defines
In particular, remote-testsvn.c fails to compile with two undeclared identifier errors relating to the 'UINT32_MAX' and 'STDIN_FILENO' symbols. In order to fix the compilation errors, we add appropriate definitions for the UINT32_MAX and STDIN_FILENO constants to an msvc compat header file. Signed-off-by: Ramsay Jones ram...@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 0x /* 4294967295U */ + +#define STDIN_FILENO 0 #define STDOUT_FILENO 1 #define STDERR_FILENO 2 -- 1.8.1 -- 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
[PATCH 4/5] msvc: test-svn-fe: Fix linker unresolved external error
In particular, while linking test-svn-fe.exe, the linker complains
that the external symbol _strtoull is unresolved. A call to this
function was added in commit ddcc8c5b (vcs-svn: skeleton of an svn
delta parser, 25-12-2010).
The NO_STRTOULL build variable attempts to provide support to old
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 ram...@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
--
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
[PATCH 5/5] msvc: avoid collisions between tags and TAGS
Commit 2f769195 (MinGW: avoid collisions between tags and TAGS, 28-09-2010) enabled MinGW to use an ETAGS file in order to avoid filename collisions on (Windows) case insensitive filesystems. In addition, this prevents 'make' from issuing several warning messages. When using the Makefile to 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 ram...@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 -- 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 v3 00/11] unify appending of sob
On Wed, Jan 30, 2013 at 9:37 AM, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Jonathan Nieder jrnie...@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 -- 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 0/5] Fix msvc build
Hi Ramsay, On Thu, 31 Jan 2013, Ramsay Jones wrote: As I mentioned recently, while discussing a cygwin specific patch (see Version 1.8.1 does not compile on Cygwin 1.7.14 thread), the MSVC build is broken for me. The first 4 patches fix the MSVC build for me. The final patch is not 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 msys...@googlegroups.com nevertheless? Thanks, Dscho -- 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 2/7] Undocument deprecated alias 'push.default=tracking'
Hi, Junio C Hamano wrote: Wow, that's a blast from the past. I tend to agree that deprecating and removing are quite different, but a simple revert of the change would not be good, either. We still would want to _discourage_ its use. Hm, I was about to try adding a line in that vein, 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 -- 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 2/7] Undocument deprecated alias 'push.default=tracking'
Jonathan Nieder wrote: Is the problem that deprecated is not precise enough? For example, would it make sense to say deprecated synonym for `upstream`. Will be dropped in git 2.1 or something like that? Also, if we plan to remove support soon, we should start warning when this setting is encountered so people know to update their configuration. Jonathan -- 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 0/5] Fix msvc build
Johannes Schindelin johannes.schinde...@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 msys...@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. -- 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: Why git-whatchanged shows a commit touching every file, but git-log doesn't?
Hi Constantine, Constantine A. Murenin wrote: DragonFly BSD uses git as its SCM, with one single repository and branch for both the kernel and the whole userland. On 2011-11-26 (1322296064), someone did a commit that somehow touched every single file in the repository, even though most of the files were not modified one bit. gitk --simplify-by-decoration might provide some insight. In the dragonfly history, it seems that imports of a packages typically proceed in two steps: 1. First, the upstream code is imported as a new initial commit with no history: cd ~/src git init gcc-4.7.2-import cd gcc-4.7.2-import tar -xf /path/to/gcc-4.7.2 mkdir contrib mv gcc-4.7.2 contrib/gcc-4.7 git add . git commit -m 'Import gcc-4.7.2 to new vendor branch' 2. Next, that code is incorporated into dragonfly. cd ~/src/dragonfly git fetch ../gcc-4.7.2-import master:refs/heads/vendor/GCC47 git merge vendor/GCC47 rm -fr ../gcc-4.7.2-import Unfortunately in the commit you mentioned, someone made a mistake. Instead of importing a single new upstream package, the author imported the entire dragonfly tree as a new vendor branch. Oops. The effects might be counterintuitive: * tools like git blame and path-limited git log get a choice: when looking at the merge that pulled in a copy of dragonfly into the existing dragonfly codebase, either parent is an equally sensible from blame's point of view as an explanation of the origin of this code. I think both prefer the first parent here, making them happen to produce the right result. * tools like git show that describe what change a commit made get a choice: when looking at a parentless commit, the diff that brings a project into existence may or may not be interesting, depending on the situation. See http://thread.gmane.org/gmane.comp.version-control.git/182571/focus=182577 for more about that. But at its heart, this is just an instance of lie when creating your history and history-mining tools will lie back to you. :) Hoping that clarifies a little, Jonathan -- 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] git-send-email: add ~/.authinfo parsing
On Thu, Jan 31, 2013 at 10:23:51AM -0500, Ted Zlatanov wrote: Jeff, is there a way for git-credential to currently support authinfo/netrc parsing? I assume that's the right way, instead of using Michal's proposal to parse internally? I'd like to add that, plus support for the 'string' and string formats, and authinfo.gpg decoding through GPG. I'd write it in Perl, if there's a choice. Yes, you could write a credential helper that understands netrc and friends; git talks to the helpers over a socket, so there is no problem with writing it in Perl. See Documentation/technical/api-credentials.txt for an overview, or the sample implementation in credential-store.c for a simple example. -Peff -- 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 2/7] Undocument deprecated alias 'push.default=tracking'
Jonathan Nieder jrnie...@gmail.com writes: Junio C Hamano wrote: Wow, that's a blast from the past. I tend to agree that deprecating and removing are quite different, but a simple revert of the change would not be good, either. We still would want to _discourage_ its use. Hm, I was about 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. While I agree we would need a way for you to easily find `tracking` mentioned near that point, listing it as if it is a proper part of the same list of possibilities is not the only way to do so. The enumeration is used by two different audiences. For those who want to _learn_ what possibilities are available to them (i.e. they are not going from `tracking` to what it means, but going in the opposite direction), it should be unmistakingly clear that `tracking` is not a part of the choices they should make. I do not think the following list created by a simple revert makes it clear. * `nothing` - do not push anything. * `matching` - push all branches having the same name in both ends. * `upstream` - push the current branch to ... * `simple` - like `upstream`, but refuses to ... * `tracking` - deprecated synonym for `upstream`. * `current` - push the current branch to a branch of the same name. When scanning, most people will scan lines to see there are 6 choices without reading anything after '-' first, and then start reading the item that sounds plausible for them without necessarily reading the others. That will imprint the word `tracking` in the context of choosing how to push, especially when that is not what they end up using. That is why I tend to prefer how check-ref-format documentation describes --print: --normalize:: Normalize 'refname' by removing any leading slash (`/`) characters and collapsing runs of adjacent slashes between name components into a single slash. Iff the normalized refname is valid then print it to standard output and exit with a status of 0. (`--print` is a deprecated way to spell `--normalize`.) When you are going from `tracking` to what it means, you have \C-s (if you are viewing in Emacs) or '/' (if you are using less) available. -- 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 2/7] Undocument deprecated alias 'push.default=tracking'
Junio C Hamano wrote: That is why I tend to prefer how check-ref-format documentation describes --print: --normalize:: Normalize 'refname' by removing any leading slash (`/`) characters and collapsing runs of adjacent slashes between name components into a single slash. Iff the normalized refname is valid then print it to standard output and exit with a status of 0. (`--print` is a deprecated way to spell `--normalize`.) That works because, as you mention, the usual way to look up an option in manpages is to search for --print, including the two minus signs. Unfortunately an analagous approach in gitconfig(5) would be seriously broken, because searching for tracking (no minus signs) is going to hit many false positives. I do not think such a change would be an improvement. Meanwhile I believe the prominent words deprecated synonym already make it completely obvious that when I write a new config file, I should use the modern option, unless I am trying to write a config file that also works with older versions of git. In the latter case (which unfortunately is not too uncommon), hiding the option is not going to make my life easier. What would allow me to make an informed choice is mentioning what version of git *introduced* the new name of the option: - `tracking` - deprecated old name for `upstream`, used by git versions before 1.7.4.2. Don't use this. Also I do not think anyone claimed we are removing tracking from the documentation in order to stop people from using it. The rationale when the patch was proposed is that it makes the documentation easier to read. I agree with that rationale, with the caveat Avar mentioned. There is a simple fix: just simplify the behavior being explained as well, by biting the bullet and dropping the tracking synonym after a suitable period in which it produces a warning. In the meantime, the documentation is valuable, and pretending that tracking does not exist for everyone who does not confusedly reread the docs a few times is just a way to lie to ourselves and make users' lives more difficult. Is that really the intent? Jonathan -- 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 2/7] Undocument deprecated alias 'push.default=tracking'
Jonathan Nieder jrnie...@gmail.com writes: Jonathan Nieder wrote: Is the problem that deprecated is not precise enough? For example, would it make sense to say deprecated synonym for `upstream`. Will be dropped in git 2.1 or something like that? Also, if we plan to remove support soon, we should start warning when this setting is encountered so people know to update their configuration. I do not think this even needs to be removed. We deprecate something for one of two reasons. One is when it was a bad idea to support it, and we would want to remove the support eventually. This needs a migration plan. The other is when there are better ways available but we do not want to break the old way. We still do not want to encourage the old way to new users. The change from 'upstream' from 'tracking' is the latter. The wording will confuse new users when they want to learn what 'tracking' as a concept is, and it is better spelt 'upstream'. But the breakage is not serious enough to warrant forcing an old timer who can explain these two concepts to newbies when needed to update his configuration files he is not planning to show to newbies. -- 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 2/7] Undocument deprecated alias 'push.default=tracking'
Jonathan Nieder jrnie...@gmail.com writes: Junio C Hamano wrote: That is why I tend to prefer how check-ref-format documentation describes --print: --normalize:: Normalize 'refname' by removing any leading slash (`/`) characters and collapsing runs of adjacent slashes between name components into a single slash. Iff the normalized refname is valid then print it to standard output and exit with a status of 0. (`--print` is a deprecated way to spell `--normalize`.) That works because, as you mention, the usual way to look up an option in manpages is to search for --print, including the two minus signs. Unfortunately an analagous approach in gitconfig(5) would be seriously broken, because searching for tracking (no minus signs) is going to hit many false positives. I do not think such a change would be an improvement. I thought your example was that you saw pull.default = tracking and wondering what it is. Why do you need global search for tracking, not just near pull.default is described, in the first place? -- 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 2/7] Undocument deprecated alias 'push.default=tracking'
Junio C Hamano wrote: For those who want to _learn_ what possibilities are available to them (i.e. they are not going from `tracking` to what it means, but going in the opposite direction), it should be unmistakingly clear that `tracking` is not a part of the choices they should make. Until pre-1.7.4 versions of git fall out of use, I don't agree that the above is true. :( I do not think the following list created by a simple revert makes it clear. * `nothing` - do not push anything. * `matching` - push all branches having the same name in both ends. * `upstream` - push the current branch to ... * `simple` - like `upstream`, but refuses to ... * `tracking` - deprecated synonym for `upstream`. * `current` - push the current branch to a branch of the same name. How about the following? * `nothing` - ... * `matching` - ... * `upstream` - ... * `simple` - ... * `current` - ... For compatibility with ancient config files, the following synonym is also supported. Don't use it. * `tracking` - old name for `upstream` -- 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 2/7] Undocument deprecated alias 'push.default=tracking'
Jonathan Nieder jrnie...@gmail.com writes: How about the following? * `nothing` - ... * `matching` - ... * `upstream` - ... * `simple` - ... * `current` - ... For compatibility with ancient config files, the following synonym is also supported. Don't use it. * `tracking` - old name for `upstream` Sounds good to me. I'm the author of the removal patch, but the patch was just part of a larger serie explaining push.default, the idea of cleaning up the obsolete alias came in the discussion and I did it, but I'm fine with reintroducing it in the doc (as long as it does not disturb new users too much). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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 2/7] Undocument deprecated alias 'push.default=tracking'
Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: That works because, as you mention, the usual way to look up an option in manpages is to search for --print, including the two minus signs. Unfortunately an analagous approach in gitconfig(5) would be seriously broken, because searching for tracking (no minus signs) is going to hit many false positives. I do not think such a change would be an improvement. I thought your example was that you saw pull.default = tracking and wondering what it is. Why do you need global search for tracking, not just near pull.default is described, in the first place? Because the UI for local searches in web browsers and man pagers is seriously lacking. Or, because people have bad habits and do not take apppropriate advantage of search in small subsections of a document. All I know is that I have seen myself and others doing searches analagous to --print and not seen searches analagous to tracking. Am I really the only one that doesn't see the --print change as hiding an option and sees burying tracking in the text as qualitatively different? Jonathan -- 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
[PATCH] gitremote-helpers.txt: rename from git-remote-helpers.txt
When looking up a topic via git help topic, git-help prepends git-
to topics that are the names of commands (either builtin or found on the
path) and git (no hyphen) to any other topic name.
git-remote-helpers is not the name of a command, so git help
remote-helpers looks for gitremote-helpers and does not find it.
Fix this by renaming git-remote-helpers.txt to
gitremote-helpers.txt.
Signed-off-by: John Keeping j...@keeping.me.uk
---
On Wed, Jan 30, 2013 at 12:28:49PM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
Does this mean that git-remote-helpers.txt should lose the first
hyphen or is help.c not being clever enough in some way?
I think it is the former. git help tutorial works exactly the
same way.
This is the patch to rename it to gitremote-helpers.txt.
Would we want to do something to avoid breaking links to the existing
document as well?
Documentation/git-remote-testgit.txt| 2 +-
Documentation/{git-remote-helpers.txt = gitremote-helpers.txt} | 6 +++---
Documentation/urls.txt | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
rename Documentation/{git-remote-helpers.txt = gitremote-helpers.txt} (99%)
diff --git a/Documentation/git-remote-testgit.txt
b/Documentation/git-remote-testgit.txt
index 612a625..f791d73 100644
--- a/Documentation/git-remote-testgit.txt
+++ b/Documentation/git-remote-testgit.txt
@@ -23,7 +23,7 @@ The best way to learn more is to read the comments and source
code in
SEE ALSO
-linkgit:git-remote-helpers[1]
+linkgit:gitremote-helpers[1]
GIT
---
diff --git a/Documentation/git-remote-helpers.txt
b/Documentation/gitremote-helpers.txt
similarity index 99%
rename from Documentation/git-remote-helpers.txt
rename to Documentation/gitremote-helpers.txt
index e36fdcb..0c91aba 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/gitremote-helpers.txt
@@ -1,9 +1,9 @@
-git-remote-helpers(1)
-=
+gitremote-helpers(1)
+
NAME
-git-remote-helpers - Helper programs to interact with remote repositories
+gitremote-helpers - Helper programs to interact with remote repositories
SYNOPSIS
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 539c0a0..3ca122f 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -55,7 +55,7 @@ may be used:
where address may be a path, a server and path, or an arbitrary
URL-like string recognized by the specific remote helper being
-invoked. See linkgit:git-remote-helpers[1] for details.
+invoked. See linkgit:gitremote-helpers[1] for details.
If there are a large number of similarly-named remote repositories and
you want to use a different format for them (such that the URLs you
--
1.8.1.1
--
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] gitremote-helpers.txt: rename from git-remote-helpers.txt
John Keeping j...@keeping.me.uk writes: Would we want to do something to avoid breaking links to the existing document as well? That would be nice to add a new git-remote-helpers.txt saying document has moved, see linkgit:gitremote-helpers.txt[1], so that HTML links to http://git-scm.com/docs/git-remote-helpers and friends do not get broken, yes. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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 2/7] Undocument deprecated alias 'push.default=tracking'
Jonathan Nieder jrnie...@gmail.com writes: Junio C Hamano wrote: For those who want to _learn_ what possibilities are available to them (i.e. they are not going from `tracking` to what it means, but going in the opposite direction), it should be unmistakingly clear that `tracking` is not a part of the choices they should make. Until pre-1.7.4 versions of git fall out of use, I don't agree that the above is true. :( The documentation ships with the version that the above is true. We are not making an update to documentation that comes with ancient versions. I do not think the following list created by a simple revert makes it clear. * `nothing` - do not push anything. * `matching` - push all branches having the same name in both ends. * `upstream` - push the current branch to ... * `simple` - like `upstream`, but refuses to ... * `tracking` - deprecated synonym for `upstream`. * `current` - push the current branch to a branch of the same name. How about the following? * `nothing` - ... * `matching` - ... * `upstream` - ... * `simple` - ... * `current` - ... For compatibility with ancient config files, the following synonym is also supported. Don't use it. * `tracking` - old name for `upstream` Didn't I say I am fine to mention it as a side note in the original message you started responding to? -- 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] gitremote-helpers.txt: rename from git-remote-helpers.txt
Matthieu Moy matthieu@grenoble-inp.fr writes: John Keeping j...@keeping.me.uk writes: Would we want to do something to avoid breaking links to the existing document as well? That would be nice to add a new git-remote-helpers.txt saying document has moved, see linkgit:gitremote-helpers.txt[1], so that HTML links to http://git-scm.com/docs/git-remote-helpers and friends do not get broken, yes. Yeah, John's patch fixes internal links, but this will make links from other sites stale. Adding to our installation rule to put a handcrafted HTML page that says The document moved here; please let the owners of the referring site to know so that they can update the link you clicked to get here would be appropriate, I think. -- 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 2/7] Undocument deprecated alias 'push.default=tracking'
From: Jonathan Nieder jrnie...@gmail.com Sent: Thursday, January 31, 2013 8:04 PM Junio C Hamano wrote: For those who want to _learn_ what possibilities are available to them (i.e. they are not going from `tracking` to what it means, but going in the opposite direction), it should be unmistakingly clear that `tracking` is not a part of the choices they should make. Until pre-1.7.4 versions of git fall out of use, I don't agree that the above is true. :( I do not think the following list created by a simple revert makes it clear. * `nothing` - do not push anything. * `matching` - push all branches having the same name in both ends. * `upstream` - push the current branch to ... * `simple` - like `upstream`, but refuses to ... * `tracking` - deprecated synonym for `upstream`. From a simple user perspective, I'd simply place it, in brackets and at the end of the list. e.g. [* `tracking` - deprecated synonym for `upstream`.] The leading bracket makes it obvious that it's different, and that the description needs to be read, rather than folk simply re-using a half remembered option, gleaned from an old blog. However formatting the leading bracket may not be as easy as the plain text version. * `current` - push the current branch to a branch of the same name. How about the following? * `nothing` - ... * `matching` - ... * `upstream` - ... * `simple` - ... * `current` - ... For compatibility with ancient config files, the following synonym is also supported. Don't use it. * `tracking` - old name for `upstream` ? s/old/deprecated/ or s/old/outdated/ for those who don't understand the jargon. -- 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 2/7] Undocument deprecated alias 'push.default=tracking'
Jonathan Nieder jrnie...@gmail.com writes: Am I really the only one that doesn't see the --print change as hiding an option and sees burying tracking in the text as qualitatively different? Sorry, but I do not understand the question. We are hiding/burying the --print option to make it clear that it is not a member with the same footing as others belonging to the group of options to the command. It is accepted, but there is no reason for the user to choose it over --normalize. We want to make sure that tracking does not appear as if it is a member of the pull.default set with equal rights as others. It is accepted, but there is no reason for the user to choose it over upstream. -- 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 2/7] Undocument deprecated alias 'push.default=tracking'
Junio C Hamano gits...@pobox.com writes: Jonathan Nieder jrnie...@gmail.com writes: Am I really the only one that doesn't see the --print change as hiding an option and sees burying tracking in the text as qualitatively different? Sorry, but I do not understand the question. We are hiding/burying the --print option to make it clear that it is not a member with the same footing as others belonging to the group of options to the command. It is accepted, but there is no reason for the user to choose it over --normalize. We want to make sure that tracking does not appear as if it is a member of the pull.default set with equal rights as others. It is accepted, but there is no reason for the user to choose it over upstream. Now I re-read the proposed update, I think it is an improvement over a straight revert in that it makes it clear that 'tracking' does not belong, but I still think it is better to make it a sidenote to the 'upstream'. It makes the connection between the two stronger. -- 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 2/7] Undocument deprecated alias 'push.default=tracking'
How about doing it this way? I do not think anything that is deprecated even deserves a separate section and do not use it! heading. -- 8 -- When looking at a configuration file edited long time ago, a user may find 'pull.default = tracking' and wonder what it means. Instead of not mentioning it, add it to the description in a way that makes it clear that users have no reason to add new uses of it preferring over 'upstream'. Documentation/config.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index d7ec507..8441050 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1795,7 +1795,8 @@ push.default:: + This is currently the default, but Git 2.0 will change the default to `simple`. -* `upstream` - push the current branch to its upstream branch. +* `upstream` - push the current branch to its upstream branch + (`tracking` is a deprecated synonym for this). With this, `git push` will update the same remote ref as the one which is merged by `git pull`, making `push` and `pull` symmetrical. See branch.name.merge for how to configure the upstream branch. -- 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 2/7] Undocument deprecated alias 'push.default=tracking'
Junio C Hamano wrote: How about doing it this way? [...] --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1795,7 +1795,8 @@ push.default:: + This is currently the default, but Git 2.0 will change the default to `simple`. -* `upstream` - push the current branch to its upstream branch. +* `upstream` - push the current branch to its upstream branch + (`tracking` is a deprecated synonym for this). I have already explained that I believe this is a bad idea and why and proposed an alternative. I take it that either we are miscommunicating or we fundamentally disagree about the role of documentation. :( -- 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 2/7] Undocument deprecated alias 'push.default=tracking'
Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: Junio C Hamano wrote: For those who want to _learn_ what possibilities are available to them (i.e. they are not going from `tracking` to what it means, but going in the opposite direction), it should be unmistakingly clear that `tracking` is not a part of the choices they should make. Until pre-1.7.4 versions of git fall out of use, I don't agree that the above is true. :( The documentation ships with the version that the above is true. We are not making an update to documentation that comes with ancient versions. Part of the context that I should have mentioned but didn't is that it is common to put $HOME on a shared filesystem. [...] How about the following? * `nothing` - ... * `matching` - ... * `upstream` - ... * `simple` - ... * `current` - ... For compatibility with ancient config files, the following synonym is also supported. Don't use it. * `tracking` - old name for `upstream` Didn't I say I am fine to mention it as a side note in the original message you started responding to? Yes, I understood what you were proposing and I directly disagreed with it and explained why. The above is something like a compromise --- more precisely, it is an attempt to do something better than a straight revert and to understand whether it would address your objection. Clearly it doesn't. I don't understand why. Perhaps the Don't use it is over the top and that is your complaint? It's true that if I were writing it without your objection in mind, I wouldn't have included that sentence. It was written on the assumption that you want to discourage people from using the tracking synonym --- I am not personally convinced that that is worth discouraging at all, but it's fine with me if the consensus is to do so. Jonathan -- 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
[PATCH] Rename {git- = git}remote-helpers.txt
When looking up a topic via git help topic, git-help prepends git-
to topics that are the names of commands (either builtin or found on the
path) and git (no hyphen) to any other topic name.
git-remote-helpers is not the name of a command, so git help
remote-helpers looks for gitremote-helpers and does not find it.
Fix this by renaming git-remote-helpers.txt to
gitremote-helpers.txt.
Signed-off-by: John Keeping j...@keeping.me.uk
---
Changes since v1:
- add gitremote-helpers.txt to the Makefile since it is no longer caught
by git-*.txt.
- add a simple git-remote-helpers.html to help people following links to
the old name.
Documentation/.gitignore | 1 +
Documentation/Makefile | 4 +-
Documentation/git-remote-helpers.html | 55 ++
Documentation/git-remote-testgit.txt | 2 +-
...it-remote-helpers.txt = gitremote-helpers.txt} | 6 +--
Documentation/urls.txt | 2 +-
6 files changed, 63 insertions(+), 7 deletions(-)
create mode 100644 Documentation/git-remote-helpers.html
rename Documentation/{git-remote-helpers.txt = gitremote-helpers.txt} (99%)
diff --git a/Documentation/.gitignore b/Documentation/.gitignore
index 2c8b2d6..5f479b8 100644
--- a/Documentation/.gitignore
+++ b/Documentation/.gitignore
@@ -1,5 +1,6 @@
*.xml
*.html
+!git-remote-helpers.html
*.[1-8]
*.made
*.texi
diff --git a/Documentation/Makefile b/Documentation/Makefile
index fe6709c..4ccb828 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,7 +1,7 @@
MAN1_TXT= \
$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
$(wildcard git-*.txt)) \
- gitk.txt gitweb.txt git.txt
+ gitk.txt gitweb.txt git.txt gitremote-helpers.txt
MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \
gitrepository-layout.txt gitweb.conf.txt
MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \
@@ -13,7 +13,7 @@ MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT))
-DOC_HTML=$(MAN_HTML)
+DOC_HTML=$(MAN_HTML) git-remote-helpers.html
ARTICLES = howto-index
ARTICLES += everyday
diff --git a/Documentation/git-remote-helpers.html
b/Documentation/git-remote-helpers.html
new file mode 100644
index 000..0c5ec27
--- /dev/null
+++ b/Documentation/git-remote-helpers.html
@@ -0,0 +1,55 @@
+!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN
+http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd;
+html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en
+head
+meta http-equiv=Content-Type content=application/xhtml+xml; charset=UTF-8
/
+titlegit-remote-helpers(1) - Document Moved/title
+style type=text/css
+/* Cut-down styles from asciidoc.css. */
+
+/* Default font. */
+body {
+ font-family: Georgia,serif;
+}
+
+/* Title font. */
+h1 {
+ font-family: Arial,Helvetica,sans-serif;
+}
+
+body {
+ margin: 1em 5% 1em 5%;
+}
+
+a {
+ color: blue;
+ text-decoration: underline;
+}
+a:visited {
+ color: fuchsia;
+}
+
+h1, h2, h3, h4, h5, h6 {
+ color: #527bbd;
+ margin-top: 1.2em;
+ margin-bottom: 0.5em;
+ line-height: 1.3;
+}
+
+/style
+/head
+body class=manpage
+div id=header
+h1
+Document Moved
+/h1
+/div
+
+pThis document is now called a
+href=gitremote-helpers.htmlgitremote-helpers/a./p
+
+pPlease let the owners of the referring site know so that they can update the
+link you clicked to get here./p
+
+/body
+/html
diff --git a/Documentation/git-remote-testgit.txt
b/Documentation/git-remote-testgit.txt
index 612a625..f791d73 100644
--- a/Documentation/git-remote-testgit.txt
+++ b/Documentation/git-remote-testgit.txt
@@ -23,7 +23,7 @@ The best way to learn more is to read the comments and source
code in
SEE ALSO
-linkgit:git-remote-helpers[1]
+linkgit:gitremote-helpers[1]
GIT
---
diff --git a/Documentation/git-remote-helpers.txt
b/Documentation/gitremote-helpers.txt
similarity index 99%
rename from Documentation/git-remote-helpers.txt
rename to Documentation/gitremote-helpers.txt
index e36fdcb..0c91aba 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/gitremote-helpers.txt
@@ -1,9 +1,9 @@
-git-remote-helpers(1)
-=
+gitremote-helpers(1)
+
NAME
-git-remote-helpers - Helper programs to interact with remote repositories
+gitremote-helpers - Helper programs to interact with remote repositories
SYNOPSIS
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 539c0a0..3ca122f 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -55,7 +55,7 @@ may be used:
where address may be a path, a server and path, or an arbitrary
URL-like string recognized by the specific remote helper being
-invoked. See linkgit:git-remote-helpers[1] for details.
+invoked. See linkgit:gitremote-helpers[1] for details.
If there are a large number of
[PATCH] Verify Content-Type from smart HTTP servers
Before parsing a suspected smart-HTTP response verify the returned
Content-Type matches the standard. This protects a client from
attempting to process a payload that smells like a smart-HTTP
server response.
JGit has been doing this check on all responses since the dawn of
time. I mistakenly failed to include it in git-core when smart HTTP
was introduced. At the time I didn't know how to get the Content-Type
from libcurl. I punted, meant to circle back and fix this, and just
plain forgot about it.
Signed-off-by: Shawn Pearce spea...@spearce.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* The original was picked up by majordomo taboo rules; resending
after minor style fix.
Was there a report of an attempted attack by malicious server or
something that triggered this, or is this just a common sense
thing to do in general?
http-push.c | 4 ++--
http.c | 31 ++-
http.h | 2 +-
remote-curl.c| 15 +++
t/lib-httpd.sh | 1 +
t/lib-httpd/apache.conf | 4
t/lib-httpd/broken-smart-http.sh | 11 +++
t/t5551-http-fetch.sh| 6 ++
8 files changed, 58 insertions(+), 16 deletions(-)
create mode 100755 t/lib-httpd/broken-smart-http.sh
diff --git a/http-push.c b/http-push.c
index 8701c12..ba45b7b 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1560,7 +1560,7 @@ static int remote_exists(const char *path)
sprintf(url, %s%s, repo-url, path);
- switch (http_get_strbuf(url, NULL, 0)) {
+ switch (http_get_strbuf(url, NULL, NULL, 0)) {
case HTTP_OK:
ret = 1;
break;
@@ -1584,7 +1584,7 @@ static void fetch_symref(const char *path, char **symref,
unsigned char *sha1)
url = xmalloc(strlen(repo-url) + strlen(path) + 1);
sprintf(url, %s%s, repo-url, path);
- if (http_get_strbuf(url, buffer, 0) != HTTP_OK)
+ if (http_get_strbuf(url, NULL, buffer, 0) != HTTP_OK)
die(Couldn't get %s for remote symref\n%s, url,
curl_errorstr);
free(url);
diff --git a/http.c b/http.c
index 44f3525..d868d8b 100644
--- a/http.c
+++ b/http.c
@@ -788,7 +788,8 @@ int handle_curl_result(struct slot_results *results)
#define HTTP_REQUEST_STRBUF0
#define HTTP_REQUEST_FILE 1
-static int http_request(const char *url, void *result, int target, int options)
+static int http_request(const char *url, struct strbuf *type,
+ void *result, int target, int options)
{
struct active_request_slot *slot;
struct slot_results results;
@@ -838,24 +839,36 @@ static int http_request(const char *url, void *result,
int target, int options)
ret = HTTP_START_FAILED;
}
+ if (type) {
+ char *t;
+ curl_easy_getinfo(slot-curl, CURLINFO_CONTENT_TYPE, t);
+ if (t)
+ strbuf_addstr(type, t);
+ }
+
curl_slist_free_all(headers);
strbuf_release(buf);
return ret;
}
-static int http_request_reauth(const char *url, void *result, int target,
+static int http_request_reauth(const char *url,
+ struct strbuf *type,
+ void *result, int target,
int options)
{
- int ret = http_request(url, result, target, options);
+ int ret = http_request(url, type, result, target, options);
if (ret != HTTP_REAUTH)
return ret;
- return http_request(url, result, target, options);
+ return http_request(url, type, result, target, options);
}
-int http_get_strbuf(const char *url, struct strbuf *result, int options)
+int http_get_strbuf(const char *url,
+ struct strbuf *type,
+ struct strbuf *result, int options)
{
- return http_request_reauth(url, result, HTTP_REQUEST_STRBUF, options);
+ return http_request_reauth(url, type, result,
+ HTTP_REQUEST_STRBUF, options);
}
/*
@@ -878,7 +891,7 @@ static int http_get_file(const char *url, const char
*filename, int options)
goto cleanup;
}
- ret = http_request_reauth(url, result, HTTP_REQUEST_FILE, options);
+ ret = http_request_reauth(url, NULL, result, HTTP_REQUEST_FILE,
options);
fclose(result);
if ((ret == HTTP_OK) move_temp_to_file(tmpfile.buf, filename))
@@ -904,7 +917,7 @@ int http_fetch_ref(const char *base, struct ref *ref)
int ret = -1;
url = quote_ref_url(base, ref-name);
- if (http_get_strbuf(url, buffer, HTTP_NO_CACHE) == HTTP_OK) {
+ if (http_get_strbuf(url, NULL, buffer, HTTP_NO_CACHE) == HTTP_OK) {
strbuf_rtrim(buffer);
if (buffer.len == 40)
ret =
Re: [PATCH] Rename {git- = git}remote-helpers.txt
John Keeping j...@keeping.me.uk writes:
When looking up a topic via git help topic, git-help prepends git-
to topics that are the names of commands (either builtin or found on the
path) and git (no hyphen) to any other topic name.
git-remote-helpers is not the name of a command, so git help
remote-helpers looks for gitremote-helpers and does not find it.
Fix this by renaming git-remote-helpers.txt to
gitremote-helpers.txt.
Signed-off-by: John Keeping j...@keeping.me.uk
---
Changes since v1:
- add gitremote-helpers.txt to the Makefile since it is no longer caught
by git-*.txt.
- add a simple git-remote-helpers.html to help people following links to
the old name.
Doesn't make clean remove the placeholder file?
Documentation/.gitignore | 1 +
Documentation/Makefile | 4 +-
Documentation/git-remote-helpers.html | 55
++
Documentation/git-remote-testgit.txt | 2 +-
...it-remote-helpers.txt = gitremote-helpers.txt} | 6 +--
Documentation/urls.txt | 2 +-
6 files changed, 63 insertions(+), 7 deletions(-)
create mode 100644 Documentation/git-remote-helpers.html
rename Documentation/{git-remote-helpers.txt = gitremote-helpers.txt} (99%)
diff --git a/Documentation/.gitignore b/Documentation/.gitignore
index 2c8b2d6..5f479b8 100644
--- a/Documentation/.gitignore
+++ b/Documentation/.gitignore
@@ -1,5 +1,6 @@
*.xml
*.html
+!git-remote-helpers.html
*.[1-8]
*.made
*.texi
diff --git a/Documentation/Makefile b/Documentation/Makefile
index fe6709c..4ccb828 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,7 +1,7 @@
MAN1_TXT= \
$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
$(wildcard git-*.txt)) \
- gitk.txt gitweb.txt git.txt
+ gitk.txt gitweb.txt git.txt gitremote-helpers.txt
MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \
gitrepository-layout.txt gitweb.conf.txt
MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \
@@ -13,7 +13,7 @@ MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT))
-DOC_HTML=$(MAN_HTML)
+DOC_HTML=$(MAN_HTML) git-remote-helpers.html
ARTICLES = howto-index
ARTICLES += everyday
diff --git a/Documentation/git-remote-helpers.html
b/Documentation/git-remote-helpers.html
new file mode 100644
index 000..0c5ec27
--- /dev/null
+++ b/Documentation/git-remote-helpers.html
@@ -0,0 +1,55 @@
+!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN
+http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd;
+html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en
+head
+meta http-equiv=Content-Type content=application/xhtml+xml;
charset=UTF-8 /
+titlegit-remote-helpers(1) - Document Moved/title
+style type=text/css
+/* Cut-down styles from asciidoc.css. */
+
+/* Default font. */
+body {
+ font-family: Georgia,serif;
+}
+
+/* Title font. */
+h1 {
+ font-family: Arial,Helvetica,sans-serif;
+}
+
+body {
+ margin: 1em 5% 1em 5%;
+}
+
+a {
+ color: blue;
+ text-decoration: underline;
+}
+a:visited {
+ color: fuchsia;
+}
+
+h1, h2, h3, h4, h5, h6 {
+ color: #527bbd;
+ margin-top: 1.2em;
+ margin-bottom: 0.5em;
+ line-height: 1.3;
+}
+
+/style
+/head
+body class=manpage
+div id=header
+h1
+Document Moved
+/h1
+/div
+
+pThis document is now called a
+href=gitremote-helpers.htmlgitremote-helpers/a./p
+
+pPlease let the owners of the referring site know so that they can update
the
+link you clicked to get here./p
+
+/body
+/html
diff --git a/Documentation/git-remote-testgit.txt
b/Documentation/git-remote-testgit.txt
index 612a625..f791d73 100644
--- a/Documentation/git-remote-testgit.txt
+++ b/Documentation/git-remote-testgit.txt
@@ -23,7 +23,7 @@ The best way to learn more is to read the comments and
source code in
SEE ALSO
-linkgit:git-remote-helpers[1]
+linkgit:gitremote-helpers[1]
GIT
---
diff --git a/Documentation/git-remote-helpers.txt
b/Documentation/gitremote-helpers.txt
similarity index 99%
rename from Documentation/git-remote-helpers.txt
rename to Documentation/gitremote-helpers.txt
index e36fdcb..0c91aba 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/gitremote-helpers.txt
@@ -1,9 +1,9 @@
-git-remote-helpers(1)
-=
+gitremote-helpers(1)
+
NAME
-git-remote-helpers - Helper programs to interact with remote repositories
+gitremote-helpers - Helper programs to interact with remote repositories
SYNOPSIS
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 539c0a0..3ca122f 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -55,7 +55,7 @@ may be used:
where address may be a path, a server and
Re: [PATCH] gitremote-helpers.txt: rename from git-remote-helpers.txt
On Thu, 31 Jan 2013 20:08:14 +, John Keeping j...@keeping.me.uk wrote:
This is the patch to rename it to gitremote-helpers.txt.
Documentation/{git-remote-helpers.txt = gitremote-helpers.txt} | 6 +++---
It feels somewhat weird to have 'git-remote' but 'gitremote-helpers'.
--
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] Rename {git- = git}remote-helpers.txt
On Thu, Jan 31, 2013 at 02:13:10PM -0800, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: When looking up a topic via git help topic, git-help prepends git- to topics that are the names of commands (either builtin or found on the path) and git (no hyphen) to any other topic name. git-remote-helpers is not the name of a command, so git help remote-helpers looks for gitremote-helpers and does not find it. Fix this by renaming git-remote-helpers.txt to gitremote-helpers.txt. Signed-off-by: John Keeping j...@keeping.me.uk --- Changes since v1: - add gitremote-helpers.txt to the Makefile since it is no longer caught by git-*.txt. - add a simple git-remote-helpers.html to help people following links to the old name. Doesn't make clean remove the placeholder file? Yes. Should I change it to git-remote-helpers.html.in and then copy it into place? That seems like the simplest answer and means that *.html will continue to refer only to generated files. John -- 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] Rename {git- = git}remote-helpers.txt
On Thu, Jan 31, 2013 at 09:59:50PM +, John Keeping wrote: When looking up a topic via git help topic, git-help prepends git- to topics that are the names of commands (either builtin or found on the path) and git (no hyphen) to any other topic name. git-remote-helpers is not the name of a command, so git help remote-helpers looks for gitremote-helpers and does not find it. Fix this by renaming git-remote-helpers.txt to gitremote-helpers.txt. Maybe it is just me, but the fact that accessing the manpage is now: man gitremote-helpers feels weird to me. I know it technically follows our syntactic rules, but having the lack of dash be significant between git and remote, but then having a dash later makes it hard on the eyes. Would it make more sense to just call it gitremotehelpers, and then access it as: git help remotehelpers or man gitremotehelpers ? That has it its own ugliness (two words run together), but at least my version of man will accept arbitrary capitalization, allowing: git help remoteHelpers and man gitremoteHelpers I dunno. -Peff -- 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 2/3] run-command: Be more informative about what failed
On Thu, Jan 31, 2013 at 08:24:21AM -0800, Junio C Hamano wrote: Stephen Boyd sb...@codeaurora.org writes: While debugging an error with verify_signed_buffer() the error messages from run-command weren't very useful: error: cannot create pipe for gpg: Too many open files error: could not run gpg. because they didn't indicate *which* pipe couldn't be created. For the message emitted here with your update (or without for that matter) to be useful, it has to hold that there is a single leaker, that leaker fails in this codepath, and that there is nobody else involved. Otherwise, you may be able to tell that one caller could not create its stdin, but the reason it couldn't may be because somebody else consumed all the available file descriptors. I am not opposed to this change per-se, but I am not sure that saying stdin etc. makes the message more useful for the purpose of debugging. Yeah, I had the same feeling. All that failed is pipe(), which does not have anything to do with what we are going to use the pipe for. So it gives some context, perhaps, but does not necessarily tell us anything useful. But it is not much code, and sometimes it is surprising what information can be helpful when debugging, so like you, I am not opposed, just doubtful. -Peff -- 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] Verify Content-Type from smart HTTP servers
On Thu, Jan 31, 2013 at 1:59 PM, Junio C Hamano gits...@pobox.com wrote: Shawn Pearce spea...@spearce.org writes: Before parsing a suspected smart-HTTP response verify the returned Content-Type matches the standard. This protects a client from attempting to process a payload that smells like a smart-HTTP server response. JGit has been doing this check on all responses since the dawn of time. I mistakenly failed to include it in git-core when smart HTTP was introduced. At the time I didn't know how to get the Content-Type from libcurl. I punted, meant to circle back and fix this, and just plain forgot about it. Signed-off-by: Shawn Pearce spea...@spearce.org --- Sounds sensible. Was there a report of attack attempts by malicious servers or something, or is it just a general common sense thing? Common-sense cleanup. I had a report a while ago about JGit not working with the Git servers at Codeplex. This failure was caused by their HTTP servers returning an invalid Content-Type, making JGit refuse to continue parsing. This has since been fixed, I verified this morning that Codeplex is returning the correct Content-Type. -- 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: [PATCHv2 1/3] gpg: Close stderr once finished with it in verify_signed_buffer()
On Thu, Jan 31, 2013 at 10:18:40AM -0800, Stephen Boyd wrote: Failing to close the stderr pipe in verify_signed_buffer() causes git to run out of file descriptors if there are many calls to verify_signed_buffer(). An easy way to trigger this is to run git log --show-signature --merges | 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 p...@peff.net Signed-off-by: Stephen Boyd sb...@codeaurora.org Thanks, looks good to me (obviously :) ). The rest of the series looks fine, too, with the caveat I mentioned on 2/3. Thanks for fixing this. -Peff -- 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] Rename {git- = git}remote-helpers.txt
John Keeping j...@keeping.me.uk writes:
Yes. Should I change it to git-remote-helpers.html.in and then copy
it into place? That seems like the simplest answer and means that
*.html will continue to refer only to generated files.
I'd like to see if we can have a way to keep its look as the default
css gets updated without maintainance burden.
How about using AsciiDoc instead of cp, perhaps like this on top
of your patch?
Documentation/.gitignore | 1 -
Documentation/Makefile| 9 +-
Documentation/git-remote-helpers.txto | 26 +
Documentation/git-remote-helpers.html | 55 ---
4 files changed, 34 insertions(+), 57 deletions(-)
diff --git a/Documentation/.gitignore b/Documentation/.gitignore
index 4685378..d62aebd 100644
--- a/Documentation/.gitignore
+++ b/Documentation/.gitignore
@@ -1,6 +1,5 @@
*.xml
*.html
-!git-remote-helpers.html
*.[1-8]
*.made
*.texi
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 13e0098..fa2f9f9 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -13,7 +13,8 @@ MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
MAN_HTML=$(patsubst %.txt,%.html,$(MAN_TXT))
-DOC_HTML=$(MAN_HTML) git-remote-helpers.html
+OBSOLETE_HTML = git-remote-helpers.html
+DOC_HTML=$(MAN_HTML) $(OBSOLETE_HTML)
ARTICLES = howto-index
ARTICLES += everyday
@@ -261,6 +262,12 @@ $(MAN_HTML): %.html : %.txt asciidoc.conf
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $ \
mv $@+ $@
+$(OBSOLETE_HTML): %.html : %.txto asciidoc.conf
+ $(QUIET_ASCIIDOC)$(RM) $@+ $@ \
+ $(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
+ $(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $ \
+ mv $@+ $@
+
manpage-base-url.xsl: manpage-base-url.xsl.in
sed s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)| $ $@
diff --git a/Documentation/git-remote-helpers.txto
b/Documentation/git-remote-helpers.txto
new file mode 100644
index 000..a966013
--- /dev/null
+++ b/Documentation/git-remote-helpers.txto
@@ -0,0 +1,25 @@
+git-remote-helpers(1)
+=
+
+NAME
+
+git-remote-helpers - obsoleted page
+
+SYNOPSIS
+
+See linkgit:gitremote-helpers[1].
+
+DESCRIPTION
+---
+This document has been moved to linkgit:gitremote-helpers[1].
+
+Please let the owners of the referring site know so that they can update the
+link you clicked to get here.
+
+SEE ALSO
+
+linkgit:gitremote-helpers[1]
+
+GIT
+---
+No longer a part of the linkgit:git[1] suite
diff --git a/Documentation/git-remote-helpers.html
b/Documentation/git-remote-helpers.html
deleted file mode 100644
index 0c5ec27..000
--- a/Documentation/git-remote-helpers.html
+++ /dev/null
@@ -1,55 +0,0 @@
-!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN
-http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd;
-html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en
-head
-meta http-equiv=Content-Type content=application/xhtml+xml; charset=UTF-8
/
-titlegit-remote-helpers(1) - Document Moved/title
-style type=text/css
-/* Cut-down styles from asciidoc.css. */
-
-/* Default font. */
-body {
- font-family: Georgia,serif;
-}
-
-/* Title font. */
-h1 {
- font-family: Arial,Helvetica,sans-serif;
-}
-
-body {
- margin: 1em 5% 1em 5%;
-}
-
-a {
- color: blue;
- text-decoration: underline;
-}
-a:visited {
- color: fuchsia;
-}
-
-h1, h2, h3, h4, h5, h6 {
- color: #527bbd;
- margin-top: 1.2em;
- margin-bottom: 0.5em;
- line-height: 1.3;
-}
-
-/style
-/head
-body class=manpage
-div id=header
-h1
-Document Moved
-/h1
-/div
-
-pThis document is now called a
-href=gitremote-helpers.htmlgitremote-helpers/a./p
-
-pPlease let the owners of the referring site know so that they can update the
-link you clicked to get here./p
-
-/body
-/html
--
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] gitremote-helpers.txt: rename from git-remote-helpers.txt
Tomas Carnecky tomas.carne...@gmail.com writes:
On Thu, 31 Jan 2013 20:08:14 +, John Keeping j...@keeping.me.uk wrote:
This is the patch to rename it to gitremote-helpers.txt.
Documentation/{git-remote-helpers.txt = gitremote-helpers.txt} | 6 +++---
It feels somewhat weird to have 'git-remote' but 'gitremote-helpers'.
But the remote helpers are not helpers to git remote (which is
essentially a glorified wrapper around git config -l remote.*).
--
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] Rename {git- = git}remote-helpers.txt
Jeff King p...@peff.net writes: Maybe it is just me, but the fact that accessing the manpage is now: man gitremote-helpers feels weird to me. It feels equally weird to say man gitremotehelpers (or in general man git-thing or man gitconcept), to me. I gave up and switched to git help remote-helpers some time ago. git help remotehelpers feels like a small regression. I dunno. Me neither. -- 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] Rename {git- = git}remote-helpers.txt
On Thu, Jan 31, 2013 at 02:43:20PM -0800, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: Yes. Should I change it to git-remote-helpers.html.in and then copy it into place? That seems like the simplest answer and means that *.html will continue to refer only to generated files. I'd like to see if we can have a way to keep its look as the default css gets updated without maintainance burden. How about using AsciiDoc instead of cp, perhaps like this on top of your patch? I tried AsciiDoc first but didn't like the output. I think putting See gitremote-helpers in the synopsis is the magic I was missing. This looks good to me. John -- 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] Rename {git- = git}remote-helpers.txt
Jeff King wrote: Maybe it is just me, but the fact that accessing the manpage is now: man gitremote-helpers feels weird to me. I know it technically follows our syntactic rules, but having the lack of dash be significant between git and remote, but then having a dash later makes it hard on the eyes. Yes. I have thought for years that it should be git-remote-helpers, that git help should be tweaked to look for that, and that the existing gitrepository-layout and friends should be replaced with redirects. I didn't say anything (except a random comment once on #git) because I can't promise to have time soon to work on it. Might try anyway. Thanks, Jonathan -- 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] Rename {git- = git}remote-helpers.txt
Jonathan Nieder jrnie...@gmail.com writes: Jeff King wrote: Maybe it is just me, but the fact that accessing the manpage is now: man gitremote-helpers feels weird to me. I know it technically follows our syntactic rules, but having the lack of dash be significant between git and remote, but then having a dash later makes it hard on the eyes. Yes. I have thought for years that it should be git-remote-helpers, that git help should be tweaked to look for that, and that the existing gitrepository-layout and friends should be replaced with redirects. Because of the git help look up rules, we cannot have two pages that only differ at the dash (or absense of it) immediately after 'git'; e.g. one about the concept of 'frotz' in the context of Git, i.e. man gitfrotz, and the other about the subcommand to perform 'frotz', i.e. man git-frotz. The way to refer to these two pages are both git help frotz. The simplest way forward may be to teach git help to try both paths? But some people configure git help -w to refer to remote site, so it won't be access(path, F_OK). Sigh... -- 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] Rename {git- = git}remote-helpers.txt
Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: Yes. I have thought for years that it should be git-remote-helpers, that git help should be tweaked to look for that, and that the existing gitrepository-layout and friends should be replaced with redirects. Because of the git help look up rules, we cannot have two pages that only differ at the dash (or absense of it) immediately after 'git'; e.g. one about the concept of 'frotz' in the context of Git, i.e. man gitfrotz, and the other about the subcommand to perform 'frotz', i.e. man git-frotz. The way to refer to these two pages are both git help frotz. Exactly. Hence the disambiguating dash-versus-nondash convention buys us nothing. -- 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] Rename {git- = git}remote-helpers.txt
John Keeping j...@keeping.me.uk writes: On Thu, Jan 31, 2013 at 02:43:20PM -0800, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: Yes. Should I change it to git-remote-helpers.html.in and then copy it into place? That seems like the simplest answer and means that *.html will continue to refer only to generated files. I'd like to see if we can have a way to keep its look as the default css gets updated without maintainance burden. How about using AsciiDoc instead of cp, perhaps like this on top of your patch? I tried AsciiDoc first but didn't like the output. I think putting See gitremote-helpers in the synopsis is the magic I was missing. This looks good to me. Actually I didn't mean take this patch, it works. I've queued a slightly different version and will push it out as part of 'pu' later. Thanks. -- 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 2/3] run-command: Be more informative about what failed
Jeff King p...@peff.net writes: But it is not much code, and sometimes it is surprising what information can be helpful when debugging, so like you, I am not opposed, just doubtful. Yes, exactly my feeling. Perhaps I should just amend the 'stdin' and friends away without asking Stephen to reroll. In the other two I did not see any issues. I've queued all three of them including this one but as separate topics. Thanks. -- 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 1/2] docs: clarify git-branch --list behavior
On Thu, Jan 31, 2013 at 1:45 AM, Jeff King p...@peff.net wrote: +If `--list` is given, or if there are no non-option arguments, existing +branches are listed; the current branch will be highlighted with an +asterisk. Option `-r` causes the remote-tracking branches to be listed, +and option `-a` shows both local and remote branches. If a `pattern` +is given, it is used as a shell wildcard to restrict the output to +matching branches. If multiple patterns are given, a branch is shown if +any it is matched by any of the patterns. s/if any it is/if it is/ -- ES -- 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 1/2] docs: clarify git-branch --list behavior
Eric Sunshine sunsh...@sunshineco.com writes: On Thu, Jan 31, 2013 at 1:45 AM, Jeff King p...@peff.net wrote: +If `--list` is given, or if there are no non-option arguments, existing +branches are listed; the current branch will be highlighted with an +asterisk. Option `-r` causes the remote-tracking branches to be listed, +and option `-a` shows both local and remote branches. If a `pattern` +is given, it is used as a shell wildcard to restrict the output to +matching branches. If multiple patterns are given, a branch is shown if +any it is matched by any of the patterns. s/if any it is/if it is/ Thanks; I'll squash this in. Peff, no need to resend. Documentation/git-branch.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index 01aa87f..2635dee 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -28,7 +28,7 @@ asterisk. Option `-r` causes the remote-tracking branches to be listed, and option `-a` shows both local and remote branches. If a `pattern` is given, it is used as a shell wildcard to restrict the output to matching branches. If multiple patterns are given, a branch is shown if -any it is matched by any of the patterns. Note that when providing a +it matches any of the patterns. Note that when providing a `pattern`, you must use `--list`; otherwise the command is interpreted as branch creation. -- 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: Aw: Re: [PATCH v3 3/6] Change 'git' to 'Git' whenever the whole system is referred to #2
Thomas Ackermann th.ac...@arcor.de writes: Thomas, I do not want to see many rounds of entire rerolls of this series on the list (nobody will look at the whole series multiple times with fine toothed comb). I do not think you want to do that either. Can you collect remaining fixups like David's message, turn them into patch form when you have collected enough to be reviewed in one sitting (say, a patchfile at around 200 lines), and send them over to the list to apply on top of the tree of that commit? Sure! I think we have waited long enough and as far as I recall we didn't see any reports of misconversion or forgotten conversion, so I'll squash the fixes parked on the topic branch, whose tip is at bfb8e1eb6375afb (fixup! Change 'git' to 'Git' whenever the whole system is referred to #4, 2013-01-22), and merge the result to 'next' sometime tomorrow. Thanks. -- 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] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
Jonathan Nieder jrnie...@gmail.com writes: Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: Odd. https://www.gravatar.com/; also seems to work. I've put in a technical support query to find out what the Gravatar admins prefer. Thanks; will hold onto Andrej's patch until we hear what the story is. Good news: a kind person from Automattic answered that www.gravatar.com should work fine over SSL, both now and in the future, and promised to add updating documentation to their todo list. Thanks for your help and patience. I'll merge Andrej's topic to 'next' in the next integration cycle. The fix should hit 'master' no later than the beginning of next week. Thanks. -- 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 2/7] Undocument deprecated alias 'push.default=tracking'
Jonathan Nieder jrnie...@gmail.com writes: [...] --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1795,7 +1795,8 @@ push.default:: + This is currently the default, but Git 2.0 will change the default to `simple`. -* `upstream` - push the current branch to its upstream branch. +* `upstream` - push the current branch to its upstream branch + (`tracking` is a deprecated synonym for this). I have already explained that I believe this is a bad idea and why and proposed an alternative. I take it that either we are miscommunicating or we fundamentally disagree about the role of documentation. :( Whatever. For tonight, I'll queue this version on 'pu' primarily because I do not want to think about it anymore today and because I do not want to see us forget that we have to fix this in some way, and this was the only one that I can simply git am on this topic. It is not because I want to say this is the version we are going to use, stfu! This topic does not even deserve such inter-developer tension, IMHO. doc: mention tracking for pull.default When looking at a configuration file edited long time ago, a user may find 'pull.default = tracking' and wonder what it means, but earlier we stopped mentioning this value, even though the code still support it and more importantly, we have no intention to force old timers to update their configuration files. Instead of not mentioning it, add it to the description in a way that makes it clear that users have no reason to add new uses of it preferring over 'upstream', by not listing it as a separate item on the same footing as other values but as a deprecated synonym of the 'upstream' in its description. Signed-off-by: Junio C Hamano gits...@pobox.com -- 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: Re: Segmentation fault with latest git (070c57df)
[snip]
Good point. Unfortunately, I can't get either yours or mine to fail,
neither with a recent version of gcc nor with gcc-4.1. But I can't
convince git to fail, either. The only gcc-4.1 I have is Debian's
4.1.3 release, which is not quite what the OP has.
Or perhaps something in the build process went wrong, and fetch.c didn't
get the memo about the new field in the struct. Depending on stack
layout, the next variable might be the 'int i' right before the
'string_list list' in the code, which could explain the value of 1.
Yeah, that would make sense to me with respect to the behavior we are
seeing, but that part of the Makefile should be pretty simple and
bug-free, I'd think (and from the original report, it seems like he was
able to reproduce it well enough to bisect). Still, trying a make clean
make might be worth it just to rule that out.
Puzzled...
-Peff
Hi, all,
Thomas's test code also returns cmp is 0.
But make clean make fixes my issue.
Sorry for the noise I made.
But usually when I build upstream Linux kernel, I don't do make clean after
git pull..
I didn't expect that I needed make clean for git build. Thanks you guys.
Best regards,
Jongman
Heo.N떑꿩�r툤y鉉싕b쾊Ф푤v�^�)頻{.n�+돴젇碼�썳變}찠꼿쟺�j:+v돣�쳭喩zZ+�+zf＂톒쉱�~넮녬i鎬z� 췿ⅱ�?솳鈺��)刪f
Re: Segmentation fault with latest git (070c57df)
허종만 jongman@samsung.com writes: But usually when I build upstream Linux kernel, I don't do make clean after git pull.. I didn't expect that I needed make clean for git build. We don't expect anybody need make clean, either. There is something wrong in the dependency. -- 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: sha1 information is lacking or useless when rebasing with a submodule pointer conflict
Heiko Voigt hvo...@hvoigt.net writes: Maybe Martin or Junio immediately see whats going wrong here? I would need to further dig into the git-am code to find out how to fix it. Thanks. I think the minimum fix is this, but there are some nits to pick around this area as well. diff --git b/git-am.sh a/git-am.sh index b4d95f5..202130f 100755 --- b/git-am.sh +++ a/git-am.sh @@ -664,7 +664,7 @@ do sed -e '1,/^$/d' $dotest/msg-clean echo $commit $dotest/original-commit get_author_ident_from_commit $commit $dotest/author-script - git diff-tree --root --binary $commit $dotest/patch + git diff-tree --root --binary --full-index $commit $dotest/patch else git mailinfo $keep $no_inbody_headers $scissors $utf8 $dotest/msg $dotest/patch \ $dotest/$msgnum $dotest/info || -- 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
[PATCH 0/3] rebasing changes that update submodules
git rebase used to use format-patch --full-index to generate a series of patches and let git am --rebase reconstruct a fake preimage tree by reading the object names from the index lines. With a230949 (am --rebasing: get patch body from commit, not from mailbox, 2012-06-26), we switched to use diff-tree, but forgot that without --full-index, the information generated on the index line is insufficient to recreate a preimage tree that contains a submodule. The first one is the real fix to this issue. The other two falls into the niceties category; they are to issue a better error messge when the machinery is fed an abbreviated object name on the index line for a submodule. Junio C Hamano (3): git-am: record full index line in the patch used while rebasing apply: simplify build_fake_ancestor() apply: diagnose incomplete submodule object name better builtin/apply.c | 30 -- git-am.sh | 2 +- t/t7402-submodule-rebase.sh | 30 -- 3 files changed, 45 insertions(+), 17 deletions(-) -- 1.8.1.2.612.g09f4be5 -- 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
[PATCH 1/3] git-am: record full index line in the patch used while rebasing
Earlier, a230949 (am --rebasing: get patch body from commit, not from mailbox, 2012-06-26) learned to regenerate patch body from the commit object while rebasing, instead of reading from the rebase-am front-end. While doing so, it used git diff-tree but without giving it the --full-index option. This does not matter for in-repository objects; during rebasing, any abbreviated object name should uniquely identify them. But we may be rebasing a commit that contains a change to a gitlink, in which case we usually should not have the object (it names a commit in the submodule). A full object name is necessary to later reconstruct a fake ancestor index for them. Signed-off-by: Junio C Hamano gits...@pobox.com --- git-am.sh | 2 +- t/t7402-submodule-rebase.sh | 30 -- 2 files changed, 29 insertions(+), 3 deletions(-) diff --git a/git-am.sh b/git-am.sh index c682d34..0e0a096 100755 --- a/git-am.sh +++ b/git-am.sh @@ -664,7 +664,7 @@ do sed -e '1,/^$/d' $dotest/msg-clean echo $commit $dotest/original-commit get_author_ident_from_commit $commit $dotest/author-script - git diff-tree --root --binary $commit $dotest/patch + git diff-tree --root --binary --full-index $commit $dotest/patch else git mailinfo $keep $no_inbody_headers $scissors $utf8 $dotest/msg $dotest/patch \ $dotest/$msgnum $dotest/info || diff --git a/t/t7402-submodule-rebase.sh b/t/t7402-submodule-rebase.sh index f919c8d..8e32f19 100755 --- a/t/t7402-submodule-rebase.sh +++ b/t/t7402-submodule-rebase.sh @@ -3,7 +3,7 @@ # Copyright (c) 2008 Johannes Schindelin # -test_description='Test rebasing and stashing with dirty submodules' +test_description='Test rebasing, stashing, etc. with submodules' . ./test-lib.sh @@ -20,7 +20,8 @@ test_expect_success setup ' echo second line file (cd submodule git pull) test_tick - git commit -m file-and-submodule -a + git commit -m file-and-submodule -a + git branch added-submodule ' @@ -89,4 +90,29 @@ test_expect_success 'stash with a dirty submodule' ' ' +test_expect_success 'rebasing submodule that should conflict' ' + git reset --hard + git checkout added-submodule + git add submodule + test_tick + git commit -m third + ( + cd submodule + git commit --allow-empty -m extra + ) + git add submodule + test_tick + git commit -m fourth + + test_must_fail git rebase --onto HEAD^^ HEAD^ HEAD^0 + git ls-files -s submodule actual + ( + cd submodule + echo 16 $(git rev-parse HEAD^) 1 submodule + echo 16 $(git rev-parse HEAD^^) 2 submodule + echo 16 $(git rev-parse HEAD) 3submodule + ) expect + test_cmp expect actual +' + test_done -- 1.8.1.2.612.g09f4be5 -- 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
[PATCH 2/3] apply: simplify build_fake_ancestor()
The local variable sha1_ptr in the build_fake_ancestor() function
used to either point at the null_sha1[] (if the ancestor did not
have the path) or at sha1[] (if we read the object name into the
local array), but 7a98869 (apply: get rid of --index-info in favor
of --build-fake-ancestor, 2007-09-17) made the missing in the
ancestor case unnecessary, hence sha1_ptr, when used, always points
at the local array.
Get rid of the unneeded variable, and restructure the if/else
cascade a bit to make it easier to read. There should be no
behaviour change.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/apply.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index 156b3ce..a1db7b4 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3598,7 +3598,6 @@ static void build_fake_ancestor(struct patch *list, const
char *filename)
* worth showing the new sha1 prefix, but until then...
*/
for (patch = list; patch; patch = patch-next) {
- const unsigned char *sha1_ptr;
unsigned char sha1[20];
struct cache_entry *ce;
const char *name;
@@ -3606,20 +3605,19 @@ static void build_fake_ancestor(struct patch *list,
const char *filename)
name = patch-old_name ? patch-old_name : patch-new_name;
if (0 patch-is_new)
continue;
- else if (get_sha1_blob(patch-old_sha1_prefix, sha1))
- /* git diff has no index line for mode/type changes */
- if (!patch-lines_added !patch-lines_deleted) {
- if (get_current_sha1(patch-old_name, sha1))
- die(mode change for %s, which is not
- in current HEAD, name);
- sha1_ptr = sha1;
- } else
- die(sha1 information is lacking or useless
- (%s)., name);
- else
- sha1_ptr = sha1;
- ce = make_cache_entry(patch-old_mode, sha1_ptr, name, 0, 0);
+ if (!get_sha1_blob(patch-old_sha1_prefix, sha1)) {
+ ; /* ok */
+ } else if (!patch-lines_added !patch-lines_deleted) {
+ /* mode-only change: update the current */
+ if (get_current_sha1(patch-old_name, sha1))
+ die(mode change for %s, which is not
+ in current HEAD, name);
+ } else
+ die(sha1 information is lacking or useless
+ (%s)., name);
+
+ ce = make_cache_entry(patch-old_mode, sha1, name, 0, 0);
if (!ce)
die(_(make_cache_entry failed for path '%s'), name);
if (add_index_entry(result, ce, ADD_CACHE_OK_TO_ADD))
--
1.8.1.2.612.g09f4be5
--
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
[PATCH 3/3] apply: diagnose incomplete submodule object name better
git am -3 uses this function to build a tree that records how the
preimage the patch was created from would have looked like. An
abbreviated object name on the index line is ordinarily sufficient
for us to figure out the object name the preimage tree would have
contained, but a change to a submodule by definition shows an object
name of a submodule commit which our repository should not have, and
get_sha1_blob() is not an appropriate way to read it (or get_sha1()
for that matter).
Use get_sha1_hex() and complain if we do not find a full object name
there.
We could read from the payload part of the patch to learn the full
object name of the commit, but the primary user git rebase has
been fixed to give us a full object name, so this should suffice
for now.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/apply.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index a1db7b4..1f78e2c 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3606,7 +3606,11 @@ static void build_fake_ancestor(struct patch *list,
const char *filename)
if (0 patch-is_new)
continue;
- if (!get_sha1_blob(patch-old_sha1_prefix, sha1)) {
+ if (S_ISGITLINK(patch-old_mode)) {
+ if (get_sha1_hex(patch-old_sha1_prefix, sha1))
+ die(submoule change for %s without full index
name,
+ name);
+ } else if (!get_sha1_blob(patch-old_sha1_prefix, sha1)) {
; /* ok */
} else if (!patch-lines_added !patch-lines_deleted) {
/* mode-only change: update the current */
--
1.8.1.2.612.g09f4be5
--
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] Rename {git- = git}remote-helpers.txt
On Thu, Jan 31, 2013 at 03:04:55PM -0800, Jonathan Nieder wrote: Jeff King wrote: Maybe it is just me, but the fact that accessing the manpage is now: man gitremote-helpers feels weird to me. I know it technically follows our syntactic rules, but having the lack of dash be significant between git and remote, but then having a dash later makes it hard on the eyes. Yes. I have thought for years that it should be git-remote-helpers, that git help should be tweaked to look for that, and that the existing gitrepository-layout and friends should be replaced with redirects. What was the original rationale for the gitfoo form? Was it just to visually distinguish command manpages from non-command manpages? I can't remember the origins now. It does seem like it is causing more hassle than it is worth, but maybe there is something I am forgetting. -Peff -- 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 1/2] docs: clarify git-branch --list behavior
On Thu, Jan 31, 2013 at 04:37:01PM -0800, Junio C Hamano wrote: Eric Sunshine sunsh...@sunshineco.com writes: On Thu, Jan 31, 2013 at 1:45 AM, Jeff King p...@peff.net wrote: +If `--list` is given, or if there are no non-option arguments, existing +branches are listed; the current branch will be highlighted with an +asterisk. Option `-r` causes the remote-tracking branches to be listed, +and option `-a` shows both local and remote branches. If a `pattern` +is given, it is used as a shell wildcard to restrict the output to +matching branches. If multiple patterns are given, a branch is shown if +any it is matched by any of the patterns. s/if any it is/if it is/ Thanks; I'll squash this in. Peff, no need to resend. Thanks. No matter how many times I proofread a doc change, I always manage to slip an error into the final version. Hooray for many eyes. -Peff -- 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] Rename {git- = git}remote-helpers.txt
Jeff King p...@peff.net writes:
What was the original rationale for the gitfoo form? Was it just to
visually distinguish command manpages from non-command manpages? I can't
remember the origins now.
b27a23e (Documentation: convert tutorials to man pages, 2008-05-24)
turns tutorial.txt into gittutorial.txt. Before that, there
were git{attributes,cli,ignore,hooks,modules}.txt. They were added
in this order, which reveals the true reason:
hooks.txt
gitignore.txt
gitmodules.txt
gitcli.txt
hooks.txt = githooks.txt
gitatributes.txt
Originally, we did not intend to name them as git$concept.txt;
instead, we just said $concept.txt. Hooks are hooks, and we
know we are discussing hooks in the context of Git, there was no
reason to say githooks. gitignore was about the file format,
and it would have been insane to call it ignore.txt. The same
applies to gitmodules.txt.
Things start to go in a strange direction when cli was added. We
know that is about the command line interface in the context of Git,
and it should have been cli.txt. To make things worse, later
hooks.txt took an example of gitcli.txt in the wrong way at
a5af0e2 (Documentation: rename hooks.txt to githooks.txt and
make it a man page, 2008-05-02).
In other way, I think this wasn't designed, but organically grown.
--
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 1/2] docs: clarify git-branch --list behavior
Jeff King p...@peff.net writes: Thanks. No matter how many times I proofread a doc change, I always manage to slip an error into the final version. I think everybody shares that trait. Hooray for many eyes. Indeed. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix some clang warnings
Jeff King p...@peff.net writes: It seems a little weird to me that clang defines __GNUC__, but I assume there are good reasons for it. The thing is that gcc is as much a language dialect these days as it is a compiler implementation, and many other compilers, including clang, explicitly try to implement that dialect (clang goes even further by trying to be compatible in other ways, e.g. command-line syntax, but that's not relevant here). __GNUC__ is a way many programs try to detect the presence of a compiler that implements that dialect, they have little choice but to define it... -Miles -- Love, n. A temporary insanity curable by marriage or by removal of the patient from the influences under which he incurred the disorder. This disease is prevalent only among civilized races living under artificial conditions; barbarous nations breathing pure air and eating simple food enjoy immunity from its ravages. It is sometimes fatal, but more frequently to the physician than to the patient. -- 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
links of london friendship bracelet is very current
The strong links of london sale http://www.linksoflondonbraceletsweetie.co.uk/ /strong has forever tried its best to bargain the customers a balance of present and sole private mode couple necklaces for lovers in the world. All crop was packed with people who like the flavor of life consistently. These offer alternatives for you. Send the links of london charm bracelet to your lover. She will like it very much. Links of London designs a sequence of innovative, rare and individual grandeur characterized harvest for those who fondness alter and tang. The links of London lays much stress on result packing. When you and your Links of London sweeties to your lover, you will assuredly get unexpected result. strong links of london friendship bracelet http://www.linksoflondonbraceletsweetie.co.uk/ /strong is very current. I think links of London charms is the best array for men and women. Every year, Links of London designs a collection of unusual originality and classic, trendy and uncontemplated harvest. The family of links of London describe loves personalized basics, allowing customers to whittle their lexis on different occasions and different moods. They are suitable for taxing on the Links of you throw your lover. Today an increasing demand for expensive twin is part of a whole male grooming boom, according to David Marshall, strong links of london charm bracelet http://www.linksoflondonbraceletsweetie.co.uk/ /strong designer of handcrafted jewelry exclusively. Recently Marshall Twins and a belt buckle to match a red gold watch for a famous client in the fashion industry. But it seems that most men have trouble matching socks. What kind of person agrees with his watch and cufflinks, to say nothing of his ties to the delights of London? http://www.linksoflondonbraceletsweetie.co.uk/ -- View this message in context: http://git.661346.n2.nabble.com/links-of-london-friendship-bracelet-is-very-current-tp7576740.html Sent from the git mailing list archive at Nabble.com. -- 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
thomas sabo jewellery are popular among people
Here I want to share you my happiness. Yesterday I have received my thomas sabo uk which I ordered a few days ago. The one I bought is made with Neon Yellow elastic with three lovely charms. So cute and fashionable these Thomas Sabo Bracelets they are. By wearing these bracelets can make us graceful, bring us an outdoor feeling. What is more, wearing these bracelets keep me in good mood all the day. With my thomas sabo bracelets, I can bout them with my clothing relaxed at will like accidental dresses and the dresses to get a social gathering. I just remembered that I went to a chic alliance that I wore my thomas sabo bracelets, abounding of my classmates said this armlet was real admirable and also the architecture was real cute. By cutting this affectionate of bracelets can physical appearance our adolescence and vigor. I told them in proudly that I bought this affectionate of cast in a very very low volume and leading high quality. Then they asked me the web site and said they as well cash to get this thomas sabo bracelets afterwards. With my thomas sabo bracelet , I can match them with my clothes together at will such as casual dresses and the dresses for a party. I just remembered that I went to a class reunion that I wore my Thomas Sabo Bracelets, many of my classmates said this bracelet was very beautiful and the design was very cute. By wearing this kind of bracelets can show our youth and vigor. I told them in proudly that I bought this kind of brand in a low price and high quality. Then they asked me the website and said they also wanted to buy this Thomas Sabo Jewelry later. Believe me if you want to find the best jewelry that suits you the most. Take Thomas Sabo into consideration and you will be different. Yes, best jewelry for best of you! You will be absolutely charming with this kind of amazing stuff with you. -- View this message in context: http://git.661346.n2.nabble.com/thomas-sabo-jewellery-are-popular-among-people-tp7576741.html Sent from the git mailing list archive at Nabble.com. -- 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
