Re: cherry-pick very slow on big repository

On Fri, Nov 10, 2017 at 10:39:39AM +0100, Peter Krefting wrote: > Running strace, it seems like it is doing lstat(), open(), mmap(), close() > and munmap() on every single file in the repository, which takes a lot of > time. > > I thought it was just updating the status, but "git status" returns

[PATCH v2 4/9] commit: move post-rewrite code to libgit

From: Phillip Wood Move run_rewrite_hook() from bulitin/commit.c to sequencer.c so it can be shared with other commands and add a new function commit_post_rewrite() based on the code in builtin/commit.c that encapsulates rewriting notes and running the post-rewrite

[PATCH v2 9/9] sequencer: try to commit without forking 'git commit'

From: Phillip Wood If the commit message does not need to be edited then create the commit without forking 'git commit'. Taking the best time of ten runs with a warm cache this reduces the time taken to cherry-pick 10 commits by 27% (from 282ms to 204ms), and the time

[PATCH v2 8/9] sequencer: load commit related config

From: Phillip Wood Load default values for message cleanup and gpg signing of commits in preparation for committing without forking 'git commit'. Signed-off-by: Phillip Wood --- Notes: changes since v1: - renamed

[PATCH v2 0/9] sequencer: dont't fork git commit

From: Phillip Wood Thanks for the feedback on v1 I've updated the patches as suggested. See the comments on each patch for what has changed. I've added a patch to the start of the series to test the commit messages of intermediate squashes. I've added this as the RFC

[PATCH v2 6/9] sequencer: don't die in print_commit_summary()

From: Phillip Wood Return an error rather than dying so that the sequencer can exit cleanly once it starts committing without forking 'git commit' Signed-off-by: Phillip Wood --- builtin/commit.c | 3 ++- sequencer.c | 17

[PATCH v2 1/9] t3404: check intermediate squash messages

From: Phillip Wood When there is more than one squash/fixup command in a row check the intermediate messages are correct. Signed-off-by: Phillip Wood --- t/t3404-rebase-interactive.sh | 4 1 file changed, 4 insertions(+) diff --git

[PATCH v2 5/9] commit: move print_commit_summary() to libgit

From: Phillip Wood Move print_commit_summary() from builtin/commit.c to sequencer.c so it can be shared with other commands. The function is modified by changing the last argument to a flag so callers can specify whether they want to show the author date in addition

[PATCH v2 3/9] Add a function to update HEAD after creating a commit

From: Phillip Wood Add update_head() based on the code that updates HEAD after committing in builtin/commit.c that can be called by 'git commit' and other commands. Signed-off-by: Phillip Wood --- Notes: changes since v1: -

[PATCH v2 7/9] sequencer: simplify adding Signed-off-by: trailer

From: Phillip Wood Add the Signed-off-by: trailer in one place rather than adding it to the message when doing a recursive merge and specifying '--signoff' when running 'git commit'. This means that if there are conflicts when merging with a strategy other than

cherry-pick very slow on big repository

