Re: [PATCH v2 1/5] core.aheadbehind: add new config setting

Jeff King writes: > I, too, had a funny feeling about calling this "core". But I didn't have > a better name, as I'm not sure what other place we have for config > options that cross many command boundaries. "diff" and "status" don't > seem quite right to me. While you can argue

Re: [PATCH 3/1] update-index doc: note a fixed bug in the untracked cache

Ævar Arnfjörð Bjarmason writes: > Document the bug tested for in my "status: add a failing test showing > a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir > invalidation in untracked code". > > Since this is very likely something others will encounter in

Re: [PATCH] status: handle worktree renames

Duy Nguyen writes: > Or we disable rename-from-worktree when porcelain v2 is requested (and > optionally introduce v3 to support it). Jeff, any preference? I actually think disabling rename-from-worktree consistently may be the best way to go.

Re: [RFC PATCH v2] http: support CURLPROXY_HTTPS

Wei Shuyu wrote: > Git has been taught to support an https:// used for http.proxy when > using recent versions of libcurl. nit: commit messages use the imperative mood, as though commanding the code base to do something: Support https:// for http.proxy when using recent versions of

Re: [PATCH v3 2/4] travis-ci: don't install default addon packages for the 32 bit Linux build

> On 27 Dec 2017, at 17:36, SZEDER Gábor wrote: > > The 32 bit Linux build job compiles Git and runs the test suite in a > Docker container, while the additional packages (apache2, git-svn, > language-pack-is) are installed on the host, therefore don't have > any effect

Re: [RFC PATCH v2] http: support CURLPROXY_HTTPS

Ævar Arnfjörð Bjarmason writes: > On Sat, Dec 23 2017, Wei Shuyu jotted: > >> Git has been taught to support an https:// used for http.proxy when >> using recent versions of libcurl. >> >> To use https proxy with self-signed certs, we need a way to >> unset

Re: [PATCH] diffcore: add a filter to find a specific blob

On Thu, Dec 14, 2017 at 6:18 PM, Junio C Hamano wrote: > Jonathan Nieder writes: > >>> Regarding finding a better name, I would want to hear from others, >>> I am happy with --find-object, though I can see --pickaxe-object >>> or --object--filter to be a

Re: [PATCH] status: add a failing test showing a core.untrackedCache bug

On Wed, Dec 27 2017, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason writes: > >> +status_is_clean() { >> +>../status.expect && >> +git status --porcelain >../status.actual && >> +test_cmp ../status.expect ../status.actual >> +} >> + >> test_lazy_prereq

Re: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

Eric Wong writes: > Fair enough, I haven't run 5.8 in a while, either. One concern > I have is it makes reviewing more difficult as the language gets > bigger and (even more) unfamiliar constructs pop up. This is > probably more important for git as most of us are not dedicated

Re: [PATCH] diffcore: add a filter to find a specific blob

Stefan Beller wrote: > On Thu, Dec 14, 2017 at 6:18 PM, Junio C Hamano wrote: >> I think it would make it a better companion to --pickaxe but we need >> to align its behaviour a little bit so that it plays better with the >> "--pickaxe-all" option, and also needs to hide mode

Re: [PATCH] status: add a failing test showing a core.untrackedCache bug

On Wed, Dec 27, 2017 at 5:25 AM, Duy Nguyen wrote: > Subject: [PATCH] dir.c: fix missing dir invalidation in untracked code > [...] > After step 3, we mark the cache valid. Any stale subdir with incorrect > recurse flagbecomes a real subdir next time we traverse the directory

Re: [PATCH] oidmap: ensure map is initialized

Brandon Williams writes: > Ensure that an oidmap is initialized before attempting to add, remove, > or retrieve an entry by simply performing the initialization step > before accessing the underlying hashmap. > > Signed-off-by: Brandon Williams > --- Looks

Re: [PATCH] status: add a failing test showing a core.untrackedCache bug

