Re: [PATCH v3 4/6] git.c: implement --list-cmds=porcelain

On Mon, Apr 23, 2018 at 3:32 PM, SZEDER Gábor wrote: > But then I noticed that it's not an accurate description of the > current situation, because there is a wide grey area between > porcelains and plumbing, and the completion script doesn't "filter out > plumbing

Re: [PATCH v1 2/2] merge: Add merge.aggressive config setting

On 4/20/2018 1:22 PM, Elijah Newren wrote: On Fri, Apr 20, 2018 at 6:36 AM, Ben Peart wrote: Add the ability to control the aggressive flag passed to read-tree via a config setting. This feels like a workaround to the performance problems with index updates in

Re: [PATCH v1 1/2] merge: Add merge.renames config setting

Hi Dscho, On Tue, Apr 24, 2018 at 4:58 AM, Johannes Schindelin wrote: > Hi Junio, > > On Tue, 24 Apr 2018, Junio C Hamano wrote: > >> Yeah, but as opposed to passing "oh, let's see if we can get a >> reasonable result without rename detection just this time" from the

Re: [PATCH 9/9] cache.h: allow sha1_object_info to handle arbitrary repositories

On Tue, 24 Apr 2018 11:42:33 -0700 Brandon Williams wrote: > On 04/24, Jonathan Tan wrote: > > On Mon, 23 Apr 2018 16:43:27 -0700 > > Stefan Beller wrote: > > > > > This involves also adapting sha1_object_info_extended and a some > > > internal functions

Re: [PATCH 6/7] diff.c: decouple white space treatment from move detection algorithm

On Tue, 24 Apr 2018 14:03:29 -0700 Stefan Beller wrote: > As we change the default, we'll adjust the tests. This statement is probably better written as: In some existing tests, options like --ignore-space-at-eol were used to control the color of the output. They have

Re: [PATCH 6/7] diff.c: decouple white space treatment from move detection algorithm

Hi Jonathan, On Tue, Apr 24, 2018 at 3:00 PM, Jonathan Tan wrote: > On Tue, 24 Apr 2018 14:03:29 -0700 > Stefan Beller wrote: > >> As we change the default, we'll adjust the tests. > > This statement is probably better written as: > > In some

Re: [PATCH v2 1/2] merge: Add merge.renames config setting

On 4/24/2018 2:59 PM, Elijah Newren wrote: Sorry, I noticed something else I missed on my last reading... On Tue, Apr 24, 2018 at 10:11 AM, Ben Peart wrote: diff --git a/builtin/merge.c b/builtin/merge.c index 8746c5e3e8..3be52cd316 100644 --- a/builtin/merge.c +++

Re: [PATCH 5/7] diff.c: add a blocks mode for moved code detection