Hi! On a big repository (57000 files, 2,5 gigabytes in .git/objects), git cherry-pick is very slow for me (v2.15.0). This is cherry-picking a one-file change, where the file is in the same place on both branches, and which applies cleanly (I am backporting a few fixes to a maintenance

Re: Bug - Status - Space in Filename

On Fri, Nov 10, 2017 at 09:52:16AM +0900, Junio C Hamano wrote: > > That said, if this is the only place that has this funny quoting, it may > > not be worth polluting the rest of the code with the idea that quoting > > spaces is a good thing to do. > > Sounds sane. We can probably use a helper

I wait for your prompt response.

Good day, I am Mr. Sam Azada from Burkina Faso a Minister confide on me to look for foreign partner who will assist him to invest the sum of Fifty Million Dollars ($50,000,000) in your country. He has investment interest in mining, exotic properties for commercial resident, development

Re: [PATCH] notes: add `rm` and `delete` commands

On Friday 10 November 2017 at 12:14 pm +0900, Junio C Hamano wrote: > Eric Sunshine writes: > > > or against the change: > > > > - synonym bloat; balloons documentation > > - steals command verbs from potential future features > > - ... > > I tend to agree

Re: [PATCH v2 Outreachy] mru: use double-linked list from list.h

> We hung back on it to leave it as low-hanging fruit for other Outreachy > applicants. Perhaps Olga would like to pick it up now that the > application period is over. It's absolutely not a problem for me, I can do that as one more warm-up exercise in the beginning of the internship. Thanks!

`git commit -a` stages ignored submodules?

Hello everyone, There seems to be a difference how Git 2.15.0 handles submodules in comparison with 2.14.2. In Git 2.14.2 `git commit -a` will not stage submodules which has `ignore = all` set in their .gitmodule section. However, in Git 2.15.0 `git commit -a` will stage all submodules no matter

[PATCH v2 2/9] commit: move empty message checks to libgit

From: Phillip Wood Move the functions that check for empty messages from bulitin/commit.c to sequencer.c so they can be shared with other commands. The functions are refactored to take an explicit cleanup mode and template filename passed by the caller.

[RFC] cover-at-tip

Hi, I'm starting to look into the cover-at-tip topic that I found in the leftover bits (http://www.spinics.net/lists/git/msg259573.html) Here's a first draft of a patch that adds support for format-patch --cover-at-tip. It compiles and works in my nice and user firnedly test case. Just wanted

Re: cherry-pick very slow on big repository

Jeff King: Can you get a backtrace? I'd do something like: Seems that it spends most time in diffcore_count_changes(), that is where it hits whenever I hit Ctrl+C (various line numbers 199-207 in diffcore-delta.c; this is on the v2.15.0 tag). (gdb) bt #0 diffcore_count_changes

Unify annotated and non-annotated tags

Hi, It is hard to work with Git tags, because on low level hash of non-annotated tag is pointing to commit, but hash for annotated tag is pointing to tag metadata. On low level that means that there is no way to get commit hash from tag in a single step. If tag is annotated, you need to find and

Re: cherry-pick very slow on big repository

On 11/10/2017 7:37 AM, Peter Krefting wrote: Jeff King: Can you get a backtrace? I'd do something like: Seems that it spends most time in diffcore_count_changes(), that is where it hits whenever I hit Ctrl+C (various line numbers 199-207 in diffcore-delta.c; this is on the v2.15.0 tag).

Re: [PATCH v1 5/8] sequencer: don't die in print_commit_summary()

On 07/11/17 15:13, Junio C Hamano wrote: > Junio C Hamano writes: > >> And this step is going in the right direction, but I am not sure if >> this made the function safe enough to be called repeatedly from the >> rebase machinery and we are ready to unleash this to the end

[PATCH v4] doc/SubmittingPatches: correct subject guidance

The examples and common practice for adding markers such as "RFC" or "v2" to the subject of patch emails is to have them within the same brackets as the "PATCH" text, not after the closing bracket. Further, the practice of `git format-patch` and the like, as well as what appears to be the more

Re: [RFC] cover-at-tip

Le 10/11/2017 à 11:24, Nicolas Morey-Chaisemartin a écrit : > Hi, > > I'm starting to look into the cover-at-tip topic that I found in the leftover > bits (http://www.spinics.net/lists/git/msg259573.html) > > Here's a first draft of a patch that adds support for format-patch > --cover-at-tip.

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

On 07/11/17 00:18, Junio C Hamano wrote: > Jacob Keller writes: > > I would have to say that the describe's one is wrong if it does not > match what for_each_glob_ref() does for the log family of commands' > "--branches=" etc. describe.c::get_name() uses positive > and

Re: cherry-pick very slow on big repository

Derrick Stolee: Git is spending time detecting renames, which implies you probably renamed a folder or added and deleted a large number of files. This rename detection is quadratic (# adds times # deletes). Yes, a couple of directories with a lot of template files have been renamed (and

Bug: cherry-pick & submodule

I faced an unexpected behaviour during cherry-picking a commit to a branch with a submodule. Git graph: A -- B [master] \ `- C -- D [test] Both branches have a file with name `a_file`. It has been added by commit A. Commits B and C add a folder with name `a_submodule` to the respective

[PATCH v3 8/8] Add Git/Packet.pm from parts of t0021/rot13-filter.pl

And while at it let's simplify t0021/rot13-filter.pl by using Git/Packet.pm. This will make it possible to reuse packet related functions in other test scripts. Signed-off-by: Christian Couder --- perl/Git/Packet.pm | 169

[PATCH v3 7/8] t0021/rot13-filter: add capability functions

These function help read and write capabilities. To make them more generic and make it easy to reuse them, the following changes are made: - we don't require capabilities to come in a fixed order, - we allow duplicates, - we check that the remote supports the capabilities we advertise, - we

[PATCH v3 2/8] t0021/rot13-filter: refactor packet reading functions

To make it possible in a following commit to move packet reading and writing functions into a Packet.pm module, let's refactor these functions, so they don't handle printing debug output and exiting. While at it let's create packet_key_val_read() to still handle erroring out in a common case.

[PATCH v3 0/8] Create Git/Packet.pm

Goal Packet related functions in Perl can be useful to write new filters or to debug or test existing filters. They might also in the future be used by other software using the same packet line protocol. So instead of having them in t0021/rot13-filter.pl, let's extract them into a new

[PATCH v3 1/8] t0021/rot13-filter: fix list comparison

Since edcc8581 ("convert: add filter..process option", 2016-10-16) when t0021/rot13-filter.pl was created, list comparison in this perl script have been quite broken. packet_txt_read() returns a 2-element list, and the right hand side of "eq" also has a list with (two, elements), but "eq" takes

[PATCH v3 3/8] t0021/rot13-filter: improve 'if .. elsif .. else' style

Before further refactoring the "t0021/rot13-filter.pl" script, let's modernize the style of its 'if .. elsif .. else' clauses to improve its readability by making it more similar to our other perl scripts. Signed-off-by: Christian Couder --- t/t0021/rot13-filter.pl | 39

[PATCH v3 4/8] t0021/rot13-filter: improve error message

If there is no new line at the end of something it receives, the packet_txt_read() function die()s, but it's difficult to debug without much context. Let's give a bit more information when that happens. Signed-off-by: Christian Couder --- t/t0021/rot13-filter.pl | 3

[PATCH v3 5/8] t0021/rot13-filter: add packet_initialize()

Let's refactor the code to initialize communication into its own packet_initialize() function, so that we can reuse this functionality in following patches. Signed-off-by: Christian Couder --- t/t0021/rot13-filter.pl | 26 -- 1 file changed, 16

[PATCH v3 6/8] t0021/rot13-filter: refactor checking final lf

As checking for a lf character at the end of a buffer will be useful in another function, let's refactor this functionality into a small remove_final_lf_or_die() helper function. Signed-off-by: Christian Couder --- t/t0021/rot13-filter.pl | 16 1 file

proper patch prefix for tweaking both git-bisect.sh and git-bisect.txt?

digging through both git-bisect.sh and git-bisect.txt, and it seems pretty clear they're both a bit out of date WRT documenting the newer alternatives "old"/"new" as opposed to the older "good"/"bad" terms, and a few other things. first, trivially, neither the script nor the man page mention

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

Rafael Ascensão writes: > I agree that describe should receive the "normalize" treatment. However, > and following the same reasoning, why should describe users adopt the > rules imposed by --glob? I could argue they're also used to the way it > works now. > > That being

Re: [PATCH v4] doc/SubmittingPatches: correct subject guidance

On Fri, Nov 10, 2017 at 03:02:50PM +, Adam Dinwoodie wrote: > The examples and common practice for adding markers such as "RFC" or > "v2" to the subject of patch emails is to have them within the same > brackets as the "PATCH" text, not after the closing bracket. Further, > the practice of

Re: is there a stylistic preference for a trailing "--" on a command?

On Fri, Nov 10, 2017 at 5:57 AM, Robert P. J. Day wrote: > > just noticed these examples in "man git-bisect": > > EXAMPLES > $ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good > ... > $ git bisect start HEAD origin --# HEAD is bad, origin is good >

Re: [PATCH 0/4] Fix issues with rename detection limits

On Fri, Nov 10, 2017 at 10:13 AM, Elijah Newren wrote: > In a repo with around 60k files with deep directory hierarchies (due to > Elijah Newren (4): > sequencer: Warn when internal merge may be suboptimal due to > renameLimit > Remove silent clamp of renameLimit >

Re: [RFC] cover-at-tip

On Fri, 10 Nov 2017 16:37:49 +0100 Nicolas Morey-Chaisemartin wrote: > > Hi, > > > > I'm starting to look into the cover-at-tip topic that I found in the > > leftover bits (http://www.spinics.net/lists/git/msg259573.html) Thanks - I personally would find this very

Re: [PATCH v2 2/9] commit: move empty message checks to libgit

On 10/11/17 11:09, Phillip Wood wrote: > From: Phillip Wood > > Move the functions that check for empty messages from bulitin/commit.c > to sequencer.c so they can be shared with other commands. The > functions are refactored to take an explicit cleanup mode and

[PATCH] bisect: mention "view" as an alternative to "visualize"

Tweak a number of files to mention "view" as an alternative to "visualize": Documentation/git-bisect.txt | 9 - Documentation/user-manual.txt | 3 ++- builtin/bisect--helper.c | 2 +- contrib/completion/git-completion.bash | 2 +- git-bisect.sh

Urgent Message.

Dear Western Union Customer, You have been awarded with the sum of $50,000 USD by our office, as one of our customers who use Western Union in their daily business transaction. This award was been selected through the internet, where your e-mail address was indicated and notified. Please

[PATCH 4/4] sequencer: Show rename progress during cherry picks

When trying to cherry-pick a change that has lots of renames, it is somewhat unsettling to wait a really long time without any feedback. Signed-off-by: Elijah Newren --- sequencer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sequencer.c b/sequencer.c index

Re: [Query] Separate hooks for Git worktrees

On Thu, Nov 9, 2017 at 9:00 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> We have no worktree specific config yet, though patches for >> this were floated on the mailing list. >> >> Though recent versions of git learned to conditionally include >>

JPMorgan Chase & Co.

JPMorgan Chase & Co. 270 Park Avenue, Midtown Manhattan New York City, Attention: We are pleased to inform you about your fund which was seized by International Monetary Fund (IMF) due to your failure to provide necessary credentials which state the legitimacy of your fund, the fund was said

Re: [PATCH v1 5/8] sequencer: don't die in print_commit_summary()

Phillip Wood writes: > On 07/11/17 15:13, Junio C Hamano wrote: > ... >> Another possibility perhaps is that the function is safe to reuse >> already even without this patch, of course ;-). >> > Hmm, maybe it is. Looking at pick_commits() and do_pick_commit() if the >

RE: cherry-pick very slow on big repository

Since this is happening during a merge, you might need to use merge.renameLimit or the merge strategy option of -Xno-renames. Although the code does fallback to use the diff.renameLimit but there is still a lot that is done before even checking the rename limit so I would first try getting

Re: cherry-pick very slow on big repository

Interesting timing. I have some performance patches specifically developed because rename detection during merges made a small cherry-pick in a large repo rather slow...in my case, I dropped the time for the cherry pick by a factor of about 30 (no guarantees you'll see the same; it's very

[PATCH 2/4] Remove silent clamp of renameLimit

In commit 0024a5492 (Fix the rename detection limit checking; 2007-09-14), the renameLimit was clamped to 32767. This appears to have been to simply avoid integer overflow in the following computation: num_create * num_src <= rename_limit * rename_limit although it also could be viewed as a

[PATCH 0/4] Fix issues with rename detection limits

In a repo with around 60k files with deep directory hierarchies (due to being predominantly java code) and which had a few high level directories moved around (making it appear to git as dozens of thousands of individual file renames), attempts to cherry-pick commits across product versions

[PATCH 0/4] Fix issues with rename detection limits

In a repo with around 60k files with deep directory hierarchies (due to being predominantly java code) and which had a few high level directories moved around (making it appear to git as dozens of thousands of individual file renames), attempts to cherry-pick commits across product versions

Re: Bug - Status - Space in Filename

Jeff King writes: > Are there callers who don't just print the result? If not, we could just > always emit. That's slightly more efficient since it drops the expensive > strbuf_insert (though there are already so many copies going on in > quote_path_relative that it hardly

Re: [RFC] cover-at-tip

Nicolas Morey-Chaisemartin writes: > I would need to add "some" level of parsing to am.c to make sure > the patch content is just garbage and that there are no actual > hunks for that. > > I did not find any public API that would allow me to do that, > although

Re: [PATCH v2 3/9] Add a function to update HEAD after creating a commit

Phillip Wood writes: > From: Phillip Wood > > Add update_head() based on the code that updates HEAD after committing > in builtin/commit.c that can be called by 'git commit' and other > commands. > > Signed-off-by: Phillip Wood

Re: [PATCH 2/4] Remove silent clamp of renameLimit

Thanks for taking a look! On Fri, Nov 10, 2017 at 10:26 AM, Stefan Beller wrote: >> - if (rename_limit <= 0 || rename_limit > 32767) >> - rename_limit = 32767; >> if ((num_create <= rename_limit || num_src <= rename_limit) && >> -

Bug: cherry-pick & submodule

I faced an unexpected behaviour during cherry-picking a commit to a branch with a submodule. Git graph: A -- B [master] \ `- C -- D [test] Both branches have a file with name `a_file`. It has been added by commit A. Commits B and C add a folder with name `a_submodule` to the respective

[PATCH 1/4] sequencer: Warn when internal merge may be suboptimal due to renameLimit

Having renamed files silently treated as deleted/modified conflicts instead of correctly resolving the renamed/modified case has caused lots of pain for some users. Eventually, some of them figured out to set merge.renameLimit to something higher, but without feedback about what value it should

[PATCH 3/4] progress: Fix progress meters when dealing with lots of work

The possibility of setting merge.renameLimit beyond 2^16 raises the possibility that the values passed to progress can exceed 2^32. For my usecase of interest, I only needed to pass a value a little over 2^31. If I were only interested in fixing my usecase, I could have simply changed last_value

Re: [PATCH 2/4] Remove silent clamp of renameLimit

On Fri, Nov 10, 2017 at 9:39 AM, Elijah Newren wrote: > In commit 0024a5492 (Fix the rename detection limit checking; 2007-09-14), > the renameLimit was clamped to 32767. This appears to have been to simply > avoid integer overflow in the following computation: > >

Re: [RFD] Long term plan with submodule refs?

> >>> Basically, a workflow where it's easier to have each submodule checked >>> out at master, and we can still keep track of historical relationship >>> of what commit was the submodule at some time ago, but without causing >>> some of these headaches. >> >> So essentially a repo or otherwise

[RFC PATCH 29/30] 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 15/30] merge-recursive: Move the get_renames() function

I want to re-use some other functions in the file without moving those other functions or dealing with a handful of annoying split function declarations and definitions. Signed-off-by: Elijah Newren --- merge-recursive.c | 138

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

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 347 1 file changed, 347 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 157299105f..115d0d2622 100755 ---

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

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

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

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

[PATCH 16/30] merge-recursive: Introduce new functions to handle rename logic

The amount of logic in merge_trees() relative to renames was just a few lines, but split it out into new handle_renames() and cleanup_renames() functions to prepare for additional logic to be added to each. No code or logic changes, just a new place to put stuff for when the rename detection

[PATCH 24/30] 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 23/30] 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 11/30] directory rename detection: testcases exploring possibly suboptimal merges

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

