Re: core.safecrlf warning is confusing[improvement suggestion?]

Vladimir Nikishkin writes: > I want to have LF line endings in the repository and CRLF endings in > the working copy. (Because I use windows-exclusive tools to develop.) > > But for start I have my code with LF endings, because I got it from a > fellow developer, who

Re: core.safecrlf warning is confusing[improvement suggestion?]

Vladimir Nikishkin writes: > So I put the source in the working directory and tell git to make > > git diff --stat > > and I see the (ambiguous) warnings: > > 'warning: LF will be replaced by CRLF in filename.m. > The file will have its original line endings in you working

What's cooking in git.git (Nov 2017, #06; Tue, 21)

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. Quite a few "fixes" have been

Re: [PATCH 5/5] sha1_file: don't re-scan pack directory for null sha1

Jeff King writes: > This is the minimal fix that addresses the performance issues. > I'd actually have no problem at all declaring that looking up a null > sha1 is insane, and having the object-lookup routines simply return "no > such object" without even doing the loose/pack

core.safecrlf warning is confusing[improvement suggestion?]

Hello, everyone. I have the following question. So I have a fresh git repository after git init, on Windows. core.autocrlf is true explicitly, and core.safecrlf is true implicitly. I want to have LF line endings in the repository and CRLF endings in the working copy. (Because I use

Re: [PATCH] sequencer: make sign_off_header a file local symbol

Junio C Hamano writes: > Ramsay Jones writes: > >> Signed-off-by: Ramsay Jones >> --- >> >> Hi Miklos, >> >> If you need to re-roll your 'mv/cherry-pick-s' branch, could you >> please squash this into the relevant

Re [PATCH 1/1] exec_cmd: RUNTIME_PREFIX on some POSIX systems

Ævar Arnfjörð Bjarmason @ 2017-11-20 21:50 UTC suggested: > So LeonT over at #p5p helped me with this. He believes this'll work > (unless MakeMaker INSTALL_BASE is set, but that should break the Git > install anyway): I think that the problem with this approach is that it uses the local "Config"

Re: [PATCH 5/5] sha1_file: don't re-scan pack directory for null sha1

Jeff King writes: > In an ideal world, we'd simply fix all of the callers to > notice the null sha1 and avoid passing it to us. But a > simple experiment to catch this with a BUG() shows that > there are a large number of code paths. Well, we can view this (or the alternative you

Re: [PATCH 6/8] ssh: 'auto' variant to select between 'ssh' and 'simple'

Junio C Hamano wrote: > Jonathan Nieder writes: >> Android's "repo" tool is a tool for managing a large codebase >> consisting of multiple smaller repositories, similar to Git's >> submodule feature. Starting with Git 94b8ae5a (ssh: introduce a >> 'simple' ssh variant,

Re: [PATCH] contrib/git-jump: allow to configure the grep command

Jeff King writes: > How about this? > > -- >8 -- > Subject: [PATCH] git-jump: give contact instructions in the README > > Let's make it clear how patches should flow into > contrib/git-jump. The normal Git maintainer does not > necessarily care about things in contrib/, and

[PATCH 1/8 v2] ssh test: make copy_ssh_wrapper_as clean up after itself

Simplify by not allowing the copied ssh wrapper to persist between tests. This way, tests can be safely reordered, added, and removed with less fear of hidden side effects. This also avoids having to call setup_ssh_wrapper to restore the value of GIT_SSH after this battery of tests, since it

Re: [PATCH 6/8] ssh: 'auto' variant to select between 'ssh' and 'simple'

Jonathan Nieder writes: > Android's "repo" tool is a tool for managing a large codebase > consisting of multiple smaller repositories, similar to Git's > submodule feature. Starting with Git 94b8ae5a (ssh: introduce a > 'simple' ssh variant, 2017-10-16), users noticed that

Re: [PATCH 5/8] connect: split ssh option computation to its own function

Jonathan Nieder writes: > This puts the determination of options to pass to each ssh variant > (see ssh.variant in git-config(1)) in one place. > > A follow-up patch will use this in an initial dry run to detect which > variant to use when the ssh command is ambiguous. > > No

Re: [PATCH 1/8] ssh test: make copy_ssh_wrapper_as clean up after itself

Jonathan Nieder writes: > +test_expect_success 'set up ssh wrapper' ' > + cp "$GIT_BUILD_DIR/t/helper/test-fake-ssh$X" \ > + "$TRASH_DIRECTORY/ssh$X" && > + GIT_SSH="$TRASH_DIRECTORY/ssh$X" && > + export GIT_SSH && > + export TRASH_DIRECTORY && > +

Re: [PATCH] list-objects-filter-options: fix up some sparse warnings

Hi, Ramsay Jones wrote: > If you need to re-roll your 'jh/object-filtering' branch, could you > please squash this (or something like it) into the relevant patch > (commit bf0aedcbe1, "list-objects: filter objects in traverse_commit_list", > 16-11-2017). Micronit: can these messages use the ISO

Re: Draft of Git Rev News edition 33

Hi, Yubin Ruan wrote: > 2017-11-20 16:33 GMT+08:00 Christian Couder : >> A draft of a new Git Rev News edition is available here: >> >> >> https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-33.md >> >> Everyone is welcome to contribute in any

Re: [PATCH] sequencer: make sign_off_header a file local symbol

Ramsay Jones writes: > Signed-off-by: Ramsay Jones > --- > > Hi Miklos, > > If you need to re-roll your 'mv/cherry-pick-s' branch, could you > please squash this into the relevant patch (commit 5ed75e2a3f, > "cherry-pick: don't forget -s

Re: [PATCH v1 1/4] fastindex: speed up index load through parallelization

On 11/20/2017 6:51 PM, Ramsay Jones wrote: On 20/11/17 14:01, Ben Peart wrote: Further testing has revealed that switching from the regular heap to a refactored version of the mem_pool in fast-import.c produces similar gains as parallelizing do_index_load().  This appears to be a much

Re: Draft of Git Rev News edition 33

2017-11-20 16:33 GMT+08:00 Christian Couder : > Hi, > > A draft of a new Git Rev News edition is available here: > > > https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-33.md > > Everyone is welcome to contribute in any section either by

Re: [PATCH 1/6] t4051: add test for comments preceding function lines

René Scharfe writes: >> I am slightly in favor of than against the above reasoning, but it >> probably deserves to be recorded somewhere more readily accessible >> than the mailing list archive... >> >> perhaps? > > That's fine with me. As there seems to be no other reason for

Re: [PATCH] git-rebase: clean up dashed-usages in messages

Kaartic Sivaraam writes: > Signed-off-by: Kaartic Sivaraam > --- Thanks. Two fewer git-foo exposed to the end user. Good ;-) > git-rebase.sh | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/git-rebase.sh

Re: [PATCH] git-send-email: fix get_maintainer.pl regression

Eric Sunshine writes: > The more I think about this, the less I consider this a bug in > git-send-email. As noted, people might legitimately use a complex > command (--cc-cmd="myscript--option arg"), so changing git-send-email > to treat cc-cmd as an atomic string seems

Re: [PATCH] git-send-email: fix get_maintainer.pl regression

On Mon, Nov 20, 2017 at 7:07 PM, Philip Oakley wrote: > From: "Eric Sunshine" > On Sat, Nov 18, 2017 at 9:54 PM, Eric Sunshine > wrote: >> > --- 8< --- >> > diff --git a/git-send-email.perl b/git-send-email.perl >> > @@

Re: What's cooking in git.git (Nov 2017, #05; Fri, 17)

Ben Peart writes: > As far as I can tell, the patches are good. I'm not aware of > anything else that should hold it up. Great; thanks.

Re: [PATCH] git-send-email: fix get_maintainer.pl regression

From: "Eric Sunshine" On Sat, Nov 18, 2017 at 9:54 PM, Eric Sunshine wrote: On Thu, Nov 16, 2017 at 10:48 AM, Alex Bennée wrote: +test_expect_success $PREREQ 'cc trailer with get_maintainer output' ' + [...] +

Bad interaction between git clean, gitignore, and deleted submodules

We have the following situation: 1) A .gitignore file that contains '*.pyc' 2) A repo with a submodule named jinja2 In normal use, clients of our repo have it checked out and run things in it, creating files like jinja2/run.pyc. I deleted the jinja2 submodule (by running `git rm jinja2` and

Re: [PATCH] Makefile: check that tcl/tk is installed

Hi, On Mon, Nov 20, 2017 at 8:19 PM, Jonathan Nieder wrote: > Hi, > > Christian Couder wrote: > >> By default running `make install` in the root directory of the >> project will set TCLTK_PATH to `wish` and then go into the "git-gui" >> and "gitk-git" sub-directories to build

Re: [PATCH 1/5] p5550: factor our nonsense-pack creation

On Mon, Nov 20, 2017 at 3:26 PM, Jeff King wrote: > p5550: factor our nonsense-pack creation s/our/out/, I guess. > We have a function to create a bunch of irrelevant packs to > measure the expense of reprepare_packed_git(). Let's make > that available to other perf scripts. > >

Re: [PATCH v1 1/4] fastindex: speed up index load through parallelization

On 20/11/17 14:01, Ben Peart wrote: > Further testing has revealed that switching from the regular heap to a > refactored version of the mem_pool in fast-import.c produces similar gains as > parallelizing do_index_load().  This appears to be a much simpler patch for > similar gains so we will

[PATCH] list-objects-filter-options: fix up some sparse warnings

In particular, sparse complains that the armor_{en,de}code_arg() functions are 'not declared - should they be static?'. Since the armor_decode_arg() symbol does not require more than file visibility, we can simply mark the declaration with static. The armor_encode_arg() function has no callers,

Re: [PATCH] bash completion: Add --autostash and --no-autostash to pull

On Mon, Nov 20, 2017 at 10:07 AM, Albert Astals Cid wrote: > Ideally we should only autocomplete if pull has --rebase since > they only work with it but could not figure out how to do that > and the error message of doing git pull --autostash points out > that you need

Re: [PATCH] git-send-email: fix --cc-cmd get_maintainer.pl regression

On Mon, Nov 20, 2017 at 6:41 AM, Alex Bennée wrote: > Since the removal of Mail::Address from git-send-email certain address > patterns returned by common get_maintainer.pl scripts now fail to get > correctly parsed by the built-in Git::parse_mailboxes. Specifically > the

Re: Re(2): [PATCH 1/1] exec_cmd: RUNTIME_PREFIX on some POSIX systems

On Mon, Nov 20 2017, Dan Jacques jotted: > On Mon, 20 Nov 2017 22:00:10, Ævar Arnfjörð Bjarmason replied: > >> [...] > > Thanks for responding. I'll readily confess that PERL and the PERL > ecosystem are not areas I'm very familiar with, so I'm really grateful > for your feedback here. > >> You

Re: [PATCH] git-send-email: fix get_maintainer.pl regression

On Mon, Nov 20, 2017 at 5:44 AM, Alex Bennée wrote: > Eric Sunshine writes: >> It is not at all clear, based upon this text, what this is fixing. >> When you re-roll, please provide a description of the regression in >> sufficient detail for

Re: [PATCH v3 0/8] Coping with unrecognized ssh wrapper scripts in GIT_SSH

On 11/20, Jonathan Nieder wrote: > Previously: [1]. > > This version should be essentially identical to v2. Changes: > - patch 1 is new and should fix the test failure on Windows > - patch 2 is new, discussed at [2] > - patch 5 split off from patch 6 as suggested at [3] > - patch 6 commit

Re: [PATCH 3/8] connect: split git:// setup into a separate function

On 11/20, Jonathan Nieder wrote: > Brandon Williams wrote: > > On 11/20, Jonathan Nieder wrote: > > >> + /* These underlying connection commands die() if they > >> + * cannot connect. > >> + */ > > > > I know this is really just code motion but maybe we can fix the style of > > the comment

Re: [PATCH 4/8] connect: split ssh command line options into separate function

On 11/20, Jonathan Nieder wrote: > Hi, > > Brandon Williams wrote: > > On 11/20, Jonathan Nieder wrote: > [long stream of quoted context snipped; please cut down the quoted > text to what you are replying to in the future] > >> @@ -972,16 +1031,13 @@ struct child_process *git_connect(int fd[2],

[PATCH 1/1] diffcore: add a filter 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

[PATCH 0/1] Teaching the diff machinery about blobfind [WAS: git describe ]

This seems to be an easier approach; thanks Junio for hinting at it. This certainly solves our immediate needs, we may want to build 'git describe ' on top of it or defer it until later. Thanks, Stefan previous descussion https://public-inbox.org/git/20171028004419.10139-1-sbel...@google.com/

Re: [PATCH 6/8] ssh: 'auto' variant to select between 'ssh' and 'simple'

On 11/20, Jonathan Nieder wrote: > Android's "repo" tool is a tool for managing a large codebase > consisting of multiple smaller repositories, similar to Git's > submodule feature. Starting with Git 94b8ae5a (ssh: introduce a > 'simple' ssh variant, 2017-10-16), users noticed that it stopped >

[RFC PATCH v2 6/9] merge-recursive: improve handling for rename/rename(2to1) conflicts

This makes the rename/rename(2to1) conflicts use the new handle_file_collision() function. Since that function was based originally on the rename/rename(2to1) handling code, the main differences here are in what was added. In particular: * If the two colliding files are similar, instead of

[RFC PATCH v2 7/9] merge-recursive: improve handling for add/add conflicts

This makes add/add conflicts use the new handle_file_collision() function. This leaves the handling of the index the same, but modifies how the working tree is handled: instead of always doing a two-way merge of the file contents and recording them at the collision path name, we instead first

[RFC PATCH v2 8/9] merge-recursive: accelerate rename detection

If a file is unmodified on one side of history (no content changes, no name change, and no mode change) and is renamed on the other side, then the correct merge result is to take both the file name and the file contents (and file mode) of the renamed file. merge-recursive detects this rename and

[RFC PATCH v2 4/9] Add testcases for improved file collision conflict handling

Adds testcases dealing with file collisions for the following types of conflicts: * add/add * rename/add * rename/rename(2to1) These tests include expectations for new, smarter behavior provided by handle_file_collision(). Since that function is not in use yet, the tests are currently

[RFC PATCH v2 5/9] merge-recursive: fix rename/add conflict handling

This makes the rename/add conflict handling make use of the new handle_file_collision() function, which fixes several bugs and improves things for the rename/add case significantly. Previously, rename/add would: * Not leave any higher order stage entries in the index, making it appear as

[PATCH v4 4/8] connect: split ssh command line options into separate function

The git_connect function is growing long. Split the portion that discovers an ssh command and options it accepts before the service name and path to a separate function to make it easier to read. No functional change intended. Signed-off-by: Jonathan Nieder Reviewed-by:

[RFC PATCH v2 9/9] diffcore-rename: filter rename_src list when possible

We have to look at each entry in rename_src a total of rename_dst_nr times. When we're not detecting copies, any exact renames or ignorable rename paths will just be skipped over. While checking that these can be skipped over is a relatively cheap check, it's still a waste of time to do that

[RFC PATCH v2 3/9] merge-recursive: new function for better colliding conflict resolutions

There are three conflict types that represent two (possibly entirely unrelated) files colliding at the same location: * add/add * rename/add * rename/rename(2to1) These three conflict types already share more similarity than might be immediately apparent from their description: (1) the

[RFC PATCH v2 1/9] diffcore-rename: no point trying to find a match better than exact

diffcore_rename() had some code to avoid having destination paths that already had an exact rename detected from being re-checked for other renames. Source paths, however, were re-checked because we wanted to allow the possibility of detecting copies. But if copy detection isn't turned on, then

[RFC PATCH v2 0/9] Improve merge recursive performance

You probably want to wait to review this series until my rename detection series lands so that I can clean up any more conflicts, but I'm posting this new series in case anyone wants to take an early look. It includes fixes identified by the reviews of my other patch series, and has been rebased

[RFC PATCH v2 2/9] merge-recursive: avoid unnecessary string list lookups

Since we're taking entries from active_cache, which is already in sorted order with same-named entries adjacent, we can skip a lookup. Also, we can just use append instead of insert (avoiding the need to find where to put the new item) and still end up with a sorted list. Signed-off-by: Elijah

Re: [PATCH] git-send-email: fix get_maintainer.pl regression

A few more comments/observations... On Thu, Nov 16, 2017 at 10:48 AM, Alex Bennée wrote: > diff --git a/perl/Git.pm b/perl/Git.pm > @@ -936,6 +936,9 @@ sub parse_mailboxes { > $end_of_addr_seen = 0; > } elsif ($token =~ /^\(/) { >

Re: [PATCH 4/8] connect: split ssh command line options into separate function

Hi, Brandon Williams wrote: > On 11/20, Jonathan Nieder wrote: [long stream of quoted context snipped; please cut down the quoted text to what you are replying to in the future] >> @@ -972,16 +1031,13 @@ struct child_process *git_connect(int fd[2], const >> char *url, >>

Re: [PATCH 6/6] grep: show non-empty lines before functions with -W

Am 20.11.2017 um 21:39 schrieb Stefan Beller: > On Sat, Nov 18, 2017 at 10:08 AM, René Scharfe wrote: >> Non-empty lines before a function definition are most likely comments >> for that function and thus relevant. Include them in function context. >> >> Such a non-empty line might

[PATCH v2 03/33] 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

Re: [PATCH 3/8] connect: split git:// setup into a separate function

Brandon Williams wrote: > On 11/20, Jonathan Nieder wrote: >> +/* These underlying connection commands die() if they >> + * cannot connect. >> + */ > > I know this is really just code motion but maybe we can fix the style of > the comment here? How about doing that as a separate

[PATCH v2 07/33] 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 0ccabed4a2..1dcf010aa6 100755 ---

[PATCH v2 08/33] 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 1dcf010aa6..29b2af7f19 100755 ---

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

t3501 had a testcase originally added in 05f2dfb965 (cherry-pick: demonstrate a segmentation fault, 2016-11-26) 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

[PATCH v2 00/33] 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 previous series, design considerations, etc. Changes since the first series include: * Rebased on latest master (addressing a couple minor

[PATCH v2 14/33] 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 7408c788fc..88243651f7 100755 ---

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

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 321 1 file changed, 321 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 29b2af7f19..5db2986de8 100755 ---

[PATCH v2 15/33] 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 | 139

[PATCH v2 12/33] 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 v2 16/33] 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 v2 13/33] directory rename detection: tests for handling overwriting untracked files

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 337 1 file changed, 337 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 9e00a26c69..7408c788fc 100755 ---

[PATCH v2 05/33] 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 d8ead7c56b..335aa1c145 100755 ---

[PATCH v2 27/33] 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 v2 19/33] 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 v2 02/33] 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 v2 23/33] 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 v2 20/33] 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 v2 32/33] 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 v2 21/33] 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 | 149 ++ 1 file changed, 149

