[PATCH v2] test-lib: simplify '--option=value' parsing

To get the 'value' from '--option=value', test-lib.sh parses said option running 'expr' with a regexp. This involves a subshell, an external process, and a lot of non-alphanumeric characters in the regexp. Use a much simpler POSIX-defined shell parameter expansion instead to do the same.

Re: make test Unexpected passes

On Fri, Apr 22, 2016 at 1:05 PM, Ramsay Jones wrote: > Hi Ben, Junio, > > In the second case, t6036-*.sh, git bisect fingered commit b61f9d6e > ("ll-merge: use a longer conflict marker for internal merge", 14-04-2016). Yeah, the t6036 testcase 'git detects conflict

[PATCH v2 2/4] t1500-rev-parse: add tests executed from sub path of the main worktree

Signed-off-by: Michael Rappazzo --- t/t1500-rev-parse.sh | 37 + 1 file changed, 37 insertions(+) diff --git a/t/t1500-rev-parse.sh b/t/t1500-rev-parse.sh index 48ee077..1e220f7 100755 --- a/t/t1500-rev-parse.sh +++ b/t/t1500-rev-parse.sh

[PATCH v2 4/4] t1700-split-index: add test for rev-parse --shared-index-path

Signed-off-by: Michael Rappazzo --- t/t1700-split-index.sh | 17 + 1 file changed, 17 insertions(+) diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh index 8aef49f..d2d9e02 100755 --- a/t/t1700-split-index.sh +++ b/t/t1700-split-index.sh @@ -200,4

[PATCH v2 0/4] rev-parse: adjust results when they should be relative

Differences from v1[1]: - Simplify implementation based on review comments - Included similar changes in rev-parse for --git-path and --shared-index-path - Added tests and separated them into individual commits [1] http://thread.gmane.org/gmane.comp.version-control.git/290669 Michael Rappazzo

[PATCH v2 3/4] t2027-worktree-list: add and adjust tests related to git-rev-parse

Adjust the incorrect expectation for `rev-parse --git-common-dir`. Add a test for `git rev-parse --git-path` executed from a linked worktree. Signed-off-by: Michael Rappazzo --- t/t2027-worktree-list.sh | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff

[PATCH] hooks: Add ability to specify where the hook directory is

