Re: [PATCH v2 2/5] builtin/config.c: support `--type=` as preferred alias for `--`

On Thu, Apr 26, 2018 at 1:58 AM, Taylor Blau wrote: > `git config` has long allowed the ability for callers to provide a 'type > specifier', which instructs `git config` to (1) ensure that incoming > values can be interpreted as that type, and (2) that outgoing values are >

Re: [PATCH v3 2/3] merge: Add merge.renames config setting

On Thu, Apr 26, 2018 at 5:54 PM, Ben Peart wrote: > On 4/26/2018 6:52 PM, Elijah Newren wrote: >> On Thu, Apr 26, 2018 at 1:52 PM, Ben Peart >> wrote: >> >>> diff --git a/merge-recursive.h b/merge-recursive.h >>> index 80d69d1401..0c5f7eff98 100644

Re: [PATCH v4 1/2] blame: prevent error if range ends past end of file

> Maybe I misread the previous discussion and/or your cover letter, > but I have been assuming that you are trying to avoid failing the > command in a useless way (e.g. when the file has only ~800 lines but > the user does not know exactly how many, instead of letting -L1,820 > to fail with "the

Re: [PATCH v3 2/3] merge: Add merge.renames config setting

On Thu, Apr 26, 2018 at 7:23 PM, Junio C Hamano wrote: > Ben Peart writes: > >> Color me puzzled. :) The consensus was that the default value for >> merge.renames come from diff.renames. diff.renames supports copy >> detection which means that

In some rebases, `exec git -C ...` has wrong working directory

Here is a repro script: #!/bin/sh set -eux git --version tmpdir="$(mktemp -d)" cd "${tmpdir}" mkdir target repo cd repo git init touch file; git add file git commit -m "Initial commit" git rebase HEAD --exec "git -C ${tmpdir}/target init" The end of

Re: [PATCH v3 2/3] merge: Add merge.renames config setting

Ben Peart writes: > Color me puzzled. :) The consensus was that the default value for > merge.renames come from diff.renames. diff.renames supports copy > detection which means that merge.renames will inherit that value. My > assumption was that is what was intended so

Re: [PATCH v4 1/2] blame: prevent error if range ends past end of file

Isabella Stephens writes: > On 27/4/18 10:50 am, Junio C Hamano wrote: >> isteph...@atlassian.com writes: >> >>> diff --git a/line-range.c b/line-range.c >>> index 323399d16..023aee1f5 100644 >>> --- a/line-range.c >>> +++ b/line-range.c >>> @@ -47,7 +47,7 @@ static

Re: [PATCH v4 1/2] blame: prevent error if range ends past end of file

My intention was to modify existing behaviour as little as possible, but I agree clipping to the first line makes a lot more sense. That raises the question though, do we clip to 1 and treat -L,-n as a valid input, or clip to -1 so that this case be detected? On 27/4/18 10:50 am, Junio C Hamano

Re: [PATCH v3 2/3] merge: Add merge.renames config setting

On 4/26/2018 6:52 PM, Elijah Newren wrote: On Thu, Apr 26, 2018 at 1:52 PM, Ben Peart wrote: +merge.renames:: + Whether and how Git detects renames. If set to "false", + rename detection is disabled. If set to "true", basic rename + detection is

Re: [PATCH v4 1/2] blame: prevent error if range ends past end of file

