> 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
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
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
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
>
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,
>
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
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
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 ++-
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
---
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
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
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
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.
>
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
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
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
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
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
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
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
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
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
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
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
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 |
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
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).
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
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
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
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
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",
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:
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
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
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
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
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
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
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
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
> > ---
Æ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
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
> > > >
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
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
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
>
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
>
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
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
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
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
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
> 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
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
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
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
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
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
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)
>
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
Good morning Git
https://bit.ly/2HSZB08
Scott McKellar
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
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
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:
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 !=
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
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
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
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]
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
70 matches
Mail list logo