Change the hardcoded lookup for .git/hooks/* to optionally lookup in $(git config core.hooksDirectory)/* instead if that config key is set. This is essentially a more intrusive version of the git-init ability to specify hooks on init time via init templates. The difference between that facility

Re: issue upgrading git from 1.8.2.1 to 2.8.0

On Fri, Apr 22, 2016 at 06:44:02PM -0400, Gennaro Torre wrote: > When we upgraded to 2.8.0, all nodes received the upgrade. > > We observed that when we tried to deploy code to the nodes (they run > `git fetch` to update the repository) this would fail. Did `git fetch` say anything interesting

Re: [PATCH v5 2/4] format-patch: add '--base' option to record base tree info

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

Re: What's cooking in git.git (Apr 2016, #06; Thu, 21)

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

Re: [PATCH v5 2/4] format-patch: add '--base' option to record base tree info

Xiaolong Ye writes: > +static struct commit *get_base_commit(const char *base_commit, > + struct commit **list, > + int total) > +{ > + struct commit *base = NULL; > + struct commit **rev; > +

Re: issue upgrading git from 1.8.2.1 to 2.8.0

On Fri, Apr 22, 2016 at 3:44 PM, Gennaro Torre wrote: > > Hi, > > Last week we upgraded git from 1.8.2.1 to 2.8.0. We saw some very > weird behavior where git clones and pushes were working, but git fetch > was not. > > Here is our setup: > > We have 10+ nodes caching a few

RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*

On Sat, Apr 23, 2016 at 1:33 AM, Ævar Arnfjörð Bjarmason wrote: > Change the hardcoded lookup for .git/hooks/* to optionally lookup in > $(git config core.hooksDirectory)/* instead if that config key is set. I think this'll do for my use-case, but I started with a rather more

Re: [PATCH] test-lib: simplify '--option=value' parsing

Jeff King writes: > For some reason I had always assumed that complicated pattern matching > with "#" was non-POSIX, but I checked and it is definitely in there. No, the offending code really dates back to the days back when I was writing most of the shell scripts (or others were

[PATCH v2 1/4] rev-parse: fix some options when executed from subpath of main tree

Executing `git-rev-parse` with `--git-common-dir`, `--git-path `, or `--shared-index-path` from the root of the main worktree results in a relative path to the git dir. When executed from a subdirectory of the main tree, however, it incorrectly returns a path which starts 'sub/path/.git'. Change

issue upgrading git from 1.8.2.1 to 2.8.0

Hi, Last week we upgraded git from 1.8.2.1 to 2.8.0. We saw some very weird behavior where git clones and pushes were working, but git fetch was not. Here is our setup: We have 10+ nodes caching a few repositories, the repos were originally cloned via git 1.8.2.1 with `git clone --mirror ` We

Re: issue upgrading git from 1.8.2.1 to 2.8.0

Stefan Beller writes: > Although 1.8..2.8 is a lot, Git ought to stay compatible there. In principle that is true, but there were deliberate backward incompatible changes at around 2.0 boundary, and those who followed along the upgrade paths were given warnings and advice

Re: [PATCH v5 2/4] format-patch: add '--base' option to record base tree info

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 >

Re: [PATCH v5 3/4] format-patch: introduce --base=auto option

Xiaolong Ye writes: > + if (upstream) { > + unsigned char sha1[20]; > + if (get_sha1(upstream, sha1)) > + die(_("Failed to resolve '%s' as a valid > ref."), upstream); > +

Re: [PATCH] name-rev: include taggerdate in considering the best name

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

[PATCH v2 0/6] object_id Part 3

This is the third of a series of patches to convert instances of unsigned char[20] to struct object_id. The focus in this series was to convert test-match-trees, related functions, and some dependencies. struct name_entry was converted as part of these dependencies. The riskiest part of this

Re: [PATCH v6 01/10] t0027: Make more reliable

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. > When the attributes

[PATCH v2 4/6] Convert struct name_entry to use struct object_id.

Signed-off-by: brian m. carlson --- builtin/grep.c | 6 +++--- builtin/merge-tree.c | 18 +- builtin/pack-objects.c | 4 ++-- builtin/reflog.c | 4 ++-- cache-tree.c | 4 ++-- fsck.c | 4 ++--

[PATCH v2 5/6] tree-walk: convert tree_entry_extract to struct object_id

Signed-off-by: brian m. carlson --- fsck.c| 6 +++--- match-trees.c | 12 ++-- tree-diff.c | 2 +- tree-walk.c | 10 +- tree-walk.h | 4 ++-- 5 files changed, 17 insertions(+), 17 deletions(-) diff --git a/fsck.c b/fsck.c index

[PATCH v2 2/6] test-match-trees: convert to use struct object_id

Signed-off-by: brian m. carlson --- test-match-trees.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/test-match-trees.c b/test-match-trees.c index 4dad7095..41aff841 100644 --- a/test-match-trees.c +++ b/test-match-trees.c @@

[PATCH v2 1/6] Introduce a get_oid function.

The get_oid function is equivalent to the get_sha1 function, but uses a struct object_id instead. Signed-off-by: brian m. carlson --- cache.h | 2 ++ sha1_name.c | 9 + 2 files changed, 11 insertions(+) diff --git a/cache.h b/cache.h index

[PATCH v2 3/6] match-trees: convert shift_tree and shift_tree_by to object_id

Signed-off-by: brian m. carlson --- cache.h| 4 ++-- match-trees.c | 44 ++-- merge-recursive.c | 4 ++-- test-match-trees.c | 2 +- 4 files changed, 27 insertions(+), 27 deletions(-) diff --git a/cache.h

[PATCH v2 6/6] match-trees: convert several leaf functions to struct object_id

Signed-off-by: brian m. carlson --- match-trees.c | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/match-trees.c b/match-trees.c index 8ca7c68f..396b7338 100644 --- a/match-trees.c +++ b/match-trees.c @@ -48,17

Re: possible bug of git stash deleting uncommitted files in corner case

On Fri, Apr 22, 2016 at 09:04:25PM +0200, Remi Galan Alfonso wrote: > For this bug it doesn't seem to be specifically linked to git stash, > since 'git status' doesn't display correct informations in the first > place (it doesn't show foo/bar as an untracked file). > > I tried something quickly,

Re: make test Unexpected passes

Ramsay Jones ramsayjones.plus.com> writes: > > Hi Ben, Junio, > > Tonight, the testsuite passed with a couple of 'unexpected passes', viz: > > In the first case, t3421-*.sh, git bisect fingered commit f32ec670 > ("git-rebase--merge: don't include absent parent as a base", 20-04-2016). > > ATB,

Re: [PATCH] hooks: Add ability to specify where the hook directory is

On Sat, Apr 23, 2016 at 2:13 AM, SZEDER Gábor wrote: > >> Change the hardcoded lookup for .git/hooks/* to optionally lookup in >> $(git config core.hooksDirectory)/* instead if that config key is set. >> >> This is essentially a more intrusive version of the git-init ability to

[PATCH] fast-import: implement --min-pack-size parameter

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

Re: [PATCH v1] travis-ci: build documentation

On Fri, Apr 22, 2016 at 10:34:02AM +0200, larsxschnei...@gmail.com wrote: > From: Lars Schneider > > Run "make doc" to check if all documentation can be build without errors. > Since the documentation is the same on every platform/compiler, the check > is only

Re: issue upgrading git from 1.8.2.1 to 2.8.0

On Sat, Apr 23, 2016 at 01:01:06AM -0400, Gennaro Torre wrote: > @Jeff King nope nothing interesting, it just hangs: > > [gtorre@host1 A:DEVEL tumblr.old]$ git fetch -vv > Looking up ... done. > Connecting to (port 9418) ... done. > Server supports multi_ack_detailed > Server supports

Re: issue upgrading git from 1.8.2.1 to 2.8.0

On Sat, Apr 23, 2016 at 01:18:50AM -0400, Gennaro Torre wrote: > This is what I see: > > 01:16:15.789969 pkt-line.c:80 packet:fetch> > git-upload-pack /tumblr.git\0host=\0 > 01:16:15.851231 pkt-line.c:80 packet:fetch< > a210029455476c3ae0d34748aeaeccf71864fd81

Re: [PATCH] fast-import: implement --min-pack-size parameter

On Sat, Apr 23, 2016 at 02:42:25AM +, Eric Wong wrote: > 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

Re: [PATCH] hooks: Add ability to specify where the hook directory is

> Change the hardcoded lookup for .git/hooks/* to optionally lookup in > $(git config core.hooksDirectory)/* instead if that config key is set. > > This is essentially a more intrusive version of the git-init ability to > specify hooks on init time via init templates. > > The difference between

Re: 0 bot for Git

> On 16 Apr 2016, at 20:02, Junio C Hamano wrote: > > Lars Schneider writes: > >>> Also this would incur wait time on Junios side >>> >>> 1) collect patches (many series over the day) >>> 2) push >>> 3) wait >>> 4) do the merges >> He could do the

Re: [git-multimail] smtplib, check certificate

Simon P writes: > Hi, Hi, and thanks for the patch. Please, add your sign-off and a proper commit message to your patch, see: https://github.com/git-multimail/git-multimail/blob/master/CONTRIBUTING.rst I'm OK with patches by email, but you may prefer using a

Re: [PATCH/RFC/GSoC 0/2] add a add.patch config variable

Hi Dominik, On Thu, 21 Apr 2016, Dominik Fischer wrote: > Indeed this needs more explanations for everyone who did not read the posts > before. Such as is the case for me. And most future readers of the commit messages ;-) > I strove to create an add.patch configuration option that did the

Re: [git-multimail] smtplib, check certificate

On 04/22/2016 08:05 AM, Matthieu Moy wrote: > Simon P writes: > > This patch is inspired from > > > > https://github.com/graingert/secure-smtplib/blob/master/src/secure_smtplib/__init__.py > > Please, add your sign-off and a proper commit message to your patch, > see: > >

Re: [PATCH/RFC/GSoC 0/2] add a add.patch config variable

Hi Dominik, On Thu, 21 Apr 2016, Dominik Fischer wrote: > Matthieu Moy writes: > > any transition plan would be far more painful than the possible benefits > I agree, it cannot be expected that every external script sets > GIT_RECURSION_DEPTH before issuing any

Re: [PATCH v2 2/2] git-p4: fix Git LFS pointer parsing

> On 20 Apr 2016, at 23:01, Junio C Hamano wrote: > > larsxschnei...@gmail.com writes: > >> -pointerContents = [i+'\n' for i in pointerFile.split('\n')[2:][:-1]] pointerFile was split here by '\n'. The splitting removes the newline and the i+'\n' adds it again. This

Re: [PATCH v2 2/2] git-p4: fix Git LFS pointer parsing

On Fri, Apr 22, 2016 at 9:53 AM, Lars Schneider wrote: > What would be the best way forward? A v3 with a better commit message > mentioning the array -> string change? I'd vote for that, yes. Also v3 could then properly incorporate my regexp. -- Sebastian Schuberth

Re: [PATCH] Update git-p4 to be compatible with git-lfs 1.2

> > > On Wed, Apr 20, 2016 at 12:36 PM, Lars Schneider > wrote: >> >>> On Wed, Apr 20, 2016 at 12:00 PM, Luke Diamand wrote: On 20 April 2016 at 19:28, Ben Woosley wrote: > From: Ben Woosley

[PATCH v1] travis-ci: build documentation

From: Lars Schneider Run "make doc" to check if all documentation can be build without errors. Since the documentation is the same on every platform/compiler, the check is only performed as part of the Linux/GCC build job to maintain a fast CI process. Signed-off-by:

Re: possible bug of git stash deleting uncommitted files in corner case

sorry I forgot: $ git --version git version 1.9.1 On Fri, Apr 22, 2016 at 1:46 PM, Daniele Segato wrote: > Hi, > > my coworker today claimed git stash deleted his files, I made him > explain me what he did and I think it could actually be a bug even if > happening

[PATCH 2/2] wrapper.c: delete dead function git_mkstemps()

Its last call site was replaced by mks_tempfile_ts() in 284098f (diff: use tempfile module - 2015-08-12) and there's a good chance mks_tempfile_ts will continue to successfully handle this job. Delete it. Signed-off-by: Nguyễn Thái Ngọc Duy --- cache.h | 2 -- wrapper.c |

[PATCH 1/2] dir.c: remove dead function fnmatch_icase()

It was largely replaced by fnmatch_icase_mem() and its last use was in 84b8b5d (remove match_pathspec() in favor of match_pathspec_depth() - 2013-07-14). Signed-off-by: Nguyễn Thái Ngọc Duy --- dir.c | 7 --- dir.h | 1 - 2 files changed, 8 deletions(-) diff --git

Re: [PATCH v1] travis-ci: build documentation

Am 22.04.2016 um 10:34 schrieb larsxschnei...@gmail.com: > From: Lars Schneider > > Run "make doc" to check if all documentation can be build without errors. s/build/built/ > Since the documentation is the same on every platform/compiler, the check > is only

possible bug of git stash deleting uncommitted files in corner case

Hi, my coworker today claimed git stash deleted his files, I made him explain me what he did and I think it could actually be a bug even if happening only in a corner case better explained with code to reproduce: git init echo 'X' > foo git add foo git commit -m 'foo file committed' what

Re: possible bug of git stash deleting uncommitted files in corner case

Daniele Segato wrote: > git init > echo 'X' > foo > git add foo > git commit -m 'foo file committed' > > rm foo > mkdir foo > echo 'B' > foo/bar > > # git status > > git stash > > at this point stash deleted the "bar" file, in his case all the work > on the previous

Re: [PATCH v1] travis-ci: build documentation

larsxschnei...@gmail.com writes: > + if [[ "$TRAVIS_OS_NAME" = linux ]] && [[ "$CC" = gcc ]]; [[ is a bashism, and doesn't bring anything here compared to the POSIX [ ... ], or "test" which is prefered in Git's source code. The ; or the newline is not needed either. I'd write if test

[PATCH v3 09/13] worktree.c: avoid referencing to worktrees[i] multiple times

Signed-off-by: Nguyễn Thái Ngọc Duy --- worktree.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/worktree.c b/worktree.c index dc092a7..927905b 100644 --- a/worktree.c +++ b/worktree.c @@ -229,10 +229,12 @@ const struct worktree

[PATCH v3 10/13] worktree.c: check whether branch is rebased in another worktree

This function find_shared_symref() is used in a couple places: 1) in builtin/branch.c: it's used to detect if a branch is checked out elsewhere and refuse to delete the branch. 2) in builtin/notes.c: it's used to detect if a note is being merged in another worktree 3) in branch.c, the

[PATCH v3 12/13] worktree.c: check whether branch is bisected in another worktree

Similar to the rebase case, we want to detect if "HEAD" in some worktree is being bisected because 1) we do not want to checkout this branch in another worktree, after bisect is done it will want to go back to this branch 2) we do not want to delete the branch is either or git bisect will

[PATCH v3 11/13] wt-status.c: split bisect detection out of wt_status_get_state()

And make it work with any given worktree, in preparation for (again) find_shared_symref(). read_and_strip_branch() is deleted because it's no longer used. Signed-off-by: Nguyễn Thái Ngọc Duy --- wt-status.c | 23 ++- wt-status.h | 2 ++ 2 files changed,

[PATCH v3 00/13] nd/worktree-various-heads

v3 fixes all the things found in v2, deletes unused stuff and adds a new patch 01/13 that renames str(n)cmp_icase to fspath(n)cmp. Interdiff diff --git a/branch.c b/branch.c index 8e323d3..a5a8dcb 100644 --- a/branch.c +++ b/branch.c @@ -338,12 +338,12 @@ void die_if_checked_out(const char

[PATCH v3 01/13] dir.c: rename str(n)cmp_icase to fspath(n)cmp

These functions compare two paths that are taken from file system. Depending on the running file system, paths may need to be compared case-sensitively or not, and maybe even something else in future. The current names do not convey that well. Signed-off-by: Nguyễn Thái Ngọc Duy

[PATCH] name-rev: include taggerdate in considering the best name

We most likely want the oldest tag that contained the commit to be reported. So let's remember the taggerdate, and make it more important than anything else when choosing the best name for a given commit. Suggested by Linus Torvalds. Note that we need to update t9903 because it tested for the

Re: history damage in linux.git

Hi Linus, On Thu, 21 Apr 2016, Linus Torvalds wrote: > On Thu, Apr 21, 2016 at 11:05 AM, Jeff King wrote: > > > > Sadly, neither git's internal version-sorting nor GNU's "sort -V" > > knows that "v1.0-rc1" comes before "v1.0", so I had to rely on > > "--sort=taggerdate". > > I'm

[PATCH v3 13/13] branch: do not rename a branch under bisect or rebase

The branch name in that case could be saved in rebase's head_name or bisect's BISECT_START files. Ideally we should try to update them as well. But it's trickier (*). Let's play safe and see if the user complains about inconveniences before doing that. (*) If we do it, bisect and rebase need to

Re: What's cooking in git.git (Apr 2016, #06; Thu, 21)

Hi Junio, On Thu, 21 Apr 2016, Junio C Hamano wrote: > * js/am-3-merge-recursive-direct (2015-10-12) 2 commits > - am: make a direct call to merge_recursive > - merge_recursive_options: introduce the "gently" flag > > The merge_recursive_generic() function has been made a bit safer to >

[PATCH v3 04/13] worktree.c: make find_shared_symref() return struct worktree *

This gives the caller more information and they can answer things like, "is it the main worktree" or "is it the current worktree". The latter question is needed for the "checkout a rebase branch" case later. Signed-off-by: Nguyễn Thái Ngọc Duy --- branch.c | 13

[PATCH v3 06/13] path.c: refactor and add worktree_git_path()

do_git_path(), which is the common code for all git_path* functions, is modified to take a worktree struct and can produce paths for any worktree. worktree_git_path() is the first function that makes use of this. It can be used to write code that can examine any worktree. For example,

[PATCH v3 05/13] worktree.c: mark current worktree

Signed-off-by: Nguyễn Thái Ngọc Duy --- worktree.c | 24 worktree.h | 1 + 2 files changed, 25 insertions(+) diff --git a/worktree.c b/worktree.c index 360ba41..dc092a7 100644 --- a/worktree.c +++ b/worktree.c @@ -2,6 +2,7 @@ #include "refs.h"

[PATCH v3 07/13] wt-status.c: split rebase detection out of wt_status_get_state()

worktree.c:find_shared_symref() later needs to know if a branch is being rebased, and only rebase, no cherry-pick, do detached branch... Split this code so it can be used independently from other in-progress tests. Signed-off-by: Nguyễn Thái Ngọc Duy --- wt-status.c | 23

[PATCH v3 02/13] path.c: add git_common_path() and strbuf_git_common_path()

These are mostly convenient functions to reduce code duplication. Most of the time, we should be able to get by with git_path() which handles $GIT_COMMON_DIR internally. However there are a few cases where we need to construct paths manually, for example some paths from a specific worktree. These

[PATCH v3 03/13] worktree.c: store "id" instead of "git_dir"

We can reconstruct git_dir from id quite easily. It's a bit hackier to do the reverse. Signed-off-by: Nguyễn Thái Ngọc Duy --- branch.c | 3 ++- worktree.c | 31 ++- worktree.h | 8 +++- 3 files changed, 27 insertions(+), 15 deletions(-)

[PATCH v3 08/13] wt-status.c: make wt_status_check_rebase() work on any worktree

This is a preparation step for find_shared_symref() to detect if any worktree is being rebased. Signed-off-by: Nguyễn Thái Ngọc Duy --- wt-status.c | 33 - wt-status.h | 5 - 2 files changed, 24 insertions(+), 14 deletions(-) diff --git

[PATCH 3/3] mmap(win32): avoid expensive fstat() call

On Windows, we have to emulate the fstat() call to fill out information that takes extra effort to obtain, such as the file permissions/type. If all we want is the file size, we can use the much cheaper GetFileSizeEx() function (available since Windows XP). Suggested by Philip Kelley.

[PATCH 2/3] mmap(win32): avoid copy-on-write when it is unnecessary

Often we are mmap()ing read-only. In those cases, it is wasteful to map in copy-on-write mode. Even worse: it can cause errors where we run out of space in the page file. So let's be extra careful to map files in read-only mode whenever possible. Signed-off-by: Johannes Schindelin

[PATCH v6 07/10] convert: unify the "auto" handling of CRLF

From: Torsten Bögershausen Before this change, $ echo "* text=auto" >.gitattributes $ echo "* eol=crlf" >>.gitattributes would have the same effect as $ echo "* text" >.gitattributes $ git config core.eol crlf Since the 'eol' attribute had higher priority than 'text=auto', this

[PATCH v6 01/10] t0027: Make more reliable

From: Torsten Bögershausen Make the commit_chk_wrnNNO test in t0027 more reliable: When the attributes of a commited file are changed and the file is otherwise unchanged, Git may not detect that the next commit may need to treat the file as changed. This happens when lstat()

[PATCH v6 03/10] t0027: test cases for combined attributes

From: Torsten Bögershausen Add more test cases for the not normalized files ("NNO"). The "text" attribute is most important, use it as the first parameter. "ident", if set, is the second paramater followed by the eol attribute. The eol attribute overrides core.autocrlf, which

[PATCH v6 08/10] convert.c: more safer crlf handling with text attribute

From: Torsten Bögershausen A follow-up after a discussion how to fix the flaky execution of t0025, gmane/$284352. This patch extends the work done in commit c480539: "Make it work also for un-normalized repositories". Make sure that CRLF can be converted round trip, or don't

[PATCH v6 06/10] convert.c: stream and early out

From: Torsten Bögershausen When statistics are done for the autocrlf handling, the search in the content can be stopped, if e.g - a search for binary is done, and a NUL character is found - a search for CRLF is done, and the first CRLF is found. Similar when statistics for binary

[PATCH v6 09/10] t6038; use crlf on all platforms

From: Torsten Bögershausen t6038 uses different code, dependig if NATIVE_CRLF is set ot not. When the native line endings are LF, merge.renormalize is not tested very well. Change the test to always use CRLF by setting core.eol=crlf. After doing so, the test fails: rm

[PATCH v6 05/10] read-cache: factor out get_sha1_from_index() helper

From: Torsten Bögershausen Factor out the retrieval of the sha1 for a given path in read_blob_data_from_index() into the function get_sha1_from_index(). This will be used in the next commit, when convert.c can do the analyze for "text=auto" without slurping the whole blob into

[PATCH v6 10/10] ce_compare_data() did not respect conversion

From: Torsten Bögershausen We define the working tree file is clean if either: * the result of running convert_to_git() on the working tree contents matches what is in the index (because that would mean doing another "git add" on the path is a no-op); OR * the result

[PATCH v6 04/10] convert.c: ident + core.autocrlf didn't work

From: Torsten Bögershausen When the ident attributes is set, get_stream_filter() did not obey core.autocrlf=true, and the file was checked out with LF. Change the rule when a streaming filter can be used: - if an external filter is specified, don't use a stream filter. - if the

[PATCH v8 1/6] builtin/verify-tag.c: ignore SIGPIPE in gpg-interface

From: Santiago Torres The verify_signed_buffer() function may trigger a SIGPIPE when the GPG child process terminates early (due to a bad keyid, for example) and Git tries to write to it afterwards. Previously, ignoring SIGPIPE was done in builtin/verify-tag.c to avoid this

[PATCH] test-lib: simplify '--option=value' parsing

To get the 'value' from '--option=value', test-lib.sh parses said option running 'expr' with a regexp. This involves a subshell, an external process, and a lot of non-alphanumeric characters in the regexp. Use a much simpler shell parameter expansion instead to do the same. Signed-off-by:

[PATCH v8 2/6] t7030: test verifying multiple tags

From: Santiago Torres The verify-tag command supports multiple tag names to verify, but existing tests only test for invocation with a single tag. Add a test invoking it with multiple tags. Helped-by: Jeff King Signed-off-by: Santiago Torres

[PATCH v8 4/6] verify-tag: prepare verify_tag for libification

From: Santiago Torres The current interface of verify_tag() resolves reference names to SHA1, however, the plan is to make this functionality public and the current interface is cumbersome for callers: they are expected to supply the textual representation of a sha1/refname. In

[PATCH 1/3] win32mmap: set errno appropriately

It is not really helpful when a `git fetch` fails with the message: fatal: mmap failed: No error In the particular instance encountered by a colleague of yours truly, the Win32 error code was ERROR_COMMITMENT_LIMIT which means that the page file is not big enough. Let's make the message

[PATCH v6 02/10] convert: allow core.autocrlf=input and core.eol=crlf

From: Torsten Bögershausen Even though the configuration parser errors out when core.autocrlf is set to 'input' when core.eol is set to 'crlf', there is no need to do so, because the core.autocrlf setting trumps core.eol. Allow all combinations of core.crlf and core.eol and

[PATCH v8 3/6] verify-tag: update variable name and type

From: Santiago Torres The run_gpg_verify() function has two variables, size and len. This may come off as confusing when reading the code. Clarify which one pertains to the length of the tag headers by renaming len to payload_size. Additionally, change the type of payload_size

[PATCH v8 0/6] Move PGP verification out of verify-tag

From: Santiago Torres This is a follow up of [1], [2], [3], [4], [5], [6], and [7]. patches 1/6, 2/6, and 3/6, are the same as the corresponding commits in pu. v8: Minor nits, I decided to quickly reroll to drop the extern qualifier in tag.c: * Eric pointed out that we

[PATCH v8 6/6] tag -v: verify directly rather than exec-ing verify-tag

From: Santiago Torres Instead of having tag -v fork to run verify-tag, use the gpg_verify_tag() function directly. Helped-by: Eric Sunshine Signed-off-by: Santiago Torres --- builtin/tag.c | 8 +--- 1 file changed, 1

[PATCH v8 5/6] verify-tag: move tag verification code to tag.c

From: Santiago Torres The PGP verification routine for tags could be accessed by other modules that require to do so. Publish the verify_tag function in tag.c and rename it to gpg_verify_tag so it does not conflict with builtin/mktag's static function. Helped-by: Junio C

[PATCH 0/3] Improve the mmap() emulation on Windows

Kevin David reported a problem last October where a simple git fetch would produce this error output: fatal: mmap failed: No error fatal: write error: Invalid argument The reason was that several bits of our mmap() emulation left room for improvement. These patches fix it, and

Re: [PATCH v8 0/6] Move PGP verification out of verify-tag

On Fri, Apr 22, 2016 at 10:51 AM, wrote: > This is a follow up of [1], [2], [3], [4], [5], [6], and [7]. patches 1/6, > 2/6, and 3/6, are the same as the corresponding commits in pu. > > v8: > Minor nits, I decided to quickly reroll to drop the extern qualifier in tag.c: > *

Re: What's cooking in git.git (Apr 2016, #06; Thu, 21)

Jeff King writes: > On Thu, Apr 21, 2016 at 03:20:39PM -0700, Junio C Hamano wrote: > >> * jk/push-client-deadlock-fix (2016-04-20) 5 commits >> - t5504: drop sigpipe=ok from push tests >> - fetch-pack: isolate sigpipe in demuxer thread >> - send-pack: isolate sigpipe in

Re: 0 bot for Git

Lars Schneider writes: > Thanks for the explanation. My intention was not to be offensive. > I was curious about your workflow and I was wondering if the > Travis CI integration could be useful for you in any way. Don't worry; I didn't feel offended. The Travis stuff

Re: [PATCH v8 5/6] verify-tag: move tag verification code to tag.c

On Fri, Apr 22, 2016 at 10:52 AM, wrote: > The PGP verification routine for tags could be accessed by other modules > that require to do so. > > Publish the verify_tag function in tag.c and rename it to gpg_verify_tag > so it does not conflict with builtin/mktag's static

[PATCH] string_list: use string-list API in unsorted_string_list_lookup()

Using the string-list API in function unsorted_string_list_lookup() makes the code more readable. So let's do this. Signed-off-by: Ralf Thielow --- string-list.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/string-list.c b/string-list.c

Re: possible bug of git stash deleting uncommitted files in corner case

Remi Galan Alfonso writes: > Daniele Segato wrote: > ... >> git version 1.9.1 > > Contrary to what I expected, this seems to still be the case with: > $ git --version > git version 2.8.0.rc2 I do not think "git stash"

Re: [PATCH] name-rev: include taggerdate in considering the best name

Jeff King writes: > That turned out to be quite simple (I wasn't sure originally if we'd > actually visit all of the tags, which is why I had conceived of this as > an initial pass; but of course it makes sense that we'd have to see all > of the tags in the existing code). > ... >

Re: What's cooking in git.git (Apr 2016, #06; Thu, 21)

Johannes Schindelin writes: > Hi Junio, > > On Thu, 21 Apr 2016, Junio C Hamano wrote: > >> * js/am-3-merge-recursive-direct (2015-10-12) 2 commits > ... > I hope to find the time next week to go through the entire call graph and > verify that we are only die()ing in

  1   2   >