Re: [ANNOUNCE] Git Merge Contributors Summit, April 8th, Paris
Hi, On Tue, Feb 24, 2015 at 11:09 PM, Jeff King p...@peff.net wrote: I wanted to make one more announcement about this, since a few more details have been posted at: http://git-merge.com/ since my last announcement. Specifically, I wanted to call attention to the contributor's summit on the 8th. Basically, there will be a space that can hold up to 50 people, it's open only to git (and JGit and libgit2) devs, and there isn't a planned agenda. So I want to: 1. Encourage developers to come. You might meet some folks in person you've worked with online. And you can see how beautiful we all are. 2. Get people thinking about what they would like to talk about. In past GitTogethers, it's been a mix of people with prepared things to talk about, group discussions of areas, and general kibitzing. We can be spontaneous on the day of the event, but if you have a topic you want to bring up, you may want to give it some thought beforehand. If you are a git dev and want to come, please RSVP to Chris Kelly amateurhu...@github.com who is organizing the event. If you would like to come, but finances make it hard (either for travel, or for the conference fee), please talk to me off-list, and we may be able to help. I'd like the Git project to set up a more organized way to pay back the travel costs and the conference fee to the developers who come. For example the Git project could say that it will at least pay back: - all the travel costs to the 5 most important Git developers who come and ask, - half the travel costs to the 5 next most important Git developers who come and ask, - all the conference fee to the 15 most important Git developers who come and ask, I think it could help developers decide to come, and it looks like enough funding could be available, thanks to GitHub and the GSoC money. What do you think? Apart from that it's also possible to find ways to accommodate some developers for free, if they don't mind crashing in someone's spare room. So please don't hesitate to ask if you would like to come. Thanks, Christian. -- 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] Add XDG support to the credential-store helper
credential-store will use ${XDG_CONFIG_HOME}/credentials to store
credentials if this file already exists and no --file option is given.
Otherwise it'll fall back to ~/.git-credentials (status quo).
Signed-off-by: Luis Ressel ara...@aixah.de
---
Documentation/git-credential-store.txt | 4 +++-
credential-store.c | 2 ++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-credential-store.txt
b/Documentation/git-credential-store.txt index bc97071..cab8f72 100644
--- a/Documentation/git-credential-store.txt
+++ b/Documentation/git-credential-store.txt
@@ -34,7 +34,9 @@ OPTIONS
Use `path` to store credentials. The file will have its
filesystem permissions set to prevent other users on the system
from reading it, but will not be encrypted or otherwise
- protected. Defaults to `~/.git-credentials`.
+ protected. Defaults to `~/.git-credentials` or
+ `$XDG_CONFIG_HOME/git/credentials` if the latter exists
+ ($XDG_CONFIG_HOME defaults to ~/.config).
EXAMPLES
diff --git a/credential-store.c b/credential-store.c
index 925d3f4..9720b42 100644
--- a/credential-store.c
+++ b/credential-store.c
@@ -138,6 +138,8 @@ int main(int argc, char **argv)
op = argv[0];
if (!file)
+ home_config_paths(NULL, file, credentials);
+ if (!file || access(file, R_OK|W_OK))
file = expand_user_path(~/.git-credentials);
if (!file)
die(unable to set up default path; use --file);
--
2.3.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Retry if fdopen() fails due to ENOMEM
Michael Haggerty mhag...@alum.mit.edu writes: One likely reason for fdopen() to fail is the lack of memory for allocating a FILE structure. When that happens, try freeing some memory and calling fdopen() again in the hope that it will work the second time. In codepaths where we are likely under memory pressure, the above might help, but I have to wonder (1) if update-server-info and daemon fall into that category; and (2) if Git continues to work under such a memory pressure to cause even fdopen() to fail. In other words, I do not see a reason not to do this change, but I am not sure how much it would help us in practice. We call fopen() from a lot more places than we call fdopen(). Do we want to do the same, or is there a good reason why this does not matter to callers of fopen(), and if so why doesn't the same reason apply to callers of fdopen()? Michael Haggerty (5): xfdopen(): if first attempt fails, free memory and try again fdopen_lock_file(): use fdopen_with_retry() copy_to_log(): use fdopen_with_retry() update_info_file(): use fdopen_with_retry() buffer_fdinit(): use fdopen_with_retry() daemon.c | 4 ++-- git-compat-util.h | 11 +++ lockfile.c| 2 +- server-info.c | 2 +- vcs-svn/line_buffer.c | 2 +- wrapper.c | 28 +--- 6 files changed, 41 insertions(+), 8 deletions(-) -- 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
Slow git pushes: sitting 1 minute in pack-objects
(Apologies, after a day I'm cross-posting from git.users. I think the question is maybe too technical for that group.) I'm experiencing very slow git pushes. On the order of 1 minute to push a trivial one-line change. When I set GIT_TRACE=1, I see that it seems to be taking a lot of time in the pack-objects phase. Others are not seeing this with the same repo, but I'm the only one working in a VM. ``` ~/ws/git/repo.1/repo date; git push mortons; date Wed Mar 4 15:03:11 EST 2015 15:03:11.086758 git.c:349 trace: built-in: git 'push' 'mortons' 15:03:11.126665 run-command.c:341 trace: run_command: 'ssh' '-p' '7999' 'git@privacy.privacy' 'git-receive-pack '\''~mortons/repo.git'\''' 15:03:20.383341 run-command.c:341 trace: run_command: 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress' 15:03:20.383945 exec_cmd.c:134 trace: exec: 'git' 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress' 15:03:20.385168 git.c:349 trace: built-in: git 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress' Counting objects: 4, done. Delta compression using up to 8 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 20.86 KiB | 0 bytes/s, done. Total 4 (delta 0), reused 0 (delta 0) To ssh://git@privacy.privacy:7999/~mortons/repo.git 5fe662f..a137bda my_branch - my_branch Wed Mar 4 15:04:22 EST 2015 ``` After it was slow at first, I tried setting these which did not help repack.writebitmaps=true pack.windowmemory=100m Details: git version 2.1.4 OS: CentOS 6.6 64-bit in a VM. repo size: huge. 6 GB .git directory, around 800 MB working tree. VM has 8 MB RAM and 8 cores. CPU: i7, 8 core (4 cores hyperthreaded) It is an ext4 filesystem on the guest linux drive. On the host side, it is a .vmdk file and the virtualization software used is virtualbox. While the drive is dynamically allocated, after I ran into this issue, I used fallocate to create a 50GB dummy file and then delete it to ensure that there was headroom in the drive and that dynamic allocation slowness was not the issue, and subsequent pushes were still slow. I have not experienced any filesystem slowness issues in the months I've been using this vm. Any ideas? I'm evaluating a move to git and this is the kind of thing that could derail it. Thanks, Stephen -- 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: Surprising interaction of binary and eol gitattributes
On 2015-03-05 17.38, Michael Haggerty wrote: I would expect that the following .gitattributes file * eol=crlf *.png -text would leave EOL translation turned off for PNG files. In other words, I would expect that explicitly setting -text would take precedence over the fact that setting eol implies that a file should be considered to be text. I would even more strongly expect * eol=crlf *.png binary to turn off EOL translation for PNG files. But in fact, in both of the above cases, EOL translation is turned *on* for PNG files. I propose that -text should override any setting for eol (which would of course fix both problems, since binary is equivalent to -diff -merge -text). What do people think? Michael (binary is not supported, we need -text) Beside that, * eol=crlf *.png -text should work as you describe. Do you think you make a test case for this ? In best case as a real patch :-) (I know that attributes should take precedence over eol settings in the config file, and this is not always the case) -- 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: [PATCHv3 0/3]More diffs for commit/status
Michael J Gruber g...@drmicha.warpmail.net writes:
v3 has the following changes:
- new leading patch by Junio to clean up t7508 (slightly modified by myself)
- adjust tests accordingly
- revert back to standard c/,i/ resp. i/,w/ diff prefixes with a header line
Open questionis for 3/3:
- Do we need the header to stick out even more? (I don't think so, although
having the STATUS_HEADER color to be different may help.)
If we have more than one paths in each category, I would think at
least a separator line (I used -{50} in my illustration you are
replying to) before the verbal Changes to be committed would help.
- Do we want the header line also for status -v? (I would say yes, but that
would be a change to current behaviour.)
I would not object to it very strongly, but I do not see a point in
changing the behaviour.
And I do not see why a new user would want it anyway. There is no
need to differenciate the changes to be committed from the changes
left in the working tree when the latter is not even shown.
--
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: [PATCHv3 0/3]More diffs for commit/status
Junio C Hamano gits...@pobox.com writes:
Extending this line of thought further.
If I am reading your patch 3/3 right, status -v -v shows the
header when there are patches to be shown for the category. I am
not sure if that is the most helpful way for the users, when either
c/i xor i/w diffs is missing.
...
So, my recommendation for status -v -v would be:
Taking the conclusion part of what I said back. I think the exact
same reasoning will lead to a much simpler and more concise output
by (1) using exactly the same logic you have in 3/3 to decide when
to show or not show the headers and (2) adding the ^-{50}$ separator
only before the second header that is shown before the changes left
in the working tree.
Then, 1-a) will show the same output as status -v, 1-b) will start
as the same as status -v, followed by a visually significant
separator followed by diff, 2-a) will be empty, and 2-b) will start
with a visually significant and unusual separator line before the
diff. That would make 1-a) and 2-b) visually very distinct and
reduce the chance of confusion.
The updated outline for status -v -v would be:
if (there are changes to be committed) {
show to be committed header;
show c/i diff;
}
if (there are changes left in the working tree) {
show left in the working tree with -{50} header;
show i/w diff;
}
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: [PATCHv3 0/3]More diffs for commit/status
Junio C Hamano gits...@pobox.com writes:
Michael J Gruber g...@drmicha.warpmail.net writes:
- Do we want the header line also for status -v? (I would say yes, but that
would be a change to current behaviour.)
I would not object to it very strongly, but I do not see a point in
changing the behaviour.
And I do not see why a new user would want it anyway. There is no
need to differenciate the changes to be committed from the changes
left in the working tree when the latter is not even shown.
Extending this line of thought further.
If I am reading your patch 3/3 right, status -v -v shows the
header when there are patches to be shown for the category. I am
not sure if that is the most helpful way for the users, when either
c/i xor i/w diffs is missing.
There are four cases, obviously ;-)
1. When there are changes to be committed:
a) When there is no change left in the working tree, the proposed
output would be the same as the more familiar status -v
output. Showing changes to be committed header would of course
help.
I wondered if the proposed behaviour hurts the user by hiding
the header for changes to be left out, though. By seeing that
the second header alone and no diff, the user will be assured
that there is no changes left in the working tree, forgotten to
be added. But this point is minor. As the users get used to
the behaviour of -v -v, they will learn to read the emptyness
and find its proper meaning that there is no change left out.
So I think the proposed behaviour would be OK in this case. In
fact, not showing the second header when there is no change left
in the working tree will help potential issues with case 2-b).
b) When there is change left in the working tree, the proposed
output is fine. Two headers are shown to indicate what the
following diff is about and cleanly shows where the boundary of
the two classes are (especially if you resurrect the -{50}
separator line I suggested, at least for the second header).
2. When there is no change to be committed:
a) When there is no change left in the working tree, the proposed
output is fine. There is no output (no header, no diff), and
the user immediately knows that the working tree and the index
are clean.
b) When there are changes left in the working tree, the user sees
one header followed by a diff in the proposed output. Visually,
the single line heading (even with the separateor line) may be
so small in the context of the whole output, and the user needs
to READ it to notice that the diff being shown are not what is
going to be committed. In other words, it is too similar to the
proposed output in case 1-a).
If we show the to be committed header followed by no diff, and
then the second header followed by diff, it would be crystial
clear to the user, because it looks unusual, that what is shown
is different from case 1-a). This would especially be true if
you resurrected -{50} separator line after the heading.
So, my recommendation for status -v -v would be:
if (there are changes to be committed, or
there are changes left in the working tree) {
show to be committed with -{50};
show c/i diff;
}
if (there are changes left in the working tree) {
show left in the working tree with -{50};
show i/w diff;
}
--
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
[GSoC microproject] Add XDG support to the credential-store helper
I'm contributing this patch in preparation for a GSoC15 application with the git project. In particular, I'm interested in the two bisect improvements listed on the Ideas page. Does anyone have other suggestions for potential improvements of git bisect that would be suitable for such a GSoC project? Oh, and should I add a testcase for the new functionality introduced by this patch? And if yes, what exactly should I test? Also, apologies if these mails arrive twice. I'm resending them because Majordomo seems to have ignored my initial attempt 6 hours ago. Regards, Luis Ressel -- 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 v2 2/2] git-C: Add test to check git -C ''
Karthik Nayak karthik@gmail.com writes: Add a test to check whether git -C '' works without giving an error. This is achieved by adding a commit and checking the log using git -C '' and comparing the log message with the commit message. Why choose something complex like commit and log, though? Wouldn't something like this match the series of current tests better? Also I think a small change with a small test like these should be in a single patch, not two separate ones. Thanks. t/t0056-git-C.sh | 10 ++ 1 file changed, 10 insertions(+) diff --git a/t/t0056-git-C.sh b/t/t0056-git-C.sh index 99c0377..551d806 100755 --- a/t/t0056-git-C.sh +++ b/t/t0056-git-C.sh @@ -14,6 +14,16 @@ test_expect_success 'git -C path runs git from the directory path' ' test_cmp expected actual ' +test_expect_success 'git -C path with an empty path is a no-op' ' + ( + mkdir -p dir1/subdir + cd dir1/subdir + git -C rev-parse --show-prefix actual + echo subdir/ expect + test_cmp expect actual + ) +' + test_expect_success 'Multiple -C options: -C dir1 -C dir2 is equivalent to -C dir1/dir2' ' test_create_repo dir1/dir2 echo 1 dir1/dir2/b.txt -- 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: Surprising interaction of binary and eol gitattributes
Michael Haggerty mhag...@alum.mit.edu writes: I would expect that the following .gitattributes file * eol=crlf *.png -text would leave EOL translation turned off for PNG files. In other words, I would expect that explicitly setting -text would take precedence over the fact that setting eol implies that a file should be considered to be text. I would even more strongly expect * eol=crlf *.png binary to turn off EOL translation for PNG files. But in fact, in both of the above cases, EOL translation is turned *on* for PNG files. I propose that -text should override any setting for eol (which would of course fix both problems, since binary is equivalent to -diff -merge -text). What do people think? Hmm, is there really something that needs a new proposal and opinions? The way I read the flow in convert.c is: convert_to_git() uses input_crlf_action() to figure out what crlf_to_git() conversion is necessary. input_crlf_action() looks at text_attr and says CRLF_BINARY when it is CRLF_BINARY without looking at eol_attr at all. text_attr above is ca.crlf_action in convert_to_git(). The whole ca.* comes from convert_attrs() inspecting attributes on the incoming path. convert_attrs() inspects eol and text attributes, among others, and sets crlf_action by calling git_path_check_crlf(). git_path_check_crlf() looks at the 'text' attribute; if it is set to false, it returns CRLF_BINARY. crlf_to_git() when given crlf_action==CRLF_BINARY is a no-op. So, with the above attributes where anything is eol=crlf by default and in addition *.png is binary (which contains -text), we shouldn't get any crlf munging. Am I reading/following the code incorrectly? Puzzled -- 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] diff --shortstat --dirstat: remove duplicate output
Mårten Kongstad marten.kongs...@gmail.com writes: v3: change how tests count (part of) the dirstat number of lines: instead of 'grep -c', use 'grep filename test_line_count'. Thanks to Torsten Bögershausen and SZEDER Gábor for pointing out how to improve the tests. Thanks. I'd squash the following on top before queuing it. The overlong lines that ignores the exit status from git diff looked problematic to me. t/t4047-diff-dirstat.sh | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/t/t4047-diff-dirstat.sh b/t/t4047-diff-dirstat.sh index 065d74f..0d50dce 100755 --- a/t/t4047-diff-dirstat.sh +++ b/t/t4047-diff-dirstat.sh @@ -974,13 +974,16 @@ test_expect_success 'diff.dirstat=future_param,0,lines should warn, but still wo ' test_expect_success '--shortstat --dirstat should output only one dirstat' ' - git diff --shortstat --dirstat=changes HEAD^..HEAD | grep dst/copy/changed/$ actual_diff_shortstat_dirstat_changes + git diff --shortstat --dirstat=changes HEAD^..HEAD out + grep dst/copy/changed/$ out actual_diff_shortstat_dirstat_changes test_line_count = 1 actual_diff_shortstat_dirstat_changes - git diff --shortstat --dirstat=lines HEAD^..HEAD | grep dst/copy/changed/$ actual_diff_shortstat_dirstat_lines + git diff --shortstat --dirstat=lines HEAD^..HEAD out + grep dst/copy/changed/$ out actual_diff_shortstat_dirstat_lines test_line_count = 1 actual_diff_shortstat_dirstat_lines - git diff --shortstat --dirstat=files HEAD^..HEAD | grep dst/copy/changed/$ actual_diff_shortstat_dirstat_files + git diff --shortstat --dirstat=files HEAD^..HEAD out + grep dst/copy/changed/$ out actual_diff_shortstat_dirstat_files test_line_count = 1 actual_diff_shortstat_dirstat_files ' -- 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] zlib: initialize git_zstream in git_deflate_init{,_gzip,_raw}
René Scharfe l@web.de writes:
Clear the git_zstream variable at the start of git_deflate_init() etc.
so that callers don't have to do that.
Signed-off-by: Rene Scharfe l@web.de
Nice. git grep -B1 git_deflate_init tells me that all existing
callers of the function do this memset(). Clearly the above is a
very good idea and is a safe and sane thing to do.
Thanks.
---
archive-zip.c | 2 --
builtin/index-pack.c | 1 -
builtin/pack-objects.c | 2 --
bulk-checkin.c | 1 -
diff.c | 1 -
fast-import.c | 3 ---
http-push.c| 1 -
remote-curl.c | 1 -
sha1_file.c| 1 -
zlib.c | 2 ++
10 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/archive-zip.c b/archive-zip.c
index 4bde019..1a54e1b 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -120,7 +120,6 @@ static void *zlib_deflate_raw(void *data, unsigned long
size,
void *buffer;
int result;
- memset(stream, 0, sizeof(stream));
git_deflate_init_raw(stream, compression_level);
maxsize = git_deflate_bound(stream, size);
buffer = xmalloc(maxsize);
@@ -349,7 +348,6 @@ static int write_zip_entry(struct archiver_args *args,
size_t out_len;
unsigned char compressed[STREAM_BUFFER_SIZE * 2];
- memset(zstream, 0, sizeof(zstream));
git_deflate_init_raw(zstream, args-compression_level);
compressed_size = 0;
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 4632117..cf654df 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -1204,7 +1204,6 @@ static int write_compressed(struct sha1file *f, void
*in, unsigned int size)
int status;
unsigned char outbuf[4096];
- memset(stream, 0, sizeof(stream));
git_deflate_init(stream, zlib_compression_level);
stream.next_in = in;
stream.avail_in = size;
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index d816587..c3a7516 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -125,7 +125,6 @@ static unsigned long do_compress(void **pptr, unsigned
long size)
void *in, *out;
unsigned long maxsize;
- memset(stream, 0, sizeof(stream));
git_deflate_init(stream, pack_compression_level);
maxsize = git_deflate_bound(stream, size);
@@ -153,7 +152,6 @@ static unsigned long write_large_blob_data(struct
git_istream *st, struct sha1fi
unsigned char obuf[1024 * 16];
unsigned long olen = 0;
- memset(stream, 0, sizeof(stream));
git_deflate_init(stream, pack_compression_level);
for (;;) {
diff --git a/bulk-checkin.c b/bulk-checkin.c
index 0c4b8a7..8d157eb 100644
--- a/bulk-checkin.c
+++ b/bulk-checkin.c
@@ -105,7 +105,6 @@ static int stream_to_pack(struct bulk_checkin_state
*state,
int write_object = (flags HASH_WRITE_OBJECT);
off_t offset = 0;
- memset(s, 0, sizeof(s));
git_deflate_init(s, pack_compression_level);
hdrlen = encode_in_pack_object_header(type, size, obuf);
diff --git a/diff.c b/diff.c
index d1bd534..dad875c 100644
--- a/diff.c
+++ b/diff.c
@@ -2093,7 +2093,6 @@ static unsigned char *deflate_it(char *data,
unsigned char *deflated;
git_zstream stream;
- memset(stream, 0, sizeof(stream));
git_deflate_init(stream, zlib_compression_level);
bound = git_deflate_bound(stream, size);
deflated = xmalloc(bound);
diff --git a/fast-import.c b/fast-import.c
index aac2c24..77fb2ff 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1062,7 +1062,6 @@ static int store_object(
} else
delta = NULL;
- memset(s, 0, sizeof(s));
git_deflate_init(s, pack_compression_level);
if (delta) {
s.next_in = delta;
@@ -1090,7 +1089,6 @@ static int store_object(
free(delta);
delta = NULL;
- memset(s, 0, sizeof(s));
git_deflate_init(s, pack_compression_level);
s.next_in = (void *)dat-buf;
s.avail_in = dat-len;
@@ -1190,7 +1188,6 @@ static void stream_blob(uintmax_t len, unsigned char
*sha1out, uintmax_t mark)
crc32_begin(pack_file);
- memset(s, 0, sizeof(s));
git_deflate_init(s, pack_compression_level);
hdrlen = encode_in_pack_object_header(OBJ_BLOB, len, out_buf);
diff --git a/http-push.c b/http-push.c
index 0beb7ab..bfb1c96 100644
--- a/http-push.c
+++ b/http-push.c
@@ -365,7 +365,6 @@ static void start_put(struct transfer_request *request)
hdrlen = sprintf(hdr, %s %lu, typename(type), len) + 1;
/* Set it up */
- memset(stream, 0, sizeof(stream));
git_deflate_init(stream, zlib_compression_level);
size = git_deflate_bound(stream, len + hdrlen);
Re: [PATCH v3 2/3] sha1_file: implement changes for cat-file --literally -t
Karthik Nayak karthik@gmail.com writes:
+const char *sha1_object_info_literally(const unsigned char *sha1)
+{
+ enum object_type type;
+ struct strbuf sb = STRBUF_INIT;
+ struct object_info oi = {NULL};
+
+ oi.typename = sb;
+ oi.typep = type;
+ if (sha1_object_info_extended(sha1, oi, LOOKUP_LITERALLY) 0)
+ return NULL;
+ if (*oi.typep 0) {
+ strbuf_release(oi.typename);
+ return typename(*oi.typep);
+ }
+ return oi.typename-buf;
+}
After calling this function to ask the textual type of an object,
should the caller free the result it obtains from this function?
oi.typename points at the strbuf on stack and its buf member points
at an allocated piece of memory. That must be freed.
On the other hand, typename(*oi.typep) is a pointer into static
piece of memory, which must never be freed.
This patch introduces this function without introducing any caller,
which makes it unnecessarily harder to judge if this problem is
caused by choosing a wrong calling convention, and/or if so what
better calling convention can be used to correct the problem, but
without looking at the caller that (presumably) will be introduced
in a later patch, I suspect that the caller should supply a pointer
to struct object_info, i.e. something along these lines:
struct object_info oi = { NULL };
struct strbuf sb = STRBUF_INIT;
enum object_type type;
...
oi.typename = sb;
sha1_object_info_literally(sha1, oi);
if (!sb.len)
that is an error;
else
use sb.buf as the name;
strbuf_release(sb);
As sha1_object_info_extended() takes oi and fills oi.typename when
it is supplied for _all_ types, not just the bogus ones, a caller of
that function, including sha1_object_info_literally() and its
caller, shouldn't have to worry about is that a known one? then
use typename() to convert the enum type to a string. Otherwise use
the oi.typename-buf at all, I would think.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC microproject] Add XDG support to the credential-store helper
Luis Ressel ara...@aixah.de writes: Oh, and should I add a testcase for the new functionality introduced by this patch? And if yes, what exactly should I test? Absolutely. Thinking things through to design what needs to be tested is part of the exercise ;-) You need to demonstrate that the new feature kicks in when it should, and also you need to make sure the new feature does not get used when it shouldn't. -- 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: [GSoC microproject] Add XDG support to the credential-store helper
Okay, I've had a look at Paul's patch for this. Sorry again for the dupe, I must've missed it before. I guess I'll attempt another microproject. However, I feel like my patch is really all that's neccessary; I don't think we should try to use both files if they exist -- I consider Paul's approach to be a bit overcomplicated. My patch still uses ~/.git-credentials as a default location, which should be sufficient for compability. A user that wants to use ~/.config/git/credentials instead has to manually create that file first, which he just shouldn't do if he has to stay compatible to previous git versions. Of course, my patch is definitly lacking a test case, and the documentation could be a tad better, too. Regards, Luis Ressel pgpUI1loUbPdU.pgp Description: OpenPGP digital signature
Re: [GSoC microproject] Add XDG support to the credential-store helper
Hi, On Thu, Mar 5, 2015 at 9:51 PM, Luis Ressel ara...@aixah.de wrote: I'm contributing this patch in preparation for a GSoC15 application with the git project. In particular, I'm interested in the two bisect improvements listed on the Ideas page. Does anyone have other suggestions for potential improvements of git bisect that would be suitable for such a GSoC project? Last year, on the ideas page: http://git.github.io/SoC-2014-Ideas.html we also had the following improvement: in some cases, git bisect may test too many merge bases, thus slowing down the bisection (making it closer to linear than logarithmic). so you could work on that too. And if you really want and have time you can also rewrite git-bisect.sh into a builtin command. There is already builtin/bisect--helper.c where you can put some migrated code step by step. Oh, and should I add a testcase for the new functionality introduced by this patch? And if yes, what exactly should I test? First, it looks like another student started working on the same microproject. Did you have a look at what he did? If you didn't, you probably should, so that reviewers don't need to tell you what they already told the other student. And if you did, you should tell it, and maybe explain what you did differently and why. If it looks like the other student is more advanced on this subject, you might want to try another microproject. And if all the microprojects are already taken, you might want to ask the list for other microprojects, or you may want to have a look at the many merge bases improvement above. (You could start by having a look at check_merge_bases() in bisect.c and by creating a script or better a test case that reproduces the problem, see t/t6030-bisect-porcelain.sh.) Welcome to the Git community! Best, Christian. -- 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: [GSoC microproject] Add XDG support to the credential-store helper
On Thu, 5 Mar 2015 23:38:19 +0100 Christian Couder christian.cou...@gmail.com wrote: Hi, Last year, on the ideas page: http://git.github.io/SoC-2014-Ideas.html we also had the following improvement: in some cases, git bisect may test too many merge bases, thus slowing down the bisection (making it closer to linear than logarithmic). so you could work on that too. And if you really want and have time you can also rewrite git-bisect.sh into a builtin command. There is already builtin/bisect--helper.c where you can put some migrated code step by step. Thanks for those suggestions! First, it looks like another student started working on the same microproject. Did you have a look at what he did? If you didn't, you probably should, so that reviewers don't need to tell you what they already told the other student. And if you did, you should tell it, and maybe explain what you did differently and why. If it looks like the other student is more advanced on this subject, you might want to try another microproject. And if all the microprojects are already taken, you might want to ask the list for other microprojects, or you may want to have a look at the many merge bases improvement above. (You could start by having a look at check_merge_bases() in bisect.c and by creating a script or better a test case that reproduces the problem, see t/t6030-bisect-porcelain.sh.) Oops. I had a quick glance at the list archives, but apparently I missed this. I'll have a look. Welcome to the Git community! Best, Christian. Thanks! Regards, Luis Ressel pgpwC6oLSqAfN.pgp Description: OpenPGP digital signature
Re: [ANNOUNCE] Git Merge Contributors Summit, April 8th, Paris
Christian Couder christian.cou...@gmail.com writes: On Tue, Feb 24, 2015 at 11:09 PM, Jeff King p...@peff.net wrote: I wanted to make one more announcement about this, since a few more details have been posted at: http://git-merge.com/ since my last announcement. Specifically, I wanted to call attention to the contributor's summit on the 8th. Basically, there will be a space that can hold up to 50 people, it's open only to git (and JGit and libgit2) devs, and there isn't a planned agenda. So I want to: 1. Encourage developers to come. You might meet some folks in person ... 2. Get people thinking about what they would like to talk about. In ... If you are a git dev and want to come, please RSVP to Chris Kelly amateurhu...@github.com who is organizing the event. If you would like to come, but finances make it hard (either for travel, or for the conference fee), please talk to me off-list, and we may be able to help. I'd like the Git project to set up a more organized way to pay back the travel costs and the conference fee to the developers who come. For example the Git project could say that it will at least pay back: - all the travel costs to the 5 most important Git developers who come and ask, - half the travel costs to the 5 next most important Git developers who come and ask, - all the conference fee to the 15 most important Git developers who come and ask, I think it could help developers decide to come, and it looks like enough funding could be available, thanks to GitHub and the GSoC money. What do you think? I personally perfer things to be kept informal---it would keep things simpler for everybody. You do not have to wonder what you should do when you think you are among the five most important people and you also know your employer will pay for the conference if you asked, for example. It feels to me that the suggestion Peff gave in his announce to ask privately for case-by-case arrangement strikes the balance much better. Apart from that it's also possible to find ways to accommodate some developers for free, if they don't mind crashing in someone's spare room. So please don't hesitate to ask if you would like to come. These five lines, by not explicitly saying something like the first 2 people who ask can crash in Christian's spare bedroom, is doing exactly the same thing as Peff did by saying please talk to me off-list, it seems to me at least. Both keep things informal and simple, and both arrange things on case-by-case basis as needed. And I think that is better than setting a seemingly hard rules upfront, and causing more problems unnecessarily (e.g. who decides who are the 5 most important, for example?). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] zlib: initialize git_zstream in git_deflate_init{,_gzip,_raw}
Clear the git_zstream variable at the start of git_deflate_init() etc.
so that callers don't have to do that.
Signed-off-by: Rene Scharfe l@web.de
---
archive-zip.c | 2 --
builtin/index-pack.c | 1 -
builtin/pack-objects.c | 2 --
bulk-checkin.c | 1 -
diff.c | 1 -
fast-import.c | 3 ---
http-push.c| 1 -
remote-curl.c | 1 -
sha1_file.c| 1 -
zlib.c | 2 ++
10 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/archive-zip.c b/archive-zip.c
index 4bde019..1a54e1b 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -120,7 +120,6 @@ static void *zlib_deflate_raw(void *data, unsigned long
size,
void *buffer;
int result;
- memset(stream, 0, sizeof(stream));
git_deflate_init_raw(stream, compression_level);
maxsize = git_deflate_bound(stream, size);
buffer = xmalloc(maxsize);
@@ -349,7 +348,6 @@ static int write_zip_entry(struct archiver_args *args,
size_t out_len;
unsigned char compressed[STREAM_BUFFER_SIZE * 2];
- memset(zstream, 0, sizeof(zstream));
git_deflate_init_raw(zstream, args-compression_level);
compressed_size = 0;
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 4632117..cf654df 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -1204,7 +1204,6 @@ static int write_compressed(struct sha1file *f, void *in,
unsigned int size)
int status;
unsigned char outbuf[4096];
- memset(stream, 0, sizeof(stream));
git_deflate_init(stream, zlib_compression_level);
stream.next_in = in;
stream.avail_in = size;
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index d816587..c3a7516 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -125,7 +125,6 @@ static unsigned long do_compress(void **pptr, unsigned long
size)
void *in, *out;
unsigned long maxsize;
- memset(stream, 0, sizeof(stream));
git_deflate_init(stream, pack_compression_level);
maxsize = git_deflate_bound(stream, size);
@@ -153,7 +152,6 @@ static unsigned long write_large_blob_data(struct
git_istream *st, struct sha1fi
unsigned char obuf[1024 * 16];
unsigned long olen = 0;
- memset(stream, 0, sizeof(stream));
git_deflate_init(stream, pack_compression_level);
for (;;) {
diff --git a/bulk-checkin.c b/bulk-checkin.c
index 0c4b8a7..8d157eb 100644
--- a/bulk-checkin.c
+++ b/bulk-checkin.c
@@ -105,7 +105,6 @@ static int stream_to_pack(struct bulk_checkin_state *state,
int write_object = (flags HASH_WRITE_OBJECT);
off_t offset = 0;
- memset(s, 0, sizeof(s));
git_deflate_init(s, pack_compression_level);
hdrlen = encode_in_pack_object_header(type, size, obuf);
diff --git a/diff.c b/diff.c
index d1bd534..dad875c 100644
--- a/diff.c
+++ b/diff.c
@@ -2093,7 +2093,6 @@ static unsigned char *deflate_it(char *data,
unsigned char *deflated;
git_zstream stream;
- memset(stream, 0, sizeof(stream));
git_deflate_init(stream, zlib_compression_level);
bound = git_deflate_bound(stream, size);
deflated = xmalloc(bound);
diff --git a/fast-import.c b/fast-import.c
index aac2c24..77fb2ff 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1062,7 +1062,6 @@ static int store_object(
} else
delta = NULL;
- memset(s, 0, sizeof(s));
git_deflate_init(s, pack_compression_level);
if (delta) {
s.next_in = delta;
@@ -1090,7 +1089,6 @@ static int store_object(
free(delta);
delta = NULL;
- memset(s, 0, sizeof(s));
git_deflate_init(s, pack_compression_level);
s.next_in = (void *)dat-buf;
s.avail_in = dat-len;
@@ -1190,7 +1188,6 @@ static void stream_blob(uintmax_t len, unsigned char
*sha1out, uintmax_t mark)
crc32_begin(pack_file);
- memset(s, 0, sizeof(s));
git_deflate_init(s, pack_compression_level);
hdrlen = encode_in_pack_object_header(OBJ_BLOB, len, out_buf);
diff --git a/http-push.c b/http-push.c
index 0beb7ab..bfb1c96 100644
--- a/http-push.c
+++ b/http-push.c
@@ -365,7 +365,6 @@ static void start_put(struct transfer_request *request)
hdrlen = sprintf(hdr, %s %lu, typename(type), len) + 1;
/* Set it up */
- memset(stream, 0, sizeof(stream));
git_deflate_init(stream, zlib_compression_level);
size = git_deflate_bound(stream, len + hdrlen);
strbuf_init(request-buffer.buf, size);
diff --git a/remote-curl.c b/remote-curl.c
index deb4bfe..af7b678 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -567,7 +567,6 @@ retry:
git_zstream stream;
int ret;
-
[PATCH] for the SoC15 micro project, Make git -C '' cmd not to barf.
Hi, here is my patch for the micro project, Please review the code. prudh@prudh-Studio-1569:~/git$ git diff diff --git a/git.c b/git.c index 8c7ee9c..364788b 100644 --- a/git.c +++ b/git.c @@ -205,6 +205,8 @@ static int handle_options(const char ***argv, int *argc, int usage(git_usage_string); } if (chdir((*argv)[1])) + if(*(*argv)[1]==0); + else if(chdir((*argv)[1])) die_errno(Cannot change to '%s', (*argv)[1]); if (envchanged) *envchanged = 1; Thank you, Prudhvee -- 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
Checkout --force without complete overwrite?
I have a repo whose workdir tends to get pretty dirty as I jump around from branch to branch tending weeds and whatnot. Sometimes when I try to switch branches git refuses because of local file changes. git checkout otherbranch error: Your local changes to the following files would be overwritten by checkout: foo.txt bar.c Please, commit your changes or stash them before you can switch branches. Aborting I resolve this by examining my local changes and deciding if I want to keep them or not. I keep the changes in the conflicting files that I want, and then I discard the rest. One way to discard the rest is to say git checkout HEAD -- foo.txt bar.c git checkout otherbranch But sometimes the list of local-change conflicts I want to discard is too long and this recipe seems like a good alternative to me: git checkout -f otherbranch But this is disastrous, because I have been focused on examining the conflicting local changes in foo.txt and bar.c, but I forgot about my non-conflicting changes to baz.c, lost as it is in a sea of untracked files making up the majority of my workdir local changes. So all my untracked files make the leap unscathed, but my precious forgotten changes in baz.c get wiped out by the checkout --force, even though the baz.c in index and in otherbranch are the same. I've read the documentation for 'git checkout --force' several times and I have a hard time deciding what it means to do. But I'm sure it's doing what it's designed to do and what the man page says it will. (English is my first language, btw.) What I am seeking is some way to checkout the other branch and replace my conflicted local changes while ignoring my non-conflicting local changes in tracked files. Something like --force-gently, maybe. Does such an option exist? I could script something, but it comes up only often enough to bite me, so I'm sure I'd forget I had scripted it. Thanks, Phil -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Mar 2015, #02; Thu, 5)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. A few more batches of topics have been merged to 'master', including both fixes and enhancements. First maintenance release for v2.3 was cut with many fixes that have already been merged to 'master', and the v2.3.2 will also appear shortly. 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 -- [Graduated to master] * ew/svn-fixes (2015-02-26) 2 commits (merged to 'next' on 2015-03-03 at 18e4684) + Merge branch 'svn-maint-fixes' into svn-fixes + git-svn: lazy load some modules (this branch uses ew/svn-maint-fixes.) * ew/svn-maint-fixes (2015-02-26) 2 commits (merged to 'next' on 2015-03-03 at 776b563) + Git::SVN::*: avoid premature FileHandle closure + git-svn: fix localtime=true on non-glibc environments (this branch is used by ew/svn-fixes.) Correct a breakage to git-svn around v2.2 era that triggers premature closing of FileHandle. * jc/apply-beyond-symlink (2015-02-10) 4 commits (merged to 'next' on 2015-02-18 at 4109de1) + apply: do not touch a file beyond a symbolic link + apply: do not read from beyond a symbolic link + apply: do not read from the filesystem under --index + apply: reject input that touches outside the working area git apply was not very careful about reading from, removing, updating and creating paths outside the working tree (under --index/--cached) or the current directory (when used as a replacement for GNU patch). * jc/apply-ws-fix-expands-report (2015-01-22) 1 commit (merged to 'next' on 2015-02-18 at b571668) + apply: detect and mark whitespace errors in context lines when fixing git apply --whitespace=fix fixed whitespace errors in the common context lines but did so without reporting. * jc/diff-test-updates (2015-02-23) 7 commits (merged to 'next' on 2015-02-23 at 9e863a7) + test_ln_s_add: refresh stat info of fake symbolic links (merged to 'next' on 2015-02-18 at f152c9f) + t4008: modernise style + t/diff-lib: check exact object names in compare_diff_raw + tests: do not borrow from COPYING and README from the real source + t4010: correct expected object names + t9300: correct expected object names + t4008: correct stale comments (this branch is used by jc/diff-b-m.) Test clean-up. * jk/daemon-interpolate (2015-02-17) 3 commits (merged to 'next' on 2015-02-20 at 21118a7) + daemon: sanitize incoming virtual hostname + t5570: test git-daemon's --interpolated-path option + git_connect: let user override virtual-host we send to daemon The interpolated-path option of git daemon inserted any string client declared on the host= capability request without checking. Sanitize and limit %H and %CH to a saner and a valid DNS name. * km/send-email-getopt-long-workarounds (2015-02-16) 1 commit (merged to 'next' on 2015-02-18 at 84c1597) + git-send-email.perl: support no- prefix with older GetOptions Even though we officially haven't dropped Perl 5.8 support, the Getopt::Long package that came with it does not support --no- prefix to negate a boolean option; manually add support to help people with older Getopt::Long package. * mh/refs-have-new (2015-02-17) 13 commits (merged to 'next' on 2015-02-23 at b8929db) + refs.h: remove duplication in function docstrings + update_ref(): improve documentation + ref_transaction_verify(): new function to check a reference's value + ref_transaction_delete(): check that old_sha1 is not null_sha1 + ref_transaction_create(): check that new_sha1 is valid + commit: avoid race when creating orphan commits + commit: add tests of commit races + ref_transaction_delete(): remove have_old parameter + ref_transaction_update(): remove have_old parameter + struct ref_update: move have_old into flags + refs.c: change some flags to unsigned int + refs: remove the gap in the REF_* constant values + refs: move REF_DELETING to refs.c Simplify the ref transaction API around how the ref should be pointing at this object is specified. * mm/am-c-doc (2015-02-20) 2 commits (merged to 'next' on 2015-02-23 at 1cd9b0f) + Documentation/git-am.txt: mention mailinfo.scissors config variable + Documentation/config.txt: document mailinfo.scissors The configuration variable 'mailinfo.scissors' was hard to discover in the documentation. * rj/no-xopen-source-for-cygwin (2015-02-22) 1 commit (merged to 'next' on 2015-02-23 at 323ac75) + git-compat-util.h: remove redundant code Code cleanups. * rs/daemon-interpolate (2015-02-17) 2 commits (merged to 'next' on 2015-02-18 at c0f5750) + daemon: use callback to build interpolated path + daemon: look up client-supplied hostname lazily git daemon looked up the hostname even when %CH and %IP interpolations are not
Re: [PATCH] for the SoC15 micro project, Make git -C '' cmd not to barf.
On Thu, Mar 5, 2015 at 5:46 PM, Prudhvee Narasimha Sadha prudhvi.s...@gmail.com wrote: Hi, here is my patch for the micro project, Please review the code. prudh@prudh-Studio-1569:~/git$ git diff Please see Documentation/SubmittingPatches and maybe have a look at the format-patch manpage. Thanks, Stefan diff --git a/git.c b/git.c index 8c7ee9c..364788b 100644 --- a/git.c +++ b/git.c @@ -205,6 +205,8 @@ static int handle_options(const char ***argv, int *argc, int usage(git_usage_string); } if (chdir((*argv)[1])) + if(*(*argv)[1]==0); + else if(chdir((*argv)[1])) die_errno(Cannot change to '%s', (*argv)[1]); if (envchanged) *envchanged = 1; Thank you, Prudhvee -- 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: Slow git pushes: sitting 1 minute in pack-objects
On Fri, Mar 6, 2015 at 4:03 AM, Stephen Morton stephen.c.mor...@gmail.com wrote: I'm experiencing very slow git pushes. On the order of 1 minute to push a trivial one-line change. When I set GIT_TRACE=1, I see that it seems to be taking a lot of time in the pack-objects phase. Others are not seeing this with the same repo, but I'm the only one working in a VM. ... Details: git version 2.1.4 OS: CentOS 6.6 64-bit in a VM. repo size: huge. 6 GB .git directory, around 800 MB working tree. VM has 8 MB RAM and 8 cores. Is it 8 GB or MB RAM? CPU: i7, 8 core (4 cores hyperthreaded) -- 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
Re: An interesting opinion on DVCS/git
On 03/04/2015 08:55 PM, Michael J Gruber wrote: Yes, that article has a few really weak lines of arguments, such as the tutorial count. Here's his definition of the main draw of a DVCS: No, the only thing that a DVCS gets you, by definition, is that everyone gets a copy of the full offline history of the entire repository to do with as you please. That completely misses the point. What about committing while offline, 'git blame' months-old changes offline, or local branches that don't have to make it to the server until they have cooked for a while, and so on and on? We're not all facebooks with multi-GB repos, and I certainly don't care as much about disk space or bandwidth if losing those features is the cost. It gets worse: Let me tell you something. Of all the time I have ever used DVCSes, over the last twenty years if we count Smalltalk changesets and twelve or so if you don’t, I have wanted to have the full history while offline a grand total of maybe about six times. I don't know how you can work on anything reasonably complex and multi-developer without using some of those features six times in a *week* (sometimes, six times in a *weekend*) let alone 12 years. -- 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
Surprising interaction of binary and eol gitattributes
I would expect that the following .gitattributes file * eol=crlf *.png -text would leave EOL translation turned off for PNG files. In other words, I would expect that explicitly setting -text would take precedence over the fact that setting eol implies that a file should be considered to be text. I would even more strongly expect * eol=crlf *.png binary to turn off EOL translation for PNG files. But in fact, in both of the above cases, EOL translation is turned *on* for PNG files. I propose that -text should override any setting for eol (which would of course fix both problems, since binary is equivalent to -diff -merge -text). What do people think? Michael -- Michael Haggerty mhag...@alum.mit.edu -- 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? git submodule add SSL certificate problem: unable to get local issuer certificate
Hi, seems to be a bug: If adding a submodule from an https URL with a certificate issued by StartSSL (or even a private/self-signed one?) leads to the following error: $ git -c http.sslverify=false submodule add https://example.com/git/xxx.git Cloning into 'xxx'... fatal: unable to access 'https://example.com/git/xxx.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none Clone of 'https://example.com/git/xxx.git' into submodule path 'xxx' failed Performing a simple clone works well: $ git -c http.sslverify=false clone https://example.com/git/xxx.git Cloning into 'xxx'... Password for 'https://example.com': Cheers, Gerd -- Gerd Aschemann --- Veröffentlichen heißt Verändern (Carmen Thomas) +49/173/3264070 -- g...@aschemann.net -- http://www.aschemann.net signature.asc Description: Message signed with OpenPGP using GPGMail
[PATCH 1/5] xfdopen(): if first attempt fails, free memory and try again
One likely reason for the failure of fdopen() is a lack of free
memory.
Also expose a new function, fdopen_with_retry(), which retries on
ENOMEM but doesn't die() on errors. In a moment this function will be
used elsewhere.
Suggested-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
git-compat-util.h | 11 +++
wrapper.c | 28 +---
2 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 3455c5e..a5652a7 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -672,7 +672,18 @@ extern ssize_t xread(int fd, void *buf, size_t len);
extern ssize_t xwrite(int fd, const void *buf, size_t len);
extern ssize_t xpread(int fd, void *buf, size_t len, off_t offset);
extern int xdup(int fd);
+
+/*
+ * Like fdopen(), but if the first attempt fails with ENOMEM, try to
+ * free up some memory and try again.
+ */
+extern FILE *fdopen_with_retry(int fd, const char *mode);
+
+/*
+ * Like fdopen_with_retry(), but die on errors.
+ */
extern FILE *xfdopen(int fd, const char *mode);
+
extern int xmkstemp(char *template);
extern int xmkstemp_mode(char *template, int mode);
extern int odb_mkstemp(char *template, size_t limit, const char *pattern);
diff --git a/wrapper.c b/wrapper.c
index d5a6cef..b60cc03 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -311,14 +311,36 @@ int xdup(int fd)
return ret;
}
-FILE *xfdopen(int fd, const char *mode)
+FILE *fdopen_with_retry(int fd, const char *mode)
{
FILE *stream = fdopen(fd, mode);
- if (stream == NULL)
- die_errno(Out of memory? fdopen failed);
+
+ if (!stream errno == ENOMEM) {
+ /*
+* Try to free up some memory, then try again. We
+* would prefer to use sizeof(FILE) here, but that is
+* not guaranteed to be defined (e.g., FILE might be
+* an incomplete type).
+*/
+ try_to_free_routine(1000);
+ stream = fdopen(fd, mode);
+ }
+
return stream;
}
+FILE *xfdopen(int fd, const char *mode)
+{
+ FILE *stream = fdopen_with_retry(fd, mode);
+
+ if (stream)
+ return stream;
+ else if (errno == ENOMEM)
+ die_errno(Out of memory? fdopen failed);
+ else
+ die_errno(fdopen failed);
+}
+
int xmkstemp(char *template)
{
int fd;
--
2.1.4
--
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/5] xfdopen(): if first attempt fails, free memory and try again
On Thu, Mar 5, 2015 at 8:07 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
One likely reason for the failure of fdopen() is a lack of free
memory.
Also expose a new function, fdopen_with_retry(), which retries on
ENOMEM but doesn't die() on errors. In a moment this function will be
used elsewhere.
Suggested-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
git-compat-util.h | 11 +++
wrapper.c | 28 +---
2 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 3455c5e..a5652a7 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -672,7 +672,18 @@ extern ssize_t xread(int fd, void *buf, size_t len);
extern ssize_t xwrite(int fd, const void *buf, size_t len);
extern ssize_t xpread(int fd, void *buf, size_t len, off_t offset);
extern int xdup(int fd);
+
+/*
+ * Like fdopen(), but if the first attempt fails with ENOMEM, try to
+ * free up some memory and try again.
+ */
+extern FILE *fdopen_with_retry(int fd, const char *mode);
+
+/*
+ * Like fdopen_with_retry(), but die on errors.
Rather like fdopen, but die on errors?
When reading this before looking at the implementation below,
I thought this would behave like
FILE *xfdopen() {
FILE *stream = fdopen(fd, mode);
if (stream == NULL)
die_errno(Out of memory? fdopen failed);
return stream;
}
which has no retrying. I kind of read that comment that way.
Maybe
This opens a FILE* handle, but tries
to deal with some errors. If unsuccessful it dies,
which guarantees to have a valid FILE* if returning.
?
I dunno.
+ */
extern FILE *xfdopen(int fd, const char *mode);
+
extern int xmkstemp(char *template);
extern int xmkstemp_mode(char *template, int mode);
extern int odb_mkstemp(char *template, size_t limit, const char *pattern);
diff --git a/wrapper.c b/wrapper.c
index d5a6cef..b60cc03 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -311,14 +311,36 @@ int xdup(int fd)
return ret;
}
-FILE *xfdopen(int fd, const char *mode)
+FILE *fdopen_with_retry(int fd, const char *mode)
{
FILE *stream = fdopen(fd, mode);
- if (stream == NULL)
- die_errno(Out of memory? fdopen failed);
+
+ if (!stream errno == ENOMEM) {
+ /*
+* Try to free up some memory, then try again. We
+* would prefer to use sizeof(FILE) here, but that is
+* not guaranteed to be defined (e.g., FILE might be
+* an incomplete type).
+*/
+ try_to_free_routine(1000);
+ stream = fdopen(fd, mode);
+ }
+
return stream;
}
+FILE *xfdopen(int fd, const char *mode)
+{
+ FILE *stream = fdopen_with_retry(fd, mode);
+
+ if (stream)
+ return stream;
+ else if (errno == ENOMEM)
+ die_errno(Out of memory? fdopen failed);
+ else
+ die_errno(fdopen failed);
My gut feeling dislikes the distinction of different errors here just
to pass in a different string to die. The die_errno will already print
an appropriate message depending on the errno set. So I'd
rather have no distinction here.
If you want to have a different message for the case of ENOMEM,
I'd rather put it into fdopen_with_retry, which then uses a loop or
counted goto [ I've seen that in the refs code:
if (nr_retries MAX_RETRIES)
goto retry_again;
]
+}
+
int xmkstemp(char *template)
{
int fd;
--
2.1.4
--
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
Possible bug with git-rebase and post-rewrite hook
Hi, I have a suspect case which happens when rebasing a branch. I'm using the post-rewrite hook and during certain circumstance, my hook is called by git-rebase with wrong parameters: old-sha1 argument is not related to new-sha1 one. This actually happens when git-rebase stops and reports: The previous cherry-pick is now empty, possibly due to conflict resolution. If you wish to commit it anyway, use: git commit --allow-empty Otherwise, please use 'git reset' rebase in progress; onto 2889531 You are currently rebasing branch 'foo' on '2889531'. If I decide to skip it by doing 'git rebase --continue' then I get the issue when my hook is run. BTW, I find that the message is not really clear since it tells me to run 'git-reset' in the case I want to ignore this empty commit. I'm not sure that 'git-reset' is really helping in that case (my index is clean) but 'git rebase --continue' would have been more appropriate IMHO. If I do 'git commit --allow-empty' then there's no issue when the hook is run. 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: Possible bug with git-rebase and post-rewrite hook
oops, I forgot to say that this happen with git 2.3.1. On 03/05/2015 02:55 PM, Francis Moreau wrote: Hi, I have a suspect case which happens when rebasing a branch. I'm using the post-rewrite hook and during certain circumstance, my hook is called by git-rebase with wrong parameters: old-sha1 argument is not related to new-sha1 one. This actually happens when git-rebase stops and reports: The previous cherry-pick is now empty, possibly due to conflict resolution. If you wish to commit it anyway, use: git commit --allow-empty Otherwise, please use 'git reset' rebase in progress; onto 2889531 You are currently rebasing branch 'foo' on '2889531'. If I decide to skip it by doing 'git rebase --continue' then I get the issue when my hook is run. BTW, I find that the message is not really clear since it tells me to run 'git-reset' in the case I want to ignore this empty commit. I'm not sure that 'git-reset' is really helping in that case (my index is clean) but 'git rebase --continue' would have been more appropriate IMHO. If I do 'git commit --allow-empty' then there's no issue when the hook is run. 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: [RFC/PATCH 0/3] protocol v2
On Wed, Mar 4, 2015 at 5:03 PM, Stefan Beller sbel...@google.com wrote: If anyone wants to experiment with the data I gathered, I can make them available. All data of `ls-remote` including the gathering script is found at (112 kB .tar.xz) https://drive.google.com/file/d/0B7E93UKgFAfjcHRvM1N2YjBfTzA/view?usp=sharing (6.6MB in .zip) https://drive.google.com/file/d/0B7E93UKgFAfjRko3WHhtUWZtTEU/view?usp=sharing I also do have all the object files which are referenced in the outputs of ls-remote, though sharing them is a bit tough as I cannot just git push them (forced pushes make some of the objects unreachable, so my local gathering repo is explicitly configured to not garbage collect), and these are huge compared to just the output of ls-remote. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] update_info_file(): use fdopen_with_retry()
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- server-info.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/server-info.c b/server-info.c index 34b0253..8c6f662 100644 --- a/server-info.c +++ b/server-info.c @@ -20,7 +20,7 @@ static int update_info_file(char *path, int (*generate)(FILE *)) fd = git_mkstemp_mode(tmp, 0666); if (fd 0) goto out; - fp = fdopen(fd, w); + fp = fdopen_with_retry(fd, w); if (!fp) goto out; ret = generate(fp); -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] buffer_fdinit(): use fdopen_with_retry()
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
vcs-svn/line_buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/vcs-svn/line_buffer.c b/vcs-svn/line_buffer.c
index 57cc1ce..10791cf 100644
--- a/vcs-svn/line_buffer.c
+++ b/vcs-svn/line_buffer.c
@@ -19,7 +19,7 @@ int buffer_init(struct line_buffer *buf, const char *filename)
int buffer_fdinit(struct line_buffer *buf, int fd)
{
- buf-infile = fdopen(fd, r);
+ buf-infile = fdopen_with_retry(fd, r);
if (!buf-infile)
return -1;
return 0;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] Retry if fdopen() fails due to ENOMEM
One likely reason for fdopen() to fail is the lack of memory for allocating a FILE structure. When that happens, try freeing some memory and calling fdopen() again in the hope that it will work the second time. This change was suggested by Jonathan Nieder [1] In the first patch it is unsatisfying that try_to_free_routine() is called with a magic number (1000) rather than sizeof(FILE). But the C standard doesn't guarantee that FILE is a complete type, so I can't think of a better approach. Suggestions, anybody? Michael [1] http://article.gmane.org/gmane.comp.version-control.git/260848 Michael Haggerty (5): xfdopen(): if first attempt fails, free memory and try again fdopen_lock_file(): use fdopen_with_retry() copy_to_log(): use fdopen_with_retry() update_info_file(): use fdopen_with_retry() buffer_fdinit(): use fdopen_with_retry() daemon.c | 4 ++-- git-compat-util.h | 11 +++ lockfile.c| 2 +- server-info.c | 2 +- vcs-svn/line_buffer.c | 2 +- wrapper.c | 28 +--- 6 files changed, 41 insertions(+), 8 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] fdopen_lock_file(): use fdopen_with_retry()
Suggested-by: Jonathan Nieder jrnie...@gmail.com Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- Jonathan's original suggestion was that this function should call xfdopen(). But a couple of callers of fdopen_lock_file() try to recover if it fails, so I decided to do it this way instead. lockfile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lockfile.c b/lockfile.c index 9889277..cad567b 100644 --- a/lockfile.c +++ b/lockfile.c @@ -232,7 +232,7 @@ FILE *fdopen_lock_file(struct lock_file *lk, const char *mode) if (lk-fp) die(BUG: fdopen_lock_file() called twice for file '%s', lk-filename.buf); - lk-fp = fdopen(lk-fd, mode); + lk-fp = fdopen_with_retry(lk-fd, mode); return lk-fp; } -- 2.1.4 -- 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] archive-zip: add --text parameter
Am 04.03.2015 um 22:13 schrieb René Scharfe:
diff --git a/archive-zip.c b/archive-zip.c
index 4bde019..3767940 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -5,6 +5,7 @@
#include archive.h
#include streaming.h
#include utf8.h
+#include xdiff-interface.h
static int zip_date;
static int zip_time;
@@ -210,6 +211,7 @@ static int write_zip_entry(struct archiver_args *args,
struct git_istream *stream = NULL;
unsigned long flags = 0;
unsigned long size;
+ int is_binary = -1;
crc = crc32(0, NULL, 0);
@@ -238,8 +240,14 @@ static int write_zip_entry(struct archiver_args *args,
method = 0;
attr2 = S_ISLNK(mode) ? ((mode | 0777) 16) :
(mode 0111) ? ((mode) 16) : 0;
- if (S_ISREG(mode) args-compression_level != 0 size 0)
- method = 8;
+ if (S_ISREG(mode)) {
+ if (args-compression_level != 0 size 0)
+ method = 8;
+ if (args-text == ARCHIVE_TEXT_ALL)
+ is_binary = 0;
+ else if (args-text == ARCHIVE_TEXT_NONE)
+ is_binary = 1;
+ }
if (S_ISREG(mode) type == OBJ_BLOB !args-convert
size big_file_threshold) {
@@ -256,6 +264,8 @@ static int write_zip_entry(struct archiver_args *args,
return error(cannot read %s,
sha1_to_hex(sha1));
crc = crc32(crc, buffer, size);
+ if (is_binary 0)
+ is_binary = buffer_is_binary(buffer, size);
out = buffer;
}
compressed_size = (method == 0) ? size : 0;
@@ -300,7 +310,6 @@ static int write_zip_entry(struct archiver_args *args,
copy_le16(dirent.extra_length, ZIP_EXTRA_MTIME_SIZE);
copy_le16(dirent.comment_length, 0);
copy_le16(dirent.disk, 0);
- copy_le16(dirent.attr1, 0);
copy_le32(dirent.attr2, attr2);
copy_le32(dirent.offset, zip_offset);
@@ -328,6 +337,8 @@ static int write_zip_entry(struct archiver_args *args,
if (readlen = 0)
break;
crc = crc32(crc, buf, readlen);
+ if (is_binary 0)
+ is_binary = buffer_is_binary(buffer, size);
buffer is NULL here, so this crashes. buf and readlen have to be used
instead. This code path is only used for entries that are too big to be
compressed in one go.
write_or_die(1, buf, readlen);
}
close_istream(stream);
@@ -361,6 +372,8 @@ static int write_zip_entry(struct archiver_args *args,
if (readlen = 0)
break;
crc = crc32(crc, buf, readlen);
+ if (is_binary 0)
+ is_binary = buffer_is_binary(buffer, size);
Same here.
zstream.next_in = buf;
zstream.avail_in = readlen;
@@ -405,6 +418,8 @@ static int write_zip_entry(struct archiver_args *args,
free(deflated);
free(buffer);
+ copy_le16(dirent.attr1, !is_binary);
+
memcpy(zip_dir + zip_dir_offset, dirent, ZIP_DIR_HEADER_SIZE);
zip_dir_offset += ZIP_DIR_HEADER_SIZE;
memcpy(zip_dir + zip_dir_offset, path, pathlen);
@@ -466,7 +481,7 @@ static int write_zip_archive(const struct archiver *ar,
static struct archiver zip_archiver = {
zip,
write_zip_archive,
- ARCHIVER_WANT_COMPRESSION_LEVELS|ARCHIVER_REMOTE
+ ARCHIVER_WANT_COMPRESSION_LEVELS|ARCHIVER_REMOTE|ARCHIVER_TEXT_ATTRIBUTE
};
void init_zip_archiver(void)
--
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] archive-zip: add --text parameter
Am 05.03.2015 um 03:16 schrieb Junio C Hamano: René Scharfe l@web.de writes: No sign-off, yet, because I'm not sure we really need another option. E.g. --text=all doesn't seem to be actually useful, but it was easy to implement. Info-ZIP's zip always creates archives like --text=auto does, so perhaps we should make that our default behavior as well? My knee-jerk reaction is yeah, why not? what are the downsides, other than the result will not be bit-for-bit identical to the output from older Git. I am sure I am missing something as I do not regularly use this format. AFAICS there won't be any other downsides. And archive stability is harder to achieve for ZIP anyway because it depends on compression level and (more fundamentally) on libz version. @@ -256,6 +264,8 @@ static int write_zip_entry(struct archiver_args *args, return error(cannot read %s, sha1_to_hex(sha1)); crc = crc32(crc, buffer, size); + if (is_binary 0) + is_binary = buffer_is_binary(buffer, size); In this codepath, do you have the path of the thing the buffer contents came from? I am wondering if consulting the attributes system is a better idea. Anything that is explicitly marked as binary or -diff is definitely binary, and anything that is not marked as binary is text to us for all practical purposes, no? Yes, attributes can help, especially to allow users to correct wrong guesses of the heuristic. Offering automatic detection of binary files by default like git diff and git grep is still a good idea, I think. buffer_is_binary() doesn't add a lot of overhead since it only looks at the first few bytes of the buffer. René -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] copy_to_log(): use fdopen_with_retry()
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
daemon.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/daemon.c b/daemon.c
index c3edd96..1d76ccf 100644
--- a/daemon.c
+++ b/daemon.c
@@ -421,8 +421,8 @@ static void copy_to_log(int fd)
struct strbuf line = STRBUF_INIT;
FILE *fp;
- fp = fdopen(fd, r);
- if (fp == NULL) {
+ fp = fdopen_with_retry(fd, r);
+ if (!fp) {
logerror(fdopen of error channel failed);
close(fd);
return;
--
2.1.4
--
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/3] cat-file: add --literally option
Third version of the patch submitted to add -literlly option to cat-file http://article.gmane.org/gmane.comp.version-control.git/264383 Thanks to Eric, Junio and David for suggesting changes on my first version. Thanks to Junio for suggestions on my second version. Changes from previous version : * Made sure no end-user printing is taking place in sha1_file.c, now the printing takes place in cat-file.c * Did not credit Junio on whose work i based my patch, Propoer credits given in the commit message in v3. -- 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/3] cache: modify for cat-file --literally -t
Add a struct strbuf *typename to object_info to hold the
typename when the literally option is used. Add a flag to
notify functions when literally is used.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
cache.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cache.h b/cache.h
index 4d02efc..949ef4c 100644
--- a/cache.h
+++ b/cache.h
@@ -830,6 +830,7 @@ extern int is_ntfs_dotgit(const char *name);
/* object replacement */
#define LOOKUP_REPLACE_OBJECT 1
+#define LOOKUP_LITERALLY 2
extern void *read_sha1_file_extended(const unsigned char *sha1, enum
object_type *type, unsigned long *size, unsigned flag);
static inline void *read_sha1_file(const unsigned char *sha1, enum object_type
*type, unsigned long *size)
{
@@ -1296,6 +1297,7 @@ struct object_info {
unsigned long *sizep;
unsigned long *disk_sizep;
unsigned char *delta_base_sha1;
+ struct strbuf *typename;
/* Response */
enum {
--
2.3.1.167.g7f4ba4b.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 v3 2/3] sha1_file: implement changes for cat-file --literally -t
Add sha1_object_info_literally() which is to be used when
the literally option is given to get the type of object
and return it. It internally uses sha1_object_info_extended().
Add unpack_sha1_header_literally() to unpack sha headers
which may be greater than 32 bytes, which is the threshold
for a regular object header. This code is borrowed from the
suggestions given by Junio C Hamano, it has been tested by me.
Modify sha1_loose_object_info() to include a flag argument
and also include changes to call unpack_sha1_header_literally()
when the literally flag is passed. Also copies the obtained
type to the typename field of object_info.
Modify sha1_object_info_extended() to call the function
sha1_loose_object_info() with flags.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
sha1_file.c | 83 +++--
1 file changed, 76 insertions(+), 7 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 69a60ec..b9e3922 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1564,6 +1564,36 @@ int unpack_sha1_header(git_zstream *stream, unsigned
char *map, unsigned long ma
return git_inflate(stream, 0);
}
+static int unpack_sha1_header_literally(git_zstream *stream, unsigned char
*map,
+ unsigned long mapsize,
+ struct strbuf *header)
+{
+ unsigned char buffer[32], *cp;
+ unsigned long bufsiz = sizeof(buffer);
+ int status;
+
+ /* Get the data stream */
+ memset(stream, 0, sizeof(*stream));
+ stream-next_in = map;
+ stream-avail_in = mapsize;
+ stream-next_out = buffer;
+ stream-avail_out = bufsiz;
+
+ git_inflate_init(stream);
+
+ do {
+ status = git_inflate(stream, 0);
+ strbuf_add(header, buffer, stream-next_out - buffer);
+ for (cp = buffer; cp stream-next_out; cp++)
+ if (!*cp)
+ /* Found the NUL at the end of the header */
+ return 0;
+ stream-next_out = buffer;
+ stream-avail_out = bufsiz;
+ } while (status == Z_OK);
+ return -1;
+}
+
static void *unpack_sha1_rest(git_zstream *stream, void *buffer, unsigned long
size, const unsigned char *sha1)
{
int bytes = strlen(buffer) + 1;
@@ -2524,13 +2554,16 @@ struct packed_git *find_sha1_pack(const unsigned char
*sha1,
}
static int sha1_loose_object_info(const unsigned char *sha1,
- struct object_info *oi)
+ struct object_info *oi,
+ int flags)
{
- int status;
+ int status = 0;
unsigned long mapsize, size;
void *map;
git_zstream stream;
char hdr[32];
+ struct strbuf hdrbuf = STRBUF_INIT;
+ char *hdrp;
if (oi-delta_base_sha1)
hashclr(oi-delta_base_sha1);
@@ -2557,10 +2590,25 @@ static int sha1_loose_object_info(const unsigned char
*sha1,
return -1;
if (oi-disk_sizep)
*oi-disk_sizep = mapsize;
- if (unpack_sha1_header(stream, map, mapsize, hdr, sizeof(hdr)) 0)
- status = error(unable to unpack %s header,
- sha1_to_hex(sha1));
- else if ((status = parse_sha1_header(hdr, size)) 0)
+ if ((flags LOOKUP_LITERALLY)) {
+ if (unpack_sha1_header_literally(stream, map, mapsize,
hdrbuf) 0)
+ status = error(unable to unpack %s header with
--literally,
+ sha1_to_hex(sha1));
+ hdrp = hdrbuf.buf;
+ } else {
+ if (unpack_sha1_header(stream, map, mapsize, hdr, sizeof(hdr))
0) {
+ status = error(unable to unpack %s header,
+ sha1_to_hex(sha1));
+ }
+ hdrp = hdr;
+ }
+ if (status)
+ ; /* We're already checking for errors */
+ else if ((flags LOOKUP_LITERALLY)) {
+ size_t typelen = strcspn(hdrbuf.buf, );
+ strbuf_add(oi-typename, hdrbuf.buf, typelen);
+ }
+ else if ((status = parse_sha1_header(hdrp, size)) 0)
status = error(unable to parse %s header, sha1_to_hex(sha1));
else if (oi-sizep)
*oi-sizep = size;
@@ -2568,6 +2616,10 @@ static int sha1_loose_object_info(const unsigned char
*sha1,
munmap(map, mapsize);
if (oi-typep)
*oi-typep = status;
+ if (oi-typename 0 = status typename(status))
+ strbuf_addstr(oi-typename, typename(status));
+ if (hdrp == hdrbuf.buf)
+ strbuf_release(hdrbuf);
return 0;
}
@@ -2594,7 +2646,7 @@ int sha1_object_info_extended(const unsigned char *sha1,
struct object_info *oi,
if
[PATCH v3 3/3] cat-file: add --literally option
made changes to cat-file to include a --literally
option which prints the type of the object without any
complaints.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
builtin/cat-file.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index df99df4..60b9ec4 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -9,7 +9,8 @@
#include userdiff.h
#include streaming.h
-static int cat_one_file(int opt, const char *exp_type, const char *obj_name)
+static int cat_one_file(int opt, const char *exp_type, const char *obj_name,
+ int literally)
{
unsigned char sha1[20];
enum object_type type;
@@ -23,6 +24,14 @@ static int cat_one_file(int opt, const char *exp_type, const
char *obj_name)
buf = NULL;
switch (opt) {
case 't':
+ if (literally) {
+ buf = sha1_object_info_literally(sha1);
+ if (!buf)
+ die(git cat-file --literally -t %s: failed,
+ obj_name);
+ printf(%s\n, buf);
+ return 0;
+ }
type = sha1_object_info(sha1, NULL);
if (type 0) {
printf(%s\n, typename(type));
@@ -323,7 +332,7 @@ static int batch_objects(struct batch_options *opt)
}
static const char * const cat_file_usage[] = {
- N_(git cat-file (-t | -s | -e | -p | type | --textconv) object),
+ N_(git cat-file (-t|-s|-e|-p|type|--textconv|-t --literally)
object),
N_(git cat-file (--batch | --batch-check) list-of-objects),
NULL
};
@@ -359,6 +368,7 @@ int cmd_cat_file(int argc, const char **argv, const char
*prefix)
int opt = 0;
const char *exp_type = NULL, *obj_name = NULL;
struct batch_options batch = {0};
+ int literally = 0;
const struct option options[] = {
OPT_GROUP(N_(type can be one of: blob, tree, commit, tag)),
@@ -369,6 +379,8 @@ int cmd_cat_file(int argc, const char **argv, const char
*prefix)
OPT_SET_INT('p', NULL, opt, N_(pretty-print object's
content), 'p'),
OPT_SET_INT(0, textconv, opt,
N_(for blob objects, run textconv on object's
content), 'c'),
+ OPT_BOOL( 0, literally, literally,
+ N_(show the type of the given loose object, use for
debugging)),
{ OPTION_CALLBACK, 0, batch, batch, format,
N_(show info and content of objects fed from the
standard input),
PARSE_OPT_OPTARG, batch_option_callback },
@@ -380,7 +392,7 @@ int cmd_cat_file(int argc, const char **argv, const char
*prefix)
git_config(git_cat_file_config, NULL);
- if (argc != 3 argc != 2)
+ if (argc != 3 argc != 2 argc != 4)
usage_with_options(cat_file_usage, options);
argc = parse_options(argc, argv, prefix, options, cat_file_usage, 0);
@@ -405,5 +417,10 @@ int cmd_cat_file(int argc, const char **argv, const char
*prefix)
if (batch.enabled)
return batch_objects(batch);
- return cat_one_file(opt, exp_type, obj_name);
+ if (literally opt == 't')
+ return cat_one_file(opt, exp_type, obj_name, literally);
+ else if (literally)
+ usage_with_options(cat_file_usage, options);
+
+ return cat_one_file(opt, exp_type, obj_name, literally);
}
--
2.3.1.167.g7f4ba4b.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 1/2] git-credential-store: support XDG config dir
Paul Tan pyoka...@gmail.com writes:
On Wed, Mar 4, 2015 at 7:01 AM, Junio C Hamano gits...@pobox.com wrote:
Paul Tan pyoka...@gmail.com writes:
struct credential entry = CREDENTIAL_INIT;
+ int found_credential = 0;
fh = fopen(fn, r);
if (!fh) {
if (errno != ENOENT)
die_errno(unable to open %s, fn);
- return;
+ return 0;
Returning found_credential here would be easier to read, no? After
all, that is why you explicitly initialized it to 0 up there to say
no we haven't found any yet.
Actually I think die_errno is a function that does not return at all.
The return is just to shut the compiler up. Perhaps I shall comment
that.
Commenting just on this part (I am not agreeing or disagreeing with
you on other parts of your message yet).
When fopen() fails because we cannot open an existing file for
reading, then die_errno() will trigger and we stop there, in which
case the return will not be reached.
But when we try to open fn and we fail only because fn does not
exist, we do not say die. We instead return to the caller,
telling it that we have not found any credential so far in the file
supplied by the caller.
So the return does matter, and spelling that zero with
found_credential does matter for readability, I would think.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git merge driver / attributes bug in 2.3.1?
Gondek, Andreas andreas.gon...@dwpbank.de writes: after upgrading the Git installation on one of our development servers from 1.9.0-rc3 to 2.3.1 we are experiencing strange behavior of merge drivers. Do you see the same with something slightly older, like say v2.2.0? The only change that I can think of offhand that may be related is 6ea358f7 (ll-merge.c: refactor `read_merge_config()` to use `git_config_string()`, 2014-08-13) that went into v2.2.0, but I don't immediately see how that would be related X-. -- 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/5] xfdopen(): if first attempt fails, free memory and try again
Michael Haggerty mhag...@alum.mit.edu writes:
One likely reason for the failure of fdopen() is a lack of free
memory.
Interesting.
Did you find this by code inspection?
Or did you actually hit this issue in real life, and applying this
patch helped? The latter would indicate that this failure is rather
common with your workload, and that Git can continue working even
when the process is so memory starved to cause fdopen() to fail.
Also expose a new function, fdopen_with_retry(), which retries on
ENOMEM but doesn't die() on errors. In a moment this function will be
used elsewhere.
Hmm, OK, I guess these three lines answers my question---asking that
question at this point in the series is moot ;-)
The code looks good.
Suggested-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
git-compat-util.h | 11 +++
wrapper.c | 28 +---
2 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 3455c5e..a5652a7 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -672,7 +672,18 @@ extern ssize_t xread(int fd, void *buf, size_t len);
extern ssize_t xwrite(int fd, const void *buf, size_t len);
extern ssize_t xpread(int fd, void *buf, size_t len, off_t offset);
extern int xdup(int fd);
+
+/*
+ * Like fdopen(), but if the first attempt fails with ENOMEM, try to
+ * free up some memory and try again.
+ */
+extern FILE *fdopen_with_retry(int fd, const char *mode);
+
+/*
+ * Like fdopen_with_retry(), but die on errors.
+ */
extern FILE *xfdopen(int fd, const char *mode);
+
extern int xmkstemp(char *template);
extern int xmkstemp_mode(char *template, int mode);
extern int odb_mkstemp(char *template, size_t limit, const char *pattern);
diff --git a/wrapper.c b/wrapper.c
index d5a6cef..b60cc03 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -311,14 +311,36 @@ int xdup(int fd)
return ret;
}
-FILE *xfdopen(int fd, const char *mode)
+FILE *fdopen_with_retry(int fd, const char *mode)
{
FILE *stream = fdopen(fd, mode);
- if (stream == NULL)
- die_errno(Out of memory? fdopen failed);
+
+ if (!stream errno == ENOMEM) {
+ /*
+ * Try to free up some memory, then try again. We
+ * would prefer to use sizeof(FILE) here, but that is
+ * not guaranteed to be defined (e.g., FILE might be
+ * an incomplete type).
+ */
+ try_to_free_routine(1000);
+ stream = fdopen(fd, mode);
+ }
+
return stream;
}
+FILE *xfdopen(int fd, const char *mode)
+{
+ FILE *stream = fdopen_with_retry(fd, mode);
+
+ if (stream)
+ return stream;
+ else if (errno == ENOMEM)
+ die_errno(Out of memory? fdopen failed);
+ else
+ die_errno(fdopen failed);
+}
+
int xmkstemp(char *template)
{
int fd;
--
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 v2] archive-zip: mark text files in archives
Set the text flag for ZIP archive entries that look like text files so
that unzip -a can be used to perform end-of-line conversions. Info-ZIP
zip does the same.
Detect binary files the same way as git diff and git grep do, namely by
checking for the attribute diff and its negation -diff, and if none
is found by falling back to checking for the presence of NUL bytes in
the first few bytes of the file contents.
7-Zip, Windows' built-in ZIP functionality and Info-ZIP unzip without
the switch -a are not affected by the change and still extract text
files without doing any end-of-line conversions.
NB: The actual end-of-line style used in the archive entries doesn't
matter to unzip -a, as it converts any CR, CRLF and LF to the line end
characters appropriate for the platform it is running on.
Suggested-by: Ulrike Fischer lua...@nililand.de
Signed-off-by: Rene Scharfe l@web.de
---
archive-zip.c | 25 -
t/t5003-archive-zip.sh | 47 ++-
2 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/archive-zip.c b/archive-zip.c
index 4bde019..0f9e87f 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -5,6 +5,8 @@
#include archive.h
#include streaming.h
#include utf8.h
+#include userdiff.h
+#include xdiff-interface.h
static int zip_date;
static int zip_time;
@@ -189,6 +191,16 @@ static int has_only_ascii(const char *s)
}
}
+static int entry_is_binary(const char *path, const void *buffer, size_t size)
+{
+ struct userdiff_driver *driver = userdiff_find_by_path(path);
+ if (!driver)
+ driver = userdiff_find_by_name(default);
+ if (driver-binary != -1)
+ return driver-binary;
+ return buffer_is_binary(buffer, size);
+}
+
#define STREAM_BUFFER_SIZE (1024 * 16)
static int write_zip_entry(struct archiver_args *args,
@@ -210,6 +222,8 @@ static int write_zip_entry(struct archiver_args *args,
struct git_istream *stream = NULL;
unsigned long flags = 0;
unsigned long size;
+ int is_binary = -1;
+ const char *path_without_prefix = path + args-baselen;
crc = crc32(0, NULL, 0);
@@ -256,6 +270,8 @@ static int write_zip_entry(struct archiver_args *args,
return error(cannot read %s,
sha1_to_hex(sha1));
crc = crc32(crc, buffer, size);
+ is_binary = entry_is_binary(path_without_prefix,
+ buffer, size);
out = buffer;
}
compressed_size = (method == 0) ? size : 0;
@@ -300,7 +316,6 @@ static int write_zip_entry(struct archiver_args *args,
copy_le16(dirent.extra_length, ZIP_EXTRA_MTIME_SIZE);
copy_le16(dirent.comment_length, 0);
copy_le16(dirent.disk, 0);
- copy_le16(dirent.attr1, 0);
copy_le32(dirent.attr2, attr2);
copy_le32(dirent.offset, zip_offset);
@@ -328,6 +343,9 @@ static int write_zip_entry(struct archiver_args *args,
if (readlen = 0)
break;
crc = crc32(crc, buf, readlen);
+ if (is_binary == -1)
+ is_binary = entry_is_binary(path_without_prefix,
+ buf, readlen);
write_or_die(1, buf, readlen);
}
close_istream(stream);
@@ -361,6 +379,9 @@ static int write_zip_entry(struct archiver_args *args,
if (readlen = 0)
break;
crc = crc32(crc, buf, readlen);
+ if (is_binary == -1)
+ is_binary = entry_is_binary(path_without_prefix,
+ buf, readlen);
zstream.next_in = buf;
zstream.avail_in = readlen;
@@ -405,6 +426,8 @@ static int write_zip_entry(struct archiver_args *args,
free(deflated);
free(buffer);
+ copy_le16(dirent.attr1, !is_binary);
+
memcpy(zip_dir + zip_dir_offset, dirent, ZIP_DIR_HEADER_SIZE);
zip_dir_offset += ZIP_DIR_HEADER_SIZE;
memcpy(zip_dir + zip_dir_offset, path, pathlen);
diff --git a/t/t5003-archive-zip.sh b/t/t5003-archive-zip.sh
index c929db5..14744b2 100755
--- a/t/t5003-archive-zip.sh
+++ b/t/t5003-archive-zip.sh
@@ -33,6 +33,37 @@ check_zip() {
test_expect_success UNZIP validate file contents
diff -r a ${dir_with_prefix}a
+
+ dir=eol_$1
+ dir_with_prefix=$dir/$2
+ extracted=${dir_with_prefix}a
+ original=a
+
+ test_expect_success UNZIP extract ZIP archive with EOL conversion '
+ (mkdir $dir cd $dir $GIT_UNZIP -a ../$zipfile)
+ '
+
+
Re: [PATCH] xmerge.c: fix xdl_merge to conform with the manual
On 04/03/15 23:01, Junio C Hamano wrote: Anton Trunov anton.a.tru...@gmail.com writes: For the code version before applying this patch the following scenario will take place if git merge -Xignore-all-space remote gets executed. base file: 1st line 2nd line master file: 1st line 2nd line with substantial change remote file: 1st line 2nd line merge result file: 1st line 2nd line with substantial change So essentially it does what git merge -s ours remote does in case if all their changes are trivial. This seems like reasonable solution to me: we _are_ trying to ignore whitespace changes and we are explicit about it. Now, the above makes readers wonder what happens when you merged master into the remote. I.e. in the opposite direction. Interesting observation. I'd like to point out that the patch doesn't change the way this merge works. But let us discuss it with the help of git log. The function xdl_merge() was introduced to the code base in commit 857b933e04bc21ce02043c3107c148f8dcbb4a01. As it was pointed out in 1cd12926cedb340d176db607e087495381032ce2 (t6023: merge-file fails to output anything for a degenerate merge) the merge-file command would just refuse to merge identical changes and produce output. Then in 5719db91ce5915ee07c50f1afdc94fe34e91529f (Change xdl_merge to generate output even for null merges) this was fixed. Let's return to the issue you've mentioned. According to the manual the merge result file should be: 1st line - our line 2nd line with substantial change - their line The problem with the current code that it doesn't work line-wise when at least one side has only whitespace changes. It just completely throws away a side without any changes and takes the other side. If we wanted to fix it then I'd suggest to completely remove the checks for null changes in xdl_merge() because xdl_do_merge() handles those. -- 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: weaning distributions off tarballs: extended verification of git tags
On 03/03/2015 12:44 AM, Junio C Hamano wrote: [...] I was about to suggest another alternative. Pretend as if Git internally used SHA-512 (or whatever hash you want to use) instead of SHA-1, compute the object names that way. Recompute the contents of a tree object is by replacing the 20-byte SHA-1 field in it with a field with whatever necessary length to hold the longer object names of elements in the tree. But then a realization hit me: what new value will be placed in the parent field in the commit object? You cannot have SHA-512 variant of commit object name without recomputing the whole history. Now, if the final objective is to replace signature of tarballs, does it matter to cover the commit object, or is it sufficient to cover the tree contents? The original goal was to replace a tarball signature, for which the alternative that you described above seems quite elegant. If the goal were really to certify the entire history, then none of the proposals that I have seen so far is adequate anyway, because none of them propose to include better than the original SHA-1s of the parent commits. Including other metadata from the release commit does not seem useful to me; how valuable is it to know the author and commit message of the last commit that happened to make it into a release? It would be more useful to know the SHA-1 of that commit, but that would presumably be included elsewhere in the packaging data used by the distribution. [...] Michael -- Michael Haggerty mhag...@alum.mit.edu -- 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 v2 1/2] git: make git -C '' cmd not to barf
It now acts like cd '' and does not barf and treats
it as a no-op, this is usefull if a caller function
does not want to change directory and hence gives no
path value, which would have generally caused git to
output an undesired error message.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
git.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/git.c b/git.c
index 8c7ee9c..ea92a64 100644
--- a/git.c
+++ b/git.c
@@ -204,10 +204,14 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
fprintf(stderr, No directory given for -C.\n
);
usage(git_usage_string);
}
- if (chdir((*argv)[1]))
- die_errno(Cannot change to '%s', (*argv)[1]);
- if (envchanged)
- *envchanged = 1;
+ if (*(*argv)[1] == 0)
+ ; /* Ignore as a directory */
+ else {
+ if (chdir((*argv)[1]))
+ die_errno(Cannot change to '%s',
(*argv)[1]);
+ if (envchanged)
+ *envchanged = 1;
+ }
(*argv)++;
(*argc)--;
} else {
--
2.3.1.167.g7f4ba4b.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 v2 2/2] git-C: Add test to check git -C ''
Add a test to check whether git -C '' works without giving an error. This is achieved by adding a commit and checking the log using git -C '' and comparing the log message with the commit message. Signed-off-by: Karthik Nayak karthik@gmail.com --- t/t0056-git-C.sh | 10 ++ 1 file changed, 10 insertions(+) diff --git a/t/t0056-git-C.sh b/t/t0056-git-C.sh index 99c0377..1cefd4a 100755 --- a/t/t0056-git-C.sh +++ b/t/t0056-git-C.sh @@ -1,3 +1,4 @@ + #!/bin/sh test_description='-C path option and its effects on other path-related options' @@ -81,4 +82,13 @@ test_expect_success 'Relative followed by fullpath: -C ./here -C /there is equ test_cmp expected actual ' +test_expect_success 'Should not barf when git -C cmd is used' ' + echo 1 a.txt + msg=initial a.txt + (git add a.txt git commit -m $msg) + echo $msg expected + git -C log --format=%s actual + test_cmp expected actual +' + test_done -- 2.3.1.167.g7f4ba4b.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: [RFH] GSoC 2015 application
On Thu, Mar 5, 2015 at 5:05 AM, Philip Oakley philipoak...@iee.org wrote: Given the mention of the GSoC ideas list, I thought it worth writing out one of my little ideas.. A possible idea is to add a date based variant of shallow clone : 'git clone --date when ...' in the same vein as the existing depth (shallow) clone. I do have plenty of topics to finish up. But I wanted to see how this feature would look like. I needed to write some code for that and for straightening my thoughts. Totally untested, but I think it looks cool :) I think this feature is feasible. The protocol and UI are still up in the air. Plenty of work for any student who wants to pick this up. Nguyễn Thái Ngọc Duy (6): upload-pack: move shallow deepen code out of receive_needs() upload-pack: move shallow sending code out of deepen() upload-pack: remove unused variable backup upload-pack: move unshallow sending code out of deepen() shallow.c: implement a generic shallow boundary finder based on rev-list upload-pack: example code to use get_shallow_commits_by_rev_list commit.h | 2 + shallow.c | 65 + upload-pack.c | 129 +- 3 files changed, 149 insertions(+), 47 deletions(-) -- 2.3.0.rc1.137.g477eb31 -- 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 v2 2/2] git-C: Add test to check git -C ''
Add a test to check whether git -C '' works without giving an error. This is achieved by adding a commit and checking the log using git -C '' and comparing the log message with the commit message. Signed-off-by: Karthik Nayak karthik@gmail.com --- t/t0056-git-C.sh | 10 ++ 1 file changed, 10 insertions(+) diff --git a/t/t0056-git-C.sh b/t/t0056-git-C.sh index 99c0377..1cefd4a 100755 --- a/t/t0056-git-C.sh +++ b/t/t0056-git-C.sh @@ -1,3 +1,4 @@ + #!/bin/sh test_description='-C path option and its effects on other path-related options' @@ -81,4 +82,13 @@ test_expect_success 'Relative followed by fullpath: -C ./here -C /there is equ test_cmp expected actual ' +test_expect_success 'Should not barf when git -C cmd is used' ' + echo 1 a.txt + msg=initial a.txt + (git add a.txt git commit -m $msg) + echo $msg expected + git -C log --format=%s actual + test_cmp expected actual +' + test_done -- 2.3.1.167.g7f4ba4b.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 v2 2/2] git-C: Add test to check git -C ''
On 03/05/2015 04:27 PM, Karthik Nayak wrote: Add a test to check whether git -C '' works without giving an error. This is achieved by adding a commit and checking the log using git -C '' and comparing the log message with the commit message. Signed-off-by: Karthik Nayak karthik@gmail.com --- t/t0056-git-C.sh | 10 ++ 1 file changed, 10 insertions(+) diff --git a/t/t0056-git-C.sh b/t/t0056-git-C.sh index 99c0377..1cefd4a 100755 --- a/t/t0056-git-C.sh +++ b/t/t0056-git-C.sh @@ -1,3 +1,4 @@ + #!/bin/sh test_description='-C path option and its effects on other path-related options' @@ -81,4 +82,13 @@ test_expect_success 'Relative followed by fullpath: -C ./here -C /there is equ test_cmp expected actual ' +test_expect_success 'Should not barf when git -C cmd is used' ' +echo 1 a.txt +msg=initial a.txt +(git add a.txt git commit -m $msg) +echo $msg expected +git -C log --format=%s actual +test_cmp expected actual +' + test_done Ignore This, Didnt connect it to the first patch! -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] shallow.c: implement a generic shallow boundary finder based on rev-list
Instead of a custom commit walker like get_shallow_commits(), this new
function uses rev-list to mark SHALLOW to all reachable commits. The
definition of reachable is to be defined by the protocol later. This
makes it more flexible to define shallow boundary.
Note: if a commit has one not_shallow parent and one shallow parent,
then it's considered the boundary. Which means in the client side,
this commit has _no_ parents. This could lead to surprising cuts if
we're not careful.
Another option is to include more commits and only mark commits whose
all parents are not-shallow as boundary.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
commit.h | 2 ++
shallow.c | 65 +++
2 files changed, 67 insertions(+)
diff --git a/commit.h b/commit.h
index 9f189cb..5c80eea 100644
--- a/commit.h
+++ b/commit.h
@@ -254,6 +254,8 @@ extern int for_each_commit_graft(each_commit_graft_fn, void
*);
extern int is_repository_shallow(void);
extern struct commit_list *get_shallow_commits(struct object_array *heads,
int depth, int shallow_flag, int not_shallow_flag);
+extern struct commit_list *get_shallow_commits_by_rev_list(
+ int ac, const char **av, int shallow_flag, int
not_shallow_flag);
extern void set_alternate_shallow_file(const char *path, int override);
extern int write_shallow_commits(struct strbuf *out, int use_pack_protocol,
const struct sha1_array *extra);
diff --git a/shallow.c b/shallow.c
index d8bf40a..1db2768 100644
--- a/shallow.c
+++ b/shallow.c
@@ -10,6 +10,8 @@
#include revision.h
#include commit-slab.h
#include sigchain.h
+#include revision.h
+#include list-objects.h
static int is_shallow = -1;
static struct stat_validity shallow_stat;
@@ -137,6 +139,69 @@ struct commit_list *get_shallow_commits(struct
object_array *heads, int depth,
return result;
}
+static void show_commit(struct commit *commit, void *data)
+{
+ commit-object.flags |= *(int *)data;
+}
+
+struct commit_list *get_shallow_commits_by_rev_list(int ac, const char **av,
+ int shallow_flag, int
not_shallow_flag)
+{
+ struct commit_list *result = NULL;
+ struct rev_info revs;
+ unsigned int i, nr;
+
+ /*
+* SHALLOW and NOT_SHALLOW should not be set at this
+* point. But better be safe than sorry.
+*/
+ nr = get_max_object_index();
+ for (i = 0; i nr; i++) {
+ struct object *o = get_indexed_object(i);
+ o-flags = ~(shallow_flag | not_shallow_flag);
+ }
+
+ is_repository_shallow(); /* make sure shallows are read */
+
+ init_revisions(revs, NULL);
+ save_commit_buffer = 0;
+ setup_revisions(ac, av, revs, NULL);
+
+ /* mark all reachable commits as SHALLOW */
+ if (prepare_revision_walk(revs))
+ die(revision walk setup failed);
+ traverse_commit_list(revs, show_commit, NULL, shallow_flag);
+
+ nr = get_max_object_index();
+ for (i = 0; i nr; i++) {
+ struct object *o = get_indexed_object(i);
+ struct commit *c = (struct commit *)o;
+ struct commit_list *p;
+ int parent_is_not_shallow = 0;
+
+ if (o-type != OBJ_COMMIT || !(o-flags shallow_flag))
+ continue;
+
+ if (parse_commit(c))
+ die(unable to parse commit %s,
+ sha1_to_hex(c-object.sha1));
+
+ for (p = c-parents; p; p = p-next) {
+ if (p-item-object.flags shallow_flag)
+ continue;
+ parent_is_not_shallow = 1;
+ if (p-item-object.flags not_shallow_flag)
+ continue;
+ p-item-object.flags |= not_shallow_flag;
+ commit_list_insert(p-item, result);
+ }
+
+ if (parent_is_not_shallow)
+ commit_list_insert(c, result);
+ }
+ return result;
+}
+
static void check_shallow_file_for_update(void)
{
if (is_shallow == -1)
--
2.3.0.rc1.137.g477eb31
--
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/6] upload-pack: remove unused variable backup
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
upload-pack.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index ea030f3..79f5525 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -547,7 +547,7 @@ static void send_shallow(struct commit_list *result)
static void deepen(int depth, const struct object_array *shallows)
{
- struct commit_list *result = NULL, *backup = NULL;
+ struct commit_list *result = NULL;
int i;
if (depth == INFINITE_DEPTH !is_repository_shallow())
for (i = 0; i shallows-nr; i++) {
@@ -555,11 +555,11 @@ static void deepen(int depth, const struct object_array
*shallows)
object-flags |= NOT_SHALLOW;
}
else
- backup = result =
+ result =
get_shallow_commits(want_obj, depth,
SHALLOW, NOT_SHALLOW);
send_shallow(result);
- free_commit_list(backup);
+ free_commit_list(result);
for (i = 0; i shallows-nr; i++) {
struct object *object = shallows-objects[i].item;
if (object-flags NOT_SHALLOW) {
--
2.3.0.rc1.137.g477eb31
--
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/6] upload-pack: move unshallow sending code out of deepen()
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
upload-pack.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 79f5525..69a3828 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -545,21 +545,10 @@ static void send_shallow(struct commit_list *result)
}
}
-static void deepen(int depth, const struct object_array *shallows)
+static void send_unshallow(const struct object_array *shallows)
{
- struct commit_list *result = NULL;
int i;
- if (depth == INFINITE_DEPTH !is_repository_shallow())
- for (i = 0; i shallows-nr; i++) {
- struct object *object = shallows-objects[i].item;
- object-flags |= NOT_SHALLOW;
- }
- else
- result =
- get_shallow_commits(want_obj, depth,
- SHALLOW, NOT_SHALLOW);
- send_shallow(result);
- free_commit_list(result);
+
for (i = 0; i shallows-nr; i++) {
struct object *object = shallows-objects[i].item;
if (object-flags NOT_SHALLOW) {
@@ -582,6 +571,24 @@ static void deepen(int depth, const struct object_array
*shallows)
/* make sure commit traversal conforms to client */
register_shallow(object-sha1);
}
+}
+
+static void deepen(int depth, const struct object_array *shallows)
+{
+ struct commit_list *result = NULL;
+ int i;
+ if (depth == INFINITE_DEPTH !is_repository_shallow())
+ for (i = 0; i shallows-nr; i++) {
+ struct object *object = shallows-objects[i].item;
+ object-flags |= NOT_SHALLOW;
+ }
+ else
+ result =
+ get_shallow_commits(want_obj, depth,
+ SHALLOW, NOT_SHALLOW);
+ send_shallow(result);
+ free_commit_list(result);
+ send_unshallow(shallows);
packet_flush(1);
}
--
2.3.0.rc1.137.g477eb31
--
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 6/6] upload-pack: example code to use get_shallow_commits_by_rev_list
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
upload-pack.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/upload-pack.c b/upload-pack.c
index 69a3828..e616e19 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -592,6 +592,18 @@ static void deepen(int depth, const struct object_array
*shallows)
packet_flush(1);
}
+static void deepen_by_rev_list(int ac, const char **av,
+ struct object_array *shallows)
+{
+ struct commit_list *result;
+
+ result = get_shallow_commits_by_rev_list(ac, av, SHALLOW, NOT_SHALLOW);
+ send_shallow(result);
+ free_commit_list(result);
+ send_unshallow(shallows);
+ packet_flush(1);
+}
+
static void receive_needs(void)
{
struct object_array shallows = OBJECT_ARRAY_INIT;
@@ -686,6 +698,12 @@ static void receive_needs(void)
return;
if (depth 0)
deepen(depth, shallows);
+#if 0
+ else if (since_is_specified) {
+ /* prepare ac, av */
+ deepen_by_rev_list(ac, av, shallows);
+ }
+#endif
else
if (shallows.nr 0) {
int i;
--
2.3.0.rc1.137.g477eb31
--
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/6] upload-pack: move shallow sending code out of deepen()
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
upload-pack.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 74f48f9..ea030f3 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -531,6 +531,20 @@ error:
}
}
+static void send_shallow(struct commit_list *result)
+{
+ while (result) {
+ struct object *object = result-item-object;
+ if (!(object-flags (CLIENT_SHALLOW|NOT_SHALLOW))) {
+ packet_write(1, shallow %s,
+sha1_to_hex(object-sha1));
+ register_shallow(object-sha1);
+ shallow_nr++;
+ }
+ result = result-next;
+ }
+}
+
static void deepen(int depth, const struct object_array *shallows)
{
struct commit_list *result = NULL, *backup = NULL;
@@ -544,16 +558,7 @@ static void deepen(int depth, const struct object_array
*shallows)
backup = result =
get_shallow_commits(want_obj, depth,
SHALLOW, NOT_SHALLOW);
- while (result) {
- struct object *object = result-item-object;
- if (!(object-flags (CLIENT_SHALLOW|NOT_SHALLOW))) {
- packet_write(1, shallow %s,
-sha1_to_hex(object-sha1));
- register_shallow(object-sha1);
- shallow_nr++;
- }
- result = result-next;
- }
+ send_shallow(result);
free_commit_list(backup);
for (i = 0; i shallows-nr; i++) {
struct object *object = shallows-objects[i].item;
--
2.3.0.rc1.137.g477eb31
--
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/6] upload-pack: move shallow deepen code out of receive_needs()
This is a prep step for further refactoring. Besides reindentation and
s/shallows\./shallows-/g, no other changes are expected.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
upload-pack.c | 99 +++
1 file changed, 52 insertions(+), 47 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index b531a32..74f48f9 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -531,6 +531,55 @@ error:
}
}
+static void deepen(int depth, const struct object_array *shallows)
+{
+ struct commit_list *result = NULL, *backup = NULL;
+ int i;
+ if (depth == INFINITE_DEPTH !is_repository_shallow())
+ for (i = 0; i shallows-nr; i++) {
+ struct object *object = shallows-objects[i].item;
+ object-flags |= NOT_SHALLOW;
+ }
+ else
+ backup = result =
+ get_shallow_commits(want_obj, depth,
+ SHALLOW, NOT_SHALLOW);
+ while (result) {
+ struct object *object = result-item-object;
+ if (!(object-flags (CLIENT_SHALLOW|NOT_SHALLOW))) {
+ packet_write(1, shallow %s,
+sha1_to_hex(object-sha1));
+ register_shallow(object-sha1);
+ shallow_nr++;
+ }
+ result = result-next;
+ }
+ free_commit_list(backup);
+ for (i = 0; i shallows-nr; i++) {
+ struct object *object = shallows-objects[i].item;
+ if (object-flags NOT_SHALLOW) {
+ struct commit_list *parents;
+ packet_write(1, unshallow %s,
+sha1_to_hex(object-sha1));
+ object-flags = ~CLIENT_SHALLOW;
+ /* make sure the real parents are parsed */
+ unregister_shallow(object-sha1);
+ object-parsed = 0;
+ parse_commit_or_die((struct commit *)object);
+ parents = ((struct commit *)object)-parents;
+ while (parents) {
+ add_object_array(parents-item-object,
+NULL, want_obj);
+ parents = parents-next;
+ }
+ add_object_array(object, NULL, extra_edge_obj);
+ }
+ /* make sure commit traversal conforms to client */
+ register_shallow(object-sha1);
+ }
+ packet_flush(1);
+}
+
static void receive_needs(void)
{
struct object_array shallows = OBJECT_ARRAY_INIT;
@@ -623,53 +672,9 @@ static void receive_needs(void)
if (depth == 0 shallows.nr == 0)
return;
- if (depth 0) {
- struct commit_list *result = NULL, *backup = NULL;
- int i;
- if (depth == INFINITE_DEPTH !is_repository_shallow())
- for (i = 0; i shallows.nr; i++) {
- struct object *object =
shallows.objects[i].item;
- object-flags |= NOT_SHALLOW;
- }
- else
- backup = result =
- get_shallow_commits(want_obj, depth,
- SHALLOW, NOT_SHALLOW);
- while (result) {
- struct object *object = result-item-object;
- if (!(object-flags (CLIENT_SHALLOW|NOT_SHALLOW))) {
- packet_write(1, shallow %s,
- sha1_to_hex(object-sha1));
- register_shallow(object-sha1);
- shallow_nr++;
- }
- result = result-next;
- }
- free_commit_list(backup);
- for (i = 0; i shallows.nr; i++) {
- struct object *object = shallows.objects[i].item;
- if (object-flags NOT_SHALLOW) {
- struct commit_list *parents;
- packet_write(1, unshallow %s,
- sha1_to_hex(object-sha1));
- object-flags = ~CLIENT_SHALLOW;
- /* make sure the real parents are parsed */
- unregister_shallow(object-sha1);
- object-parsed = 0;
- parse_commit_or_die((struct commit *)object);
- parents = ((struct commit *)object)-parents;
- while (parents) {
-
[PATCHv3 1/3] t7508: .gitignore 'expect' and 'output' files
From: Junio C Hamano gits...@pobox.com
These files are used to observe the behaviour of the 'status'
command and if there weren't any such observer, the expected
output from 'status' wouldn't even mention them.
Place them in .gitignore to unclutter the output expected by the
tests. An added benefit is that future tests can add such files
that are purely for use by the observer, i.e. the tests themselves,
by naming them as expect-foo and/or output-bar.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
t/t7508-status.sh | 78 ++-
1 file changed, 13 insertions(+), 65 deletions(-)
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 8ed5788..514df67 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -66,6 +66,12 @@ strip_comments () {
rm $1 mv $1.tmp $1
}
+cat .gitignore \EOF
+.gitignore
+expect*
+output*
+EOF
+
test_expect_success 'status --column' '
cat expect \EOF
# On branch master
@@ -83,8 +89,8 @@ test_expect_success 'status --column' '
# Untracked files:
# (use git add file... to include in what will be committed)
#
-# dir1/untracked dir2/untracked output
-# dir2/modified expect untracked
+# dir1/untracked dir2/untracked
+# dir2/modified untracked
#
EOF
COLUMNS=50 git -c status.displayCommentPrefix=true status
--column=column dense output
@@ -116,8 +122,6 @@ cat expect \EOF
# dir1/untracked
# dir2/modified
# dir2/untracked
-# expect
-# output
# untracked
#
EOF
@@ -167,8 +171,6 @@ Untracked files:
dir1/untracked
dir2/modified
dir2/untracked
- expect
- output
untracked
EOF
@@ -186,8 +188,6 @@ A dir2/added
?? dir1/untracked
?? dir2/modified
?? dir2/untracked
-?? expect
-?? output
?? untracked
EOF
@@ -320,7 +320,11 @@ EOF
test_i18ncmp expect output
'
-rm -f .gitignore
+cat .gitignore \EOF
+.gitignore
+expect*
+output*
+EOF
cat expect \EOF
## master
@@ -329,8 +333,6 @@ A dir2/added
?? dir1/untracked
?? dir2/modified
?? dir2/untracked
-?? expect
-?? output
?? untracked
EOF
@@ -434,8 +436,6 @@ Untracked files:
dir2/modified
dir2/untracked
dir3/
- expect
- output
untracked
EOF
@@ -456,8 +456,6 @@ A dir2/added
?? dir2/modified
?? dir2/untracked
?? dir3/
-?? expect
-?? output
?? untracked
EOF
test_expect_success 'status -s -unormal' '
@@ -493,8 +491,6 @@ Untracked files:
dir2/untracked
dir3/untracked1
dir3/untracked2
- expect
- output
untracked
EOF
@@ -518,8 +514,6 @@ A dir2/added
?? dir1/untracked
?? dir2/modified
?? dir2/untracked
-?? expect
-?? output
?? untracked
EOF
test_expect_success 'status -s -uall' '
@@ -554,8 +548,6 @@ Untracked files:
untracked
../dir2/modified
../dir2/untracked
- ../expect
- ../output
../untracked
EOF
@@ -569,8 +561,6 @@ A ../dir2/added
?? untracked
?? ../dir2/modified
?? ../dir2/untracked
-?? ../expect
-?? ../output
?? ../untracked
EOF
test_expect_success 'status -s with relative paths' '
@@ -586,8 +576,6 @@ A dir2/added
?? dir1/untracked
?? dir2/modified
?? dir2/untracked
-?? expect
-?? output
?? untracked
EOF
@@ -625,8 +613,6 @@ Untracked files:
BLUEdir1/untrackedRESET
BLUEdir2/modifiedRESET
BLUEdir2/untrackedRESET
- BLUEexpectRESET
- BLUEoutputRESET
BLUEuntrackedRESET
EOF
@@ -647,8 +633,6 @@ cat expect \EOF
BLUE??RESET dir1/untracked
BLUE??RESET dir2/modified
BLUE??RESET dir2/untracked
-BLUE??RESET expect
-BLUE??RESET output
BLUE??RESET untracked
EOF
@@ -676,8 +660,6 @@ cat expect \EOF
BLUE??RESET dir1/untracked
BLUE??RESET dir2/modified
BLUE??RESET dir2/untracked
-BLUE??RESET expect
-BLUE??RESET output
BLUE??RESET untracked
EOF
@@ -694,8 +676,6 @@ A dir2/added
?? dir1/untracked
?? dir2/modified
?? dir2/untracked
-?? expect
-?? output
?? untracked
EOF
@@ -755,8 +735,6 @@ Untracked files:
dir1/untracked
dir2/modified
dir2/untracked
- expect
- output
untracked
EOF
@@ -772,8 +750,6 @@ A dir2/added
?? dir1/untracked
?? dir2/modified
?? dir2/untracked
-?? expect
-?? output
?? untracked
EOF
@@ -798,8 +774,6 @@ Untracked files:
dir1/untracked
dir2/
- expect
- output
untracked
EOF
@@ -848,8 +822,6 @@ Untracked files:
dir1/untracked
dir2/modified
dir2/untracked
- expect
- output
untracked
EOF
@@ -870,8 +842,6 @@ A sm
?? dir1/untracked
?? dir2/modified
?? dir2/untracked
-?? expect
-?? output
?? untracked
EOF
test_expect_success 'status -s submodule summary is disabled by default' '
@@ -913,8 +883,6 @@ Untracked files:
dir1/untracked
dir2/modified
dir2/untracked
- expect
- output
untracked
EOF
@@
[PATCHv3 0/3]More diffs for commit/status
v3 has the following changes: - new leading patch by Junio to clean up t7508 (slightly modified by myself) - adjust tests accordingly - revert back to standard c/,i/ resp. i/,w/ diff prefixes with a header line Open questionis for 3/3: - Do we need the header to stick out even more? (I don't think so, although having the STATUS_HEADER color to be different may help.) - Do we want the header line also for status -v? (I would say yes, but that would be a change to current behaviour.) Junio C Hamano (1): t7508: .gitignore 'expect' and 'output' files Michael J Gruber (2): t7508: test git status -v commit/status: show the index-worktree diff with -v -v Documentation/git-commit.txt | 4 ++ t/t7508-status.sh| 102 +++ wt-status.c | 16 +++ 3 files changed, 55 insertions(+), 67 deletions(-) -- 2.3.1.303.g5174db1 -- 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
[PATCHv3 3/3] commit/status: show the index-worktree diff with -v -v
git commit and git status in long format show the diff between HEAD
and the index when given -v. This allows previewing a commit to be made.
They also list tracked files with unstaged changes, but without a diff.
Introduce '-v -v' which shows the diff between the index and the
worktree in addition to the HEAD index diff. This allows a review of unstaged
changes which might be missing from the commit.
In the case of '-v -v', additonal header lines
Changes to be committed:
and
Changes not staged for commit:
are inserted before the diffs, which are equal to those in the status
part.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
Documentation/git-commit.txt | 4
t/t7508-status.sh| 10 ++
wt-status.c | 16
3 files changed, 30 insertions(+)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 1e74b75..f14d2ec 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -284,6 +284,10 @@ configuration variable documented in linkgit:git-config[1].
would be committed at the bottom of the commit message
template. Note that this diff output doesn't have its
lines prefixed with '#'.
++
+If specified twice, show in addition the unified diff between
+what would be committed and the worktree files, i.e. the unstaged
+changes to tracked files.
-q::
--quiet::
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index e3c9cf9..b392376 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -143,6 +143,16 @@ test_expect_success 'status -v' '
test_i18ncmp expect-with-v output
'
+test_expect_success 'status -v -v' '
+ (cat expect
+echo Changes to be committed:
+git -c diff.mnemonicprefix=true diff --cached
+echo Changes not staged for commit:
+git -c diff.mnemonicprefix=true diff) expect-with-v
+ git status -v -v output
+ test_i18ncmp expect-with-v output
+'
+
test_expect_success 'setup fake editor' '
cat .git/editor -\EOF
#! /bin/sh
diff --git a/wt-status.c b/wt-status.c
index 29666d0..3cdb356 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -849,6 +849,8 @@ static void wt_status_print_verbose(struct wt_status *s)
{
struct rev_info rev;
struct setup_revision_opt opt;
+ int dirty_submodules;
+ const char *c = color(WT_STATUS_HEADER, s);
init_revisions(rev, NULL);
DIFF_OPT_SET(rev.diffopt, ALLOW_TEXTCONV);
@@ -873,7 +875,21 @@ static void wt_status_print_verbose(struct wt_status *s)
rev.diffopt.use_color = 0;
wt_status_add_cut_line(s-fp);
}
+ if (s-verbose 1 s-commitable) {
+ /* print_updated() printed header */
+ status_printf_ln(s, c, _(Changes to be committed:));
+ rev.diffopt.a_prefix = c/;
+ rev.diffopt.b_prefix = i/;
+ } /* else use prefix as per user config */
run_diff_index(rev, 1);
+ if (s-verbose 1
+ wt_status_check_worktree_changes(s, dirty_submodules)) {
+ status_printf_ln(s, c, _(Changes not staged for commit:));
+ setup_work_tree();
+ rev.diffopt.a_prefix = i/;
+ rev.diffopt.b_prefix = w/;
+ run_diff_files(rev, 0);
+ }
}
static void wt_status_print_tracking(struct wt_status *s)
--
2.3.1.303.g5174db1
--
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
[PATCHv3 2/3] t7508: test git status -v
status -v had no test. Include one.
This also requires changing the .gitignore subtests, which is a good thing:
they include testing a .gitignore pattern now.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
t/t7508-status.sh | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 514df67..e3c9cf9 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -137,6 +137,12 @@ test_expect_success 'status with
status.displayCommentPrefix=false' '
test_i18ncmp expect output
'
+test_expect_success 'status -v' '
+ (cat expect git diff --cached) expect-with-v
+ git status -v output
+ test_i18ncmp expect-with-v output
+'
+
test_expect_success 'setup fake editor' '
cat .git/editor -\EOF
#! /bin/sh
@@ -201,7 +207,7 @@ test_expect_success 'status -s' '
test_expect_success 'status with gitignore' '
{
echo .gitignore
- echo expect
+ echo expect*
echo output
echo untracked
} .gitignore
@@ -222,6 +228,7 @@ test_expect_success 'status with gitignore' '
!! dir1/untracked
!! dir2/untracked
!! expect
+ !! expect-with-v
!! output
!! untracked
EOF
@@ -253,6 +260,7 @@ Ignored files:
dir1/untracked
dir2/untracked
expect
+ expect-with-v
output
untracked
@@ -264,7 +272,7 @@ EOF
test_expect_success 'status with gitignore (nothing untracked)' '
{
echo .gitignore
- echo expect
+ echo expect*
echo dir2/modified
echo output
echo untracked
@@ -285,6 +293,7 @@ test_expect_success 'status with gitignore (nothing
untracked)' '
!! dir2/modified
!! dir2/untracked
!! expect
+ !! expect-with-v
!! output
!! untracked
EOF
@@ -312,6 +321,7 @@ Ignored files:
dir2/modified
dir2/untracked
expect
+ expect-with-v
output
untracked
--
2.3.1.303.g5174db1
--
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 merge driver / attributes bug in 2.3.1?
Hello, after upgrading the Git installation on one of our development servers from 1.9.0-rc3 to 2.3.1 we are experiencing strange behavior of merge drivers. A merge driver registered as * merge=name_of_merge_driver in the .gitattributes is now executed even if there isn't any merge conflict. This only happens for files that are part of the merge. This is reproducible in test repositories. Greetings Andreas Gondek Applications Deutsche WertpapierService Bank AG ITTAS Derendorfer Allee 2 40476 Düsseldorf Tel.: +49 69 5099 9503 Fax: +49 69 5099 85 9503 E-Mail: andreas.gon...@dwpbank.de http://www.dwpbank.de Deutsche WertpapierService Bank AG | Wildunger Straße 14 | 60487 Frankfurt am Main Sitz der AG: Frankfurt am Main, HRB 56913 | USt.-ID: DE 813759005 Vorstand: Thomas Klanten, Dr. Christian Tonnesen Aufsichtsrat: Wilfried Groos (Vors.) -- 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: Surprising interaction of binary and eol gitattributes
On 03/05/2015 11:08 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
I would expect that the following .gitattributes file
* eol=crlf
*.png -text
would leave EOL translation turned off for PNG files. In other words, I
would expect that explicitly setting -text would take precedence over
the fact that setting eol implies that a file should be considered to
be text.
I would even more strongly expect
* eol=crlf
*.png binary
to turn off EOL translation for PNG files.
But in fact, in both of the above cases, EOL translation is turned *on*
for PNG files.
I propose that -text should override any setting for eol (which
would of course fix both problems, since binary is equivalent to
-diff -merge -text). What do people think?
Hmm, is there really something that needs a new proposal and
opinions?
The way I read the flow in convert.c is:
convert_to_git() uses input_crlf_action() to figure out what
crlf_to_git() conversion is necessary.
input_crlf_action() looks at text_attr and says CRLF_BINARY when
it is CRLF_BINARY without looking at eol_attr at all.
text_attr above is ca.crlf_action in convert_to_git().
The whole ca.* comes from convert_attrs() inspecting attributes
on the incoming path.
convert_attrs() inspects eol and text attributes, among
others, and sets crlf_action by calling git_path_check_crlf().
git_path_check_crlf() looks at the 'text' attribute; if it is
set to false, it returns CRLF_BINARY.
crlf_to_git() when given crlf_action==CRLF_BINARY is a no-op.
So, with the above attributes where anything is eol=crlf by default
and in addition *.png is binary (which contains -text), we shouldn't
get any crlf munging. Am I reading/following the code incorrectly?
Puzzled
--
I need to admit that I can't reproduce it here,
the following should trigger it, but all test cases pass
diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh
index 452320d..22f031d 100755
--- a/t/t0027-auto-crlf.sh
+++ b/t/t0027-auto-crlf.sh
@@ -37,7 +37,8 @@ create_gitattributes () {
echo *.txt text .gitattributes
;;
-text)
- echo *.txt -text .gitattributes
+ echo * eol=crlf .gitattributes
+ echo *.txt -text .gitattributes
;;
crlf)
echo *.txt eol=crlf .gitattributes
--
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: Slow git pushes: sitting 1 minute in pack-objects
8GB of RAM. Sorry, typo. Steve On Thu, Mar 5, 2015 at 7:25 PM, Duy Nguyen pclo...@gmail.com wrote: On Fri, Mar 6, 2015 at 4:03 AM, Stephen Morton stephen.c.mor...@gmail.com wrote: I'm experiencing very slow git pushes. On the order of 1 minute to push a trivial one-line change. When I set GIT_TRACE=1, I see that it seems to be taking a lot of time in the pack-objects phase. Others are not seeing this with the same repo, but I'm the only one working in a VM. ... Details: git version 2.1.4 OS: CentOS 6.6 64-bit in a VM. repo size: huge. 6 GB .git directory, around 800 MB working tree. VM has 8 MB RAM and 8 cores. Is it 8 GB or MB RAM? CPU: i7, 8 core (4 cores hyperthreaded) -- 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
[PATCH v3] git: make git -C '' cmd not to barf
It now acts like cd '' and does not barf and treats
it as a no-op. This is useful if a caller function
does not want to change directory and hence gives no
path value, which would have generally caused git to
output an undesired error message.
Included a simple test to check the same, as suggested
by Junio.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
git.c| 12
t/t0056-git-C.sh | 8
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/git.c b/git.c
index 8c7ee9c..d734afa 100644
--- a/git.c
+++ b/git.c
@@ -204,10 +204,14 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
fprintf(stderr, No directory given for -C.\n
);
usage(git_usage_string);
}
- if (chdir((*argv)[1]))
- die_errno(Cannot change to '%s', (*argv)[1]);
- if (envchanged)
- *envchanged = 1;
+ if (*((*argv)[1]) == 0)
+ ; /* DO not change directory if no directory is
given*/
+ else {
+ if (chdir((*argv)[1]))
+ die_errno(Cannot change to '%s',
(*argv)[1]);
+ if (envchanged)
+ *envchanged = 1;
+ }
(*argv)++;
(*argc)--;
} else {
diff --git a/t/t0056-git-C.sh b/t/t0056-git-C.sh
index 99c0377..a6b52f1 100755
--- a/t/t0056-git-C.sh
+++ b/t/t0056-git-C.sh
@@ -14,6 +14,14 @@ test_expect_success 'git -C path runs git from the
directory path' '
test_cmp expected actual
'
+test_expect_success 'git -C path with an empty path is a no-op' '
+ mkdir -p dir1/subdir
+ cd dir1/subdir
+ git -C rev-parse --show-prefix actual
+ echo subdir/ expect
+ test_cmp expect actual
+'
+
test_expect_success 'Multiple -C options: -C dir1 -C dir2 is equivalent to
-C dir1/dir2' '
test_create_repo dir1/dir2
echo 1 dir1/dir2/b.txt
--
2.3.1.167.g7f4ba4b.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
GSoC applicants: discuss other applicants patches, perhaps?
The objective of GSoC program is to learn how to work on projects as a part of an open source community, and working in Git project is not only about writing your own patches. Constructively critiquing design and implementation of patches by other people is also an important skill you need to learn in order to effectively collaborate with others. So, if you have time and inclination, it would be beneficial to read and understand other applicants' patches, think if you agree that the problem they are trying to solve is worth solving, the approach they are taking is the best way (or if you think of a better way to solve it), etc., and respond to their patches with the result of your thinking as a review. What do mentors and others think? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][GSoC] revision: forbid --graph and --no-walk usage
Not sure, why this mail is not showing on Gmane. I used git to send the email, and tested it by sending the patch to myself before sending it to the list. On Fri, Mar 6, 2015 at 12:40 AM, Akshay Aurora akshayaur...@yahoo.com wrote: Signed-off-by: Akshay Aurora akshayaur...@yahoo.com --- This is my first patch for a GSoC Microproject, would be great to have your feedback. revision.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/revision.c b/revision.c index bd027bc..d578652 100644 --- a/revision.c +++ b/revision.c @@ -2248,7 +2248,8 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s */ if (revs-reverse revs-graph) die(cannot combine --reverse with --graph); - + if (revs-no_walk revs-graph) + die(cannot combine --no-walk with --graph); if (revs-reflog_info revs-graph) die(cannot combine --walk-reflogs with --graph); if (!revs-reflog_info revs-grep_filter.use_reflog_filter) -- 2.3.1 -- AA -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Retry if fdopen() fails due to ENOMEM
On 03/05/2015 05:07 PM, Michael Haggerty wrote: One likely reason for fdopen() to fail is the lack of memory for allocating a FILE structure. When that happens, try freeing some memory and calling fdopen() again in the hope that it will work the second time. This change was suggested by Jonathan Nieder [1] In the first patch it is unsatisfying that try_to_free_routine() is called with a magic number (1000) rather than sizeof(FILE). But the C standard doesn't guarantee that FILE is a complete type, so I can't think of a better approach. Suggestions, anybody? it's not the sizeof(FILE) which is critical, it is the size of the buffer associated with a FILE http://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdio.h.html BUFSIZ may be your friend, and if it is not defined, 4096 may be a useful default. -- 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][GSoC] revision: forbid --graph and --no-walk usage
Signed-off-by: Akshay Aurora akshayaur...@yahoo.com --- This is my first patch for a GSoC Microproject, would be great to have your feedback. revision.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/revision.c b/revision.c index bd027bc..d578652 100644 --- a/revision.c +++ b/revision.c @@ -2248,7 +2248,8 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s */ if (revs-reverse revs-graph) die(cannot combine --reverse with --graph); - + if (revs-no_walk revs-graph) + die(cannot combine --no-walk with --graph); if (revs-reflog_info revs-graph) die(cannot combine --walk-reflogs with --graph); if (!revs-reflog_info revs-grep_filter.use_reflog_filter) -- 2.3.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
