[PATCH 0/2] git-p4: support python3 in the tests

[Luke Diamand]

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

[Luke Diamand]

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

[Luke Diamand]

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

[John Darrington]

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)

[Pranit Bauva]

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

[Carlos Pita]

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

[Pranit Bauva]

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

[Ye Xiaolong]

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

[Torsten Bögershausen]

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

[Eric Wong]

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

[Ye Xiaolong]

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

[Ye Xiaolong]

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

[Johannes Schindelin]

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

[Johannes Schindelin]

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