[PATCH 09/30] directory rename detection: testcases checking which side did the rename

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

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

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 00811f512a..021513ec00 100755 ---

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

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

[PATCH 00/30] Add directory rename detection to git

[This series is entirely independent of my rename detection limits series. However, I have a separate rename detection performance series that depends on both this series and the rename detection limits series.] In this patchset, I introduce directory rename detection to merge-recursive,

[PATCH 01/30] Tighten and correct a few testcases for merging and cherry-picking

t3501 had a testcase originally added to ensure cherry-pick wouldn't segfault when working with a dirty file involved in a rename. While the segfault was fixed, there was another problem this test demonstrated: namely, that git would overwrite a dirty file involved in a rename. Further, the test

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

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

[PATCH 26/30] 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 05/30] directory rename detection: directory splitting testcases

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

Re: [RFC] protocol version 2

On Fri, 20 Oct 2017 10:18:39 -0700 Brandon Williams wrote: > Some of the pain points with the current protocol spec are: After some in-office discussion, I think that the most important pain point is that we have to implement each protocol twice: once for HTTP(S), and once

[PATCH 04/30] directory rename detection: basic testcases

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

[PATCH 21/30] 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 | 146 ++ 1 file changed, 146

[PATCH 13/30] directory rename detection: tests for handling overwriting untracked files

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

