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 develops on UNIX, with LF lin
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 directory.'
>
> How I r
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 accu
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 lookup first.
>
> di
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 windows-excl
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 patch (commit 5ed75e2a3f,
>> "cherry-pick: don't forget -s on failure", 14-09-201
Æ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"
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 sent later that
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, 2017-10-16), users noticed
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 authors of
> individua
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 mean
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 it stopped
> handling
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 functional change in
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 &&
> + >"$TRASH_DIRECTO
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
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 section either by editing the
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 on failure", 14-09-2017).
What automated procedure are yo
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 simp
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 editing the
> above page on GitHub
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 updating the seri
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 b/git-rebase.sh
> index 6344e8d5e..2f5d138a0 100755
> --- a
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 like a bad idea.
I concur
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
>> > @@ -1724,7 +1724,7 @@ sub recipients_cmd {
>> > -open my $fh, "-|", "$cmd \
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.
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' '
+ [...]
+ git send-email -1 --to=recipi...@example.com \
+ --cc-cmd
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
pushi
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 and install these 2
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.
>
> Signed-off-by: J
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
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, so
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 --rebase so i guess it's goo
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 patterns with embedded pa
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 n
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 readers to easily understand the problem and the
>> sol
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 message
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 he
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], c
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 imple
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/
St
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
> ha
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 bei
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 esti
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 if
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: Stefan Beller
---
Brand
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 chec
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 g
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 expect
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 handl
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 o
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 Ne
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 t
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 =~ /^\(/) {
> pu
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,
>> conn->use_s
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 also belong to
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
---
m
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 commi
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
--- a/t/t6043-merge-renam
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
--- a/t/t6043-merge-renam
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 g
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 co
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
--- a/t/t6043-merge-renam
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
--- a/t/t6043-merge-renam
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 +++---
1 file change
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 re
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
gains
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
--- a/t/t6043-merge-renam
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
--- a/t/t6043-merge-renam
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 +++-
t/t6043-merg
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 | 87
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 overlo
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 u
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(+)
diff --git a/merge-
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
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 insertions(+)
diff --git a/m
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
--- a/t/t6043-merge-renam
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
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 4b7ae37d14..6aed0f4b9d 1006
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,
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
---
merge-recursive.c | 11 +
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 828861803c..6974717719 100644
--- a/
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
--- a/t/t6043-merge-renam
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 importa
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 whic
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.
Signed-
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
---
merge-recursive.
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.
Signed-of
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 su
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
b/t/t6043-merge-rename-directories.sh
new f
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
--- a/t/t6043-merge-renam
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 you
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: Jonatha
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
> ---
> As before.
>
> co
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 metho
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 GIT_S
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 t5603-clone-d
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 cause:
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
---
As before.
connect.c|
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 N
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: Stefan Beller
---
As be
git_connect has the structure
struct child_process *conn = &no_fork;
...
switch (protocol) {
case PROTO_GIT:
if (git_use_proxy(hostandport))
conn = git_proxy_connect(fd, hostandport);
else
1 - 100 of 153 matches
Mail list logo