Ævar Arnfjörð Bjarmason writes: > +status_is_clean() { > + >../status.expect && > + git status --porcelain >../status.actual && > + test_cmp ../status.expect ../status.actual > +} > + > test_lazy_prereq UNTRACKED_CACHE ' > { git update-index

Re: [PATCH] status: handle worktree renames

Duy Nguyen writes: >> The problem is, you cannot know if it's a rename from HEAD or from >> worktree with this updated v2 (or perhaps you could because HEAD name >> should be all zero?). > > I'm wrong about this. the "" code for HEAD rename would be "R." > while worktree

Re: [RFC] Prepend "tags/" when describing tags with embedded name

Daniel Knittl-Frank writes: > On Fri, Dec 15, 2017 at 8:25 PM, Junio C Hamano wrote: >> I think the code makes sense, but it won't be understandable by >> those who do not know what you discussed in the original thread. >> >> A proper commit log

Re: [PATCH v3 1/4] travis-ci: fine tune the use of 'set -x' in 'ci/*' scripts

> On 27 Dec 2017, at 17:36, SZEDER Gábor wrote: > > The change in commit 4f2636667 (travis-ci: use 'set -x' in 'ci/*' > scripts for extra tracing output, 2017-12-12) left a couple of rough > edges: > > - 'ci/run-linux32-build.sh' is executed in a Docker container and >

Re: [PATCH v3 3/4] travis-ci: save prove state for the 32 bit Linux build

> On 27 Dec 2017, at 17:36, SZEDER Gábor wrote: > > This change follows suit of 6272ed319 (travis-ci: run previously > failed tests first, then slowest to fastest, 2016-01-26), which did > this for the Linux and OSX build jobs. Travis CI build jobs run the > tests

Re: [PATCH v3 4/4] travis-ci: only print test failures if there are test results available

> On 27 Dec 2017, at 17:36, SZEDER Gábor wrote: > > When a build job running the test suite fails, our > 'ci/print-test-failures.sh' script scans all 't/test-results/*.exit' > files to find failed tests and prints their verbose output. However, > if a build job were to

Re: [PATCH] setup.c: move statement under condition

Johannes Schindelin writes: >> I suppose that if the condition is fulfilled then the previously >> obtained value will not be necessary. > > I have to be honest: this commit message (including the subject) left me > quite puzzled as to the intent of this patch. > >

Re: Bring together merge and rebase

On Dec 27, 2017, at 06:35, Carl Baldwin wrote: > > On Sun, Dec 24, 2017 at 10:52:15PM -0500, Theodore Ts'o wrote: >> >> My experience, from seeing these much more complex use cases --- >> starting with something as simple as the Linux Kernel Stable Kernel >> Series, and

Re: [PATCH v2 7/7] wildmatch test: create & test files on disk in addition to in-memory

Ævar Arnfjörð Bjarmason writes: > + # Turn foo/bar/baz into foo/bar to create foo/bar as a > + # directory structure. > + dirs=$(echo "$file" | sed -r 's!/[^/]+$!!') Let's not limit this script to GNUism systems. You want to see if $file has a slash followed by

Re: [PATCH v2 8/9] rebase -i: learn to abbreviate command names