[PATCH 19/30] 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 28/30] merge-recursive: Avoid clobbering untracked files with directory renames

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

[PATCH 20/30] 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 | 24 merge-recursive.h | 8 2 files changed, 32 insertions(+) diff --git

[PATCH 27/30] 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 | 195

[PATCH 02/30] merge-recursive: Fix logic ordering issue

merge_trees() did a variety of work, including: * Calling get_unmerged() to get unmerged entries * Calling record_df_conflict_files() with all unmerged entries to do some work to ensure we could handle D/F conflicts correctly * Calling get_renames() to check for renames. An easily

[PATCH 03/30] 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 22/30] 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 17/30] 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.

[PATCH 25/30] 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 30/30] 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 18/30] 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 v1] fsmonitor: simplify determining the git worktree under Windows

I haven't tested the non Windows paths but the patch looks reasonable. This inspired me to get someone more familiar with perl (thanks Johannes) to revisit this code for the Windows side as well. The logic for determining the git worktree when running on Windows is more complex than necessary.

Re: [PATCH v2 0/9] sequencer: dont't fork git commit

Phillip Wood writes: > Here's the summary from the previous version > These patches teach the sequencer to create commits without forking > git commit when the commit message does not need to be edited. This > speeds up cherry picking 10 commits by 26% and picking 10

Re: [PATCH] bisect: mention "view" as an alternative to "visualize"

Thanks for the patch. Some comments below... On Fri, Nov 10, 2017 at 11:32 AM, Robert P. J. Day wrote: > Tweak a number of files to mention "view" as an alternative to > "visualize": You probably want to end this sentence with a period, not a colon. >

Re: [PATCH v3 0/8] Create Git/Packet.pm

Christian Couder writes: > There are only a few small changes compared to v2: Please go incremental as v2 is already in 'next', and small changes are easier to reiew and understand when given as follow-up "polish this minor glitch in the initial effort" patches.

Re: [PATCH] bisect: mention "view" as an alternative to "visualize"

On Fri, 10 Nov 2017, Eric Sunshine wrote: > Thanks for the patch. Some comments below... > > On Fri, Nov 10, 2017 at 11:32 AM, Robert P. J. Day > wrote: > > Tweak a number of files to mention "view" as an alternative to > > "visualize": > > You probably want to end this

  1   2   >