On Tue, 24 Apr 2018 14:03:28 -0700 Stefan Beller wrote: > Suggested-by: Ævar Arnfjörð Bjarmason > (https://public-inbox.org/git/87o9j0uljo@evledraar.gmail.com/) > Signed-off-by: Stefan Beller Firstly, I don't know if this is the

[PATCH v9 0/4] worktree: teach "add" to check out existing branches

Previous rounds are at <20180121120208.12760-1-t.gumme...@gmail.com>, <20180204221305.28300-1-t.gumme...@gmail.com>, <20180317220830.30963-1-t.gumme...@gmail.com>, <2018031719.4940-1-t.gumme...@gmail.com>, <20180325134947.25828-1-t.gumme...@gmail.com>,

[PATCH v9 1/4] worktree: remove extra members from struct add_opts

There are two members of 'struct add_opts', which are only used inside the 'add()' function, but being part of 'struct add_opts' they are needlessly also passed to the 'add_worktree' function. Make them local to the 'add()' function to make it clearer where they are used. Signed-off-by: Thomas

[PATCH v9 2/4] worktree: improve message when creating a new worktree

Currently 'git worktree add' produces output like the following: Preparing ../foo (identifier foo) HEAD is now at 26da330922 The '../foo' is the path where the worktree is created, which the user has just given on the command line. The identifier is an internal implementation detail,

[PATCH v9 3/4] worktree: factor out dwim_branch function

Factor out a dwim_branch function, which takes care of the dwim'ery in 'git worktree add '. It's not too much code currently, but we're adding a new kind of dwim in a subsequent patch, at which point it makes more sense to have it as a separate function. Factor it out now to reduce the patch

[PATCH v9 4/4] worktree: teach "add" to check out existing branches

Currently 'git worktree add ' creates a new branch named after the basename of the path by default. If a branch with that name already exists, the command refuses to do anything, unless the '--force' option is given. However we can do a little better than that, and check the branch out if it is

[PATCH 5/7] diff.c: add a blocks mode for moved code detection

The new "blocks" mode provides a middle ground between plain and zebra. It is as intuitive (few colors) as plain, but still has the requirement for a minimum of lines/characters to count a block as moved. Suggested-by: Ævar Arnfjörð Bjarmason

[PATCH 6/7] diff.c: decouple white space treatment from move detection algorithm

In the original implementation of the move detection logic the choice for ignoring white space changes is the same for the move detection as it is for the regular diff. Some cases came up where different treatment would have been nice. Allow the user to specify that whitespace should be ignored

[PATCH 1/7] xdiff/xdiff.h: remove unused flags

These flags were there since the beginning (3443546f6e (Use a *real* built-in diff generator, 2006-03-24), but were never used. Remove them. Signed-off-by: Stefan Beller --- xdiff/xdiff.h | 8 1 file changed, 8 deletions(-) diff --git a/xdiff/xdiff.h

[PATCHv2 0/7] Moved code detection: ignore space on uniform indentation

v2: I think I have addressed Jonathans feedback * by using a string instead of counting the first character only. * refined tests slightly (easier to read) * moved white space handling for moved blocks into its own flag field, keeping the enum for the actual mode of move detection. v1: This is

[PATCH 2/7] xdiff/xdiffi.c: remove unneeded function declarations

There is no need to forward-declare these functions, as they are used after their implementation only. Signed-off-by: Stefan Beller --- xdiff/xdiffi.c | 17 - 1 file changed, 17 deletions(-) diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c index

[PATCH 3/7] diff.c: do not pass diff options as keydata to hashmap

When we initialize the hashmap, we give it a pointer to the diff_options, which it then passes along to each call of the hashmap_cmp_fn function. There's no need to pass it a second time as the "keydata" parameter, and our comparison functions never look at keydata. This was a mistake left over

[PATCH 7/7] diff.c: add --color-moved-ignore-space-delta option

This marks moved code still as blocks when their indentation level changes uniformly. Signed-off-by: Stefan Beller --- Documentation/diff-options.txt | 4 ++ diff.c | 83 +++--- diff.h | 2 +

[PATCH 4/7] diff.c: adjust hash function signature to match hashmap expectation

This makes the follow up patch easier. Signed-off-by: Stefan Beller --- diff.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/diff.c b/diff.c index ce7bedc1b9..d1bae900cd 100644 --- a/diff.c +++ b/diff.c @@ -707,11 +707,15 @@ struct

Re: [PATCH v3 09/11] technical/shallow: describe the relationship with replace refs

Hi dscho From: "Johannes Schindelin" : Tuesday, April 24, 2018 8:10 PM On Sun, 22 Apr 2018, Philip Oakley wrote: From: "Johannes Schindelin" > Now that grafts are deprecated, we should start to assume that readers > have no idea what

Fetching tags overwrites existing tags

If have a repository with a tag "v1.0.0" and I add a remote repository which also has a tag "v1.0.0" tag is overwritten. Google found [1] from 2011 and option 3 is what I'd like to see. Has it been implemented and I just don't see it? [1]:

[PATCH v10 2/2] fixup! t6046: testcases checking whether updates can be skipped in a merge

--- t/t6046-merge-skip-unneeded-updates.sh | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/t/t6046-merge-skip-unneeded-updates.sh b/t/t6046-merge-skip-unneeded-updates.sh index 880cd782d7..fcefffcaec 100755 --- a/t/t6046-merge-skip-unneeded-updates.sh +++

[PATCH v10 1/2] fixup! merge-recursive: fix was_tracked() to quit lying with some renamed paths

--- merge-recursive.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/merge-recursive.c b/merge-recursive.c index 1de8dc1c53..f2cbad4f10 100644 --- a/merge-recursive.c +++ b/merge-recursive.c @@ -3146,10 +3146,10 @@ int merge_trees(struct merge_options *o, /*

[PATCHv2 5/9] packfile: add repository argument to packed_object_info

From: Jonathan Nieder Add a repository argument to allow callers of packed_object_info to be more specific about which repository to handle. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with

[PATCHv2 3/9] packfile: add repository argument to retry_bad_packed_offset

Add a repository argument to allow the callers of retry_bad_packed_offset to be more specific about which repository to handle. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro

[PATCHv2 9/9] cache.h: allow oid_object_info to handle arbitrary repositories

This involves also adapting oid_object_info_extended and a some internal functions that are used to implement these. It all has to happen in one patch, because of a single recursive chain of calls visits all these functions. sha1_object_info_extended is also used in partial clones, which allow

[PATCHv2 8/9] packfile: add repository argument to cache_or_unpack_entry

Add a repository argument to allow the callers of cache_or_unpack_entry to be more specific about which repository to act on. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to

[PATCHv2 2/9] cache.h: add repository argument to oid_object_info

Add a repository argument to allow the callers of oid_object_info to be more specific about which repository to handle. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to catch

[PATCHv2 7/9] packfile: add repository argument to unpack_entry

Add a repository argument to allow the callers of unpack_entry to be more specific about which repository to act on. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to catch

[PATCHv2 6/9] packfile: add repository argument to read_object

Add a repository argument to allow the callers of read_object to be more specific about which repository to act on. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to catch

[PATCHv2 9/9] cache.h: allow sha1_object_info to handle arbitrary repositories

This involves also adapting sha1_object_info_extended and a some internal functions that are used to implement these. It all has to happen in one patch, because of a single recursive chain of calls visits all these functions. sha1_object_info_extended is also used in partial clones, which allow

[PATCHv2 1/9] cache.h: add repository argument to oid_object_info_extended

Add a repository argument to allow oid_object_info_extended callers to be more specific about which repository to act on. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. Signed-off-by: Stefan Beller

[PATCHv2 4/9] packfile: add repository argument to packed_to_object_type

Add a repository argument to allow the callers of packed_to_object_type to be more specific about which repository to handle. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to

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

v2: * fixed the sha1/oid typo * removed spurious new line * Brandon and Jonthan discovered another dependency that I missed due to cherrypicking that commit from a tree before partial clone was a thing. We error out when attempting to use fetch_object for repos that are not the_repository.

Re: GSoC students and mentors in 2018

On 24.04.2018 00:01, Stefan Beller wrote: Hi Git community, This year we'll participate once again in Google Summer or Code! We'll have 3 students and 3 mentors, which is more than in recent years. Paul-Sebastian Ungureanu mentored by DScho, wants to convert git-stash into a builtin. Alban

Confidential Request!!

-- Hello Dear Friend, I am Williams Abbas, I need your services in a confidential matter regarding money transfer. This requires a private arrangement though the details of the transaction will be furnished to you if you indicate your interest in this proposal.We have all the legal documents

[PATCH v2 1/2] merge: Add merge.renames config setting

Add the ability to control rename detection for merge via a config setting. Reviewed-by: Johannes Schindelin Signed-off-by: Ben Peart --- Documentation/diff-config.txt | 3 ++- Documentation/merge-config.txt | 8 +++-

[PATCH v2 2/2] merge: Add merge.aggressive config setting

Add the ability to control the aggressive flag passed to read-tree via a config setting. Reviewed-by: Johannes Schindelin Signed-off-by: Ben Peart --- Documentation/merge-config.txt | 4 merge-recursive.c | 1 + 2 files

Re: [PATCH v1 1/2] merge: Add merge.renames config setting

On 4/23/2018 5:32 PM, Eckhard Maaß wrote: On Mon, Apr 23, 2018 at 09:15:09AM -0400, Ben Peart wrote: In commit 2a2ac926547 when merge.renamelimit was added, it was decided to have separate settings for merge and diff to give users the ability to control that behavior. In this particular

Re: [PATCH v2 1/2] merge: Add merge.renames config setting

On Tue, Apr 24, 2018 at 10:11 AM, Ben Peart wrote: > Add the ability to control rename detection for merge via a config setting. Sweet, thanks for including the documentation updates. I lean towards the side of the argument that says that since merge.renameLimit

Re: [PATCH 2/9] cache.h: add repository argument to oid_object_info

On Mon, 23 Apr 2018 16:43:20 -0700 Stefan Beller wrote: > Add a repository argument to allow the callers of oid_object_info > to be more specific about which repository to handle. This is a small > mechanical change; it doesn't change the implementation to handle >

Re: [PATCH 5/9] packfile: add repository argument to packed_object_info

On Mon, 23 Apr 2018 16:43:23 -0700 Stefan Beller wrote: > diff --git a/sha1_file.c b/sha1_file.c > index 93f25c6c6a..b292e04fd3 100644 > --- a/sha1_file.c > +++ b/sha1_file.c > @@ -1307,7 +1307,8 @@ int oid_object_info_extended_the_repository(const > struct object_id *oid,

Re: [PATCH 9/9] cache.h: allow sha1_object_info to handle arbitrary repositories

On Mon, 23 Apr 2018 16:43:27 -0700 Stefan Beller wrote: > This involves also adapting sha1_object_info_extended and a some > internal functions that are used to implement these. It all has to > happen in one patch, because of a single recursive chain of calls visits > all

Re: [PATCH v3 5/9] ref-filter: use generation number for --contains

Derrick Stolee writes: > On 4/18/2018 5:02 PM, Jakub Narebski wrote: >> Derrick Stolee writes: >> >>> A commit A can reach a commit B only if the generation number of A >>> is larger than the generation number of B. This condition allows >>> significantly

[PATCH v2 0/2] add additional config settings for merge

Updated in response to feedback. Mostly documentation changes but the diffstat at the end of the merge (if on) now honors the new merge.rename setting as well. Base Ref: master Web-Diff: https://github.com/benpeart/git/commit/653bfe6e01 Checkout: git fetch https://github.com/benpeart/git

Re: [PATCH v4 04/11] replace: "libify" create_graft() and callees

Hi Stefan, On Mon, 23 Apr 2018, Stefan Beller wrote: > On Fri, Apr 20, 2018 at 3:21 PM, Johannes Schindelin > wrote: > > @@ -250,27 +257,38 @@ static void import_object(struct object_id *oid, enum > > object_type type, > > - if (strbuf_read(, cmd.out,

Re: [PATCH v2 1/2] merge: Add merge.renames config setting

Sorry, I noticed something else I missed on my last reading... On Tue, Apr 24, 2018 at 10:11 AM, Ben Peart wrote: > diff --git a/builtin/merge.c b/builtin/merge.c > index 8746c5e3e8..3be52cd316 100644 > --- a/builtin/merge.c > +++ b/builtin/merge.c > @@ -424,6 +424,7 @@

Re: [PATCH 0/3] Colorful blame output

On Mon, Apr 23, 2018 at 7:09 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> This is a revamp of >> https://public-inbox.org/git/20180416220955.46163-1-sbel...@google.com/ >> >> Junio had some issue with that version, as it would collide config and

Re: [PATCH v3 7/7] contrib/git-jump/git-jump: jump to match column in addition to line

On Tue, Apr 24, 2018 at 01:37:36AM -0400, Eric Sunshine wrote: > On Tue, Apr 24, 2018 at 1:07 AM, Taylor Blau wrote: > > Take advantage of 'git-grep(1)''s new option, '--column-number' in order > > to teach Peff's 'git-jump' script how to jump to the correct column for > > any

Re: [PATCH v4 05/11] replace: introduce --convert-graft-file

Hi Eric, On Sat, 21 Apr 2018, Eric Sunshine wrote: > On Sat, Apr 21, 2018 at 5:48 AM, Johannes Schindelin > wrote: > > This option is intended to help with the transition away from the > > now-deprecated graft file. > > > > Signed-off-by: Johannes Schindelin

Re: [PATCH v4 04/11] replace: "libify" create_graft() and callees

Hi Johannes, On Tue, Apr 24, 2018 at 11:51 AM, Johannes Schindelin wrote: > > Oy vey. How many more mistakes can I introduce in one commit... > I ask this myself all the time, but Software is hard when not having computer assisted checks. The test suite doesn't

Re: [PATCH v3 4/6] git.c: implement --list-cmds=porcelain

On Tue, Apr 24, 2018 at 6:12 PM, Duy Nguyen wrote: > git-completion.bash will be updated to ask git "give me the commands > in the mainporcelain, completable or external category". This also > addresses another thing that bugs me: I wanted an option to let me > complete all

[PATCH] git: add -N as a short option for --no-pager

In modern setups, less, the pager, uses alternate screen to show the content. When it is closed, it switches back to the original screen, and all content is gone. It is not uncommon to request that the output remains visible in the terminal. For this, the option --no-pager can be used. But it is

Re: [PATCH 9/9] cache.h: allow sha1_object_info to handle arbitrary repositories

On 04/24, Jonathan Tan wrote: > On Mon, 23 Apr 2018 16:43:27 -0700 > Stefan Beller wrote: > > > This involves also adapting sha1_object_info_extended and a some > > internal functions that are used to implement these. It all has to > > happen in one patch, because of a single

Re: [PATCH v3 09/11] technical/shallow: describe the relationship with replace refs

Hi Philip, On Sun, 22 Apr 2018, Philip Oakley wrote: > From: "Johannes Schindelin" > > Now that grafts are deprecated, we should start to assume that readers > > have no idea what grafts are. So it makes more sense to describe the > > "shallow" feature in terms of

Re: [PATCH v8 06/16] sequencer: introduce the `merge` command

From: "Johannes Schindelin" On Mon, 23 Apr 2018, Philip Oakley wrote: From: "Johannes Schindelin" : Monday, April 23, 2018 1:03 PM Subject: Re: [PATCH v8 06/16] sequencer: introduce the `merge` command [...] > > > > label onto > > > >

Re: [PATCH 2/2] unpack_trees_options: free messages when done

On Mon, Apr 23, 2018 at 10:13 PM, Martin Ågren wrote: > The strings allocated in `setup_unpack_trees_porcelain()` are never > freed. Provide a function `clear_unpack_trees_porcelain()` to do so and > call it in the functions which use `setup_unpack_trees_porcelain()`.

Re: [PATCH v1 2/2] merge: Add merge.aggressive config setting

Hi Ben, On Tue, Apr 24, 2018 at 9:45 AM, Ben Peart wrote: > On 4/20/2018 1:22 PM, Elijah Newren wrote: >> On Fri, Apr 20, 2018 at 6:36 AM, Ben Peart >> wrote: >>> >>> Add the ability to control the aggressive flag passed to read-tree via a >>> config

Re: [PATCH v2 2/6] grep.c: take column number as argument to show_line()

On Tue, Apr 24, 2018 at 03:13:55PM +0900, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > > > I think when we add features to git-grep we should be as close to GNU > > grep as possible (e.g. not add this -m alias meaning something different > > as in your v1), but if

Assalamu`Alaikum.

Dear Sir/Madam. Assalamu`Alaikum. I am Dr mohammad ouattara, I have ($14.6 Million us dollars) to transfer into your account, I will send you more details about this deal and the procedures to follow when I receive a positive response from you, Have a great day, Dr mohammad ouattara.

Re: [PATCHv2 9/9] cache.h: allow oid_object_info to handle arbitrary repositories

On Tue, 24 Apr 2018 14:59:09 -0700 Stefan Beller wrote: > This involves also adapting oid_object_info_extended and a some > internal functions that are used to implement these. It all has to > happen in one patch, because of a single recursive chain of calls visits > all

Re: [PATCH 5/7] diff.c: add a blocks mode for moved code detection

On Tue, 24 Apr 2018 15:37:51 -0700 Stefan Beller wrote: > These can be combined independently, so would > you expect the user to expect two options for them? > For example "--color-moved=zebra" could be split > into "--skip-small --alternate-blocks" Yes, this is a good

Re: [PATCH] git: add -N as a short option for --no-pager

Johannes Sixt writes: > In modern setups, less, the pager, uses alternate screen to show > the content. When it is closed, it switches back to the original > screen, and all content is gone. > > It is not uncommon to request that the output remains visible in > the terminal. For

Re: [PATCH v3 09/11] technical/shallow: describe the relationship with replace refs

"Philip Oakley" writes: > Perhaps something like: > +$GIT_DIR/shallow, and handle its contents similar to replace > +refs (with the difference that shallow does not actually > +create those replace refs) with the difference that shallow commits will > +always have their

Re: [PATCH 7/7] diff.c: add --color-moved-ignore-space-delta option

On Tue, 24 Apr 2018 16:23:28 -0700 Stefan Beller wrote: > >> s/missmatch/mismatch/ > >> Also, what is this used for? > > > > The mismatch should be used for (thanks for catching!) > > checking if the remainder of a line is the same, although a boolean > > may be not the

Re: [PATCH 5/9] packfile: add repository argument to packed_object_info

Jonathan Tan writes: > On Mon, 23 Apr 2018 16:43:23 -0700 > Stefan Beller wrote: > >> diff --git a/sha1_file.c b/sha1_file.c >> index 93f25c6c6a..b292e04fd3 100644 >> --- a/sha1_file.c >> +++ b/sha1_file.c >> @@ -1307,7 +1307,8 @@ int

Re: [PATCH 25/41] builtin/receive-pack: avoid hard-coded constants for push certs

On Tue, Apr 24, 2018 at 11:58:17AM +0200, Martin Ågren wrote: > On 24 April 2018 at 01:39, brian m. carlson > > diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c > > index c4272fbc96..5f35596c14 100644 > > --- a/builtin/receive-pack.c > > +++ b/builtin/receive-pack.c > > @@ -454,21

Re: [PATCH 7/7] diff.c: add --color-moved-ignore-space-delta option

On Tue, 24 Apr 2018 14:03:30 -0700 Stefan Beller wrote: > +--color-moved-[no-]ignore-space-prefix-delta:: > + Ignores whitespace when comparing lines when performing the move > + detection for --color-moved. This ignores uniform differences > + of white space at

[PATCH v3] Make running git under other debugger-like programs easy

This allows us to run git, when using the script from bin-wrappers, under other programs. A few examples for usage within testsuite scripts: debug git checkout master debug --debugger=nemiver git $ARGS debug -d "valgrind --tool-memcheck --track-origins=yes" git $ARGS Or, if someone has

Re: Fetching tags overwrites existing tags

On Tue, Apr 24, 2018 at 5:52 PM, Junio C Hamano wrote: > Wink Saville writes: > >> Ideally I would have liked the tags fetched from gbenchmark to have a prefix >> of gbenchmark/, like the branches have, maybe something like: >> >> $ git fetch --tags

Re: Fetching tags overwrites existing tags

On Tue, Apr 24, 2018 at 5:52 PM, Junio C Hamano wrote: > Wink Saville writes: > >> Ideally I would have liked the tags fetched from gbenchmark to have a prefix >> of gbenchmark/, like the branches have, maybe something like: >> >> $ git fetch --tags

Re: [PATCH v2 0/3] Some add-on patches on top of dj/runtime-prefix

Johannes Schindelin writes: > Thank you, and sorry for the trouble. I am just too used to a Continuous > Integration setting with exactly one integration branch. Fixing problems close to the source (i.e. picking an appropriately aged base) and making sure everthing

Re: [PATCH 21/41] http: eliminate hard-coded constants

On Wed, Apr 25, 2018 at 08:44:19AM +0900, Junio C Hamano wrote: > Martin Ågren writes: > > >> switch (data[i]) { > >> case 'P': > >> i++; > >> - if (i + 52 <= buf.len && > >> +

Re: [PATCHv2 0/7] Moved code detection: ignore space on uniform indentation

On Tue, Apr 24, 2018 at 3:37 PM, Jonathan Tan wrote: > On Tue, 24 Apr 2018 14:03:23 -0700 > Stefan Beller wrote: > >> v2: >> I think I have addressed Jonathans feedback >> * by using a string instead of counting the first character only. >> * refined

Re: [PATCH 7/7] diff.c: add --color-moved-ignore-space-delta option

Replied to Jonathan only instead of all. My reply is below: On Tue, Apr 24, 2018 at 3:55 PM, Stefan Beller wrote: > On Tue, Apr 24, 2018 at 3:35 PM, Jonathan Tan > wrote: >> On Tue, 24 Apr 2018 14:03:30 -0700 >> Stefan Beller

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

On Tue, Apr 24, 2018 at 11:50:16AM +0200, Martin Ågren wrote: > On 24 April 2018 at 01:39, brian m. carlson > wrote: > > The code for reading certain pack v2 offsets had a hard-coded 5 > > representing the number of uint32_t words that we needed to skip over. > >

git https and github

Hi list, I'm struggling with git connecting to Github. The problem might be SSL/TLS related. https://githubengineering.com/crypto-removal-notice/ I suspect that my setup still uses tlsv1 or tlsv1.1. I've tried to explicitly set git to use tlsv1.2 in my .gitconfig file like this: [http]

Re: [PATCH 21/41] http: eliminate hard-coded constants

Martin Ågren writes: >> switch (data[i]) { >> case 'P': >> i++; >> - if (i + 52 <= buf.len && >> + if (i + hexsz + 12 <= buf.len && >>

Re: [PATCH v2 0/2] add additional config settings for merge

Ben Peart writes: > diff.renameLimit:: > The number of files to consider when performing the copy/rename > - detection; equivalent to the 'git diff' option `-l`. > + detection; equivalent to the 'git diff' option `-l`. This setting > + has no effect if

Re: [PATCH 25/41] builtin/receive-pack: avoid hard-coded constants for push certs

On 25 April 2018 at 04:00, brian m. carlson wrote: > On Tue, Apr 24, 2018 at 11:58:17AM +0200, Martin Ågren wrote: >> On 24 April 2018 at 01:39, brian m. carlson >> > diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c >> > index c4272fbc96..5f35596c14

Re: [PATCHv2 0/7] Moved code detection: ignore space on uniform indentation

On Tue, 24 Apr 2018 14:03:23 -0700 Stefan Beller wrote: > v2: > I think I have addressed Jonathans feedback > * by using a string instead of counting the first character only. > * refined tests slightly (easier to read) > * moved white space handling for moved blocks into its

Re: [PATCH 5/7] diff.c: add a blocks mode for moved code detection

On Tue, Apr 24, 2018 at 2:50 PM, Jonathan Tan wrote: > On Tue, 24 Apr 2018 14:03:28 -0700 > Stefan Beller wrote: > >> Suggested-by: Ævar Arnfjörð Bjarmason >> (https://public-inbox.org/git/87o9j0uljo@evledraar.gmail.com/) >>

Re: Fetching tags overwrites existing tags

On Tue, Apr 24, 2018 at 12:57 PM, Wink Saville wrote: > If have a repository with a tag "v1.0.0" and I add a remote repository > which also has a tag "v1.0.0" tag is overwritten. > > Google found [1] from 2011 and option 3 is what I'd like to see. Has it been > implemented and I

Re: [PATCH v1 2/2] merge: Add merge.aggressive config setting

Ben Peart writes: > That said, it makes sense to me to do >> this when rename detection is turned off. In fact, I think you'd >> automatically want to set aggressive to true whenever rename detection >> is turned off (whether by your merge.renames option or the >>

Re: Fetching tags overwrites existing tags

Wink Saville writes: > Ideally I would have liked the tags fetched from gbenchmark to have a prefix > of gbenchmark/, like the branches have, maybe something like: > > $ git fetch --tags gbenchmark > ... > * [new branch] v2 -> gbenchmark/v2 > * [new tag]

Re: [PATCH] git: add -N as a short option for --no-pager

On Wed, Apr 25, 2018 at 09:05:56AM +0900, Junio C Hamano wrote: > Johannes Sixt writes: > > > In modern setups, less, the pager, uses alternate screen to show > > the content. When it is closed, it switches back to the original > > screen, and all content is gone. > > > > It is

Re: [PATCH v2 2/6] grep.c: take column number as argument to show_line()

Ævar Arnfjörð Bjarmason writes: > I think when we add features to git-grep we should be as close to GNU > grep as possible (e.g. not add this -m alias meaning something different > as in your v1), but if GNU grep doesn't have something go with the trend > of other grep tools,

Re: [PATCH 1/2] merge: setup `opts` later in `checkout_fast_forward()`

On Mon, Apr 23, 2018 at 10:13 PM, Martin Ågren wrote: > After we initialize the various fields in `opts` but before we actually > use them, we might return early. Move the initialization further down, > to immediately before we use `opts`. > > This limits the scope of

[PATCH v3] unpack_trees: fix breakage when o->src_index != o->dst_index

Currently, all callers of unpack_trees() set o->src_index == o->dst_index. The code in unpack_trees() does not correctly handle them being different. There are two separate issues: First, there is the possibility of memory corruption. Since unpack_trees() creates a temporary index in o->result

Re: [PATCH 23/41] upload-pack: replace use of several hard-coded constants

On Mon, Apr 23, 2018 at 11:39:33PM +, brian m. carlson wrote: > [snip] > > diff --git a/upload-pack.c b/upload-pack.c > index 4a82602be5..0858527c5b 100644 > --- a/upload-pack.c > +++ b/upload-pack.c > @@ -450,7 +450,7 @@ static int get_common_commits(void) >

Re: [PATCH v8 06/16] sequencer: introduce the `merge` command

Hi Philip, On Mon, 23 Apr 2018, Philip Oakley wrote: > From: "Johannes Schindelin" : Monday, April 23, > 2018 1:03 PM > Subject: Re: [PATCH v8 06/16] sequencer: introduce the `merge` command > > [...] > > > > > > label onto > > > > > > > > # Branch abc > > > > reset

Re: [PATCH v8 08/16] rebase-helper --make-script: introduce a flag to rebase merges

Hi Philip, On Sun, 22 Apr 2018, Philip Oakley wrote: > From: "Johannes Schindelin" > > Sorry for the very late in the series comments.. > > > The sequencer just learned new commands intended to recreate branch > > structure (similar in spirit to --preserve-merges,

Dear Sir/Million Dollar Deal...

Dear Sir Please this is important and very urgent, I am Mr Ahmed Omar, The Director of the Contractors Award and Review Department with the Nigerian national Petroleum Corporation (NNPC). I need your partnership on an urgent transaction of US$55,000,000.00 (Fiftyfive million United Stated Dollars

Re: [PATCH 21/41] http: eliminate hard-coded constants

On 24 April 2018 at 01:39, brian m. carlson wrote: > Use the_hash_algo to find the right size for parsing pack names. > > Signed-off-by: brian m. carlson > --- > http.c | 11 ++- > 1 file changed, 6 insertions(+), 5

Re: [PATCH 31/41] wt-status: convert two uses of EMPTY_TREE_SHA1_HEX

On 24 April 2018 at 01:39, brian m. carlson wrote: > Convert two uses of EMPTY_TREE_SHA1_HEX to use oid_to_hex_r and > the_hash_algo to avoid a dependency on a given hash algorithm. Use > oid_to_hex_r in preference to oid_to_hex because the buffer needs to > last

Re: [PATCH v8 09/16] rebase: introduce the --rebase-merges option

Hi Philip, On Sun, 22 Apr 2018, Philip Oakley wrote: > From: "Johannes Schindelin" > > Once upon a time, this here developer thought: wouldn't it be nice if, > > say, Git for Windows' patches on top of core Git could be represented as > > a thicket of branches, and

Re: [PATCH 1/2] merge: setup `opts` later in `checkout_fast_forward()`

On 24 April 2018 at 08:20, Jacob Keller wrote: > I'm guessing the diff algorithm simply found that this was a more > compact representation of the change? It's a bit confusing when your > description indicates you "moved" some code down, but it looks like > you moved code

Re: Git archeology

Hi Szedar, Thank you for the reply! I didn't expect it could be so instant! I checked 'git log -L' option and it seems to the best one so far. But nevertheless is has a pit fall: I run it like 'git log -L ,:somefile' and get the output that needs manual scraping since each commit spans the whole

  1   2   >