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 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: [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: 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 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: [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: 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 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

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 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 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 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] 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 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: [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. > >

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

[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: [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 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 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: [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: [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, 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: [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 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

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 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

[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 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 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 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 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 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.

[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 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

[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 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 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 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,

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

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

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

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

[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 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

[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 +

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 +++

[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, /*

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]:

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: [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 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 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 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 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

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 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 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 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 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

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 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 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 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 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 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 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

[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

[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

[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 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 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 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 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

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 v2 0/3] Some add-on patches on top of dj/runtime-prefix

Hi Junio, On Tue, 24 Apr 2018, Junio C Hamano wrote: > Junio C Hamano writes: > > > Junio C Hamano writes: > > > >>> base-commit: b46fe60e1d7235603a29499822493bd3791195da > >> > >> Basing your work on the tip of 'next' is good for discussion, but > >> not

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

On 2018-04-13 01:01 PM, Michał Górny wrote: Currently git does not control mtimes of files being checked out. This means that the only assumption you could make is that all files created or modified within a single checkout action will have mtime between start time and end time of this

Re: [PATCH v3 7/9] commit: add short-circuit to paint_down_to_common()

On 4/23/2018 5:38 PM, Jakub Narebski wrote: Derrick Stolee writes: On 4/18/2018 7:19 PM, Jakub Narebski wrote: Derrick Stolee writes: [...] [...], and this saves time during 'git branch --contains' queries that would otherwise walk "around" the

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

Hi Junio, On Tue, 24 Apr 2018, Junio C Hamano wrote: > Ben Peart writes: > > >> I also had to wonder how "merge -s resolve" faired, if the project > >> is not interested in renamed paths at all. > >> > > > > To be clear, it isn't that we're not interested in detecting

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

Hi Martin, On Tue, 24 Apr 2018, Martin Ågren wrote: > 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

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: Git archeology

Hi Christian, Thank you for the reply. After I got the reply from Szedar I was so excited about git community passion for help. And your reply made me ever more assure in it. Once again thank your for the comprehensive answer. I appreciate Daniel German's research and going to try token based

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

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 25/41] builtin/receive-pack: avoid hard-coded constants for push certs

On 24 April 2018 at 01:39, brian m. carlson wrote: > Use the GIT_SHA1_RAWSZ and GIT_SHA1_HEXSZ macros instead of hard-coding > the constants 20 and 40. Switch one use of 20 with a format specifier > for a hex value to use the hex constant instead, as the original

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 18/41] index-pack: abstract away hash function constant

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. > Specify this value in terms of a value from the_hash_algo. > >

  1   2   >