Re: [RFC/PATCH v2] CodingGuidelines: add Python coding guidelines
On 01/29/2013 08:08 PM, John Keeping wrote:
These are kept short by simply deferring to PEP-8. Most of the Python
code in Git is already very close to this style (some things in contrib/
are not).
Rationale for version suggestions:
- Amongst the noise in [1], there isn't any disagreement about using
2.6 as a base (see also [2]), although Brandon Casey recently added
support for 2.4 and 2.5 to git-p4 [3].
- Restricting ourselves to 2.6+ makes aiming for Python 3 compatibility
significantly easier [4].
- Advocating Python 3 support in all scripts is currently unrealistic
because:
- 'p4 -G' provides output in a format that is very hard to use with
Python 3 (and its documentation claims Python 3 is unsupported).
- Mercurial does not support Python 3.
- Bazaar does not support Python 3.
- But we should try to make new scripts compatible with Python 3
because all new Python development is happening on version 3 and the
Python community will eventually stop supporting Python 2 [5].
- Python 3.1 is required to support the 'surrogateescape' error handler
for encoding/decodng filenames to/from Unicode strings and Python 3.0
is not longer supported.
[1] http://thread.gmane.org/gmane.comp.version-control.git/210329
[2] http://article.gmane.org/gmane.comp.version-control.git/210429
[3] http://thread.gmane.org/gmane.comp.version-control.git/214579
[4]
http://docs.python.org/3.3/howto/pyporting.html#try-to-support-python-2-6-and-newer-only
[5] http://www.python.org/dev/peps/pep-0404/
---
Changes since v1:
- Set 3.1 as the minimum Python 3 version
- Remove the section on Unicode literals - it just adds confusion and
doesn't apply to the current code; we can deal with any issues if they
ever arise.
Documentation/CodingGuidelines | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 69f7e9b..db7a416 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -179,6 +179,19 @@ For C programs:
- Use Git's gettext wrappers to make the user interface
translatable. See Marking strings for translation in po/README.
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+ also be compatible with Python 3.1 and later.
+
+ - We use the 'b' prefix for bytes literals. Note that even though
+ the Python documentation for version 2.6 does not mention this
+ prefix it is supported since version 2.6.0.
+
Writing Documentation:
Every user-visible change should be reflected in the documentation.
Nit: s/it is supported/it has been supported/
I think this would be a good Python policy.
I would hate to junk up all Python code with things like
' '.encode('ascii')
though, so maybe we should establish a small Python library of
compatibility utilities (like a small six). It could contain b().
Another handy utility function could be
def check_python_version(minimum_v2=0x0206,
minimum_v3=0x0301)
which checks our default Python requirements by default, but is
overrideable by specific scripts if they know that they can deal with
older Python versions.
But I haven't had time to think of where to put such a library, how to
install it, etc.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.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
[BUG] incorrect search result returned when using git log with a future date parameter
Hi there, when I'm using the commit limit option `--before/--until` when doing `git log` search, I meet a bug when the upper-bound date is 10days later in the future. Here is an example: $ date +%F 2013-01-30 $ git log --oneline --since=2013-01-01 --until=2013-02-01 several git log entry from 2013-01-01 to 2013-01-30 printed $ git log --oneline --since=2013-01-01 --until=2013-02-13 null I debugged into the problem with ./test-date program in git source tree, got: $ ./test-date approxidate 2013-02-01 2013-02-01 - 2013-02-01 10:47:13 + // correctly parsed $ ./test-date approxidate 2013-02-13 2013-02-13 - 2013-01-02 10:47:20 + // incorrectly parsed When looking into the codes of date.c, in is_date() function, I found: 382 /* Be it commit time or author time, it does not make 383 * sense to specify timestamp way into the future. Make 384 * sure it is not later than ten days from now... 385 */ 386 if (now + 10*24*3600 specified) 387 return 0; 388 tm-tm_mon = r-tm_mon; 389 tm-tm_mday = r-tm_mday; 390 if (year != -1) 391 tm-tm_year = r-tm_year; 392 return 1; If I comment Line 386 387 out, the parsing works correctly. So I guess here is the cause of the problem. Then I checked the git history, the change was introduced in commit 38035cf4 by Junio C Hamano (cc-ed): ~ commit 38035cf4a51c48cccf6c5e3977130261bc0c03a7 Author: Junio C Hamano jun...@cox.net Date: Wed Apr 5 15:31:12 2006 -0700 date parsing: be friendlier to our European friends. This does three things, only applies to cases where the user manually tries to override the author/commit time by environment variables, with non-ISO, non-2822 format date-string: - Refuses to use the interpretation to put the date in the future; recent kernel history has a commit made with 10/03/2006 which is recorded as October 3rd. - Adds '.' as the possible year-month-date separator. We learned from our European friends on the #git channel that dd.mm. is the norm there. - When the separator is '.', we prefer dd.mm. over mm.dd.; otherwise mm/dd/yy[yy] takes precedence over dd/mm/yy[yy]. Signed-off-by: Junio C Hamano jun...@cox.net ~~ It seems like the original commit was going to fix European date style, but it fixed(?) the future date problem as well. However, this part of fix is not perfect: 1) it makes date parsing not working correctly. (see my test examples above). IMO, it should be in another place (maybe in commit.c or somewhere else?) we check if commit date is valid or not, instead of in the date parsing function. A date parsing function should parse _all dates with correctly format_, despite if it's an old date, or the date in the future. 2) from the test example I gave above, in fact the codes don't really prevent git from accepting the changes with illegal date, e.g., if there is a commit recorded as 2013-02-13, it will be parsed to 2013-01-02, which is a legal (old) date, thus, this commit will be accepted, but this is wrong. My suggestion is we might need to revert the first part of commit 38035cf4 since this part of code doesn't work correctly and causes problems; then we should create a new checking mechanism to prevent those future date commits to be accepted in other functions. I'm not able to do the second part since I'm not familiar with git codes yet.. :-( Thoughts? Caspar -- 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
[BUG] incorrect search result returned when using git log with a future date parameter
Hi there, when I'm using the commit limit option `--before/--until` when doing `git log` search, I meet a bug when the upper-bound date is 10days later in the future. Here is an example: $ date +%F 2013-01-30 $ git log --oneline --since=2013-01-01 --until=2013-02-01 several git log entry from 2013-01-01 to 2013-01-30 printed $ git log --oneline --since=2013-01-01 --until=2013-02-13 null I debugged into the problem with ./test-date program in git source tree, got: $ ./test-date approxidate 2013-02-01 2013-02-01 - 2013-02-01 10:47:13 + // correctly parsed $ ./test-date approxidate 2013-02-13 2013-02-13 - 2013-01-02 10:47:20 + // incorrectly parsed When looking into the codes of date.c, in is_date() function, I found: 382 /* Be it commit time or author time, it does not make 383 * sense to specify timestamp way into the future. Make 384 * sure it is not later than ten days from now... 385 */ 386 if (now + 10*24*3600 specified) 387 return 0; 388 tm-tm_mon = r-tm_mon; 389 tm-tm_mday = r-tm_mday; 390 if (year != -1) 391 tm-tm_year = r-tm_year; 392 return 1; If I comment Line 386 387 out, the parsing works correctly. So I guess here is the cause of the problem. Then I checked the git history, the change was introduced in commit 38035cf4 by Junio C Hamano (cc-ed): ~ commit 38035cf4a51c48cccf6c5e3977130261bc0c03a7 Author: Junio C Hamano jun...@cox.net Date: Wed Apr 5 15:31:12 2006 -0700 date parsing: be friendlier to our European friends. This does three things, only applies to cases where the user manually tries to override the author/commit time by environment variables, with non-ISO, non-2822 format date-string: - Refuses to use the interpretation to put the date in the future; recent kernel history has a commit made with 10/03/2006 which is recorded as October 3rd. - Adds '.' as the possible year-month-date separator. We learned from our European friends on the #git channel that dd.mm. is the norm there. - When the separator is '.', we prefer dd.mm. over mm.dd.; otherwise mm/dd/yy[yy] takes precedence over dd/mm/yy[yy]. Signed-off-by: Junio C Hamano jun...@cox.net ~~ It seems like the original commit was going to fix European date style, but it fixed(?) the future date problem as well. However, this part of fix is not perfect: 1) it makes date parsing not working correctly. (see my test examples above). IMO, it should be in another place (maybe in commit.c or somewhere else?) we check if commit date is valid or not, instead of in the date parsing function. A date parsing function should parse _all dates with correctly format_, despite if it's an old date, or the date in the future. 2) from the test example I gave above, in fact the codes don't really prevent git from accepting the changes with illegal date, e.g., if there is a commit recorded as 2013-02-13, it will be parsed to 2013-01-02, which is a legal (old) date, thus, this commit will be accepted, but this is wrong. My suggestion is we might need to revert the first part of commit 38035cf4 since this part of code doesn't work correctly and causes problems; then we should create a new checking mechanism to prevent those future date commits to be accepted in other functions. I'm not able to do the second part since I'm not familiar with git codes yet.. :-( Thoughts? Caspar -- 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
Anybody know a website with up-to-date git documentation?
Hi, does anybody know a website where one can view that latest git documentation? Here, latest means latest release (though being also able to access it for next would of course be a nice bonus, likewise for older versions). While I do have those docs on my local machine, I would like to access them online, too (e.g. easier to pointer people at this, I can access it from other machines, etc.). My problem is that all sites I know of are outdated, and thus don't show recent improvements. Also, for many it is hard to determine for which version of git they carry documentation. Here are the contenders I know, and the problems they have: * The closest I know is http://git-scm.com/ -- they fit the bill almost perfectly. Except that sadly, some pages that are crucial for me are permanently stuck at outdated versions, like http://git-scm.com/docs/git-remote-helpers which is stuck at 1.7.12.3. I tried contacting them about this for two months now, but to no avail (multiple bug reports, direct emails, etc. all went w/o reaction). Of course time and resources are limited, so I fully understand and respect that the people behind it (Scott Chacon in particular, who did an awesome job creating that site in the first place) have other priorities. * http://www.kernel.org/pub/software/scm/git/docs/ was last updated in May 2012. No hints on who maintains this and how to contact them. Attempts to contact kernel.org webadmins to find out more were not answered either :-(. Anybody know more? * http://schacon.github.com/git/git-remote-helpers.html was lasted updated in May 2011. I assume git-scm.com is supposed to replace it, though, as Scott Chacon made git-scm.com. (In that case, a redirect to git-scm.com might be nice *g* but of course is extra work) * http://www.manpagez.com/man/1/git/ and http://man.he.net/man1/git at least document on each page from which git version it is taken. Unfortunately, both are stuck at the 1.7.x series. * http://linux.die.net/man/1/git does not indicate the git version, but it seems to be a 1.7.x, too Anybody know an up-to-date alternative? Or do I have to setup my own? :-(. Cheers, Max-- 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: Anybody know a website with up-to-date git documentation?
On Wed, Jan 30, 2013 at 12:46:47PM +0100, Max Horn wrote: does anybody know a website where one can view that latest git documentation? Here, latest means latest release (though being also able to access it for next would of course be a nice bonus, likewise for older versions). While I do have those docs on my local machine, I would like to access them online, too (e.g. easier to pointer people at this, I can access it from other machines, etc.). How about http://git-htmldocs.googlecode.com/git/ ? It's just a directory listing of the git-htmldocs repository that Junio maintains - the latest update was yesterday: Autogenerated HTML docs for v1.8.1.2-422-g08c0e. [I didn't know Google Code let you view the repository like that, but I got there by clicking the raw link against one of the files so I assume it's not likely to go away.] 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: Anybody know a website with up-to-date git documentation?
Hello Max, git-scm.com is the best source and it's not outdated. It gets an update after every single release of Git. See e.g. http://git-scm.com/docs/git-config which was updated in the current stable version. It seems that git-remote-helper's documentation was just not updated since version 1.7.12.3. Best regards, Sebastian 2013/1/30 John Keeping j...@keeping.me.uk: On Wed, Jan 30, 2013 at 12:46:47PM +0100, Max Horn wrote: does anybody know a website where one can view that latest git documentation? Here, latest means latest release (though being also able to access it for next would of course be a nice bonus, likewise for older versions). While I do have those docs on my local machine, I would like to access them online, too (e.g. easier to pointer people at this, I can access it from other machines, etc.). How about http://git-htmldocs.googlecode.com/git/ ? It's just a directory listing of the git-htmldocs repository that Junio maintains - the latest update was yesterday: Autogenerated HTML docs for v1.8.1.2-422-g08c0e. [I didn't know Google Code let you view the repository like that, but I got there by clicking the raw link against one of the files so I assume it's not likely to go away.] 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 -- 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: What's cooking in git.git (Jan 2013, #10; Sun, 27)
gits...@pobox.com wrote on Sun, 27 Jan 2013 22:45 -0800: * pw/git-p4-on-cygwin (2013-01-26) 21 commits - git p4: introduce gitConfigBool - git p4: avoid shell when calling git config - git p4: avoid shell when invoking git config --get-all - git p4: avoid shell when invoking git rev-list - git p4: avoid shell when mapping users - git p4: disable read-only attribute before deleting - git p4 test: use test_chmod for cygwin - git p4: cygwin p4 client does not mark read-only - git p4 test: avoid wildcard * in windows - git p4 test: use LineEnd unix in windows tests too - git p4 test: newline handling - git p4: scrub crlf for utf16 files on windows - git p4: remove unreachable windows \r\n conversion code - git p4 test: translate windows paths for cygwin - git p4 test: start p4d inside its db dir - git p4 test: use client_view in t9806 - git p4 test: avoid loop in client_view - git p4 test: use client_view to build the initial client - git p4: generate better error message for bad depot path - git p4: remove unused imports - git p4: temp branch name should use / even on windows Improve git p4 on Cygwin. The cover letter said it is not yet ready for full Windows support so I won't move this to 'next' until told by the author (the area maintainer) otherwise. The series is ready as is to support Cygwin platforms, and thus useful to people who would use git on windows via cygwin. Future work will be to add support for Msysgit. That work will need much of the changes in this Cygwin series as well. It is more complicated since there's no native python for Msysgit (yet). I think the Cygwin changes should go in now. -- Pete -- 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: Anybody know a website with up-to-date git documentation?
Hi Max, it seems that this is some sort of caching problem on git-scm.com. I saw you've already opened an issue at https://github.com/github/gitscm-next/issues/232. So there's probably not much you can do right now. And I don't know any better source for documentation right now, apart from the locally installed HTML version. Best regards, Sebastian 2013/1/30 Max Horn m...@quendi.de: Hi Sebastian, On 30.01.2013, at 12:56, Sebastian Staudt wrote: Hello Max, git-scm.com is the best source and it's not outdated. Then it seems you are using the word outdated in a different way than me which I don't understand :-). Sure, it strives to be up-to-date, but fact is that it fails to do that, due to a bug (I guess). The end result (failure to update at all, vs. failure in an attempted update) sadly amount to the same. It gets an update after every single release of Git. See e.g. http://git-scm.com/docs/git-config which was updated in the current stable version. It seems that git-remote-helper's documentation was just not updated since version 1.7.12.3. Yes, and it is not alone in that, which makes the site somewhat unreliable, sadly. Some more examples of pages tuck at version 1.7.12.3 and showing outdated content: http://git-scm.com/docs/git-log http://git-scm.com/docs/git-merge http://git-scm.com/docs/git-merge-base http://git-scm.com/docs/git-mergetool http://git-scm.com/docs/git-reset http://git-scm.com/docs/git-rm http://git-scm.com/docs/git-status http://git-scm.com/docs/git-symbolic-ref I did not bother to check every single page, though, and I am pretty sure there are plenty more. Because there definitely is a plethora of other pages that are stuck at 1.7.12.3. Several of them still show the latest version due to not having had updates since the 1.7.12.3, but that is not always easy to tell due to included files (e.g. git-log.txt was not changed v1.7.12.2, but it includes rev-list-options.txt which was last changed in 1.8.1). So, yeah, I do think git-scm.com is outdated -- in the sense that for many pages, it does not show the latest officially released version of the page. Best regards, Max -- 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 Tue, Jan 29, 2013 at 04:16:11AM -0500, Jeff King wrote:
When we are doing a commit traversal that does not need to
look at the commit messages themselves (e.g., rev-list,
merge-base, etc), we spend a lot of time accessing,
decompressing, and parsing the commit objects just to find
the parent and timestamp information. We can make a
space-time tradeoff by caching that information on disk in a
compact, uncompressed format.
And this is a (messy) patch on top that avoids storing SHA-1
directly. On my linux-2.6.git (575 MB pack, 73 MB index), .commits
file is 5.2 MB and 27 MB with and without my patch respectively. Nice
shrinkage.
However, performance seems to suffer too. Maybe I do more lookups than
necessary, I don't know. I should probably measure the cost of
revindex separately.
git rev-list --all --quiet on vanilla git:
real0m3.645s
user0m3.556s
sys 0m0.080s
commit cache without my patch:
real0m0.723s
user0m0.677s
sys 0m0.045s
and with my patch:
real0m1.338s
user0m1.259s
sys 0m0.075s
Another point, but not really important at this stage, I think we have
memory leak somewhere (lookup_commit??). It used up to 800 MB RES on
linux-2.6.git while generating the 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..55f7ea9 100644
--- a/commit-metapack.c
+++ b/commit-metapack.c
@@ -3,11 +3,12 @@
#include metapack.h
#include commit.h
#include sha1-lookup.h
+#include pack-revindex.h
struct commit_metapack {
struct metapack mp;
- uint32_t nr;
- unsigned char *index;
+ struct packed_git *pack;
+ uint32_t first, last;
unsigned char *data;
struct commit_metapack *next;
};
@@ -16,7 +17,7 @@ static struct commit_metapack *commit_metapacks;
static struct commit_metapack *alloc_commit_metapack(struct packed_git *pack)
{
struct commit_metapack *it = xcalloc(1, sizeof(*it));
- uint32_t version;
+ uint32_t version, nr;
if (metapack_init(it-mp, pack, commits, version) 0) {
free(it);
@@ -39,22 +40,25 @@ static struct commit_metapack *alloc_commit_metapack(struct
packed_git *pack)
free(it);
return NULL;
}
- memcpy(it-nr, it-mp.data, 4);
- it-nr = ntohl(it-nr);
+ memcpy(it-first, it-mp.data, 4);
+ it-first = ntohl(it-first);
+ memcpy(it-last, it-mp.data + 4, 4);
+ it-last = ntohl(it-last);
+ nr = it-last - it-first + 1;
+ it-pack = pack;
/*
-* We need 84 bytes for each entry: sha1(20), date(4), tree(20),
-* parents(40).
+* We need 16 bytes for each entry: date(4), tree index(4),
+* parent indexes(8).
*/
- if (it-mp.len (84 * it-nr + 4)) {
+ if (it-mp.len (16 * 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-data = it-mp.data + 8;
return it;
}
@@ -81,31 +85,61 @@ static void prepare_commit_metapacks(void)
initialized = 1;
}
+static const unsigned char *idx_to_sha1(struct packed_git *p,
+ uint32_t nth)
+{
+ struct revindex_entry *revindex = get_revindex(p);
+ if (!revindex)
+ return NULL;
+ return nth_packed_object_sha1(p, revindex[nth].nr);
+}
+
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);
- if (pos 0)
+ uint32_t p1, p2;
+
Re: Anybody know a website with up-to-date git documentation?
On 30.01.2013, at 12:54, John Keeping wrote: On Wed, Jan 30, 2013 at 12:46:47PM +0100, Max Horn wrote: does anybody know a website where one can view that latest git documentation? Here, latest means latest release (though being also able to access it for next would of course be a nice bonus, likewise for older versions). While I do have those docs on my local machine, I would like to access them online, too (e.g. easier to pointer people at this, I can access it from other machines, etc.). How about http://git-htmldocs.googlecode.com/git/ ? It's just a directory listing of the git-htmldocs repository that Junio maintains - the latest update was yesterday: Autogenerated HTML docs for v1.8.1.2-422-g08c0e. [I didn't know Google Code let you view the repository like that, but I got there by clicking the raw link against one of the files so I assume it's not likely to go away.] Thanks John, that looks pretty good! In addition, I just discovered http://manned.org/git-remote-helpers/2b9e4c86 which contains git docs from Arch Linux, Debian, FreeBSD and Ubuntu packages. And since Arch tends to have the latest, so does manned.org. And best, it even lets me browser to older versions of a file. So, taken together, I guess that solves my problem -- with John's link, I can see the bleeding edge versions, with manned.org the latest released version (as soon as Arch Linux catches up, which seems to be pretty quick :-). Thanks! Max-- 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 add completion should exclude staged content
-Original Message- From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf Of Manlio Perillo Sent: Monday, January 28, 2013 3:16 PM To: Junio C Hamano Cc: Michael J Gruber; wookietreiber; git@vger.kernel.org Subject: Re: [feature request] git add completion should exclude staged content -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 28/01/2013 18:52, Junio C Hamano ha scritto: [...] Thanks both for commenting. I'll find time to read it over again and perhaps we can merge it to 'next' and advertise it in the next issue of What's cooking report to ask for wider testing to move it forward. Thanks. I will try to update the patch, with your latest suggestions (avoid tricky POSIX shell syntax, and CDPATH issue - if I remember correctly), and with an update for the t/t9902-completion.sh test (that I completely missed). Hi Manlio, I'm trying to update git-completion.tcsh to work properly with your nice new completion feature. But I'm having trouble with the missing '/' at the end of directories. The new logic in git-completion.bash tells bash that 'filenames' completion is ongoing so bash will add a '/' after directories. Sadly, tcsh won't do that, so it would be simpler if git-completion.bash added the '/' itself. I looked at the git-completion.bash script changes and I noticed that for bash version 4, you have to add the '/' yourself. I also noticed the following comment: # XXX if we append a slash to directory names when using # `compopt -o filenames`, Bash will append another slash. # This is pretty stupid, and this the reason why we have to # define a compatible version for this function. So I gather you would rather add a '/' all the time to deal with older bash version transparently. This would be great for tcsh also. I'm trying to figure out when bash mis-behaves when you add the '/' all the time? When I try it (I have bash 4.1.5(1)-release) I didn't run into the double slash problem you mention in the comment. I'm hoping we can straighten this out and have git-completion.bash add the '/' all the time. Could you explain when the problem happens? Thanks Marc -- 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
LcandoloVERIFICAINFORAZIONIyahoo
return-path: market...@displaycreative.it LcandoloVERIFICAINFORAZIONIyahoo Bella, intelligente, socievole donna per o'uomo in cerca di un inconteo in talia ae avviare una relazione seria. ±Â Il mio indirizzo e-mail bella.do...@yahoo.com Scrivi q me e ik ti invierà la mia beloa foto e lettere. ¦¯Iryna ;) -- 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 8:56 PM, Duy Nguyen pclo...@gmail.com wrote: However, performance seems to suffer too. Maybe I do more lookups than necessary, I don't know. Yes, I should have stored the position in the sha-1 - offset map instead of the position of the object in .pack file. Even so, performance does not improve. I should probably measure the cost of revindex separately. And the cost of create_pack_revindex() is 0.6 sec :-( Perhaps we could store abbrev sha-1 instead of full sha-1. Nice space/time trade-off. -- Duy -- 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
ChiarasciuttoVERIFICAINFORMAZIONIalice
return-path: l.huml...@ckibis.cz ChiarasciuttoVERIFICAINFORMAZIONIalice Bella, intelligente, socievole donna per l'uomi in cerca di un incontro ih Italia ad avvuare una relazione seria. ª Il mio indirizzo e-mail bella.do...@yahoo.com Scrivi a me s io ti invierà la mia bella foto s lettere. ÂIryna ) -- 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: Bug, feature, or pilot error: format-patch
Ping It would be useful to get some comment on this On 01/28/2013 12:03 PM, Gene Czarcinski wrote: I am not on the mailing list so please CC me. I am running git 1.8.1 on Fedora 18. I aam having what appears to be a problem. Here is the sequence which generally describes what I did and what happened: git checkout -b test1 master git am 0001-simple-1.patch git checkout -b test2 master git am 0001-simple-2.patch### this is known to conflict with 0001-simple-1.patch git checkout test1 git merge test2 [here git-merge detects a conflict] git mergetool ###to resolve the conflict [conflict resolved] git commit -a -s git log [shows two commits -- one for simple-2 and one for the merge] git format-patch master..HEAD [two patch files created: 0001-simple-1.patch and 0002-simple-2.patch] [0002-simple-2.patch and 0001-simple-2.patch are exactly equal and do not reflect the resolved conflict] If you do git-diff between commit-patch-1 and HEAD, you get something different that you got from format-patch. 1. Bug ... format-patch is broken 2. Feature ... that is the way it works 3. Pilot error ... ?? I can create a good version of patch-2 manually but should I have to? Color me foolish but I assumed I could do git-format-patch in one branch and then use git-am to recreate that branch elsewhere. Gene -- 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 Tue, 29 Jan 2013 11:53:19 -0800 Junio C Hamano gits...@pobox.com wrote: JCH Makes one wonder why .authinfo and not .netrc; JCH http://www.gnu.org/software/emacs/manual/html_node/auth/Help-for-users.html JCH phrases it amusingly: JCH “Netrc” files are usually called .authinfo or .netr JCH nowadays .authinfo seems to be more popular and the JCH auth-source library encourages this confusion by accepting JCH both I wrote this and the auth-source.el library in Emacs (I'm glad it was amusing :). The confusion is further perpetuated by our (in Emacs) encouragement to use a .authinfo.gpg file, which is then decrypted on the fly by Emacs through GPG. The format is the same; by the time auth-source.el sees the contents, they are plain text since the decoding happens at the file handler level. I think it makes sense to write the code to support both `git-send-email' and credentials. I have had it in my TODO list for almost 2 years now to work on credential support, and to support the ~/.authinfo.gpg decoding specifically. Ideally this would also support the other formats... Michal, would you be interested in that feature? I promise to get off my rear and help out. +The '~/.authinfo' file is read if Text::CSV Perl module is installed +on the system; if it's missing, a notification message will be printed +and the file ignored altogether. The file should contain a line with +the following format: ++ + machine domain port port login user password pass JCH It is rather strange to require a comma-separated-values parser to JCH read a file format this simple, isn't it? I'd recommend a hand-crafted parser. Among other things, you should accept both strings and 'strings' if possible (I've seen both formats in the wild), and the format is simple enough to avoid the module dependency. ++ +Contrary to other tools, 'git-send-email' does not support symbolic +port names like 'imap' thus `port` must be a number. JCH Perhaps you can convert at least some popular ones yourself? After JCH all, the user may be using an _existing_ .authinfo/.netrc that she JCH has been using with other programs that do understand symbolic port JCH names. Rather than forcing all such users to update their files, JCH the patch can work a bit harder for them and the world will be a JCH better place, no? I agree, port imap is a nice self-documenting token. Maybe it can be interpreted by the program that requests the token with a services lookup, where supported. 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
Files excluded but not ignored
I prefer to not add core.* files to my ignore listings because I find it helpful to see them in git status -- It helps me notice and clean them up periodically. Not having them ignored is also good ,because it allows git clean to care of core.* files. The problem is that git add -A, git stash -u, etc, remain interested in the core files. Trying to start up discussion of whether there would be merit to a half- ignored state -- Files which are excluded from tracking, but which still show in git status, and which are removed by git clean. Not trying to propose yet how .git/exclude or .gitignore would be formatted or anything like that. Just looking for opinions on whether such a state would be considered by the community as a good thing and merit the added complexity in the code. -- 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
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. -- 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
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. Yeah, that sounds like a neat idea. -- 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: Anybody know a website with up-to-date git documentation?
On Wed, Jan 30, 2013 at 7:28 PM, Max Horn m...@quendi.de wrote: On 30.01.2013, at 12:54, John Keeping wrote: On Wed, Jan 30, 2013 at 12:46:47PM +0100, Max Horn wrote: does anybody know a website where one can view that latest git documentation? Here, latest means latest release (though being also able to access it for next would of course be a nice bonus, likewise for older versions). While I do have those docs on my local machine, I would like to access them online, too (e.g. easier to pointer people at this, I can access it from other machines, etc.). How about http://git-htmldocs.googlecode.com/git/ ? It's just a directory listing of the git-htmldocs repository that Junio maintains - the latest update was yesterday: Autogenerated HTML docs for v1.8.1.2-422-g08c0e. [I didn't know Google Code let you view the repository like that, but I got there by clicking the raw link against one of the files so I assume it's not likely to go away.] Thanks John, that looks pretty good! In addition, I just discovered http://manned.org/git-remote-helpers/2b9e4c86 which contains git docs from Arch Linux, Debian, FreeBSD and Ubuntu packages. And since Arch tends to have the latest, so does manned.org. And best, it even lets me browser to older versions of a file. So, taken together, I guess that solves my problem -- with John's link, I can see the bleeding edge versions, with manned.org the latest released version (as soon as Arch Linux catches up, which seems to be pretty quick :-). I'm curious... what's wrong with 'git checkout html' from the git repo and just browsing them using a web browser? -- 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: Files excluded but not ignored
Jason Wenger jcwen...@gmail.com writes: I prefer to not add core.* files to my ignore listings because I find it helpful to see them in git status -- It helps me notice and clean them up periodically. Not having them ignored is also good ,because it allows git clean to care of core.* files. The problem is that git add -A, git stash -u, etc, remain interested in the core files. Trying to start up discussion of whether there would be merit to a half- ignored state -- Files which are excluded from tracking, but which still show in git status, and which are removed by git clean. Not trying to propose yet how .git/exclude or .gitignore would be formatted or anything like that. Just looking for opinions on whether such a state would be considered by the community as a good thing and merit the added complexity in the code. I see no merit for ignored and never to be tracked, but are still shown loudly in the untracked list myself. Use cases for ignored and never to be tracked, but not expendable class were mentioned often in the past, though. -- 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: Anybody know a website with up-to-date git documentation?
Max Horn m...@quendi.de writes: does anybody know a website where one can view that latest git documentation? Here, latest means latest release (though being also able to access it for next would of course be a nice bonus, likewise for older versions). Preformatted ones for the tip of 'master' are reachable from http://git-htmldocs.googlecode.com/git/git.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: Anybody know a website with up-to-date git documentation?
On 30.01.2013, at 16:59, Sitaram Chamarty wrote: I'm curious... what's wrong with 'git checkout html' from the git repo and just browsing them using a web browser? Hm, do you mean make html, perhaps? At least I couldn't figure out what git checkout html should do, but out of curiosity gave it a try and got an error... But supposing that you meant make html: There is nothing wrong with it. This is mostly a matter of convenience: * Many people just use git and don't have the git.git repos (or any git sources) at hand. And while for many things, older versions of the reference pages may suffice, this is not always the case. * When I want to point somebody at something specific in the git docs while, say, while discussing on IRC or a mailing list, it is very convenient to point them at a website, like this: http://git-htmldocs.googlecode.com/git/git-fast-import.html#_code_notemodify_code * Similarly if I am standing physically next to somebody sitting at their computer and they ask me something about git, it is nice to be able to send them to a current version of the docs online * I can access the web version from my tablet -- and I actually do that (use my tablet as secondary screen showing some git refs and other docs while coding on my laptop). * a website can be update by one person (or ideally: one script) and serve many people with the same need Seems more efficient than each of those people setting up an appropriate clone a cron job to keep it up-to-date on each machine where they need it. But of course, the make html has its own clear advantages, e.g. I can use it online, I have full control over which exact version of the docs I get, including most recent changes, etc. To me, the two complement each other. Anyway, I'll stop spamming the list, I got my answers from John and Junio: http://git-htmldocs.googlecode.com/git/git.html and in addition http://manned.org/git.1 Thanks again, Max-- 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: Anybody know a website with up-to-date git documentation?
Max Horn m...@quendi.de writes:
[administrivia: please wrap lines to a reasonable width]
On 30.01.2013, at 16:59, Sitaram Chamarty wrote:
I'm curious... what's wrong with 'git checkout html' from the git repo
and just browsing them using a web browser?
Hm, do you mean make html, perhaps? At least I couldn't figure
out what git checkout html should do, but out of curiosity gave
it a try and got an error...
Perhaps some information from A note from the maintainer (posted
to this list from time to time) is lacking. Some excerpts:
You can browse the HTML manual pages at:
http://git-htmldocs.googlecode.com/git/git.html
Preformatted documentation from the tip of the master branch can be
found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
...
Armed with that knowledge, I think Sitaram may have something like
this:
[remote htmldocs]
url = git://git.kernel.org/pub/scm/git/git-htmldocs.git/
fetch = +refs/heads/master:refs/heads/html
and does
git fetch htmldocs
git checkout html
You can, too, of course ;-)
--
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/7] perl/Git.pm: a bunch of fixes for Windows
From: Gustavo L. de M. Chaves gnust...@cpan.org I'm working on Git::Hooks, a Perl module to facilitate the implementation of git hooks. (http://search.cpan.org/dist/Git-Hooks/) Git::Hooks uses the Git module implemented in perl/Git.pm and distributed with git. While working on porting Git::Hooks to Windows I stumbled upon a few problems in the Git module, problems specific to the Windows environment. In the following sequence of patches I try to fix them. For the record, I'm using Strawberry Perl on Windows. This is my first patch submission to git. I tried to follow all the project conventions but I may have done it wrong. If so, please, help me learn it. Thanks! Gustavo L. de M. Chaves (7): perl/Git.pm: test portably if a path is absolute perl/Git.pm: set up command environment on Windows perl/Git.pm: fix _cmd_close on Windows perl/Git.pm: escape external command's arguments on Windows perl/Git.pm: simplify Git::activestate_pipe perl/Git.pm: make command pipe work in slurp-mode on Windows perl/Git.pm: rename 'ActiveState' to 'Windows' perl/Git.pm | 63 +++-- 1 file changed, 36 insertions(+), 27 deletions(-) -- 1.7.12.464.g83379df.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
[PATCH 2/7] perl/Git.pm: set up command environment on Windows
From: Gustavo L. de M. Chaves gnust...@cpan.org
Routine _cmd_exec invokes _setup_git_cmd_env inside the child process
before invoking an external git command to set up the environment
variables GIT_DIR and GIT_WORK_TREE and, also, to chdir to the
repository. But _cmd_exec is only used on Unix. On Windows, it's not
used and the main code path is in _command_common_pipe, which didn't
prepare the environment like _cmd_exec.
Without this environment preparation some git commands, such as git
clone, don't work.
We can't use _setup_git_cmd_env in this case because we don't use a
forking open like _cmd_exec does and don't get a chance to make such
preparations on the child process.
So, the preparation is done on _command_common_pipe by setting up
localized environment variables and by chdir temporarily just before
invoking the external command.
Signed-off-by: Gustavo L. de M. Chaves gnust...@cpan.org
---
perl/Git.pm | 14 ++
1 file changed, 14 insertions(+)
diff --git a/perl/Git.pm b/perl/Git.pm
index 658b602..e14b41a 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1302,6 +1302,19 @@ sub _command_common_pipe {
# warn 'ignoring STDERR option - running w/ ActiveState';
$direction eq '-|' or
die 'input pipe for ActiveState not implemented';
+
+ # Set up repo environment
+ local $ENV{GIT_DIR} = $self-repo_path() if defined $self
$self-repo_path();
+ local $ENV{GIT_WORK_TREE} = $self-wc_path() if defined $self
$self-repo_path() $self-wc_path();
+
+ my $cwd = cwd;
+
+ if (defined $self) {
+ chdir $self-repo_path() if $self-repo_path();
+ chdir $self-wc_path() if $self-wc_path();
+ chdir $self-wc_subdir() if $self-wc_subdir();
+ }
+
# the strange construction with *ACPIPE is just to
# explain the tie below that we want to bind to
# a handle class, not scalar. It is not known if
@@ -1310,6 +1323,7 @@ sub _command_common_pipe {
tie (*ACPIPE, 'Git::activestate_pipe', $cmd, @args);
$fh = *ACPIPE;
+ chdir $cwd;
} else {
my $pid = open($fh, $direction);
if (not defined $pid) {
--
1.7.12.464.g83379df.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
[PATCH 4/7] perl/Git.pm: escape external command's arguments on Windows
From: Gustavo L. de M. Chaves gnust...@cpan.org
On Windows, the external git commands are invoked using backticks by
Git::activestate_pipe::TIEHANDLE, but there was no attempt to properly
quote their arguments. This caused problems with all but the simplest
command invokations.
The arguments are now surrounded by quotes and internal quotes are
doubled. This is not a complete quoting solution but takes care of
some of the most common problems on Windows.
Signed-off-by: Gustavo L. de M. Chaves gnust...@cpan.org
---
perl/Git.pm | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index ef3134b..42c3971 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1398,12 +1398,10 @@ use strict;
sub TIEHANDLE {
my ($class, @params) = @_;
- # FIXME: This is probably horrible idea and the thing will explode
- # at the moment you give it arguments that require some quoting,
- # but I have no ActiveState clue... --pasky
- # Let's just hope ActiveState Perl does at least the quoting
- # correctly.
- my @data = qx{git @params};
+ # FIXME: The quoting done below is not completely right but it
+ # should take care of the most common cases.
+ my @escaped_params = map { \$_\ } map { s///g; $_ } @params;
+ my @data = qx{git @escaped_params};
bless { i = 0, data = \@data, exit = $? }, $class;
}
--
1.7.12.464.g83379df.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
[PATCH 1/7] perl/Git.pm: test portably if a path is absolute
From: Gustavo L. de M. Chaves gnust...@cpan.org
The code was testing if a path was absolute by checking if its first
character was a '/'. This does not work on Windows.
The portable way to do it is to use File::Spec::file_name_is_absolute.
Signed-off-by: Gustavo L. de M. Chaves gnust...@cpan.org
---
perl/Git.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 931047c..658b602 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -185,7 +185,7 @@ sub repository {
};
if ($dir) {
- $dir =~ m#^/# or $dir = $opts{Directory} . '/' . $dir;
+ $dir = $opts{Directory} . '/' . $dir unless
File::Spec-file_name_is_absolute($dir);
$opts{Repository} = abs_path($dir);
# If --git-dir went ok, this shouldn't die either.
--
1.7.12.464.g83379df.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
[PATCH 7/7] perl/Git.pm: rename 'ActiveState' to 'Windows'
From: Gustavo L. de M. Chaves gnust...@cpan.org
Windows specific code was mentioning ActiveState Perl specifically,
but that code works with Strawberry Perl too.
Hence, we rename every instance of 'ActivePerl' to 'Windows' to convey
the more general idea.
Signed-off-by: Gustavo L. de M. Chaves gnust...@cpan.org
---
perl/Git.pm | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index fdef024..e03b82f 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1297,11 +1297,10 @@ sub _command_common_pipe {
my $fh;
if ($^O eq 'MSWin32') {
- # ActiveState Perl
#defined $opts{STDERR} and
- # warn 'ignoring STDERR option - running w/ ActiveState';
+ # warn 'ignoring STDERR option - running on Windows;
$direction eq '-|' or
- die 'input pipe for ActiveState not implemented';
+ die 'input pipe for Windows not implemented';
# Set up repo environment
local $ENV{GIT_DIR} = $self-repo_path() if defined $self
$self-repo_path();
@@ -1315,13 +1314,13 @@ sub _command_common_pipe {
chdir $self-wc_subdir() if $self-wc_subdir();
}
- # the strange construction with *ACPIPE is just to
+ # the strange construction with *WINPIPE is just to
# explain the tie below that we want to bind to
# a handle class, not scalar. It is not known if
- # it is something specific to ActiveState Perl or
+ # it is something specific to Perl on Windows or
# just a Perl quirk.
- tie (*ACPIPE, 'Git::activestate_pipe', $cmd, @args);
- $fh = *ACPIPE;
+ tie (*WINPIPE, 'Git::windows_pipe', $cmd, @args);
+ $fh = *WINPIPE;
chdir $cwd;
} else {
@@ -1391,9 +1390,9 @@ sub DESTROY {
}
-# Pipe implementation for ActiveState Perl.
+# Pipe implementation for Perl on Windows.
-package Git::activestate_pipe;
+package Git::windows_pipe;
use strict;
sub TIEHANDLE {
--
1.7.12.464.g83379df.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
Re: [PATCH v3 00/11] unify appending of sob
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. -- 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 add completion should exclude staged content
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 30/01/2013 15:06, Marc Khouzam ha scritto:
[...]
I will try to update the patch, with your latest suggestions (avoid
tricky POSIX shell syntax, and CDPATH issue - if I remember
correctly),
and with an update for the t/t9902-completion.sh test (that I
completely
missed).
Hi Manlio,
Hi.
I'm trying to update git-completion.tcsh to work properly with
your nice new completion feature. But I'm having trouble with
the missing '/' at the end of directories.
The new logic in git-completion.bash tells bash that 'filenames'
completion is ongoing so bash will add a '/' after directories.
Sadly, tcsh won't do that, so it would be simpler if
git-completion.bash added the '/' itself. I looked at the
git-completion.bash script changes and I noticed that for
bash version 4, you have to add the '/' yourself.
The compatible version is not only required for Bash; you can use it for
other shells.
Try to redefine the __git_index_file_list_filter function to use the
version that adds a slash to directory names.
I also noticed the following comment:
# XXX if we append a slash to directory names when using
# `compopt -o filenames`, Bash will append another slash.
# This is pretty stupid, and this the reason why we have to
# define a compatible version for this function.
So I gather you would rather add a '/' all the time to deal
with older bash version transparently. This would be great
for tcsh also. I'm trying to figure out
when bash mis-behaves when you add the '/' all the time?
When I try it (I have bash 4.1.5(1)-release) I didn't run
into the double slash problem you mention in the comment.
I'm using the same version: 4.1.5(1), on Debian stable.
I'm hoping we can straighten this out and have
git-completion.bash add the '/' all the time.
Could you explain when the problem happens?
Bash 4.1.5(1) always adds an additional slash for directories.
I have tested it right now: change the filter function to use the
compatible version:
__git_index_file_list_filter ()
{
# Default to Bash = 4.x
__git_index_file_list_filter_compat
}
Then running `git add TAB` inside the git repository, I get this file
completion list:
$ git add TAB
contrib//
Thanks
Thanks to you
Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEJZUMACgkQscQJ24LbaUQUGACgkMG/bZrJKBzlZ8toEQwmggQX
m9kAn2ATJbSp87kOkoCCc00eHmh71r3y
=D9iu
-END PGP SIGNATURE-
--
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
What's cooking in git.git (Jan 2013, #11; Wed, 30)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. As usual, this cycle is expected to last for 8 to 10 weeks, with a preview -rc0 sometime in the middle of next month. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * ab/gitweb-use-same-scheme (2013-01-28) 1 commit - gitweb: refer to picon/gravatar images over the same scheme Avoid mixed contents on a page coming via http and https when gitweb is hosted on a https server. Will merge to 'next'. * jk/python-styles (2013-01-29) 1 commit - CodingGuidelines: add Python coding guidelines Expecting a reroll. $gmane/215007. * mn/send-email-authinfo (2013-01-29) 1 commit - git-send-email: add ~/.authinfo parsing Expecting a reroll. $gmane/215004, $gmane/215024. * nd/edit-branch-desc-while-detached (2013-01-30) 1 commit (merged to 'next' on 2013-01-30 at 69307d6) + branch: no detached HEAD check when editing another branch's description (this branch is used by nd/branch-error-cases.) Attempt to branch --edit-description an existing branch, while being on a detached HEAD, errored out. Will merge to 'master'. -- [Graduated to master] * bc/fix-array-syntax-for-3.0-in-completion-bash (2013-01-18) 1 commit (merged to 'next' on 2013-01-25 at d113c1a) + git-completion.bash: replace zsh notation that breaks bash 3.X Fix use of an array notation that older versions of bash do not understand. * dl/am-hg-locale (2013-01-18) 1 commit (merged to 'next' on 2013-01-25 at 3419019) + am: invoke perl's strftime in C locale Datestamp recorded in Hg format patch was reformatted incorrectly to an e-mail looking date using locale dependant strftime, causing patch application to fail. * jc/help (2013-01-18) 1 commit (merged to 'next' on 2013-01-25 at b2b087e) + help: include common-cmds.h only in one file A header file that has the definition of a static array was included in two places, wasting the space. * nd/magic-pathspec-from-root (2013-01-21) 2 commits (merged to 'next' on 2013-01-25 at b056b57) + grep: avoid accepting ambiguous revision + Update :/abc ambiguity check When giving arguments without -- disambiguation, object names that come earlier on the command line must not be interpretable as pathspecs and pathspecs that come later on the command line must not be interpretable as object names. Tweak the disambiguation rule so that :/ (no other string before or after) is always interpreted as a pathspec, to avoid having to say git cmd -- :/. * rr/minimal-stat (2013-01-22) 1 commit (merged to 'next' on 2013-01-25 at 11c4453) + Enable minimal stat checking Some reimplementations of Git does not write all the stat info back to the index due to their implementation limitations (e.g. jgit running on Java). A configuration option can tell Git to ignore changes to most of the stat fields and only pay attention to mtime and size, which these implementations can reliably update. This avoids excessive revalidation of contents. * tb/t0050-maint (2013-01-21) 3 commits (merged to 'next' on 2013-01-25 at 682b1e2) + t0050: Use TAB for indentation + t0050: honor CASE_INSENSITIVE_FS in add (with different case) + t0050: known breakage vanished in merge (case change) Update tests that were expecting to fail due to a bug that was fixed earlier. -- [Stalled] * dg/subtree-fixes (2013-01-08) 7 commits - contrib/subtree: mkdir the manual directory if needed - contrib/subtree: honor $(DESTDIR) - contrib/subtree: fix synopsis and command help - contrib/subtree: better error handling for add - contrib/subtree: add --unannotate option - contrib/subtree: use %B for split Subject/Body - t7900: remove test number comments contrib/subtree updates; there are a few more from T. Zheng that were posted separately, with an overlap. Expecting a reroll. * mp/diff-algo-config (2013-01-16) 3 commits - diff: Introduce --diff-algorithm command line option - config: Introduce diff.algorithm variable - git-completion.bash: Autocomplete --minimal and --histogram for git-diff Add diff.algorithm configuration so that the user does not type diff --histogram. Looking better; may want tests to protect it from future breakages, but otherwise it looks ready for 'next'. Expecting a follow-up to add tests. * mb/gitweb-highlight-link-target (2012-12-20) 1 commit - Highlight the link target line in Gitweb using CSS Expecting a reroll. $gmane/211935 * jl/submodule-deinit (2012-12-04) 1 commit - submodule: add 'deinit' command There was no Porcelain way to say I no longer am interested in this submodule, once you express your
sha1 information is lacking or useless when rebasing with a submodule pointer conflict
I'm seeing what might be a bug that was introduced in git 1.7.12 (also observed in 1.8.1.2). If not a bug, it's a changed behavior from previous versions that I don't understand. Here's the scenario: * I have a remote repo containing a pointer to a submodule. * Developer A and Developer B clone this repo, and both make a commit to first the submodule, and then the parent repo, changing some files and also the submodule pointer at the same time. * Developer A pushes his changes to both the submodule and the parent module to the shared remote * Developer B either does a git pull --rebase or a git fetch git rebase origin/master Results: When applying Developer B's changes on top of origin/master, the following messages are observed: fatal: sha1 information is lacking or useless (sub). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Furthermore, an immediate git status reports all conflicts fixed, does not report the submodule pointer as unmerged, and the changes to the other files in the parent module made by Developer B are not applied. Expected Results: Similar to how 1.7.12.1 behaves. No mention of sha1 information or blobs being lacking. git status should report the submodule pointer and any other changed files as being unmerged. Conflicting changes should not be lost. I'm witnessing this behavior on OS X 10.8.2 with git versions 1.7.12, 1.7.12.1, and 1.8.1.2, installed via homebrew. I do not see this behavior in 1.7.11.5 or any of the 8 previous versions I've tried back to 1.7.4.1. Workaround: Using an interactive rebase (git fetch git rebase -i origin/master) with no changes made to the commit list seems to sidestep this behavior. Thanks in advance for any help with this. Reproduce script: Execute the following, then cd local-b; git pull --rebase #!/bin/sh set -e -v BASEDIR=`pwd` # Make bare remote repos mkdir remotes pushd remotes git init --bare super.git git init --bare sub.git popd # Initialize the submodule repo git clone --no-hardlinks remotes/sub.git sub pushd sub echo subfile subfile git add subfile git commit -m initial-submodule git push origin master popd rm -Rf sub # Clone into local-a and initialize supermodule repo git clone --no-hardlinks remotes/super.git local-a pushd local-a git submodule add $BASEDIR/remotes/sub.git sub echo file file git add sub file git commit -m initial git push origin master popd # Clone into local-b git clone --no-hardlinks remotes/super.git local-b pushd local-b git submodule init git submodule update popd # Make a change to supermodule file and submodule pointer from local-a and push to remote pushd local-a cd sub echo subfile changed from local-a subfile git add subfile git commit -m subfile-changed-from-local-a git push cd .. echo file changed from local-a file git add sub file git commit -m change-from-local-a git push popd # Make a conflicting change to both supermodule file and submodule pointer from local-b pushd local-b cd sub echo subfile changed from local-b subfile git add subfile git commit -m subfile-changed-from-local-b cd .. echo file changed from local-b file git add sub file git commit -m change-from-local-b popd -- 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 v3 0/8] Hiding refs
The third round. - Multi-valued variable transfer.hiderefs lists prefixes of ref hierarchies to be hidden from the requests coming over the network. - A configuration optionally allows uploadpack to accept fetch requests for an object at the tip of a hidden ref. Elsewhere, we discussed delaying ref advertisement (aka expand refs), but it is an orthogonal feature and this hiding refs completely from advertisement series does not attempt to address. Patch #2 (simplify request validation), #4 (clarify the codeflow), and #5 (use struct ref) are new. The are all long overdue clean-ups for these codepaths. The last patch is an illustration why it wouldn't make sense to optionally allow pushing into hidden refs, and not meant to be part of the series proper. For those who missed it, earlier rounds are at: http://thread.gmane.org/gmane.comp.version-control.git/213951 http://thread.gmane.org/gmane.comp.version-control.git/214888 Junio C Hamano (8): upload-pack: share more code upload-pack: simplify request validation upload/receive-pack: allow hiding ref hierarchies parse_fetch_refspec(): clarify the codeflow a bit fetch: use struct ref to represent refs to be fetched upload-pack: optionally allow fetching from the tips of hidden refs fetch: fetch objects by their exact SHA-1 object names WIP: receive.allowupdatestohidden Documentation/config.txt | 23 +++ builtin/fetch-pack.c | 40 +++ builtin/receive-pack.c | 31 +++ cache.h | 3 +- fetch-pack.c | 101 --- fetch-pack.h | 11 +++--- refs.c | 41 +++ refs.h | 3 ++ remote.c | 41 ++- remote.h | 1 + t/t5512-ls-remote.sh | 9 + t/t5516-fetch-push.sh| 82 ++ transport.c | 9 + upload-pack.c| 86 14 files changed, 374 insertions(+), 107 deletions(-) -- 1.8.1.2.589.ga9b91ac -- 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 v3 1/8] upload-pack: share more code
We mark the objects pointed at our refs with OUR_REF flag in two
functions (mark_our_ref() and send_ref()), but we can just use the
former as a helper for the latter.
Update the way mark_our_ref() prepares in-core object to use
lookup_unknown_object() to delay reading the actual object data,
just like we did in 435c833 (upload-pack: use peel_ref for ref
advertisements, 2012-10-04).
Signed-off-by: Junio C Hamano gits...@pobox.com
---
upload-pack.c | 31 ++-
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 95d8313..3dd220d 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -722,15 +722,28 @@ static void receive_needs(void)
free(shallows.objects);
}
+static int mark_our_ref(const char *refname, const unsigned char *sha1, int
flag, void *cb_data)
+{
+ struct object *o = lookup_unknown_object(sha1);
+ if (!o)
+ die(git upload-pack: cannot find object %s:,
sha1_to_hex(sha1));
+ if (!(o-flags OUR_REF)) {
+ o-flags |= OUR_REF;
+ nr_our_refs++;
+ }
+ return 0;
+}
+
static int send_ref(const char *refname, const unsigned char *sha1, int flag,
void *cb_data)
{
static const char *capabilities = multi_ack thin-pack side-band
side-band-64k ofs-delta shallow no-progress
include-tag multi_ack_detailed;
- struct object *o = lookup_unknown_object(sha1);
const char *refname_nons = strip_namespace(refname);
unsigned char peeled[20];
+ mark_our_ref(refname, sha1, flag, cb_data);
+
if (capabilities)
packet_write(1, %s %s%c%s%s agent=%s\n,
sha1_to_hex(sha1), refname_nons,
@@ -740,27 +753,11 @@ static int send_ref(const char *refname, const unsigned
char *sha1, int flag, vo
else
packet_write(1, %s %s\n, sha1_to_hex(sha1), refname_nons);
capabilities = NULL;
- if (!(o-flags OUR_REF)) {
- o-flags |= OUR_REF;
- nr_our_refs++;
- }
if (!peel_ref(refname, peeled))
packet_write(1, %s %s^{}\n, sha1_to_hex(peeled),
refname_nons);
return 0;
}
-static int mark_our_ref(const char *refname, const unsigned char *sha1, int
flag, void *cb_data)
-{
- struct object *o = parse_object(sha1);
- if (!o)
- die(git upload-pack: cannot find object %s:,
sha1_to_hex(sha1));
- if (!(o-flags OUR_REF)) {
- o-flags |= OUR_REF;
- nr_our_refs++;
- }
- return 0;
-}
-
static void upload_pack(void)
{
if (advertise_refs || !stateless_rpc) {
--
1.8.1.2.589.ga9b91ac
--
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 v3 3/8] upload/receive-pack: allow hiding ref hierarchies
Teach upload-pack and receive-pack to omit some refs from their
initial advertisements by paying attention to the transfer.hiderefs
multi-valued configuration variable. Any ref that is under the
hierarchies listed on the value of this variable is excluded from
responses to requests made by ls-remote, fetch, clone, push,
etc.
A typical use case may be
[transfer]
hiderefs = refs/pull
to hide the refs that are internally used by the hosting site and
should not be exposed over the network.
Because these hidden refs do not count as OUR_REF, an attempt to
fetch objects at the tip of them will be rejected, and because these
refs do not get advertised, git push : will not see local branches
that have the same name as them as matching ones to be sent.
An attempt to update/delete these hidden refs with an explicit
refspec, e.g. git push origin :refs/pull/11/head, is rejected.
This is not a new restriction. To the pusher, it would appear that
there is no such ref, so its push request will conclude with Now
that I sent you all the data, it is time for you to update the refs.
I saw that the ref did not exist when I started pushing, and I want
the result to point at this commit. The receiving end will apply
the compare-and-swap rule to this request and rejects the push with
Well, your update request conflicts with somebody else; I see there
is such a ref., which is the right thing to do. Otherwise a push to
a hidden ref will always be the last one wins, which is not a good
default.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/config.txt | 11 +++
builtin/receive-pack.c | 24
refs.c | 41 +
refs.h | 3 +++
t/t5512-ls-remote.sh | 9 +
t/t5516-fetch-push.sh| 24
upload-pack.c| 14 +-
7 files changed, 125 insertions(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ef45c99..f57c802 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2057,6 +2057,17 @@ transfer.fsckObjects::
not set, the value of this variable is used instead.
Defaults to false.
+transfer.hiderefs::
+ String(s) `upload-pack` and `receive-pack` use to decide
+ which refs to omit from their initial advertisement. Use
+ more than one transfer.hiderefs configuration variables to
+ specify multiple prefix strings. A ref that are under the
+ hierarchies listed on the value of this variable is excluded,
+ and is hidden from `git ls-remote`, `git fetch`, `git push :`,
+ etc. An attempt to update or delete a hidden ref by `git push`
+ is rejected, and an attempt to fetch a hidden ref by `git fetch`
+ will fail.
+
transfer.unpackLimit::
When `fetch.unpackLimit` or `receive.unpackLimit` are
not set, the value of this variable is used instead.
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index ff781fe..a8248d9 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -59,6 +59,11 @@ static enum deny_action parse_deny_action(const char *var,
const char *value)
static int receive_pack_config(const char *var, const char *value, void *cb)
{
+ int status = parse_hide_refs_config(var, value, cb);
+
+ if (status)
+ return status;
+
if (strcmp(var, receive.denydeletes) == 0) {
deny_deletes = git_config_bool(var, value);
return 0;
@@ -119,6 +124,9 @@ static int receive_pack_config(const char *var, const char
*value, void *cb)
static void show_ref(const char *path, const unsigned char *sha1)
{
+ if (ref_is_hidden(path))
+ return;
+
if (sent_capabilities)
packet_write(1, %s %s\n, sha1_to_hex(sha1), path);
else
@@ -688,6 +696,20 @@ static int iterate_receive_command_list(void *cb_data,
unsigned char sha1[20])
return -1; /* end of list */
}
+static void reject_updates_to_hidden(struct command *commands)
+{
+ struct command *cmd;
+
+ for (cmd = commands; cmd; cmd = cmd-next) {
+ if (cmd-error_string || !ref_is_hidden(cmd-ref_name))
+ continue;
+ if (is_null_sha1(cmd-new_sha1))
+ cmd-error_string = deny deleting a hidden ref;
+ else
+ cmd-error_string = deny updating a hidden ref;
+ }
+}
+
static void execute_commands(struct command *commands, const char
*unpacker_error)
{
struct command *cmd;
@@ -704,6 +726,8 @@ static void execute_commands(struct command *commands,
const char *unpacker_erro
0, cmd))
set_connectivity_errors(commands);
+ reject_updates_to_hidden(commands);
+
if (run_receive_hook(commands, pre_receive_hook, 0)) {
[PATCH v3 4/8] parse_fetch_refspec(): clarify the codeflow a bit
Most parts of the cascaded if/else if/... checked an allowable
condition but some checked forbidden conditions. This makes adding
new allowable conditions unnecessarily inconvenient.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
remote.c | 29 -
1 file changed, 12 insertions(+), 17 deletions(-)
diff --git a/remote.c b/remote.c
index 4b1153f..1b7828d 100644
--- a/remote.c
+++ b/remote.c
@@ -538,7 +538,7 @@ static struct refspec *parse_refspec_internal(int
nr_refspec, const char **refsp
/*
* Before going on, special case : (or +:) as a refspec
-* for matching refs.
+* for pushing matching refs.
*/
if (!fetch rhs == lhs rhs[1] == '\0') {
rs[i].matching = 1;
@@ -565,26 +565,21 @@ static struct refspec *parse_refspec_internal(int
nr_refspec, const char **refsp
flags = REFNAME_ALLOW_ONELEVEL | (is_glob ?
REFNAME_REFSPEC_PATTERN : 0);
if (fetch) {
- /*
-* LHS
-* - empty is allowed; it means HEAD.
-* - otherwise it must be a valid looking ref.
-*/
+ /* LHS */
if (!*rs[i].src)
- ; /* empty is ok */
- else if (check_refname_format(rs[i].src, flags))
+ ; /* empty is ok; it means HEAD */
+ else if (!check_refname_format(rs[i].src, flags))
+ ; /* valid looking ref is ok */
+ else
goto invalid;
- /*
-* RHS
-* - missing is ok, and is same as empty.
-* - empty is ok; it means not to store.
-* - otherwise it must be a valid looking ref.
-*/
+ /* RHS */
if (!rs[i].dst)
- ; /* ok */
+ ; /* missing is ok; it is the same as empty */
else if (!*rs[i].dst)
- ; /* ok */
- else if (check_refname_format(rs[i].dst, flags))
+ ; /* empty is ok; it means do not store */
+ else if (!check_refname_format(rs[i].dst, flags))
+ ; /* valid looking ref is ok */
+ else
goto invalid;
} else {
/*
--
1.8.1.2.589.ga9b91ac
--
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 v3 5/8] fetch: use struct ref to represent refs to be fetched
Even though git fetch has full infrastructure to parse refspecs to
be fetched and match them against the list of refs to come up with
the final list of refs to be fetched, the list of refs that are
requested to be fetched were internally converted to a plain list of
strings at the transport layer and then passed to the underlying
fetch-pack driver.
Stop this conversion and instead pass around an array of refs.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/fetch-pack.c | 40 --
cache.h | 3 +-
fetch-pack.c | 79 +++-
fetch-pack.h | 11
transport.c | 9 ++
5 files changed, 89 insertions(+), 53 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index 940ae35..cc6bf8f 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -7,12 +7,31 @@ static const char fetch_pack_usage[] =
[--include-tag] [--upload-pack=git-upload-pack] [--depth=n]
[--no-progress] [-v] [host:]directory [refs...];
+static void add_sought_entry_mem(struct ref ***sought, int *nr, int *alloc,
+const char *name, int namelen)
+{
+ struct ref *ref = xcalloc(1, sizeof(*ref) + namelen + 1);
+
+ memcpy(ref-name, name, namelen);
+ ref-name[namelen] = '\0';
+ (*nr)++;
+ ALLOC_GROW(*sought, *nr, *alloc);
+ (*sought)[*nr - 1] = ref;
+}
+
+static void add_sought_entry(struct ref ***sought, int *nr, int *alloc,
+const char *string)
+{
+ add_sought_entry_mem(sought, nr, alloc, string, strlen(string));
+}
+
int cmd_fetch_pack(int argc, const char **argv, const char *prefix)
{
int i, ret;
struct ref *ref = NULL;
const char *dest = NULL;
- struct string_list sought = STRING_LIST_INIT_DUP;
+ struct ref **sought;
+ int nr_sought = 0, alloc_sought = 0;
int fd[2];
char *pack_lockfile = NULL;
char **pack_lockfile_ptr = NULL;
@@ -94,7 +113,7 @@ int cmd_fetch_pack(int argc, const char **argv, const char
*prefix)
* refs from the standard input:
*/
for (; i argc; i++)
- string_list_append(sought, xstrdup(argv[i]));
+ add_sought_entry(sought, nr_sought, alloc_sought, argv[i]);
if (args.stdin_refs) {
if (args.stateless_rpc) {
/* in stateless RPC mode we use pkt-line to read
@@ -107,14 +126,14 @@ int cmd_fetch_pack(int argc, const char **argv, const
char *prefix)
break;
if (line[n-1] == '\n')
n--;
- string_list_append(sought, xmemdupz(line, n));
+ add_sought_entry_mem(sought, nr_sought,
alloc_sought, line, n);
}
}
else {
/* read from stdin one ref per line, until EOF */
struct strbuf line = STRBUF_INIT;
while (strbuf_getline(line, stdin, '\n') != EOF)
- string_list_append(sought,
strbuf_detach(line, NULL));
+ add_sought_entry(sought, nr_sought,
alloc_sought, line.buf);
strbuf_release(line);
}
}
@@ -131,7 +150,7 @@ int cmd_fetch_pack(int argc, const char **argv, const char
*prefix)
get_remote_heads(fd[0], ref, 0, NULL);
ref = fetch_pack(args, fd, conn, ref, dest,
-sought, pack_lockfile_ptr);
+sought, nr_sought, pack_lockfile_ptr);
if (pack_lockfile) {
printf(lock %s\n, pack_lockfile);
fflush(stdout);
@@ -141,7 +160,7 @@ int cmd_fetch_pack(int argc, const char **argv, const char
*prefix)
if (finish_connect(conn))
return 1;
- ret = !ref || sought.nr;
+ ret = !ref;
/*
* If the heads to pull were given, we should have consumed
@@ -149,8 +168,13 @@ int cmd_fetch_pack(int argc, const char **argv, const char
*prefix)
* remote no-such-ref' would silently succeed without issuing
* an error.
*/
- for (i = 0; i sought.nr; i++)
- error(no such remote ref %s, sought.items[i].string);
+ for (i = 0; i nr_sought; i++) {
+ if (!sought[i] || sought[i]-matched)
+ continue;
+ error(no such remote ref %s, sought[i]-name);
+ ret = 1;
+ }
+
while (ref) {
printf(%s %s\n,
sha1_to_hex(ref-old_sha1), ref-name);
diff --git a/cache.h b/cache.h
index c257953..03b3285 100644
--- a/cache.h
+++ b/cache.h
@@ -1013,7 +1013,8 @@ struct ref {
nonfastforward:1,
not_forwardable:1,
[PATCH v3 6/8] upload-pack: optionally allow fetching from the tips of hidden refs
With uploadpack.allowtipsha1inwant configuration option set, future
versions of git fetch that allow an exact object name (likely to
have been obtained out of band) on the LHS of the fetch refspec can
make a request with a want line that names an object that may not
have been advertised due to transfer.hiderefs configuration.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/config.txt | 8 +++-
upload-pack.c| 25 +++--
2 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index f57c802..2dce021 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2066,13 +2066,19 @@ transfer.hiderefs::
and is hidden from `git ls-remote`, `git fetch`, `git push :`,
etc. An attempt to update or delete a hidden ref by `git push`
is rejected, and an attempt to fetch a hidden ref by `git fetch`
- will fail.
+ will fail. See also `uploadpack.allowtipsha1inwant`.
transfer.unpackLimit::
When `fetch.unpackLimit` or `receive.unpackLimit` are
not set, the value of this variable is used instead.
The default value is 100.
+uploadpack.allowtipsha1inwant::
+ When `transfer.hiderefs` is in effect, allow `upload-pack`
+ to accept a fetch request that asks for an object at the tip
+ of a hidden ref (by default, such a request is rejected).
+ see also `transfer.hiderefs`.
+
url.base.insteadOf::
Any URL that starts with this value will be rewritten to
start, instead, with base. In cases where some site serves a
diff --git a/upload-pack.c b/upload-pack.c
index 6b10843..37977e2 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -26,6 +26,7 @@ static const char upload_pack_usage[] = git upload-pack
[--strict] [--timeout=
#define SHALLOW(1u 16)
#define NOT_SHALLOW(1u 17)
#define CLIENT_SHALLOW (1u 18)
+#define HIDDEN_REF (1u 19)
static unsigned long oldest_have;
@@ -33,6 +34,7 @@ static int multi_ack;
static int no_done;
static int use_thin_pack, use_ofs_delta, use_include_tag;
static int no_progress, daemon_mode;
+static int allow_tip_sha1_in_want;
static int shallow_nr;
static struct object_array have_obj;
static struct object_array want_obj;
@@ -487,6 +489,12 @@ static int get_common_commits(void)
}
}
+static int is_our_ref(struct object *o)
+{
+ return o-flags
+ ((allow_tip_sha1_in_want ? HIDDEN_REF : 0) | OUR_REF);
+}
+
static void check_non_tip(void)
{
static const char *argv[] = {
@@ -523,7 +531,7 @@ static void check_non_tip(void)
o = get_indexed_object(--i);
if (!o)
continue;
- if (!(o-flags OUR_REF))
+ if (!is_our_ref(o))
continue;
memcpy(namebuf + 1, sha1_to_hex(o-sha1), 40);
if (write_in_full(cmd.in, namebuf, 42) 0)
@@ -532,7 +540,7 @@ static void check_non_tip(void)
namebuf[40] = '\n';
for (i = 0; i want_obj.nr; i++) {
o = want_obj.objects[i].item;
- if (o-flags OUR_REF)
+ if (is_our_ref(o))
continue;
memcpy(namebuf, sha1_to_hex(o-sha1), 40);
if (write_in_full(cmd.in, namebuf, 41) 0)
@@ -566,7 +574,7 @@ error:
/* Pick one of them (we know there at least is one) */
for (i = 0; i want_obj.nr; i++) {
o = want_obj.objects[i].item;
- if (!(o-flags OUR_REF))
+ if (!is_our_ref(o))
die(git upload-pack: not our ref %s,
sha1_to_hex(o-sha1));
}
@@ -646,7 +654,7 @@ static void receive_needs(void)
sha1_to_hex(sha1_buf));
if (!(o-flags WANTED)) {
o-flags |= WANTED;
- if (!(o-flags OUR_REF))
+ if (!is_our_ref(o))
has_non_tip = 1;
add_object_array(o, NULL, want_obj);
}
@@ -725,8 +733,10 @@ static int mark_our_ref(const char *refname, const
unsigned char *sha1, int flag
{
struct object *o = lookup_unknown_object(sha1);
- if (ref_is_hidden(refname))
+ if (ref_is_hidden(refname)) {
+ o-flags |= HIDDEN_REF;
return 1;
+ }
if (!o)
die(git upload-pack: cannot find object %s:,
sha1_to_hex(sha1));
o-flags |= OUR_REF;
@@ -745,9 +755,10 @@ static int send_ref(const char *refname, const unsigned
char *sha1, int flag, vo
return 0;
if (capabilities)
- packet_write(1, %s %s%c%s%s agent=%s\n,
+ packet_write(1, %s %s%c%s%s%s agent=%s\n,
sha1_to_hex(sha1), refname_nons,
0,
RE: [feature request] git add completion should exclude staged content
-Original Message-
From: git-ow...@vger.kernel.org
[mailto:git-ow...@vger.kernel.org] On Behalf Of Manlio Perillo
Sent: Wednesday, January 30, 2013 1:24 PM
To: Marc Khouzam
Cc: 'Junio C Hamano'; 'Michael J Gruber'; 'wookietreiber';
'git@vger.kernel.org'
Subject: Re: [feature request] git add completion should
exclude staged content
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 30/01/2013 15:06, Marc Khouzam ha scritto:
[...]
I will try to update the patch, with your latest suggestions (avoid
tricky POSIX shell syntax, and CDPATH issue - if I remember
correctly),
and with an update for the t/t9902-completion.sh test (that I
completely
missed).
Hi Manlio,
Hi.
I'm trying to update git-completion.tcsh to work properly with
your nice new completion feature. But I'm having trouble with
the missing '/' at the end of directories.
The new logic in git-completion.bash tells bash that 'filenames'
completion is ongoing so bash will add a '/' after directories.
Sadly, tcsh won't do that, so it would be simpler if
git-completion.bash added the '/' itself. I looked at the
git-completion.bash script changes and I noticed that for
bash version 4, you have to add the '/' yourself.
The compatible version is not only required for Bash; you can
use it for
other shells.
Try to redefine the __git_index_file_list_filter function to use the
version that adds a slash to directory names.
I hadn't thought of that!
Although I would prefer not to have special cases like that,
it does work well.
Thanks!
I also noticed the following comment:
# XXX if we append a slash to directory names when using
# `compopt -o filenames`, Bash will append another slash.
# This is pretty stupid, and this the reason why we have to
# define a compatible version for this function.
So I gather you would rather add a '/' all the time to deal
with older bash version transparently. This would be great
for tcsh also. I'm trying to figure out
when bash mis-behaves when you add the '/' all the time?
When I try it (I have bash 4.1.5(1)-release) I didn't run
into the double slash problem you mention in the comment.
I'm using the same version: 4.1.5(1), on Debian stable.
I'm hoping we can straighten this out and have
git-completion.bash add the '/' all the time.
Could you explain when the problem happens?
Bash 4.1.5(1) always adds an additional slash for directories.
I have tested it right now: change the filter function to use the
compatible version:
__git_index_file_list_filter ()
{
# Default to Bash = 4.x
__git_index_file_list_filter_compat
}
Then running `git add TAB` inside the git repository, I get
this file
completion list:
$ git add TAB
contrib//
Ok, I see. The double-slash is visible in the completion list
but it does not appear on the command-line when bash automatically
adds it. So if you typed
git add contritab
you will properly get
git add contrib/
That is the case I was looking at.
I understand why you cannot put that second slash in the code now.
Thanks
Thanks
Thanks to you
Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEJZUMACgkQscQJ24LbaUQUGACgkMG/bZrJKBzlZ8toEQwmggQX
m9kAn2ATJbSp87kOkoCCc00eHmh71r3y
=D9iu
-END PGP SIGNATURE-
--
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: What's cooking in git.git (Jan 2013, #11; Wed, 30)
John Keeping j...@keeping.me.uk writes: On Wed, Jan 30, 2013 at 10:33:10AM -0800, Junio C Hamano wrote: [Discarded] * jk/update-install-for-p4 (2013-01-20) 1 commit . INSTALL: git-p4 doesn't support Python 3 Made obsolete by bc/git-p4-for-python-2.4 topic. I disagree with this - that branch doesn't change INSTALL to list not Python 3 in the supported versions. Brandon, would you mind doing s/2.4 or later/2.4 - 2.7/ on your branch? Thanks for being a careful reader. Let's do something like this on top of the topic. INSTALL | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/INSTALL b/INSTALL index b96e16d..2dc3b61 100644 --- a/INSTALL +++ b/INSTALL @@ -131,8 +131,9 @@ Issues of note: use English. Under autoconf the configure script will do this automatically if it can't find libintl on the system. - - Python version 2.4 or later is needed to use the git-p4 - interface to Perforce. + - Python version 2.4 or later (but not 3.x, which is not + supported by Perforce) is needed to use the git-p4 interface + to Perforce. - Some platform specific issues are dealt with Makefile rules, but depending on your specific installation, you may 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: What's cooking in git.git (Jan 2013, #11; Wed, 30)
On Wed, Jan 30, 2013 at 11:17:15AM -0800, Junio C Hamano wrote: Let's do something like this on top of the topic. This looks good to me. INSTALL | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/INSTALL b/INSTALL index b96e16d..2dc3b61 100644 --- a/INSTALL +++ b/INSTALL @@ -131,8 +131,9 @@ Issues of note: use English. Under autoconf the configure script will do this automatically if it can't find libintl on the system. - - Python version 2.4 or later is needed to use the git-p4 - interface to Perforce. + - Python version 2.4 or later (but not 3.x, which is not + supported by Perforce) is needed to use the git-p4 interface + to Perforce. - Some platform specific issues are dealt with Makefile rules, but depending on your specific installation, you may 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 -- 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] git_remote_helpers: remove GIT-PYTHON-VERSION upon clean
fadf8c7 (git_remote_helpers: force rebuild if python version changes, 2013-01-20) started using a marker file to keep track of the version of Python interpreter used for the last build, but forgot to remove it when asked to make clean. Signed-off-by: Junio C Hamano gits...@pobox.com --- git_remote_helpers/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git_remote_helpers/Makefile b/git_remote_helpers/Makefile index 0d2ae74..3d12232 100644 --- a/git_remote_helpers/Makefile +++ b/git_remote_helpers/Makefile @@ -42,4 +42,4 @@ instlibdir: $(pysetupfile) clean: $(QUIET)$(PYTHON_PATH) $(pysetupfile) $(QUIETSETUP) clean -a - $(RM) *.pyo *.pyc + $(RM) *.pyo *.pyc GIT-PYTHON-VERSION -- 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] fixup! mergetool--lib: add functions for finding available tools
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-mergetool--lib.sh | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 25631cd..b6ed2fa 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -34,9 +34,9 @@ show_tool_names () {
then
echo $preamble
preamble=
- shown_any=yes
fi
- printf %s%s\n $per_line_prefix $tool
+ shown_any=yes
+ printf %s%s\n $per_line_prefix $toolname
fi
done
test -n $shown_any
@@ -244,6 +244,7 @@ show_tool_help () {
tab=' ' av_shown= unav_shown=
+ cmd_name=${TOOL_MODE}tool
if show_tool_names 'mode_ok is_available' $tab$tab \
$tool_opt may be set to one of the following:
then
--
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
[PATCH 3/3] mergetool--lib: list user configured tools in '--tool-help'
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-mergetool--lib.sh | 41 -
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index b44a2c8..e338be5 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -20,9 +20,24 @@ is_available () {
type $merge_tool_path /dev/null 21
}
+list_config_tools () {
+ section=$1
+ line_prefix=${2:-}
+
+ git config --get-regexp $section'\..*\.cmd' |
+ while read -r key value
+ do
+ toolname=${key#$section.}
+ toolname=${toolname%.cmd}
+
+ printf %s%s\n $line_prefix $toolname
+ done
+}
+
show_tool_names () {
condition=${1:-true} per_line_prefix=${2:-} preamble=${3:-}
not_found_msg=${4:-}
+ extra_content=${5:-}
shown_any=
( cd $MERGE_TOOLS_DIR ls ) | {
@@ -41,6 +56,19 @@ show_tool_names () {
fi
done
+ if test -n $extra_content
+ then
+ if test -n $preamble
+ then
+ # Note: no '\n' here since we don't want a
+ # blank line if there is no initial content.
+ printf %s $preamble
+ preamble=
+ fi
+ shown_any=yes
+ printf \n%s\n $extra_content
+ fi
+
if test -n $preamble test -n $not_found_msg
then
printf %s\n $not_found_msg
@@ -255,9 +283,20 @@ show_tool_help () {
any_shown=no
cmd_name=${TOOL_MODE}tool
+ config_tools=$({
+ diff_mode list_config_tools difftool $tab$tab
+ list_config_tools mergetool $tab$tab
+ } | sort)
+ extra_content=
+ if test -n $config_tools
+ then
+ extra_content=${tab}user-defined:${LF}$config_tools
+ fi
+
show_tool_names 'mode_ok is_available' $tab$tab \
$tool_opt may be set to one of the following: \
- No suitable tool for 'git $cmd_name --tool=tool' found.
+ No suitable tool for 'git $cmd_name --tool=tool' found. \
+ $extra_content
any_shown=yes
show_tool_names 'mode_ok ! is_available' $tab$tab \
--
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: [BUG] incorrect search result returned when using git log with a future date parameter
Caspar Zhang cas...@casparzhang.com writes: A date parsing function should parse _all dates with correctly format_, despite if it's an old date, or the date in the future. When it is fed 2013-02-12, it is ambiguous and approxidate can and should use whatever heuristics (including rejection of future) to guess what the user wanted, but 2013-02-13 cannot be interpreted in any other way, so we should parse it as such. Patches welcome, as long as the fix does not make things worse for cases other than you observed. 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: [feature request] git add completion should exclude staged content
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 30/01/2013 19:55, Marc Khouzam ha scritto:
[...]
The new logic in git-completion.bash tells bash that 'filenames'
completion is ongoing so bash will add a '/' after directories.
Sadly, tcsh won't do that, so it would be simpler if
git-completion.bash added the '/' itself. I looked at the
git-completion.bash script changes and I noticed that for
bash version 4, you have to add the '/' yourself.
The compatible version is not only required for Bash; you can
use it for
other shells.
Try to redefine the __git_index_file_list_filter function to use the
version that adds a slash to directory names.
I hadn't thought of that!
Although I would prefer not to have special cases like that,
it does work well.
The zsh compatible code does something like this; this is the reason I
tried to do the same thing, in order to keep coding consistent.
[...]
Bash 4.1.5(1) always adds an additional slash for directories.
I have tested it right now: change the filter function to use the
compatible version:
__git_index_file_list_filter ()
{
# Default to Bash = 4.x
__git_index_file_list_filter_compat
}
Then running `git add TAB` inside the git repository, I get
this file
completion list:
$ git add TAB
contrib//
Ok, I see. The double-slash is visible in the completion list
but it does not appear on the command-line when bash automatically
adds it.
Right; that's why I wrote in the comment that Bash behaviour seems stupid.
But probably that comment should be remove or changed for the final
version of the patch; I'll leave that to a Bash expert.
[...]
Regards Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEJe0kACgkQscQJ24LbaUScGgCeMDDdprJMgnYtFzqnFQamhfvU
BikAniMkwbOEVkkomOd9G0m3KY44f/9O
=c8rC
-END PGP SIGNATURE-
--
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] mergetool: add user configured commands to '--tool-help'
The first couple of these are fixups to da/mergetool-docs. I think the first one's obvious, but the second one should possible be changed into an incremental patch on top. I did it this way for now since that patch is basically my comments in [1] in patch form. The final patch adds tools from git-config to the '--tool-help' output. [1] http://article.gmane.org/gmane.comp.version-control.git/214964 John Keeping (3): fixup! mergetool--lib: add functions for finding available tools fixup! doc: generate a list of valid merge tools mergetool--lib: list user configured tools in '--tool-help' git-mergetool--lib.sh | 82 +++ 1 file changed, 63 insertions(+), 19 deletions(-) -- 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
[PATCH 2/3] fixup! doc: generate a list of valid merge tools
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-mergetool--lib.sh | 40 ++--
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index b6ed2fa..b44a2c8 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -22,6 +22,7 @@ is_available () {
show_tool_names () {
condition=${1:-true} per_line_prefix=${2:-} preamble=${3:-}
+ not_found_msg=${4:-}
shown_any=
( cd $MERGE_TOOLS_DIR ls ) | {
@@ -32,13 +33,19 @@ show_tool_names () {
then
if test -n $preamble
then
- echo $preamble
+ printf %s\n $preamble
preamble=
fi
shown_any=yes
printf %s%s\n $per_line_prefix $toolname
fi
done
+
+ if test -n $preamble test -n $not_found_msg
+ then
+ printf %s\n $not_found_msg
+ fi
+
test -n $shown_any
}
}
@@ -242,30 +249,27 @@ list_merge_tool_candidates () {
show_tool_help () {
tool_opt='git ${TOOL_MODE}tool --tool-tool'
- tab=' ' av_shown= unav_shown=
+ tab=' '
+ LF='
+'
+ any_shown=no
cmd_name=${TOOL_MODE}tool
- if show_tool_names 'mode_ok is_available' $tab$tab \
- $tool_opt may be set to one of the following:
- then
- av_shown=yes
- else
- echo No suitable tool for 'git $cmd_name --tool=tool' found.
- av_shown=no
- fi
+ show_tool_names 'mode_ok is_available' $tab$tab \
+ $tool_opt may be set to one of the following: \
+ No suitable tool for 'git $cmd_name --tool=tool' found.
+ any_shown=yes
- if show_tool_names 'mode_ok ! is_available' $tab$tab \
- The following tools are valid, but not currently available:
- then
- unav_shown=yes
- fi
+ show_tool_names 'mode_ok ! is_available' $tab$tab \
+ ${LF}The following tools are valid, but not currently
available:
+ any_shown=yes
- case ,$av_shown,$unav_shown, in
- *,yes,*)
+ if test $any_shown = yes
+ then
echo
echo Some of the tools listed above only work in a windowed
echo environment. If run in a terminal-only session, they will
fail.
- esac
+ fi
exit 0
}
--
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] git_remote_helpers: remove GIT-PYTHON-VERSION upon clean
On Wed, Jan 30, 2013 at 11:30:10AM -0800, Junio C Hamano wrote: fadf8c7 (git_remote_helpers: force rebuild if python version changes, 2013-01-20) started using a marker file to keep track of the version of Python interpreter used for the last build, but forgot to remove it when asked to make clean. Signed-off-by: Junio C Hamano gits...@pobox.com Looks obviously correct to me. Sorry for missing this at the time. FWIW: Reviewed-by: John Keeping j...@keeping.me.uk --- git_remote_helpers/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git_remote_helpers/Makefile b/git_remote_helpers/Makefile index 0d2ae74..3d12232 100644 --- a/git_remote_helpers/Makefile +++ b/git_remote_helpers/Makefile @@ -42,4 +42,4 @@ instlibdir: $(pysetupfile) clean: $(QUIET)$(PYTHON_PATH) $(pysetupfile) $(QUIETSETUP) clean -a - $(RM) *.pyo *.pyc + $(RM) *.pyo *.pyc GIT-PYTHON-VERSION -- 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-remote-helpers.txt: should it be gitremote-helpers.txt?
Max Horn's email today prompted me to try reading the git-remote-helpers man page, so I tried: $ git help remote-helpers No manual entry for gitremote-helpers But man git-remote-helpers does work. It turns out that builtin/help.c maps its argument to a page by prepending git- if given the name of a Git command and git otherwise. Does this mean that git-remote-helpers.txt should lose the first hyphen or is help.c not being clever enough in some way? 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 1/3] fixup! mergetool--lib: add functions for finding available tools
John Keeping j...@keeping.me.uk writes:
Signed-off-by: John Keeping j...@keeping.me.uk
---
git-mergetool--lib.sh | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Thanks.
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 25631cd..b6ed2fa 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -34,9 +34,9 @@ show_tool_names () {
then
echo $preamble
preamble=
- shown_any=yes
fi
- printf %s%s\n $per_line_prefix $tool
+ shown_any=yes
+ printf %s%s\n $per_line_prefix $toolname
Thanks for spotting s/tool/toolname/; does the change to shown_any
matter, though?
fi
done
test -n $shown_any
@@ -244,6 +244,7 @@ show_tool_help () {
tab=' ' av_shown= unav_shown=
+ cmd_name=${TOOL_MODE}tool
if show_tool_names 'mode_ok is_available' $tab$tab \
$tool_opt may be set to one of the following:
then
--
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-remote-helpers.txt: should it be gitremote-helpers.txt?
John Keeping j...@keeping.me.uk writes: Max Horn's email today prompted me to try reading the git-remote-helpers man page, so I tried: $ git help remote-helpers No manual entry for gitremote-helpers But man git-remote-helpers does work. It turns out that builtin/help.c maps its argument to a page by prepending git- if given the name of a Git command and git otherwise. 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. -- 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] fixup! mergetool--lib: add functions for finding available tools
On Wed, Jan 30, 2013 at 12:23:34PM -0800, Junio C Hamano wrote:
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 25631cd..b6ed2fa 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -34,9 +34,9 @@ show_tool_names () {
then
echo $preamble
preamble=
- shown_any=yes
fi
- printf %s%s\n $per_line_prefix $tool
+ shown_any=yes
+ printf %s%s\n $per_line_prefix $toolname
Thanks for spotting s/tool/toolname/; does the change to shown_any
matter, though?
Not really since we don't call it with an empty $preamble but if
something ever did then this ensures that shown_any is set correctly.
The $tool - $toolname doesn't really matter either since setup_tool
sets it as a global variable, but I'd rather not rely on that.
fi
done
test -n $shown_any
@@ -244,6 +244,7 @@ show_tool_help () {
tab=' ' av_shown= unav_shown=
+ cmd_name=${TOOL_MODE}tool
if show_tool_names 'mode_ok is_available' $tab$tab \
$tool_opt may be set to one of the following:
then
--
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 v3] CodingGuidelines: add Python coding guidelines
These are kept short by simply deferring to PEP-8. Most of the Python code in Git is already very close to this style (some things in contrib/ are not). Rationale for version suggestions: - Amongst the noise in [1], there isn't any disagreement about using 2.6 as a base (see also [2]), although Brandon Casey recently added support for 2.4 and 2.5 to git-p4 [3]. - Restricting ourselves to 2.6+ makes aiming for Python 3 compatibility significantly easier [4]. - Advocating Python 3 support in all scripts is currently unrealistic because: - 'p4 -G' provides output in a format that is very hard to use with Python 3 (and its documentation claims Python 3 is unsupported). - Mercurial does not support Python 3. - Bazaar does not support Python 3. - But we should try to make new scripts compatible with Python 3 because all new Python development is happening on version 3 and the Python community will eventually stop supporting Python 2 [5]. - Python 3.1 is required to support the 'surrogateescape' error handler for encoding/decodng filenames to/from Unicode strings and Python 3.0 is not longer supported. [1] http://thread.gmane.org/gmane.comp.version-control.git/210329 [2] http://article.gmane.org/gmane.comp.version-control.git/210429 [3] http://thread.gmane.org/gmane.comp.version-control.git/214579 [4] http://docs.python.org/3.3/howto/pyporting.html#try-to-support-python-2-6-and-newer-only [5] http://www.python.org/dev/peps/pep-0404/ --- Changes since v2: - Tone down discussion of the byte string prefix. - Change is supported since to has been supported since. Documentation/CodingGuidelines | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 69f7e9b..432c6cd 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -179,6 +179,20 @@ For C programs: - Use Git's gettext wrappers to make the user interface translatable. See Marking strings for translation in po/README. +For Python scripts: + + - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/). + + - As a minimum, we aim to be compatible with Python 2.6 and 2.7. + + - Where required libraries do not restrict us to Python 2, we try to + also be compatible with Python 3.1 and later. + + - When you must differentiate between Unicode literals and byte string + literals, it is OK to use the 'b' prefix. Even though the Python + documentation for version 2.6 does not mention this prefix, it has + been supported since version 2.6.0. + Writing Documentation: Every user-visible change should be reflected in the documentation. -- 1.8.1.2.633.gbba9ccc -- 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
Hi, On Wed, Jan 30, 2013 at 12:43:31PM -0600, Michael Sims wrote: I'm seeing what might be a bug that was introduced in git 1.7.12 (also observed in 1.8.1.2). If not a bug, it's a changed behavior from previous versions that I don't understand. Here's the scenario: * I have a remote repo containing a pointer to a submodule. * Developer A and Developer B clone this repo, and both make a commit to first the submodule, and then the parent repo, changing some files and also the submodule pointer at the same time. * Developer A pushes his changes to both the submodule and the parent module to the shared remote * Developer B either does a git pull --rebase or a git fetch git rebase origin/master Thanks for the detailed bug report and the demo script. I can reproduce the behavior here and will have a look into it. The submodule should be marked as conflict. Cheers Heiko -- 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: [BUG] incorrect search result returned when using git log with a future date parameter
Junio C Hamano wrote: When it is fed 2013-02-12, it is ambiguous and approxidate can and should use whatever heuristics (including rejection of future) to guess what the user wanted, but 2013-02-13 cannot be interpreted in any other way, so we should parse it as such. FWIW, if you said 02/12/2013, I'd agree, but I've never seen someone using 2013-02-12 to mean December 2. So that suggests another possible tweak on top. :) 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: [BUG] incorrect search result returned when using git log with a future date parameter
Jonathan Nieder jrnie...@gmail.com writes: When it is fed 2013-02-12, it is ambiguous and approxidate can and should use whatever heuristics (including rejection of future) to guess what the user wanted, but 2013-02-13 cannot be interpreted in any other way, so we should parse it as such. FWIW, if you said 02/12/2013, I'd agree, but I've never seen someone using 2013-02-12 to mean December 2. So that suggests another possible tweak on top. :) I think in the original context that triggered the be more friendly to Europeans discussion long time ago, some correlations between the delimiting characters (i.e. '-xx-xx' vs '.xx.xx' vs '/xx/xx') and month-day ordering convention. I do not recall if we actually added that as a signal when disambiguating, though. -- 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: sha1 information is lacking or useless when rebasing with a submodule pointer conflict
Hi, On Wed, Jan 30, 2013 at 10:56:15PM +0100, Heiko Voigt wrote: On Wed, Jan 30, 2013 at 12:43:31PM -0600, Michael Sims wrote: I'm seeing what might be a bug that was introduced in git 1.7.12 (also observed in 1.8.1.2). If not a bug, it's a changed behavior from previous versions that I don't understand. Here's the scenario: * I have a remote repo containing a pointer to a submodule. * Developer A and Developer B clone this repo, and both make a commit to first the submodule, and then the parent repo, changing some files and also the submodule pointer at the same time. * Developer A pushes his changes to both the submodule and the parent module to the shared remote * Developer B either does a git pull --rebase or a git fetch git rebase origin/master Thanks for the detailed bug report and the demo script. I can reproduce the behavior here and will have a look into it. The submodule should be marked as conflict. Bisect identified the following commit: commit a230949409f4a650c6a1a9a5879e2a8b993ba695 (HEAD) Author: Martin von Zweigbergk martin.von.zweigbe...@gmail.com Date: Tue Jun 26 07:51:56 2012 -0700 am --rebasing: get patch body from commit, not from mailbox Rebasing a commit that contains a diff in the commit message results in a failure with output such as First, rewinding head to replay your work on top of it... Applying: My cool patch. fatal: sha1 information is lacking or useless (app/controllers/settings_controller.rb). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 My cool patch. The reason is that 'git rebase' without -p/-i/-m internally calls 'git format-patch' and pipes the output to 'git am --rebasing', which has no way of knowing what is a real patch and what is a commit message that contains a patch. Make 'git am' while in --rebasing mode get the patch body from the commit object instead of extracting it from the mailbox. Patch by Junio, test case and commit log message by Martin. Reported-by: anikey arty.ani...@gmail.com Helped-by: Junio C Hamano gits...@pobox.com Signed-off-by: Martin von Zweigbergk martin.von.zweigbe...@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.com 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. Cheers Heiko -- 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: Anybody know a website with up-to-date git documentation?
On Wed, Jan 30, 2013 at 09:18:24AM -0800, Junio C Hamano wrote:
Max Horn m...@quendi.de writes:
[administrivia: please wrap lines to a reasonable width]
Curiously, gmail's web interface appears to have started doing
this only recently. I've noticed it when trying to respond to
others too.
On 30.01.2013, at 16:59, Sitaram Chamarty wrote:
I'm curious... what's wrong with 'git checkout html' from the git repo
and just browsing them using a web browser?
Hm, do you mean make html, perhaps? At least I couldn't figure
out what git checkout html should do, but out of curiosity gave
it a try and got an error...
Perhaps some information from A note from the maintainer (posted
to this list from time to time) is lacking. Some excerpts:
You can browse the HTML manual pages at:
http://git-htmldocs.googlecode.com/git/git.html
Preformatted documentation from the tip of the master branch can be
found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
...
Armed with that knowledge, I think Sitaram may have something like
this:
[remote htmldocs]
url = git://git.kernel.org/pub/scm/git/git-htmldocs.git/
fetch = +refs/heads/master:refs/heads/html
and does
git fetch htmldocs
git checkout html
Hmm; I don't recall ever doing that. But I just realised that
my html branch is stuck at 1.7.7:
$ git branch -v -v | grep html
html 8fb66e5 [origin/html] Autogenerated HTML docs for
v1.7.7-138-g7f41b6
Is it possible that upto that point, the main git.git repo did
carry this branch also? I have 3 remotes:
$ git remote -v
gc https://code.google.com/p/git-core (fetch)
gc https://code.google.com/p/git-core (push)
ghgit git://github.com/git/git.git (fetch)
ghgit git://github.com/git/git.git (push)
origin git://git.kernel.org/pub/scm/git/git.git (fetch)
origin git://git.kernel.org/pub/scm/git/git.git (push)
and all 3 of them carry this branch:
$ git branch -a -v -v | grep html
html 8fb66e5 [origin/html] Autogenerated HTML docs for
v1.7.7-138-g7f41b6
remotes/gc/html 8fb66e5 Autogenerated HTML docs for
v1.7.7-138-g7f41b6
remotes/ghgit/html8fb66e5 Autogenerated HTML docs for
v1.7.7-138-g7f41b6
remotes/origin/html 8fb66e5 Autogenerated HTML docs for
v1.7.7-138-g7f41b6
Even if I had, at one point, added a remote specifically for
html, I am sure it could not have created those refs!
So I tried a prune:
$ git remote update --prune
Fetching origin
x [deleted] (none) - origin/html
x [deleted] (none) - origin/man
Fetching ghgit
x [deleted] (none) - ghgit/html
x [deleted] (none) - ghgit/man
Fetching gc
x [deleted] (none) - gc/html
x [deleted] (none) - gc/man
and now I'm on par with the rest of you ;-)
You can, too, of course ;-)
You can do even more! If you don't find a suitable website for
this, it's trivial to host it yourself. You can host it on your
intranet, if you have one.
--
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. am -3 has never worked on a patch that describes changes to any non-blobs; the underlyihng apply --fake-ancestor is not prepared to see anything other than blobs. -- 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://.
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. 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
Segmentation fault with latest git (070c57df)
Hi all,
Looks like following commit causes a segmentation fault in my machine (when
running git pull or git fetch);
commit 8dd5afc926acb9829ebf56e9b78826a5242cd638
Author: Junio C Hamano gits...@pobox.com
Date: Mon Jan 7 12:24:55 2013 -0800
string-list: allow case-insensitive string list
In my case, list-cmp (at get_entry_index() function) has an invalid address,
obviously not an address of string comparision function, instead it points to 1.
Regards,
Jongman
Heo.N떑꿩�r툤y鉉싕b쾊Ф푤v�^�)頻{.n�+돴젇碼�썳變}찠꼿쟺�j:+v돣�쳭喩zZ+�+zf＂톒쉱�~넮녬i鎬z� 췿ⅱ�?솳鈺��)刪f
[PATCH 0/3] GPG running out of pipes fixes
While running --show-signatures on the linux kernel I noticed that after a while git failed with an error message indicating it had run out of file descriptors. The first patch fixes this problem, and the next two are randmom bits since I was in the area. Stephen Boyd (3): gpg: Close stderr once finished with it in verify_signed_buffer() run-command: Be more informative about what failed gpg: Allow translation of more error messages gpg-interface.c | 8 +--- run-command.c | 8 ++-- 2 files changed, 11 insertions(+), 5 deletions(-) -- 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
[PATCH 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. Signed-off-by: Stephen Boyd sb...@codeaurora.org --- gpg-interface.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gpg-interface.c b/gpg-interface.c index 0863c61..2c0bed3 100644 --- a/gpg-interface.c +++ b/gpg-interface.c @@ -133,6 +133,8 @@ int verify_signed_buffer(const char *payload, size_t payload_size, if (gpg_output) strbuf_read(gpg_output, gpg.err, 0); ret = finish_command(gpg); + if (gpg_output) + close(gpg.err); 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
[PATCH 3/3] gpg: Allow translation of more error messages
Mark these strings for translation so that error messages are
printed in the user's language of choice.
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
gpg-interface.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gpg-interface.c b/gpg-interface.c
index 2c0bed3..474c037 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -109,10 +109,10 @@ int verify_signed_buffer(const char *payload, size_t
payload_size,
args_gpg[0] = gpg_program;
fd = git_mkstemp(path, PATH_MAX, .git_vtag_tmpXX);
if (fd 0)
- return error(could not create temporary file '%s': %s,
+ return error(_(could not create temporary file '%s': %s),
path, strerror(errno));
if (write_in_full(fd, signature, signature_size) 0)
- return error(failed writing detached signature to '%s': %s,
+ return error(_(failed writing detached signature to '%s': %s),
path, strerror(errno));
close(fd);
@@ -124,7 +124,7 @@ int verify_signed_buffer(const char *payload, size_t
payload_size,
args_gpg[2] = path;
if (start_command(gpg)) {
unlink(path);
- return error(could not run gpg.);
+ return error(_(could not run gpg.));
}
write_in_full(gpg.in, payload, payload_size);
--
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
[PATCH 2/3] run-command: Be more informative about what failed
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. Print which pipe failed to be created in the error message so we can more easily debug similar problems in the future. For example, the above error now prints: error: cannot create stderr pipe for gpg: Too many open files error: could not run gpg. 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; } -- 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
[PATCH 0/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.
During a build/install cycle of the current HEAD whilst attempting to identify the cause of a bug in git version 1.8.0.3 whilst doing: GIT_CURL_VERBOSE=1 git clone -v https://git01.codeplex.com/typescript * GnuTLS recv error (-9): A TLS packet with unexpected length was received. * Closing connection #0 error: RPC failed; result=56, HTTP code = 200 I hit a local install failure whilst installing to the prefix /usr/local/ where the $(INSTALL) command reported a Permission Denied error. This was due to the $(INSTALL) modes being 755/644 but the file-system modes being 775/664. In this case ownership and permissions are: $ ls -ald /usr/local drwxrwxr-x 13 root adm 4096 Sep 26 04:16 /usr/local Users belonging to the 'adm' group have permission to install local packages. The fix I've implemented is to convert the hard-coded 755/644 modes to variables which can be over-ridden on the make command-line if necessary. -- 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/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.
Installation would fail if the target location had anything other than 755/644 file permissions. Therefore replace the hard-coded modes for each $(INSTALL) with variables. Default values are 755/644 but can be over-ridden on the make command line e.g. make INSTALL_MODE_EXECUTABLE=755 INSTALL_MODE_DATA=644 install. Signed-off-by: TJ g...@iam.tj --- Documentation/Makefile | 20 ++-- Makefile | 17 +++-- contrib/emacs/Makefile | 2 +- contrib/subtree/Makefile | 4 ++-- git-gui/Makefile | 12 ++-- gitk-git/Makefile| 6 +++--- gitweb/Makefile | 8 templates/Makefile | 2 +- 8 files changed, 38 insertions(+), 33 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 971977b..913928c 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -190,16 +190,16 @@ pdf: user-manual.pdf install: install-man install-man: man - $(INSTALL) -d -m 755 $(DESTDIR)$(man1dir) - $(INSTALL) -d -m 755 $(DESTDIR)$(man5dir) - $(INSTALL) -d -m 755 $(DESTDIR)$(man7dir) - $(INSTALL) -m 644 $(DOC_MAN1) $(DESTDIR)$(man1dir) - $(INSTALL) -m 644 $(DOC_MAN5) $(DESTDIR)$(man5dir) - $(INSTALL) -m 644 $(DOC_MAN7) $(DESTDIR)$(man7dir) + $(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) install-info: info - $(INSTALL) -d -m 755 $(DESTDIR)$(infodir) - $(INSTALL) -m 644 git.info gitman.info $(DESTDIR)$(infodir) + $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(infodir) + $(INSTALL) -m $(INSTALL_MODE_DATA) git.info gitman.info $(DESTDIR)$(infodir) if test -r $(DESTDIR)$(infodir)/dir; then \ $(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) git.info ;\ $(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) gitman.info ;\ @@ -208,8 +208,8 @@ install-info: info fi install-pdf: pdf - $(INSTALL) -d -m 755 $(DESTDIR)$(pdfdir) - $(INSTALL) -m 644 user-manual.pdf $(DESTDIR)$(pdfdir) + $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(pdfdir) + $(INSTALL) -m $(INSTALL_MODE_DATA) user-manual.pdf $(DESTDIR)$(pdfdir) install-html: html '$(SHELL_PATH_SQ)' ./install-webdoc.sh $(DESTDIR)$(htmldir) diff --git a/Makefile b/Makefile index 731b6a8..7a59202 100644 --- a/Makefile +++ b/Makefile @@ -354,6 +354,11 @@ ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS) ALL_LDFLAGS = $(LDFLAGS) STRIP ?= strip +# default installation file modes. Can be overridden from the 'make' command-line. +# E.g. For allowing group write: make INSTALL_MODE_EXECUTABLE=775 install +INSTALL_MODE_EXECUTABLE = 755 +INSTALL_MODE_DATA = 644 + # Among the variables below, these: # gitexecdir # template_dir @@ -2257,16 +2262,16 @@ mergetools_instdir_SQ = $(subst ','\'',$(mergetools_instdir)) install_bindir_programs := $(patsubst %,%$X,$(BINDIR_PROGRAMS_NEED_X)) $(BINDIR_PROGRAMS_NO_X) install: all - $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)' - $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' + $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(bindir_SQ)' + $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' - $(INSTALL) -m 644 $(SCRIPT_LIB) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' + $(INSTALL) -m $(INSTALL_MODE_DATA) $(SCRIPT_LIB) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' $(INSTALL) $(install_bindir_programs) '$(DESTDIR_SQ)$(bindir_SQ)' $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install - $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(mergetools_instdir_SQ)' - $(INSTALL) -m 644 mergetools/* '$(DESTDIR_SQ)$(mergetools_instdir_SQ)' + $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(mergetools_instdir_SQ)' + $(INSTALL) -m $(INSTALL_MODE_DATA) mergetools/* '$(DESTDIR_SQ)$(mergetools_instdir_SQ)' ifndef NO_GETTEXT - $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(localedir_SQ)' + $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(localedir_SQ)' (cd po/build/locale $(TAR) cf - .) | \ (cd '$(DESTDIR_SQ)$(localedir_SQ)' umask 022 $(TAR) xof -) endif diff --git a/contrib/emacs/Makefile b/contrib/emacs/Makefile index 24d9312..a405744 100644 --- a/contrib/emacs/Makefile +++ b/contrib/emacs/Makefile @@ -4,7 +4,7 @@ EMACS = emacs ELC = git.elc git-blame.elc INSTALL ?= install -INSTALL_ELC = $(INSTALL) -m 644 +INSTALL_ELC = $(INSTALL) -m $(INSTALL_MODE_DATA) prefix ?= $(HOME) emacsdir =
Re: [PATCH 1/3] gpg: Close stderr once finished with it in verify_signed_buffer()
On Wed, Jan 30, 2013 at 06:01:04PM -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.
I was able to easily reproduce the bug and verify your fix here.
diff --git a/gpg-interface.c b/gpg-interface.c
index 0863c61..2c0bed3 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -133,6 +133,8 @@ int verify_signed_buffer(const char *payload, size_t
payload_size,
if (gpg_output)
strbuf_read(gpg_output, gpg.err, 0);
ret = finish_command(gpg);
+ if (gpg_output)
+ close(gpg.err);
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.
-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?
Thanks, Andrew. you said: --have the server reject commits that have the 'committer' set to someone other then the authenticated user but I don't know how to do that? Our central repository is hosted by apache, and there are some username and passwords saved by apache to authentication valid user, but as I know, there are no relation between the apache username and the git client user ino (saved in .gitconfig), so can you describe some detail? Regards, Scott Yan On Thu, Jan 31, 2013 at 1:56 PM, Andrew Ardill andrew.ard...@gmail.com wrote: On 31 January 2013 16:52, Scott Yan scottya...@gmail.com wrote: The user info of git client (user name and email) is set by the users themselves, so , how to avoid userA pretend to be userB? Git server could authentication the user, but it do nothing about the user info of commit message. The simplest thing is to have the server reject commits that have the 'committer' set to someone other then the authenticated user. Of course, there are potential workflows that this would cause problems for, such as if you sync directly to another user's repository and then try and push those to a central server. The most robust system would probably involve using signed tags to verify what is being pushed, however I am not aware of any set-ups that have done this yet. Regards, Andrew Ardill -- 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 Thu, 31 Jan 2013 13:52:32 +0800, Scott Yan scottya...@gmail.com wrote: Hello everyone: The user info of git client (user name and email) is set by the users themselves, so , how to avoid userA pretend to be userB? Git server could authentication the user, but it do nothing about the user info of commit message. For example: There are 20 people of my team, and everyone can push to the public repository(git server), If I found some backdoor code in my project, and the commit record shows it was committed by userA, so I ask userA: why do you do this? but he told me: no, this is not my code, I have never committed such thing. and yes, everyone could change his user info to userA very easily . so... what should I do to avoid such situations? gitolite keeps a log of which SSH user pushed which commits. The smart-http backend does the same if you have reflog enabled on the server (see the ENVIRONMENT section in man git-http-backend). So unless someone can steal userA's credentials (http password, ssh key) you'll be able to detect who it really was. -- 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?
(resending previous response. Forgot to turn off HTML, and apprently gmail doesn't wrap lines automatically anymore?) On 31 January 2013 16:52, Scott Yan scottya...@gmail.com wrote: The user info of git client (user name and email) is set by the users themselves, so , how to avoid userA pretend to be userB? Git server could authentication the user, but it do nothing about the user info of commit message. The simplest thing is to have the server reject commits that have the 'committer' set to someone other then the authenticated user. Of course, there are potential workflows that this would cause problems for, such as if you sync directly to another user's repository and then try and push those to a central server. The most robust system would probably involve using signed tags to verify what is being pushed, however I am not aware of any set-ups that have done this yet. Regards, Andrew Ardill -- 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/2] improve git branch --contains=commit pattern
On Wed, Jan 30, 2013 at 07:57:03PM +0100, Peter Wu wrote: Hi, I was trying to check whether a certain branch contained a commit and ran: git branch --contains ddc150f7a33ae0c9cb16eaac3641abc00f56316f master This resulted in: fatal: A branch named 'master' already exists. When name does not exist, this command creates a branch. I expect this command to search the mentioned branch, not trying to create it. The manual page of git-branch(1) does not mention such special behavior either. Yeah, it's sort-of a bug. It is a syntactic ambiguity that an argument to git-branch could be a listing pattern or a new branch name. When using a listing pattern, you need to explicitly specify that you want list mode with `--list`. This is documented in git-branch under --list, but it should be more prominent, in the section that covers the various invocation modes. The first patch below fixes that. 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 -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
[PATCH 1/2] docs: clarify git-branch --list behavior
It was not clear from the description section of git-branch(1) that using a pattern meant that you _had_ to use the --list option. Let's clarify that, and while we're at it, reword some clunky and ambiguous sentences. Signed-off-by: Jeff King p...@peff.net --- Documentation/git-branch.txt | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index 45a225e..01aa87f 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -22,13 +22,15 @@ DESCRIPTION DESCRIPTION --- -With no arguments, existing branches are listed and the current branch will -be highlighted with an asterisk. Option `-r` causes the remote-tracking -branches to be listed, and option `-a` shows both. This list mode is also -activated by the `--list` option (see below). -pattern restricts the output to matching branches, the pattern is a shell -wildcard (i.e., matched using fnmatch(3)). -Multiple patterns may be given; if any of them matches, the branch is shown. +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. Note that when providing a +`pattern`, you must use `--list`; otherwise the command is interpreted +as branch creation. With `--contains`, shows only the branches that contain the named commit (in other words, the branches whose tip commits are descendants of the -- 1.8.1.2.5.g1cb3f73 -- 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/2] branch: let branch filters imply --list
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
---
Documentation/git-branch.txt | 6 +++---
builtin/branch.c | 3 +++
t/t3201-branch-contains.sh | 35 +++
3 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 01aa87f..07ef5af 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -195,15 +195,15 @@ start-point is either a local or remote-tracking branch.
--contains [commit]::
Only list branches which contain the specified commit (HEAD
- if not specified).
+ if not specified). Implies `--list`.
--merged [commit]::
Only list branches whose tips are reachable from the
- specified commit (HEAD if not specified).
+ specified commit (HEAD if not specified). Implies `--list`.
--no-merged [commit]::
Only list branches whose tips are not reachable from the
- specified commit (HEAD if not specified).
+ specified commit (HEAD if not specified). Implies `--list`.
branchname::
The name of the branch to create or delete.
diff --git a/builtin/branch.c b/builtin/branch.c
index 873f624..4aa3d4e 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -825,6 +825,9 @@ int cmd_branch(int argc, const char **argv, const char
*prefix)
if (!delete !rename !edit_description !new_upstream
!unset_upstream argc == 0)
list = 1;
+ if (with_commit || merge_filter != NO_FILTER)
+ list = 1;
+
if (!!delete + !!rename + !!force_create + !!list + !!new_upstream +
!!unset_upstream 1)
usage_with_options(builtin_branch_usage, options);
diff --git a/t/t3201-branch-contains.sh b/t/t3201-branch-contains.sh
index f86f4bc..141b061 100755
--- a/t/t3201-branch-contains.sh
+++ b/t/t3201-branch-contains.sh
@@ -55,6 +55,16 @@ test_expect_success 'branch --contains=side' '
'
+test_expect_success 'branch --contains with pattern implies --list' '
+
+ git branch --contains=master master actual
+ {
+ echo master
+ } expect
+ test_cmp expect actual
+
+'
+
test_expect_success 'side: branch --merged' '
git branch --merged actual
@@ -66,6 +76,16 @@ test_expect_success 'side: branch --merged' '
'
+test_expect_success 'branch --merged with pattern implies --list' '
+
+ git branch --merged=side master actual
+ {
+ echo master
+ } expect
+ test_cmp expect actual
+
+'
+
test_expect_success 'side: branch --no-merged' '
git branch --no-merged actual
@@ -95,4 +115,19 @@ test_expect_success 'master: branch --no-merged' '
'
+test_expect_success 'branch --no-merged with pattern implies --list' '
+
+ git branch --no-merged=master master actual
+ expect
+ test_cmp expect actual
+
+'
+
+test_expect_success 'implicit --list conflicts with modification options' '
+
+ test_must_fail git branch --contains=master -d
+ test_must_fail git branch --contains=master -m foo
+
+'
+
test_done
--
1.8.1.2.5.g1cb3f73
--
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 01:35:21AM +, Jongman Heo wrote: Looks like following commit causes a segmentation fault in my machine (when running git pull or git fetch); commit 8dd5afc926acb9829ebf56e9b78826a5242cd638 Author: Junio C Hamano gits...@pobox.com Date: Mon Jan 7 12:24:55 2013 -0800 string-list: allow case-insensitive string list In my case, list-cmp (at get_entry_index() function) has an invalid address, obviously not an address of string comparision function, instead it points to 1. Can you show us a stack trace? The string-list functions are generic and get called in a lot of places. It would be useful to know which list is causing the problem. -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?
Thanks to all.
Tomas:
I can't find reflog setting of git-http-backend
doc(http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html),
I tried this setting:
git config core.logAllRefUpdates true
and after some test push, the output is as below:
git log -g master
commit d34e61baa28eabf46ba5e9f6a2feb24cc683ed39
Reflog: master@{0} (Scott Yan scottya...@gmail.com)
Reflog message: push
Author: Scott Yan scottya...@gmail.com
Date: Thu Jan 31 14:19:30 2013 +0800
this log shows when pushed, but still can't tell Who, because the
author info may be fake.
I don't know if I made some mistake.
Sitaram:
It seems I must host my central repo on Gitolite first...
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.
Regards,
Scott Yan
On Thu, Jan 31, 2013 at 2:10 PM, Sitaram Chamarty sitar...@gmail.com wrote:
On 01/31/2013 11:38 AM, Tomas Carnecky wrote:
On Thu, 31 Jan 2013 13:52:32 +0800, Scott Yan scottya...@gmail.com wrote:
Hello everyone:
The user info of git client (user name and email) is set by the users
themselves, so , how to avoid userA pretend to be userB?
Git server could authentication the user, but it do nothing about the
user info of commit message.
For example:
There are 20 people of my team, and everyone can push to the public
repository(git server),
If I found some backdoor code in my project, and the commit record
shows it was committed by userA, so I ask userA: why do you do this?
but he told me: no, this is not my code, I have never committed such
thing. and yes, everyone could change his user info to userA very
easily .
so... what should I do to avoid such situations?
gitolite keeps a log of which SSH user pushed which commits. The smart-http
backend does the same if you have reflog enabled on the server (see the
ENVIRONMENT section in man git-http-backend). So unless someone can steal
userA's credentials (http password, ssh key) you'll be able to detect who it
really was.
See also my rant on this topic:
https://github.com/sitaramc/gitolite/blob/master/src/VREF/EMAIL-CHECK#L37
--
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)
In clean.c we have a string_list created on the stack with STRING_LIST_INIT_NODUP (there are probably others, I stopped at the first occurrence). But, STRING_LIST_INIT_NODUP doesn't init the list-cmp pointer which can thus be random. I don't have much time to provide a patch right now (have to go to work), but will tonight if still needed. Antoine, On Thu, Jan 31, 2013 at 7:49 AM, Jeff King p...@peff.net wrote: On Thu, Jan 31, 2013 at 01:35:21AM +, Jongman Heo wrote: Looks like following commit causes a segmentation fault in my machine (when running git pull or git fetch); commit 8dd5afc926acb9829ebf56e9b78826a5242cd638 Author: Junio C Hamano gits...@pobox.com Date: Mon Jan 7 12:24:55 2013 -0800 string-list: allow case-insensitive string list In my case, list-cmp (at get_entry_index() function) has an invalid address, obviously not an address of string comparision function, instead it points to 1. Can you show us a stack trace? The string-list functions are generic and get called in a lot of places. It would be useful to know which list is causing the problem. -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 -- 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)
On Thu, Jan 31, 2013 at 7:49 AM, Jeff King wrote: On Thu, Jan 31, 2013 at 01:35:21AM +, Jongman Heo wrote: Looks like following commit causes a segmentation fault in my machine (when running git pull or git fetch); commit 8dd5afc926acb9829ebf56e9b78826a5242cd638 Author: Junio C Hamano Date: Mon Jan 7 12:24:55 2013 -0800 string-list: allow case-insensitive string list In my case, list-cmp (at get_entry_index() function) has an invalid address, obviously not an address of string comparision function, instead it points to 1. Can you show us a stack trace? The string-list functions are generic and get called in a lot of places. It would be useful to know which list is causing the problem. -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 Hi, FYI, gdb backtrace and valgrind output attached below, Thanks. (gdb) run fetch Starting program: /home/hjongman/repos/git/git fetch warning: .dynamic section for /lib/libc.so.6 is not at the expected address warning: difference appears to be caused by prelink, adjusting expectations [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x0001 in ?? () (gdb) bt #0 0x0001 in ?? () #1 0x0812b457 in get_entry_index (list=0xbfffe7c0, string=0x821ec3c refs/remotes/origin/HEAD, exact_match=0xbfffe568) at string-list.c:14 #2 0x0812bd60 in add_entry (list=0xbfffe7c0, insert_at=-1, string=0x821ec3c refs/remotes/origin/HEAD) at string-list.c:33 #3 string_list_insert_at_index (list=0xbfffe7c0, insert_at=-1, string=0x821ec3c refs/remotes/origin/HEAD) at string-list.c:63 #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 #6 0x0810af97 in do_one_ref (base=value optimized out, fn=0x8071820 add_existing, trim=0, flags=value optimized out, cb_data=0xbfffe7c0, entry=0x821ec10) at refs.c:525 #7 0x0810bd9f in do_for_each_ref_in_dirs (dir1=0x8215d54, dir2=0x821ea44, base=0x814f9ff , fn=0x8071820 add_existing, trim=0, flags=0, cb_data=0xbfffe7c0) at refs.c:627 #8 0x0810bc8e in do_for_each_ref_in_dirs (dir1=0x8215cac, dir2=0x8226954, base=0x814f9ff , fn=0x8071820 add_existing, trim=0, flags=0, cb_data=0xbfffe7c0) at refs.c:597 #9 0x0810bc8e in do_for_each_ref_in_dirs (dir1=0x8215c0c, dir2=0x8215a54, base=0x814f9ff , fn=0x8071820 add_existing, trim=0, flags=0, cb_data=0xbfffe7c0) at refs.c:597 #10 0x0810bc8e in do_for_each_ref_in_dirs (dir1=0x8215a1c, dir2=0x821862c, base=0x814f9ff , fn=0x8071820 add_existing, trim=0, flags=0, cb_data=0xbfffe7c0) at refs.c:597 #11 0x0810c304 in do_for_each_ref (submodule=value optimized out, base=0x814f9ff , fn=0x8071820 add_existing, trim=0, flags=0, cb_data=0xbfffe7c0) at refs.c:1295 #12 0x0810c63b in for_each_ref (fn=0x8071820 add_existing, cb_data=0xbfffe7c0) at refs.c:1343 #13 0x0807390a in do_fetch (remote=value optimized out, argc=0, argv=0xbfffe9f8) at builtin/fetch.c:699 #14 fetch_one (remote=value optimized out, argc=0, argv=0xbfffe9f8) at builtin/fetch.c:949 #15 0x08074251 in cmd_fetch (argc=1, argv=0xbfffe9f8, prefix=0x0) at builtin/fetch.c:992 #16 0x0804b60b in run_builtin (argc=1, argv=0xbfffe9f8) at git.c:281 #17 handle_internal_command (argc=1, argv=0xbfffe9f8) at git.c:443 #18 0x0804ba51 in run_argv (argc=1, argv=0xbfffe9f8) at git.c:489 #19 main (argc=1, argv=0xbfffe9f8) at git.c:564 $ valgrind git fetch ==2195== Memcheck, a memory error detector ==2195== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==2195== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==2195== Command: git fetch ==2195== ==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) ==2195== ==2195== Use of uninitialised value of size 4 ==2195==at 0x812B454: get_entry_index (string-list.c:14) ==2195==by 0x812BD5F: string_list_insert_at_index (string-list.c:33) ==2195==
Re: Re: Segmentation fault with latest git (070c57df)
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;
}
--
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
tiffany uk: fashionables
Among the loads of established rings, tiffany uk http://www.cheapstiffanyandcoclub.co.uk . add on gets as being the admit to take into account a classy women in any move of your community. Having said that, a Tiffany Rings Add on is released together with the fasted speeding as being the quick acknowledgement of your definite models while in the look and feel community. Let me allotment on hand by using quite a few innovative recommendations, however you actually admit to became quite a few guidelines to say that a genuine rings. http://www.cheapstiffanyandcoclub.co.uk -- View this message in context: http://git.661346.n2.nabble.com/tiffany-uk-fashionables-tp7576639.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