[PATCH v2 10/33] 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 5db2986de8..2c57a02c6d 100755 ---

[PATCH v2 25/33] 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 v2 28/33] 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 v2 33/33] 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 v2 18/33] 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 v2 30/33] 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 v2 11/33] directory rename detection: testcases exploring possibly suboptimal merges

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

[PATCH v2 26/33] 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 v2 31/33] 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 v2 17/33] 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 v2 22/33] 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 v2 24/33] 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 v2 29/33] 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 v2 04/33] 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 v2 06/33] 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 335aa1c145..0ccabed4a2 100755 ---

Re(2): [PATCH 1/1] exec_cmd: RUNTIME_PREFIX on some POSIX systems

On Mon, 20 Nov 2017 22:00:10, Ævar Arnfjörð Bjarmason replied: > [...] Thanks for responding. I'll readily confess that PERL and the PERL ecosystem are not areas I'm very familiar with, so I'm really grateful for your feedback here. > You need to bust the perl/PM.stamp cache as a function of

Re: [PATCH 4/8] connect: split ssh command line options into separate function

On 11/20, Jonathan Nieder wrote: > The git_connect function is growing long. Split the portion that > discovers an ssh command and options it accepts before the service > name and path to a separate function to make it easier to read. > > No functional change intended. > > Signed-off-by:

Re: [PATCH 3/8] connect: split git:// setup into a separate function

On 11/20, Jonathan Nieder wrote: > The git_connect function is growing long. Split the > PROTO_GIT-specific portion to a separate function to make it easier to > read. > > No functional change intended. > > Signed-off-by: Jonathan Nieder > Reviewed-by: Stefan Beller

Re: [PATCH 1/1] exec_cmd: RUNTIME_PREFIX on some POSIX systems

On Mon, Nov 20 2017, Ævar Arnfjörð Bjarmason jotted: > On Sun, Nov 19 2017, Dan Jacques jotted: > >> [...] > > Firstly the promise of this is very neat. I'm happy to offer any help I > can give. > >> Enable Git to resolve its own binary location using a variety of >> OS-specific and generic

Re: [PATCH 1/8] ssh test: make copy_ssh_wrapper_as clean up after itself

On 11/20, Jonathan Nieder wrote: > Simplify by not allowing the copied ssh wrapper to persist between > tests. This way, tests can be safely reordered, added, and removed > with less fear of hidden side effects. > > This also avoids having to call setup_ssh_wrapper to restore the value > of

[PATCH 8/8] ssh: 'simple' variant does not support --port

When trying to connect to an ssh:// URL with port explicitly specified and the ssh command configured with GIT_SSH does not support such a setting, it is less confusing to error out than to silently suppress the port setting and continue. This requires updating the GIT_SSH setting in

