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 i
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 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 specified range. Tests and
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 specified range.
This commit
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 | 1 +
1 file changed
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 482af05a6a..aa08dd219d 100644
--- a/.gi
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).
Æva
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 --git a/.gitattribut
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 generation numbers).
>>
>> Since the commit-g
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
> > --- a/Documentation/technical/shallow.txt
>
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
> are
Æ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 bother of enabling t
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
> > > > wrote:
> > > > >
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 = opt->defval;
> +
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 A
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: eliminat
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 != GENERATION_NUMBER_INFINITY)
+
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 ((*list)->generation != GENE
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 case. Only those who re
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 behaviour wrt the relative orde
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.
>
> What's the donen
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 with a
>> new one, which
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 94123e0299..
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 linux" assumption. Anybody
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 -n
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 "\141\31
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 an
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 for taking a look.
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
> > hit the filesystem c
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 like
> 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 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 repository `p` as submodule `s`
> - Reposit
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,
> > > we've just done wri
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 thin
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] https://github.co
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 B
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 ++-
2 files changed, 4 inser
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
---
Documentation/merge-config.txt| 6 ++
Doc
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 settin
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
---
merge-recursive.c | 4 +++-
1 file chang
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 is checked out "at a c
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 settings related to merge.
>
>
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 B
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 of
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 branches namespace.
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", Git will
> + detect c
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: Johannes Schindelin
> Signed-of
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
> ---
> Documentation/diff-config.txt | 3 ++-
>
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 89973554b52c ("diffcor
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 direction
>> for fetching tags and putting
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 B
Good morning Git
https://bit.ly/2HSZB08
Scott McKellar
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 than treating it
>> as a textfile
>> with tw
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 repository `p` as submodule `s`
> - Reposit
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 B
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 enabled. If set to "copies
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 wr
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 const char *parse_loc(const c
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 when I reimplemented it,
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 thi
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 merge.renames will inherit that value. My
>> assum
> 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 f
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
>>> --- a/merge-recursive.h
>>> +++ b/merge-recu
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
> canonicalized under tha
On Thu, Apr 26, 2018 at 2:00 AM, Taylor Blau wrote:
> 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 'typ
On Thu, Apr 26, 2018 at 1:58 AM, Taylor Blau wrote:
> [...]
> For consistency, let's introduce `--type=color` and encourage its use
> with `--default` together over `--get-color` alone.
>
> Signed-off-by: Taylor Blau
> ---
> diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
68 matches
Mail list logo