isteph...@atlassian.com writes: > diff --git a/line-range.c b/line-range.c > index 323399d16..023aee1f5 100644 > --- a/line-range.c > +++ b/line-range.c > @@ -47,7 +47,7 @@ static const char *parse_loc(const char *spec, > nth_line_fn_t nth_line, > else if (!num) >

Proposal

Hello Greetings to you today i asked before but i did't get a response please i know this might come to you as a surprise because you do not know me personally i have a business proposal for you please reply for more info. Best Regards, Esentepe Mahallesi Büyükdere Caddesi Kristal Kule

Re: git merge banch w/ different submodule revision

On Thu, Apr 26, 2018 at 3:49 AM, Middelschulte, Leif wrote: > Hi, > > we're using git-flow as a basic development workflow. However, doing so > revealed unexpected merge-behavior by git. > > Assume the following setup: > > - Repository `S` is sourced by

Re: git merge banch w/ different submodule revision

On Thu, Apr 26, 2018 at 2:46 PM, Jacob Keller wrote: > On Thu, Apr 26, 2018 at 10:56 AM, Stefan Beller wrote: >> We often treating a submodule as a file from the superproject, but not >> always. >> And in case of a merge, git seems to be a bit smarter

[no subject]

Good morning Git https://bit.ly/2HSZB08 Scott McKellar

Proposal

Hello Greetings to you today i asked before but i did't get a response please i know this might come to you as a surprise because you do not know me personally i have a business proposal for you please reply for more info. Best Regards, Esentepe Mahallesi Büyükdere Caddesi Kristal Kule

Re: Fetching tags overwrites existing tags

Junio C Hamano writes: > Wink Saville writes: > >> I've tried to teach 'git remote add' the --prefix-tags option using the >> technique Junio provided. At moment it is PR #486 on github [1] >> and I'd love some comments on whether or not this the right

Re: [PATCH v3 1/3] merge: update documentation for {merge,diff}.renameLimit

On Thu, 26 Apr 2018 16:11:50 -0700 Elijah Newren wrote: > Patch looks fine, but it's hard for me not to notice a separate issue > in this area independent of your series: I'm curious if we should > document that the value of 0 is special here (as per Jonathan Tan's > commit

Re: [PATCH v3 1/3] merge: update documentation for {merge,diff}.renameLimit

On Thu, Apr 26, 2018 at 1:52 PM, Ben Peart wrote: > Update the documentation to better indicate that the renameLimit setting is > ignored if rename detection is turned off via command line options or config > settings. > > Signed-off-by: Ben Peart

Re: [PATCH v3 3/3] merge: pass aggressive when rename detection is turned off

On Thu, Apr 26, 2018 at 1:52 PM, Ben Peart wrote: > Set aggressive flag in git_merge_trees() when rename detection is turned off. > This allows read_tree() to auto resolve more cases that would have otherwise > been handled by the rename detection. > > Reviewed-by:

Re: [PATCH v3 2/3] merge: Add merge.renames config setting

On Thu, Apr 26, 2018 at 1:52 PM, Ben Peart wrote: > +merge.renames:: > + Whether and how Git detects renames. If set to "false", > + rename detection is disabled. If set to "true", basic rename > + detection is enabled. If set to "copies" or "copy",

Re: Fetching tags overwrites existing tags

Wink Saville writes: > I've tried to teach 'git remote add' the --prefix-tags option using the > technique Junio provided. At moment it is PR #486 on github [1] > and I'd love some comments on whether or not this the right direction > for fetching tags and putting them in the

Re: git merge banch w/ different submodule revision

Stefan wrote: > See https://github.com/git/git/commit/68d03e4a6e448aa557f52adef92595ac4d6cd4bd > (68d03e4a6e (Implement automatic fast-forward merge for submodules, > 2010-07-07) > to explain the situation you encounter. (specifically merge_submodule > at the end of the diff) +cc Heiko, author

Proposal

Hello Greetings to you today i asked before but i did't get a response please i know this might come to you as a surprise because you do not know me personally i have a business proposal for you please reply for more info. Best Regards, Esentepe Mahallesi Büyükdere Caddesi Kristal Kule

Re: [PATCH v3 0/3] add merge.renames config setting

Hi Ben, On Thu, Apr 26, 2018 at 1:52 PM, Ben Peart wrote: > This is a complete rewrite based on the feedback from earlier patches. Thanks for pushing forward on this. > Update the documentation to better indicate command line options that override > various config

Re: git merge banch w/ different submodule revision

On Thu, Apr 26, 2018 at 10:56 AM, Stefan Beller wrote: > We often treating a submodule as a file from the superproject, but not always. > And in case of a merge, git seems to be a bit smarter than treating it > as a textfile > with two different lines. Sure, but a submodule

[PATCH v3 3/3] merge: pass aggressive when rename detection is turned off

Set aggressive flag in git_merge_trees() when rename detection is turned off. This allows read_tree() to auto resolve more cases that would have otherwise been handled by the rename detection. Reviewed-by: Johannes Schindelin Signed-off-by: Ben Peart

[PATCH v3 2/3] merge: Add merge.renames config setting

Add the ability to control rename detection for merge via a config setting. This setting behaves the same and defaults to the value of diff.renames but only applies to merge. Reviewed-by: Johannes Schindelin Signed-off-by: Ben Peart ---

[PATCH v3 1/3] merge: update documentation for {merge,diff}.renameLimit

Update the documentation to better indicate that the renameLimit setting is ignored if rename detection is turned off via command line options or config settings. Signed-off-by: Ben Peart --- Documentation/diff-config.txt | 3 ++- Documentation/merge-config.txt | 3 ++-

[PATCH v3 0/3] add merge.renames config setting

This is a complete rewrite based on the feedback from earlier patches. Update the documentation to better indicate command line options that override various config settings related to merge. Add a new config merge.renames setting to to control the rename detection behavior of merge. This

Proposal

Hello Greetings to you today i asked before but i did't get a response please i know this might come to you as a surprise because you do not know me personally i have a business proposal for you please reply for more info. Best Regards, Esentepe Mahallesi Büyükdere Caddesi Kristal Kule

Re: Fetching tags overwrites existing tags

I've tried to teach 'git remote add' the --prefix-tags option using the technique Junio provided. At moment it is PR #486 on github [1] and I'd love some comments on whether or not this the right direction for fetching tags and putting them in the branches namespace. -- Wink [1]

Re: [RFC PATCH] checkout: Force matching mtime between files

On Thu, Apr 26, 2018 at 07:53:58PM +0200, SZEDER Gábor wrote: > BTW, wouldn't running > > git clone --template=/path/to/template/dir/with/hooks/ > > invoke the post-checkout hook in there? > Yes but it's cumbersome, preparing a template just for one extra hook. I never like this template

Re: [RFC PATCH] checkout: Force matching mtime between files

On Thu, Apr 26, 2018 at 05:48:35PM +, Robin H. Johnson wrote: > On Thu, Apr 26, 2018 at 06:43:56PM +0200, Duy Nguyen wrote: > > On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud > > wrote: > > > Are we all that sure that the performance hit is that drastic? After all, >

Re: git merge banch w/ different submodule revision

On Thu, Apr 26, 2018 at 3:49 AM, Middelschulte, Leif wrote: > Hi, > > we're using git-flow as a basic development workflow. However, doing so > revealed unexpected merge-behavior by git. > > Assume the following setup: > > - Repository `S` is sourced by

Re: [RFC PATCH] checkout: Force matching mtime between files

> On Wed, Apr 25, 2018 at 10:41:18AM +0200, �var Arnfj�r� Bjarmason wrote: > > 2. Add some config so we can have hook search paths, and ship with a > > default search path for hooks shipped with git. > > I would go for something like this instead of search paths. This > allows you to specify

Re: [RFC PATCH] checkout: Force matching mtime between files

On Thu, Apr 26, 2018 at 07:15:40PM +0200, Duy Nguyen wrote: > On Wed, Apr 25, 2018 at 10:41:18AM +0200, Ævar Arnfjörð Bjarmason wrote: > > 2. Add some config so we can have hook search paths, and ship with a > > default search path for hooks shipped with git. > > I would go for something

Re: [RFC PATCH] checkout: Force matching mtime between files

On Thu, Apr 26, 2018 at 06:43:56PM +0200, Duy Nguyen wrote: > On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud wrote: > > Are we all that sure that the performance hit is that drastic? After all, > > we've just done write_entry(). Calling utime() at that point should just >

Re: BUG report: unicode normalization on APFS (Mac OS High Sierra)

On Thu, Apr 26, 2018 at 10:13 AM, Torsten Bögershausen wrote: > Hm, > thanks for the report. > I don't have a high sierra box, but I can probably get one. > t0050 -should- pass automagically, so I feel that I can do something. > Unless someone is faster of course. Sweet, thanks

Re: [RFC PATCH] checkout: Force matching mtime between files

On Wed, Apr 25, 2018 at 10:41:18AM +0200, Ævar Arnfjörð Bjarmason wrote: > 2. Add some config so we can have hook search paths, and ship with a > default search path for hooks shipped with git. I would go for something like this instead of search paths. This allows you to specify a path to

Re: BUG report: unicode normalization on APFS (Mac OS High Sierra)

On 26.04.18 18:48, Elijah Newren wrote: > On HFS (which appears to be the default Mac filesystem prior to High > Sierra), unicode names are "normalized" before recording. Thus with a > script like: > > mkdir tmp > cd tmp > > auml=$(printf "\303\244") > aumlcdiar=$(printf

BUG report: unicode normalization on APFS (Mac OS High Sierra)

On HFS (which appears to be the default Mac filesystem prior to High Sierra), unicode names are "normalized" before recording. Thus with a script like: mkdir tmp cd tmp auml=$(printf "\303\244") aumlcdiar=$(printf "\141\314\210") >"$auml" echo "auml: " $(echo

Re: [RFC PATCH] checkout: Force matching mtime between files

On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud wrote: > Are we all that sure that the performance hit is that drastic? After all, > we've just done write_entry(). Calling utime() at that point should just > hit the filesystem cache. I have a feeling this has "this is

Re: [PATCHv3 0/9] object store: oid_object_info is the next contender

On 04/25, Stefan Beller wrote: > v3: > * fixed and extended the commit message of last commit > * fixed the last patch, as Jonathan Tan suggested, see interdiff: > > $ git diff remotes/origin/sb/oid-object-info (which is v2) > diff --git c/sha1_file.c w/sha1_file.c > index

Re: [PATCH 18/41] index-pack: abstract away hash function constant

On Wed, Apr 25, 2018 at 8:49 PM, Martin Ågren wrote: >> I agree that pack v2 is not going to have anything but SHA-1. However, >> writing all the code such that it's algorithm agnostic means that we can >> do testing of new algorithms by wholesale replacing the algorithm

Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)

On Wed, Apr 25, 2018 at 10:37 AM, Junio C Hamano wrote: > * nd/pack-objects-pack-struct (2018-04-16) 15 commits > ... > > "git pack-objects" needs to allocate tons of "struct object_entry" > while doing its work, and shrinking its size helps the performance > quite a bit. >

Re: [RFC PATCH] checkout: Force matching mtime between files

W dniu czw, 26.04.2018 o godzinie 10∶25 +0900, użytkownik Junio C Hamano napisał: > Marc Branchaud writes: > > > > But Git is not an archiver (tar), but is a source code control > > > system, so I do not think we should spend any extra cycles to > > > "improve" its

Re: [RFC PATCH] checkout: Force matching mtime between files

On 2018-04-25 09:25 PM, Junio C Hamano wrote: Marc Branchaud writes: But Git is not an archiver (tar), but is a source code control system, so I do not think we should spend any extra cycles to "improve" its behaviour wrt the relative ordering, at least for the default

Re: [PATCH v4 03/10] commit-graph: compute generation numbers

On 4/26/2018 8:58 AM, Derrick Stolee wrote: n 4/25/2018 10:35 PM, Junio C Hamano wrote: Derrick Stolee writes: @@ -439,6 +439,9 @@ static void write_graph_chunk_data(struct hashfile *f, int hash_len,   else   packedDate[0] = 0;   +    if

Re: [PATCH v4 03/10] commit-graph: compute generation numbers

n 4/25/2018 10:35 PM, Junio C Hamano wrote: Derrick Stolee writes: @@ -439,6 +439,9 @@ static void write_graph_chunk_data(struct hashfile *f, int hash_len, else packedDate[0] = 0; + if ((*list)->generation !=

Re: What's cooking in git.git (Apr 2018, #03; Wed, 25)

On 4/25/2018 1:43 PM, Brandon Williams wrote: On 04/25, Ævar Arnfjörð Bjarmason wrote: * bw/protocol-v2 (2018-03-15) 35 commits (merged to 'next' on 2018-04-11 at 23ee234a2c) + remote-curl: don't request v2 when pushing + remote-curl: implement stateless-connect command + http:

git merge banch w/ different submodule revision

Hi, we're using git-flow as a basic development workflow. However, doing so revealed unexpected merge-behavior by git. Assume the following setup: - Repository `S` is sourced by repository `p` as submodule `s` - Repository `p` has two branches: `feature_x` and `develop` - The revisions sourced

Re: [PATCH v3 0/4] rebase -i: avoid stale "# This is a combinationof" in commit messages

On 26/04/18 10:51, Johannes Schindelin wrote: > Hi Phillip, > > On Wed, 25 Apr 2018, Phillip Wood wrote: > >> On 25/04/18 13:48, Johannes Schindelin wrote: >>> >>> On Mon, 23 Apr 2018, Phillip Wood wrote: >>> On 23/04/18 19:11, Stefan Beller wrote: > > On Sat, Apr 21, 2018 at 12:34

Re: [PATCH v2 2/5] builtin/config.c: support `--type=` as preferred alias for `--`

Taylor Blau writes: > +static int option_parse_type(const struct option *opt, const char *arg, > + int unset) > +{ > + /* > + * To support '--' style flags, begin with new_type equal to > + * opt->defval. > + */ > + int new_type

Re: [PATCH v3 0/4] rebase -i: avoid stale "# This is a combinationof" in commit messages

Hi Phillip, On Wed, 25 Apr 2018, Phillip Wood wrote: > On 25/04/18 13:48, Johannes Schindelin wrote: > > > > On Mon, 23 Apr 2018, Phillip Wood wrote: > > > > > On 23/04/18 19:11, Stefan Beller wrote: > > > > > > > > On Sat, Apr 21, 2018 at 12:34 AM, Johannes Schindelin > > > >

Re: [PATCH 0/3] enable userdiff for more things in git.git

Ævar Arnfjörð Bjarmason writes: > A noticed that git.git doesn't have userdiff enabled for perl files, > and looking over some recent patches this gave better results, while > I'm at it add one for Python too. I couldn't find anything in > gitattributes(5) that was worth the

Re: `iconv` should have the encoding `ISO646-SE2`

Hi Abinsium, On Wed, 25 Apr 2018, Abinsium wrote: > I installed from `Git-2.16.2-64-bit.exe` from git-scm.com. `iconv` is included > in this package. I think `iconv` should have the encoding `ISO646-SE2`. Ubuntu > 16.04 has this encoding. I use it to read old Swedish text files, which there >

Re: [PATCH v5 09/11] technical/shallow: stop referring to grafts

Hi Kuba, On Wed, 25 Apr 2018, Jakub Narębski wrote: > On 25 April 2018 at 11:54, Johannes Schindelin > wrote: > > diff --git a/Documentation/technical/shallow.txt > > b/Documentation/technical/shallow.txt > > index 5183b154229..4ec721335d2 100644 > > ---

Re: [PATCH v4 04/10] commit: use generations in paint_down_to_common()

Junio C Hamano writes: > Derrick Stolee writes: > >> Define compare_commits_by_gen_then_commit_date(), which uses generation >> numbers as a primary comparison and commit date to break ties (or as a >> comparison when both commits do not have computed

[PATCH 0/3] enable userdiff for more things in git.git

A noticed that git.git doesn't have userdiff enabled for perl files, and looking over some recent patches this gave better results, while I'm at it add one for Python too. I couldn't find anything in gitattributes(5) that was worth the bother of enabling this (e.g. we just have one Ruby file).

[PATCH 3/3] .gitattributes: add a diff driver for Python

Declare that the *.py files in our tree are Python for the purposes of diffing, and as in 00ddc9d13c ("Fix build with core.autocrlf=true", 2017-05-09) set eol=lf on them, which makes sense like with the *.perl files. Signed-off-by: Ævar Arnfjörð Bjarmason --- .gitattributes |

[PATCH 2/3] .gitattributes: use the "perl" differ for Perl

As noted in gitattributes(5) this gives better patch context for these types of files. Signed-off-by: Ævar Arnfjörð Bjarmason --- .gitattributes | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/.gitattributes b/.gitattributes index

[PATCH 1/3] .gitattributes: add *.pl extension for Perl

Change the list of Perl extensions added in 00ddc9d13c ("Fix build with core.autocrlf=true", 2017-05-09) to also include *.pl, we have some of those in the tree, e.g. in t/. Signed-off-by: Ævar Arnfjörð Bjarmason --- .gitattributes | 1 + 1 file changed, 1 insertion(+) diff

[PATCH v4 2/2] log: prevent error if line range ends past end of file

From: Isabella Stephens If the -L option is used to specify a line range in git log, and the end of the range is past the end of the file, git will fail with a fatal error. This commit prevents such behaviour - instead we perform the log for existing lines within the

[PATCH v4 1/2] blame: prevent error if range ends past end of file

From: Isabella Stephens If the -L option is used to specify a line range in git blame, and the end of the range is past the end of the file, git will fail with a fatal error. This commit prevents such behavior - instead we display the blame for existing lines within the

[PATCH v4 0/2] blame and log: prevent error if range ends past end of file

Picking this back up after a little while. This solution means we can still accept -L, for an empty file but any other range will fail. I've made the change for both blame and log (as two separate patches). I've also changed behaviour in a couple of corner cases - before we couldn't distinguish

Re: Antw: Re: java diffs show no method context

On Thu, Apr 26 2018, Ulrich Windl wrote: > Thanks for that. It sounds plausible, but I wonder why it works automagically > for C, but not for Java (Politcal reasons put aside): Using ".c" for C is > about > as common as using ".java" for Java ;-) It has a bit to do with it being in C, but not

Antw: Re: java diffs show no method context

Hi! Thanks for that. It sounds plausible, but I wonder why it works automagically for C, but not for Java (Politcal reasons put aside): Using ".c" for C is about as common as using ".java" for Java ;-) Regards, Ulrich >>> Alban Gruin schrieb am 25.04.2018 um 17:05 in

Re: [PATCH v9 00/17] rebase -i: offer to recreate commit topology by rebasing merges

Junio C Hamano writes: >> - Rebased the patch series on top of current `master`, i.e. both >> `pw/rebase-keep-empty-fixes` and `pw/rebase-signoff`, to resolve merge >> conflicts myself. > > Good to see the last item, as this gave me a chance to make sure > that the

Re: [PATCH 5/5] builtin/config: introduce `color` type specifier

On Thu, Apr 26, 2018 at 02:32:54PM +0900, Junio C Hamano wrote: > Taylor Blau writes: > > > diff --git a/builtin/config.c b/builtin/config.c > > index d7acf912cd..ec5c11293b 100644 > > --- a/builtin/config.c > > +++ b/builtin/config.c > > @@ -61,6 +61,7 @@ static int

Re: [PATCH 2/5] builtin/config.c: support `--type=` as preferred alias for `--type`

On Thu, Apr 26, 2018 at 02:25:44PM +0900, Junio C Hamano wrote: > Taylor Blau writes: > > > Subject: Re: [PATCH 2/5] builtin/config.c: support `--type=` as > > preferred alias for `--type` > > I'd retitle while queuing, as the last 'type' is a placeholder for > concrete types