[PATCH 6/8] ssh: 'auto' variant to select between 'ssh' and 'simple'

Android's "repo" tool is a tool for managing a large codebase consisting of multiple smaller repositories, similar to Git's submodule feature. Starting with Git 94b8ae5a (ssh: introduce a 'simple' ssh variant, 2017-10-16), users noticed that it stopped handling the port in ssh:// URLs. The

[PATCH 7/8] ssh: 'simple' variant does not support -4/-6

If the user passes -4/--ipv4 or -6/--ipv6 to "git fetch" or "git push" and the ssh command configured with GIT_SSH does not support such a setting, error out instead of ignoring the option and continuing. Signed-off-by: Jonathan Nieder Acked-by: Stefan Beller

[PATCH 5/8] connect: split ssh option computation to its own function

This puts the determination of options to pass to each ssh variant (see ssh.variant in git-config(1)) in one place. A follow-up patch will use this in an initial dry run to detect which variant to use when the ssh command is ambiguous. No functional change intended yet. Signed-off-by: Jonathan

[PATCH 4/8] connect: split ssh command line options into separate function

The git_connect function is growing long. Split the portion that discovers an ssh command and options it accepts before the service name and path to a separate function to make it easier to read. No functional change intended. Signed-off-by: Jonathan Nieder Reviewed-by:

[PATCH 2/8] connect: move no_fork fallback to git_tcp_connect

git_connect has the structure struct child_process *conn = _fork; ... switch (protocol) { case PROTO_GIT: if (git_use_proxy(hostandport)) conn = git_proxy_connect(fd, hostandport); else

  1   2   >