[PATCH 0/2] git-p4: support python3 in the tests
This patchset updates the git-p4 tests so that they work with either Python2 or Python3. Note that this does *not* fix git-p4 to work with Python3 - that's a much bigger challenge. Luke Diamand (2): git-p4 tests: cd to testdir before running python git-p4 tests: work with python3 as well as python2 t/lib-git-p4.sh| 7 --- t/t9802-git-p4-filetype.sh | 6 +++--- 2 files changed, 7 insertions(+), 6 deletions(-) -- 2.8.1.218.gd2cea43.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] git-p4 tests: work with python3 as well as python2
Update the git-p4 tests so that they work with both Python2 and Python3. We have to be explicit about the difference between Unicode text strings (Python3 default) and raw binary strings which will be exchanged with Perforce. Additionally, print always takes braces in Python3. Signed-off-by: Luke Diamand --- t/lib-git-p4.sh| 5 +++-- t/t9802-git-p4-filetype.sh | 6 +++--- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh index 77802fe..b97d27c 100644 --- a/t/lib-git-p4.sh +++ b/t/lib-git-p4.sh @@ -198,9 +198,10 @@ marshal_dump() { cat >"$TRASH_DIRECTORY/marshal-dump.py" <<-EOF && import marshal import sys + instream = getattr(sys.stdin, 'buffer', sys.stdin) for i in range($line): - d = marshal.load(sys.stdin) - print d['$what'] + d = marshal.load(instream) + print(d[b'$what'].decode('utf-8')) EOF "$PYTHON_PATH" "$TRASH_DIRECTORY/marshal-dump.py" } diff --git a/t/t9802-git-p4-filetype.sh b/t/t9802-git-p4-filetype.sh index 66d3fc9..eb9a8ed 100755 --- a/t/t9802-git-p4-filetype.sh +++ b/t/t9802-git-p4-filetype.sh @@ -223,12 +223,12 @@ build_gendouble() { import sys import struct - s = struct.pack(">LL18s", + s = struct.pack(b">LL18s", 0x00051607, # AppleDouble 0x0002, # version 2 - "" # pad to 26 bytes + b"" # pad to 26 bytes ) - sys.stdout.write(s) + getattr(sys.stdout, 'buffer', sys.stdout).write(s) EOF } -- 2.8.1.218.gd2cea43.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] git-p4 tests: cd to testdir before running python
The python one-liner for getting the current time prints out error messages if the current directory is deleted while it is running if using python3. Avoid these messages by switching back to the test directory before running python3, instead of remaining in the trash directory. Signed-off-by: Luke Diamand --- t/lib-git-p4.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh index f9ae1d7..77802fe 100644 --- a/t/lib-git-p4.sh +++ b/t/lib-git-p4.sh @@ -50,7 +50,7 @@ native_path() { # at runtime (e.g. via NTP). The 'clock_gettime(CLOCK_MONOTONIC)' # function could fix that but it is not in Python until 3.3. time_in_seconds() { - python -c 'import time; print int(time.time())' + (cd "$TEST_DIRECTORY" && python -c 'import time; print(int(time.time()))') } # Try to pick a unique port: guess a large number, then hope -- 2.8.1.218.gd2cea43.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
Awkward and confusing question in git --send-email
Git --send-email poses the question: "Who should the emails be sent to (if any)?" Apart from sounding clumsy (not to mention incorrect grammar), it took me a while to work out what this meant. I suggest this be changed to : "To whom should the email be sent (if anyone) ?" J' -- Avoid eavesdropping. Send strong encryted email. PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key. signature.asc Description: Digital signature
Re: What's cooking in git.git (Apr 2016, #06; Thu, 21)
On Sat, Apr 23, 2016 at 3:42 AM, Junio C Hamano wrote: > Junio C Hamano writes: > Is this going to be rerolled? ($gmane/291382) >>> >>> The changes weren't that big enough and I had my end semester exams >>> coming so I decided not to re-roll it. >>> If you think contrary, I can do a re-roll with the changes suggested >>> by Eric Sunshine. >> >> I agree that this was pretty close to be done. Let me see if I can >> find time to finish it up in the coming few days. > > I looked at the reviews again and I take the above back--the end > result of applying all patches may not have to change a lot, but > the ordering and structure of the series may need cleanign up. Surely I can work on the patches. I will have to try and squeeze out some time from studying so you can expect the patches in around 1 week. I will once again clarify with Eric about the tests since there was quite misunderstanding. Regards, Pranit Bauva -- 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
铜铅精矿
你的老朋友邀你来Q群:343257759 抢红包 抢秒杀 抢vip 什么都要抢。太刺激了。不靠手气只拼手速
Allow worktree in same path with different gitdir
Hi all, I usually keep my dotfiles, scripts, etc. in a git repo at ~, both as a backup solution and as a way to sync config between my different computers and remote servers in which I have to work. Some of these computers require a small number of local configurations that I like to keep in a repo too (mainly for backup purposes). These modifications to the base repo may be made branches of the base configuration but then keeping the common configurations in sync between all branches becomes cumbersome and error prone, with a lot of rebasing, cherry picking, stashing and whatnot. What I prefer is to create an orphan branch for local files, create a worktree for this branch, then move this worktree gitdir to something like ~/.gitlocal, next to the main ~/.git, update .git/worktrees to avoid pruning and define a handy alias like lgit='GIT_DIR=~/.gitlocal git'. This way I'm able to keep some files below ~ in a specific branch and some others in a shared master branch, all at the same time and in the same directory. What I find a bit cumbersome about this workflow is the inability to directly create the worktree at . specifying a gitdir like .gitlocal. Is there any fundamental reason this is not allowed for the worktree subcommand? If not, please consider this a feature request. Notice the same is valid for cloning the ~ repo, instead of just creating a worktree from it. The clone subcommand will also reject a . path and also doesn't provide a way to specify a different gitdir (even --separate-git-dir requires a "fake" .git). Cheers -- Carlos -- 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 Project Selected | Incremental Rewrite of git bisect
Hey everyone, I am Pranit Bauva studying Mining Engineering at Indian Institute of Technology, Kharagpur. I have applied for Google Summer of Code 2016 under Git organization and my project[1], "Incremental Rewrite of git bisect has been selected under the guidance of mentors namely Christian Couder and Lars Schneider. Overview of the project: Git bisect is a frequently used command which helps the developers in finding the commit which introduced the regression. Some part of it is written in shell script. I intend to convert it to portable C code thus making them builtins. This will increase Git’s portability. A word of thanks: Firstly I would really like to thank everyone who was involved in planning GSoC for Git especially my mentors. Also thanking Eric Sunshine, SZEDER and Junio for patiently reviewing my micro-project and helping me through that. It was a really great experience. I had previously no clue about git bisect and have never used it mainly because I was never involved with maintaining big projects. Posting my idea to the mailing list (which initially contained a lot of mistakes) was extremely helpful. Thanks to Christian Couder, Matthieu Moy, Johannes Schindelin and Stefan Beller for providing useful comments. Experimenting by converting one function really helped me a lot to write the proposal. Thanks Roberto for making submitgit. The subtle hints dropped were the most helpful. Thanks for explaining those when I could not pick up those hints in the first time. Status of Micro-project: I had finalized v14[1] but recently Junio pointed out that the series requires ordering and restructuring so I will finish with that. I have my end semester exams going on so I will try to squeeze out some time in between and try to work on the patches. Status of the function conversion: I had attempted to port a function 'check_term_format' from shell to C. The last version was v3[2]. In the newer version (there only exist a local copy as I have neither sent it in the mailing list nor I have pushed it on github) as one test is not exiting properly. The code written with confusing error handling and return statements which were mainly there to help me understand "What's happening and where is it happening?" As requested by Christian, I will still push these changes to my github fork[3]. Also the function I have written does not use the API of git as at that time I wasn't quite familiar with it. I am still not completely familiar with it but I guess that will take some time. Status of learning about git plumbing commands: I have learned about: - git-check-ref-format - git-rev-list - git-rev-parse The one's left are: - git-symbolic-refs - git-show-branch - git-update-ref - git-for-each-ref Status of Week 1 of my proposal: In my 1st week I was going to set up kcov to test the coverage of shell scripts as gcov does not cover them. kcov is a lot trickier than gcov which I hadn't realized it before. I tried to use it in a simple way but it just wasn't possible for me. So I dug further and found a patch[5] submitted by Dmitry Vyukov. The linux kernel recently started using kcov for their coverage and to also find bugs by using some fuzzy logic. Setting this up is well not a piece of cake at least for me. I tried reading his patch and wasn't quite able to digest it in the first read but then I didn't look into that further. I would really like if someone could look this up and recommend whether I should try and implement this or not in the first week. If let's say I try to implement it, then I probably think it is more than a week's job. I recollect Matthieu saying that Paul Tan had used this before. Could you please explain how he achieved this? When will I officially start working? My end semester exams end on 29th April, 2016 and I will reach my home on 1st May, 2016. I will officially start working from 2nd May, 2016 and will complete reading up on plumbing commands and other API parts which seems a bit ambitious as for now. Other remarks: - I can now finally use git-send-email when I reach home. - I will regularly (weekly) keep posting my progress on my blog[6] which will be revived as it has been a bit stale for some time now. I will also send the text-only version to the mailing list as requested by Christian. - The more I dived in, the more it started to realize that my time line needs some restructuring which I guess can be determined by the above paragraphs. - I will also work out on a time line and post it on my blog[6] and send it to mentors. [1]: https://docs.google.com/document/d/1stnDPA5Hs3u0a8sqoWZicTFpCz1wHP9bkifcKY13Ocw/edit?usp=sharing [2]: http://thread.gmane.org/gmane.comp.version-control.git/291311 [3]: http://thread.gmane.org/gmane.comp.version-control.git/289599 [4]: https://github.com/pranitbauva1997/git [5]: http://thread.gmane.org/gmane.linux.kernel/2126762 [6]: http://bauva.in -- To unsubscribe from this list: send the line "unsubscribe git" in the body of
Re: [PATCH v5 2/4] format-patch: add '--base' option to record base tree info
On Fri, Apr 22, 2016 at 02:39:28PM -0700, Junio C Hamano wrote: >Xiaolong Ye writes: > >> diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh >> index eed2981..a6ce727 100755 >> --- a/t/t4014-format-patch.sh >> +++ b/t/t4014-format-patch.sh >> @@ -1460,4 +1460,19 @@ test_expect_success 'format-patch -o overrides >> format.outputDirectory' ' >> test_path_is_dir patchset >> ' >> >> +test_expect_success 'format-patch --base' ' >> +git checkout side && >> +git format-patch --stdout --base=HEAD~~~ -1 >patch && >> +grep -e "^base-commit:" -A3 patch >actual && >> +echo "base-commit: $(git rev-parse HEAD~~~)" >expected && > >HEAD~3 would be easier to read (and HEAD~2 is easier than HEAD~~). > >> +echo "prerequisite-patch-id: $(git show --patch HEAD~~ | git patch-id >> --stable | awk "{print \$1}")" >>expected && >> +echo "prerequisite-patch-id: $(git show --patch HEAD~ | git patch-id >> --stable | awk "{print \$1}")" >>expected && >> +test_cmp expected actual >> +' >> + >> +test_expect_success 'format-patch --base error handling' ' >> +! git format-patch --base=HEAD~ -2 && >> +! git format-patch --base=HEAD~ -3 >> +' > >When making sure that "git" exits with a failure in a controlled way >(i.e. you want to consider "git" that segfaults as not passing the >test), do not use "! git cmd", but use "test_must_fail git cmd" >instead. Thanks for the reminder, I misunderstood the guide in t/README before. > >You now have a quite elaborate logic in base validation in this >rounhd. Is the topology of the history used in this test still >complex enough to make sure the logic is being tested? I'll try to set up more complex topology of the history for the testcase. Thanks, Xiaolong. -- 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 v6 01/10] t0027: Make more reliable
On 2016-04-23 00.03, Junio C Hamano wrote: > tbo...@web.de writes: > >> From: Torsten Bögershausen >> Subject: Re: [PATCH v6 01/10] t0027: Make more reliable > > "Make more reliable" does not sound very grammatical. > >> Make the commit_chk_wrnNNO test in t0027 more reliable: > > Neither is the colon at the end. > After Re-reading the series (with fresh eyes) I found more spelling errors, typos in different commit messages. 9/10 is missing the SOB. How about this for 1/10: Subject: [PATCH v6 01/10] t0027: Make commit_chk_wrnNNO() reliable When the content of a commited file is unchanged and the attributes are changed, Git may not detect that the next commit must treat the file as changed. This happens when lstat() doesn't detect a change, since neither inode, mtime nor size are changed. Add a singe "Z" character to change the file size. Ignore it when comparing the files later. Signed-off-by: Torsten Bögershausen -- 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] fast-import: implement unpack limit
Jeff King wrote: > There we have fetch.unpackLimit and receive.unpackLimit for the two > operations, plus transfer.unpackLimit to control both of them. This > doesn't necessarily need to be tied to that config, but you could > certainly consider it in the same boat. It's a way of transferring a > load of objects into the repository. Ah, thanks, I've always overlooked those :x But it makes sense to me this way. > So it would make some sense to me to have fastimport.unpackLimit, > falling back to transfer.unpackLimit. Done below, purely as a config option with no CLI switch. I'm hoping the change in default behavior is acceptable to match behavior of the other "transfer" mechanisms. I needed to adjust the t9300 test, though. -8<- Subject: [PATCH] fast-import: implement unpack limit With many incremental imports, small packs become highly inefficient due to the need to readdir scan and load many indices to locate even a single object. Frequent repacking and consolidation may be prohibitively expensive in terms of disk I/O, especially in large repositories where the initial packs were aggressively optimized and marked with .keep files. In those cases, users may be better served with loose objects and relying on "git gc --auto". This changes the default behavior of fast-import for small imports found in test cases, so adjustments to t9300 were necessary. Signed-off-by: Eric Wong --- Documentation/config.txt| 9 +++ Documentation/git-fast-import.txt | 2 ++ fast-import.c | 31 t/t9300-fast-import.sh | 2 ++ t/t9302-fast-import-unpack-limit.sh | 48 + 5 files changed, 92 insertions(+) create mode 100755 t/t9302-fast-import-unpack-limit.sh diff --git a/Documentation/config.txt b/Documentation/config.txt index 42d2b50..3d8bc97 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1154,6 +1154,15 @@ difftool..cmd:: difftool.prompt:: Prompt before each invocation of the diff tool. +fastimport.unpackLimit:: + If the number of objects imported by linkgit:git-fast-import[1] + is below this limit, then the objects will be unpacked into + loose object files. However if the number of imported objects + equals or exceeds this limit then the pack will be stored as a + pack. Storing the pack from a fast-import can make the import + operation complete faster, especially on slow filesystems. If + not set, the value of `transfer.unpackLimit` is used instead. + fetch.recurseSubmodules:: This option can be either set to a boolean value or to 'on-demand'. Setting it to a boolean changes the behavior of fetch and pull to diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index 66910aa..644df99 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -136,6 +136,8 @@ Performance and Compression Tuning Maximum size of each output packfile. The default is unlimited. +fastimport.unpackLimit:: + See linkgit:git-config[1] Performance --- diff --git a/fast-import.c b/fast-import.c index 9fc7093..381d3a0 100644 --- a/fast-import.c +++ b/fast-import.c @@ -166,6 +166,7 @@ Format of STDIN stream: #include "quote.h" #include "exec_cmd.h" #include "dir.h" +#include "run-command.h" #define PACK_ID_BITS 16 #define MAX_PACK_ID ((1pack_name); + + unpack.in = p->pack_fd; + unpack.git_cmd = 1; + unpack.stdout_to_stderr = 1; + argv_array_push(&unpack.args, "unpack-objects"); + argv_array_push(&unpack.args, "-q"); + + return run_command(&unpack); +} + static void end_packfile(void) { static int running; @@ -972,6 +990,12 @@ static void end_packfile(void) fixup_pack_header_footer(pack_data->pack_fd, pack_data->sha1, pack_data->pack_name, object_count, cur_pack_sha1, pack_size); + + if (object_count <= unpack_limit) { + if (loosen_small_pack(pack_data) == 0) + goto discard_pack; + } + close(pack_data->pack_fd); idx_name = keep_pack(create_index()); @@ -1002,6 +1026,7 @@ static void end_packfile(void) pack_id++; } else { +discard_pack: close(pack_data->pack_fd); unlink_or_warn(pack_data->pack_name); } @@ -3317,6 +3342,7 @@ static void parse_option(const char *option) static void git_pack_config(void) { int indexversion_value; + int limit; unsigned long packsizelimit_value; if (!git_config_get_ulong("pack.depth", &max_depth)) { @@ -3341,6
Re: [PATCH v5 3/4] format-patch: introduce --base=auto option
On Fri, Apr 22, 2016 at 02:54:16PM -0700, Junio C Hamano wrote: >Xiaolong Ye writes: > >> +if (upstream) { >> +unsigned char sha1[20]; >> +if (get_sha1(upstream, sha1)) >> +die(_("Failed to resolve '%s' as a valid >> ref."), upstream); >> +struct commit *commit = lookup_commit_or_die(sha1, >> "upstream base"); >> +struct commit_list *base_list = >> get_merge_bases_many(commit, total, list); > >This introduces decl-after-statement. will fix it. Thanks, Xiaolong. -- 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 v5 2/4] format-patch: add '--base' option to record base tree info
On Fri, Apr 22, 2016 at 02:59:42PM -0700, Junio C Hamano wrote: >Xiaolong Ye writes: > >> +test_expect_success 'format-patch --base' ' >> +git checkout side && >> +git format-patch --stdout --base=HEAD~~~ -1 >patch && >> +grep -e "^base-commit:" -A3 patch >actual && > >The -A3 is GNUism. To do this portably, perhaps you can do > > sed -n -e "/^base-commit:/,+3p" > >or something like that. > >But more importantly, grabbing 3 lines (and always 3 lines) will not >catch a future bug that somebody else may introduce to this code >that shows extra "prerequisite-patch-id:" after them. I'll try to improve the testcase to make it more sensible. Thanks, Xiaolong > >> +echo "base-commit: $(git rev-parse HEAD~~~)" >expected && >> +echo "prerequisite-patch-id: $(git show --patch HEAD~~ | git patch-id >> --stable | awk "{print \$1}")" >>expected && >> +echo "prerequisite-patch-id: $(git show --patch HEAD~ | git patch-id >> --stable | awk "{print \$1}")" >>expected && >> +test_cmp expected actual >> +' -- 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] name-rev: include taggerdate in considering the best name
Hi, [fixing Uwe's email address, as the address bounces that was recorded in the commit introducing the flawed behavior, and I failed to check mailmap earlier.] On Fri, 22 Apr 2016, Junio C Hamano wrote: > Linus Torvalds writes: > > > ... I think this is still the simplest model we can use > > without trying to really do a topo-sort. And in many ways it's the > > simplest one to explain to people too: "we try to use the oldest > > reference we can find as a base for the resulting name" is not a > > complex or hard concept to explain. > > Yes, the more I look at Dscho's patch, the more like it exactly for > that reason. Its behaviour is very simple from the end-user's point > of view, unlike the historical one. Well, seeing as I introduced the bug, it's only fair that I fix it, too. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC Project Selected | Incremental Rewrite of git bisect
Hi Pranit, On Sun, 24 Apr 2016, Pranit Bauva wrote: > I am Pranit Bauva studying Mining Engineering at Indian Institute of > Technology, Kharagpur. I have applied for Google Summer of Code 2016 > under Git organization and my project[1], "Incremental Rewrite of git > bisect has been selected under the guidance of mentors namely Christian > Couder and Lars Schneider. Awesome, congratulations! Looking forward to seeing your project progress, and to you feeling at home here in the Git developer community. Ciao, Johannes -- 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