Duy Nguyen writes: > On Mon, Dec 4, 2017 at 5:17 AM, Liam Beguin wrote: >> +static const char command_to_char(const enum todo_command command) >> +{ >> + if (command < TODO_COMMENT && todo_command_info[command].c) >> + return

Re: [PATCH 2/2] travis-ci: record and skip successfully built trees

> On 27 Dec 2017, at 17:49, SZEDER Gábor wrote: > > Travis CI dutifully builds and tests each new branch tip, even if its > tree has previously been successfully built and tested. This happens > often enough in contributors' workflows, when a work-in-progress > branch is

Re: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

Hi, Ævar Arnfjörð Bjarmason wrote: > This is similar to Jeff King's jk/drop-ancient-curl series in that > we're dropping perl releases that are rarely tested anymore, however > unlike those patches git still works on e.g. 5.8.8 (I couldn't build > anything older). FWIW I think this is a good

Re: [RFC/PATCH] perl: bump the required Perl version to 5.10.0 from 5.8.0

Jonathan Nieder wrote: > Ævar Arnfjörð Bjarmason wrote: >> This is similar to Jeff King's jk/drop-ancient-curl series in that >> we're dropping perl releases that are rarely tested anymore, however >> unlike those patches git still works on e.g. 5.8.8 (I couldn't build >> anything older). [...] >

Re: [PATCH 2/5] t/lib-submodule-update.sh: Fix test ignoring ignored files in submodules

On Fri, Dec 22, 2017 at 11:34 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> It turns out that this buggy test passed due to the buggy implementation, >> which will soon be corrected. Let's fix the test first. > > Please clarify "buggy test".

Re: [PATCH 2/2] travis-ci: record and skip successfully built trees

> On 27 Dec 2017, at 17:49, SZEDER Gábor wrote: > > Travis CI dutifully builds and tests each new branch tip, even if its > tree has previously been successfully built and tested. This happens > often enough in contributors' workflows, when a work-in-progress > branch is

Re: [PATCH] Fix confusing wording

Ivan Pozdeev writes: > Not sure if I should add a CVE-2009-0037 reference as well. Not in an end-user facing message like this one, I would say. > > --- Sign off? > http.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/http.c b/http.c > index

Re: [PATCH 1/2] travis-ci: don't try to create the cache directory unnecessarily

SZEDER Gábor wrote: > Travis CI creates that directory for us anyway, even when a previous > cache doesn't exist for the current build job. > > In itself it doesn't hurt to try, of course, but the following patch > will access the Travis CI cache much earlier in the build process, and > then

Re: [PATCH] diffcore: add a filter to find a specific blob

Jonathan Nieder writes: > Stefan Beller wrote: >> On Thu, Dec 14, 2017 at 6:18 PM, Junio C Hamano wrote: > >>> I think it would make it a better companion to --pickaxe but we need >>> to align its behaviour a little bit so that it plays better with the >>>

[PATCH v3 3/4] travis-ci: save prove state for the 32 bit Linux build

This change follows suit of 6272ed319 (travis-ci: run previously failed tests first, then slowest to fastest, 2016-01-26), which did this for the Linux and OSX build jobs. Travis CI build jobs run the tests parallel, which is sligtly faster when tests are run in slowest to fastest order,

[PATCH v3 0/4] Rest of the Travis CI fixes

These are the rest of the fixes that were in the second half of the v2 patch series but not already in 'sg/travis-fixes', which was already merged to next, perhaps a bit prematurely. Patch 1/4 fixes some rough edges related to tracing executed commands according to the discussion. Patches 2/4,

[PATCH v3 4/4] travis-ci: only print test failures if there are test results available

When a build job running the test suite fails, our 'ci/print-test-failures.sh' script scans all 't/test-results/*.exit' files to find failed tests and prints their verbose output. However, if a build job were to fail before it ever gets to run the test suite, then there will be no files to match

[PATCH v3 1/4] travis-ci: fine tune the use of 'set -x' in 'ci/*' scripts

The change in commit 4f2636667 (travis-ci: use 'set -x' in 'ci/*' scripts for extra tracing output, 2017-12-12) left a couple of rough edges: - 'ci/run-linux32-build.sh' is executed in a Docker container and therefore doesn't source 'ci/lib-travisci.sh', which would enable tracing

[PATCH v3 2/4] travis-ci: don't install default addon packages for the 32 bit Linux build

The 32 bit Linux build job compiles Git and runs the test suite in a Docker container, while the additional packages (apache2, git-svn, language-pack-is) are installed on the host, therefore don't have any effect and are unnecessary. Signed-off-by: SZEDER Gábor ---

[PATCH 1/2] travis-ci: don't try to create the cache directory unnecessarily

Travis CI creates that directory for us anyway, even when a previous cache doesn't exist for the current build job. In itself it doesn't hurt to try, of course, but the following patch will access the Travis CI cache much earlier in the build process, and then creating the cache directory this

[PATCH 2/2] travis-ci: record and skip successfully built trees

Travis CI dutifully builds and tests each new branch tip, even if its tree has previously been successfully built and tested. This happens often enough in contributors' workflows, when a work-in-progress branch is rebased changing e.g. only commit messages or the order or number of commits while

[PATCH 0/2] Travis CI: skip commits with successfully built and tested trees

Travis CI dutifully builds and tests each new branch tip, even if its tree has previously been successfully built and tested. This happens often enough in contributors' workflows, when a work-in-progress branch is rebased changing e.g. only commit messages or the order or number of commits while

[PATCH v3 3/6] wt-status.c: coding style fix

Signed-off-by: Nguyễn Thái Ngọc Duy --- wt-status.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/wt-status.c b/wt-status.c index 59338adb8b..db06fc7c85 100644 --- a/wt-status.c +++ b/wt-status.c @@ -406,7 +406,8 @@ static void

[PATCH v3 4/6] wt-status.c: catch unhandled diff status codes

Signed-off-by: Nguyễn Thái Ngọc Duy --- wt-status.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/wt-status.c b/wt-status.c index db06fc7c85..05af895fe2 100644 --- a/wt-status.c +++ b/wt-status.c @@ -468,8 +468,8 @@ static void

[PATCH v3 6/6] wt-status.c: handle worktree renames

Before 425a28e0a4 (diff-lib: allow ita entries treated as "not yet exist in index" - 2016-10-24) there are never "new files" in the index, which essentially disables rename detection because we only detect renames when a new file appears in a diff pair. After that commit, an i-t-a entry can

[PATCH v3 5/6] wt-status.c: rename rename-related fields in wt_status_change_data

These field "head_path" is used for rename display only. In the next patch we introduce another rename pair where the rename source is no longer HEAD. Rename it to something more generic. While at there, rename "score" as well and store the rename diff code in a separate field instead of

[PATCH 3/1] update-index doc: note a fixed bug in the untracked cache

Document the bug tested for in my "status: add a failing test showing a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir invalidation in untracked code". Since this is very likely something others will encounter in the future on older versions, and it's not obvious how to fix

Re: [PATCH] status: add a failing test showing a core.untrackedCache bug

On Tue, Dec 26, 2017 at 05:47:19PM +0700, Duy Nguyen wrote: > Strangely, root dir is not cached (no valid flag). I don't know why > but that's ok we'll roll with it. I figured this out. Which is good because now I know how/why the bug happens. > An invalidate_directory() call before the "return

[PATCH v3 0/6] Renames in git-status "changed not staged" section

v3 more or less goes back to v1 after my discussion with Igor about porcelain formats. So 7/7 is not needed anymore. 4/7 becomes 5/6. The meat is still in 6/6, now with some more updates in git-status.txt and to address the comment from Torsten. Nguyễn Thái Ngọc Duy (6): t2203: test status

[PATCH v3 1/6] t2203: test status output with porcelain v2 format

Signed-off-by: Nguyễn Thái Ngọc Duy --- t/t2203-add-intent.sh | 12 1 file changed, 12 insertions(+) diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh index 1bdf38e80d..878e73fe98 100755 --- a/t/t2203-add-intent.sh +++ b/t/t2203-add-intent.sh @@ -25,6

[PATCH v3 2/6] Use DIFF_DETECT_RENAME for detect_rename assignments

This field can have two values (2 for copy). Use this name instead for clarity. Many places have already used this constant. Note, the detect_rename assignments in merge-recursive.c remain unchanged because it's actually a boolean there. Signed-off-by: Nguyễn Thái Ngọc Duy

waiting to hear from you soon.

Hello dear how are you? Nice to meet you,my name is Miss Nadege Yann, can we become friends? hope to hear from you so that we can know each other very well, love matters mostly in life,i will also send you my pictures and tell you more about myself, my email address is(missnade...@gmail.com)

Re: [PATCH 2/2] travis-ci: record and skip successfully built trees

On Thu, Dec 28, 2017 at 12:00 AM, SZEDER Gábor wrote: > On Wed, Dec 27, 2017 at 8:15 PM, Lars Schneider > wrote: >>> + then >>> + cat <<-EOF >>> + Skipping build job for commit $TRAVIS_COMMIT.

[PATCHv2 4/5] unpack-trees: oneway_merge to update submodules

When there is a one way merge, each submodule needs to be one way merged as well, if we're asked to recurse into submodules. In case of a submodule, check if it is up-to-date, otherwise set the flag CE_UPDATE, which will trigger an update of it in the phase updating the tree later.

[PATCHv2 1/5] t/helper/test-lazy-name-hash: fix compilation

I was compiling origin/master today with stricter compiler flags today and was greeted by t/helper/test-lazy-init-name-hash.c: In function ‘cmd_main’: t/helper/test-lazy-init-name-hash.c:172:5: error: ‘nr_threads_used’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

[PATCHv2 0/5] Fix --recurse-submodules for submodule worktree changes

I dropped the patch to `same()` as I realized we only need to fix the oneway_merge function, the others (two, three way merge) are fine as they have the checks already in place. The test added in the last patch got slightly larger as now we also test for newly staged files to be blown away in the

[PATCHv2 5/5] submodule: submodule_move_head omits old argument in forced case

When using hard reset or forced checkout with the option to recurse into submodules, the submodules need to be reset, too. It turns out that we need to omit the duplicate old argument to read-tree in all forced cases to omit the 2 way merge and use the more assertive behavior of reading the

[PATCHv2 2/5] t/lib-submodule-update.sh: clarify test

Keep the local branch name as the upstream branch name to avoid confusion. Signed-off-by: Stefan Beller --- t/lib-submodule-update.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/lib-submodule-update.sh b/t/lib-submodule-update.sh index

[PATCHv2 3/5] t/lib-submodule-update.sh: Fix test ignoring ignored files in submodules

It turns out that the test replacing a submodule with a file with the submodule containing an ignored file is incorrectly titled, because the test put the file in place, but never ignored that file. When having an untracked file Instead of an ignored file in the submodule, git should refuse to

[PATCH 0/2] When DC_SHA1 was made the default we missed a spot

When SHADC was made the default in 2.13.0 we forgot that NO_OPENSSL=1 would still turn it off implicitly, and that Windows would use BLK_SHA1=1 by default thinking it would be getting the OpenSSL version. Ævar Arnfjörð Bjarmason (2): Makefile: NO_OPENSSL=1 should no longer imply BLK_SHA1=1

Re: [PATCH 0/5] A couple of sequencer cleanups

Johannes Schindelin writes: > Johannes Schindelin (5): > rebase: do not continue when the todo list generation failed > sequencer: strip bogus LF at end of error messages > sequencer: remove superfluous conditional > sequencer: report when noop has an argument

What's cooking in git.git (Dec 2017, #05; Wed, 27)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. You can find the changes

Re: [PATCH v3 3/4] travis-ci: save prove state for the 32 bit Linux build

On Wed, Dec 27, 2017 at 7:46 PM, Lars Schneider wrote: >> + --volume "${HOME}/travis-cache:/tmp/travis-cache" \ > > I assume "${HOME}/travis-cache:/usr/src/git/t/.prove" would not > work because that would be a mapping in another mapping? 't/.prove' is a file, but

Re: [PATCH v2 8/9] rebase -i: learn to abbreviate command names

Hi Junio, On 27 December 2017 at 20:15, Junio C Hamano wrote: > Duy Nguyen writes: > >> On Mon, Dec 4, 2017 at 5:17 AM, Liam Beguin wrote: >>> +static const char command_to_char(const enum todo_command command) >>> +{ >>> + if

Re: [PATCH v6] Makefile: replace perl/Makefile.PL with simple make rules

On Fri, Dec 22 2017, Junio C. Hamano jotted: > Ævar Arnfjörð Bjarmason writes: > >> Signed-off-by: Ævar Arnfjörð Bjarmason >> --- > > Thanks, but I thought the patch was already in 'next' for a week or > more and it's time to refine incrementally. > > Here

Re: [PATCH 5/5] sequencer: do not invent whitespace when transforming OIDs

Hi Johannes, On 23 December 2017 at 00:56, Johannes Schindelin wrote: > For commands that do not have an argument, there is no need to append a > trailing space at the end of the line. > > Signed-off-by: Johannes Schindelin > --- >

[PATCH 2/2] Windows: stop supplying BLK_SHA1=YesPlease by default

Using BLK_SHA1 in lieu of the OpenSSL routines was done in [1], but since DC_SHA1 is now the default for git in general it makes sense for Windows to use that too, this looks like something that was missed back in [2]. As noted in [3] OpenSSL has a performance benefit compared to BLK_SHA1 on

[PATCH 1/2] Makefile: NO_OPENSSL=1 should no longer imply BLK_SHA1=1

Stop supplying BLK_SHA1=YesPlease when NO_OPENSSL=UnfortunatelyYes is supplied. This has been done ever since [1], when switching to DC_SHA1 by default in [2] this should have been changed as well. 1. dd53c7ab29 ("[PATCH] Support for NO_OPENSSL", 2005-07-29) 2. e6b07da278 ("Makefile: make

Re: [PATCH 2/2] travis-ci: record and skip successfully built trees

On Wed, Dec 27, 2017 at 8:15 PM, Lars Schneider wrote: > >> On 27 Dec 2017, at 17:49, SZEDER Gábor wrote: >> +# Skip the build job if the same tree has already been built and tested >> +# successfully before (e.g. because the branch got rebased,

Re: [PATCH 1/2] Makefile: NO_OPENSSL=1 should no longer imply BLK_SHA1=1

Hi, Ævar Arnfjörð Bjarmason wrote: > Stop supplying BLK_SHA1=YesPlease when NO_OPENSSL=UnfortunatelyYes is > supplied. This has been done ever since [1], when switching to DC_SHA1 > by default in [2] this should have been changed as well. I had trouble parsing this, I think for a few reasons:

Re: [PATCH 2/2] Windows: stop supplying BLK_SHA1=YesPlease by default

+git-for-windows Ævar Arnfjörð Bjarmason wrote: > Using BLK_SHA1 in lieu of the OpenSSL routines was done in [1], but > since DC_SHA1 is now the default for git in general it makes sense for > Windows to use that too, this looks like something that was missed > back in [2]. > > As noted in [3]

[PATCH 0/1] Add blob find pickaxe option

This is a resend for sb/diff-blobfind, but now the option --find-object is a native of the pickaxe family. Stefan Beller (1): diffcore: add a pickaxe option to find a specific blob Documentation/diff-options.txt | 10 +++ diff.c | 21 - diff.h

[PATCH 1/1] diffcore: add a pickaxe option to find a specific blob

Sometimes users are given a hash of an object and they want to identify it further (ex.: Use verify-pack to find the largest blobs, but what are these? or [1]) One might be tempted to extend git-describe to also work with blobs, such that `git describe ` gives a description as ':'. This was

Re: [PATCH v3 0/6] Renames in git-status "changed not staged" section

Hi Duy, On 27/12/2017 11:18, Nguyễn Thái Ngọc Duy wrote: > > v3 more or less goes back to v1 after my discussion with Igor about > porcelain formats. So 7/7 is not needed anymore. 4/7 becomes 5/6. The > meat is still in 6/6, now with some more updates in git-status.txt and > to address the

Re: [PATCH v2 6/7] wt-status.c: handle worktree renames

p.s. An extra note for the casual reader, just in case: On 28/12/2017 01:50, Igor Djordjevic wrote: > > ... it totally slipped me that documentation is/was pretty strict > about being HEAD path (exclusively), where I was still > expecting it to show renamed working tree "from" value as > in

[PATCH v5 14/34] directory rename detection: tests for handling overwriting dirty files

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 436 1 file changed, 436 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 7248c3807..bdffdb70b 100755 ---

[PATCH v5 28/34] merge-recursive: apply necessary modifications for directory renames

This commit hooks together all the directory rename logic by making the necessary changes to the rename struct, it's dst_entry, and the diff_filepair under consideration. Signed-off-by: Elijah Newren --- merge-recursive.c | 187

[PATCH v5 22/34] merge-recursive: add get_directory_renames()

This populates a list of directory renames for us. The list of directory renames is not yet used, but will be in subsequent commits. Signed-off-by: Elijah Newren --- merge-recursive.c | 155 -- 1 file changed, 152

[PATCH v5 10/34] directory rename detection: more involved edge/corner testcases

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 381 1 file changed, 381 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 50fb8f41e..cfb53295b 100755 ---

[PATCH v5 23/34] merge-recursive: check for directory level conflicts

Before trying to apply directory renames to paths within the given directories, we want to make sure that there aren't conflicts at the directory level. There will be additional checks at the individual file level too, which will be added later. Signed-off-by: Elijah Newren

[PATCH v5 34/34] merge-recursive: ensure we write updates for directory-renamed file

When a file is present in HEAD before the merge and the other side of the merge does not modify that file, we try to avoid re-writing the file and making it stat-dirty. However, when a file is present in HEAD before the merge and was in a directory that was renamed by the other side of the merge,

[PATCH v5 30/34] merge-recursive: fix overwriting dirty files involved in renames

This fixes an issue that existed before my directory rename detection patches that affects both normal renames and renames implied by directory rename detection. Additional codepaths that only affect overwriting of directy files that are involved in directory rename detection will be added in a

[PATCH v5 00/34] Add directory rename detection to git

This patchset introduces directory rename detection to merge-recursive. See https://public-inbox.org/git/20171110190550.27059-1-new...@gmail.com/ for the first series (including design considerations, etc.), and follow-up series can be found at

[PATCH v5 04/34] directory rename detection: basic testcases

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 430 1 file changed, 430 insertions(+) create mode 100755 t/t6043-merge-rename-directories.sh diff --git a/t/t6043-merge-rename-directories.sh

[PATCH v5 11/34] directory rename detection: testcases exploring possibly suboptimal merges

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 394 1 file changed, 394 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index cfb53295b..7c75363e5 100755 ---

[PATCH v5 29/34] merge-recursive: avoid clobbering untracked files with directory renames

Signed-off-by: Elijah Newren --- merge-recursive.c | 42 +++-- t/t6043-merge-rename-directories.sh | 6 +++--- 2 files changed, 43 insertions(+), 5 deletions(-) diff --git a/merge-recursive.c b/merge-recursive.c index

[PATCH v5 33/34] merge-recursive: avoid spurious rename/rename conflict from dir renames

If a file on one side of history was renamed, and merely modified on the other side, then applying a directory rename to the modified side gives us a rename/rename(1to2) conflict. We should only apply directory renames to pairs representing either adds or renames. Making this change means that a

[PATCH v5 21/34] merge-recursive: make a helper function for cleanup for handle_renames

In anticipation of more involved cleanup to come, make a helper function for doing the cleanup at the end of handle_renames. Rename the already existing cleanup_rename[s]() to final_cleanup_rename[s](), name the new helper initial_cleanup_rename(), and leave the big comment in the code about why

[PATCH v5 12/34] directory rename detection: miscellaneous testcases to complete coverage

I came up with the testcases in the first eight sections before coding up the implementation. The testcases in this section were mostly ones I thought of while coding/debugging, and which I was too lazy to insert into the previous sections because I didn't want to re-label with all the testcase

[PATCH v5 18/34] merge-recursive: make !o->detect_rename codepath more obvious

Previously, if !o->detect_rename then get_renames() would return an empty string_list, and then process_renames() would have nothing to iterate over. It seems more straightforward to simply avoid calling either function in that case. Signed-off-by: Elijah Newren ---

[PATCH v5 20/34] merge-recursive: add a new hashmap for storing directory renames

This just adds dir_rename_entry and the associated functions; code using these will be added in subsequent commits. Signed-off-by: Elijah Newren --- merge-recursive.c | 35 +++ merge-recursive.h | 8 2 files changed, 43 insertions(+)

[PATCH v5 24/34] merge-recursive: add a new hashmap for storing file collisions

Directory renames with the ability to merge directories opens up the possibility of add/add/add/.../add conflicts, if each of the N directories being merged into one target directory all had a file with the same name. We need a way to check for and report on such collisions; this hashmap will be

[PATCH v5 07/34] directory rename detection: partially renamed directory testcase/discussion

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 104 1 file changed, 104 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 433d99584..28b2d2a2b 100755 ---

[PATCH v5 03/34] merge-recursive: add explanation for src_entry and dst_entry

If I have to walk through the debugger and inspect the values found in here in order to figure out their meaning, despite having known these things inside and out some years back, then they probably need a comment for the casual reader to explain their purpose. Signed-off-by: Elijah Newren

[PATCH v5 19/34] merge-recursive: split out code for determining diff_filepairs

Create a new function, get_diffpairs() to compute the diff_filepairs between two trees. While these are currently only used in get_renames(), I want them to be available to some new functions. No actual logic changes yet. Signed-off-by: Elijah Newren --- merge-recursive.c |

[PATCH v5 08/34] directory rename detection: files/directories in the way of some renames

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 320 1 file changed, 320 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 28b2d2a2b..468d6d537 100755 ---

[PATCH v5 32/34] directory rename detection: new testcases showcasing a pair of bugs

Add a testcase showing spurious rename/rename(1to2) conflicts occurring due to directory rename detection. Also add a pair of testcases dealing with moving directory hierarchies around that were suggested by Stefan Beller as "food for thought" during his review of an earlier patch series, but

[PATCH v5 31/34] merge-recursive: fix remaining directory rename + dirty overwrite cases

Signed-off-by: Elijah Newren --- merge-recursive.c | 26 +++--- t/t6043-merge-rename-directories.sh | 8 2 files changed, 27 insertions(+), 7 deletions(-) diff --git a/merge-recursive.c b/merge-recursive.c index

[PATCH v5 25/34] merge-recursive: add computation of collisions due to dir rename & merging

directory renaming and merging can cause one or more files to be moved to where an existing file is, or to cause several files to all be moved to the same (otherwise vacant) location. Add checking and reporting for such cases, falling back to no-directory-rename handling for such paths.

[PATCH v5 05/34] directory rename detection: directory splitting testcases

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 137 1 file changed, 137 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index d8ead7c56..acf49d6b4 100755 ---

[PATCH v5 06/34] directory rename detection: testcases to avoid taking detection too far

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 150 1 file changed, 150 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index acf49d6b4..433d99584 100755 ---

[PATCH v5 27/34] merge-recursive: when comparing files, don't include trees

get_renames() would look up stage data that already existed (populated in get_unmerged(), taken from whatever unpack_trees() created), and if it didn't exist, would call insert_stage_data() to create the necessary entry for the given file. The insert_stage_data() fallback becomes much more

[PATCH v5 26/34] merge-recursive: check for file level conflicts then get new name

Before trying to apply directory renames to paths within the given directories, we want to make sure that there aren't conflicts at the file level either. If there aren't any, then get the new name from any directory renames. Signed-off-by: Elijah Newren --- merge-recursive.c

[PATCH v5 17/34] merge-recursive: fix leaks of allocated renames and diff_filepairs

get_renames() has always zero'ed out diff_queued_diff.nr while only manually free'ing diff_filepairs that did not correspond to renames. Further, it allocated struct renames that were tucked away in the return string_list. Make sure all of these are deallocated when we are done with them.

  1   2   >