Re: [PATCH v2 3/3] unpack_trees_options: free messages when done

On 18 May 2018 at 00:10, Junio C Hamano wrote: > Martin Ågren writes: > >> The `opts` string array contains multiple copies of the same pointers. >> Be careful to only free each pointer once, then zeroize the whole array >> so that we do not leave any

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

On Thu, May 17, 2018 at 12:46:51PM -0700, Stefan Beller wrote: > diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt > index bb9f1b7cd82..7b2527b9a19 100644 > --- a/Documentation/diff-options.txt > +++ b/Documentation/diff-options.txt > @@ -292,6 +292,19 @@ dimmed_zebra::

Re: [PATCH v5 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

On Sat, May 12, 2018 at 03:07:04PM +0900, Junio C Hamano wrote: > Taylor Blau writes: > > > I re-read your note and understand more clearly now what your suggestion > > is. To ensure that we're in agreement, do you mean: > > > > 1. '--column -v' will _never_ give a column,

Re: [PATCH v2 13/14] merge: use commit-slab in merge remote desc instead of commit->util

Nguyễn Thái Ngọc Duy writes: > diff --git a/commit.c b/commit.c > index 57049118a5..8202067cd5 100644 > --- a/commit.c > +++ b/commit.c > @@ -1574,13 +1574,21 @@ int commit_tree_extended(const char *msg, size_t > msg_len, > return result; > } > >

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

On Thu, May 17, 2018 at 2:48 PM, Junio C Hamano wrote: > Martin Ågren writes: > >> 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

[PATCH 05/19] commit: add repository argument to read_graft_file

From: Jonathan Nieder Add a repository argument to allow the caller of read_graft_file 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

[PATCH 15/19] cache: convert get_graft_file to handle arbitrary repositories

This conversion was done without the #define trick used in the earlier series refactoring to have better repository access, because this function is easy to review, as all lines are converted and it has only one caller. Signed-off-by: Stefan Beller Signed-off-by: Junio C

[PATCH 09/19] shallow: add repository argument to register_shallow

Add a repository argument to allow callers of register_shallow 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

Re: What's cooking in git.git (May 2018, #02; Thu, 17)

>> Please do not replace what already hit 'next'. > > Here is what I made these two into a relative fix on top. Thanks, I was about to prepare the same.

Re: [PATCH] grep: handle corrupt index files early

Stefan Beller writes: > On Wed, May 16, 2018 at 6:36 PM, Junio C Hamano wrote: >> Duy Nguyen writes: >> >>> With a majority of call sites dying like this though, I wonder if we >>> should just add repo_read_index_or_die() with die()

[PATCH 12/19] commit: convert commit_graft_pos() to handle arbitrary repositories

From: Brandon Williams Signed-off-by: Brandon Williams Signed-off-by: Stefan Beller --- commit.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/commit.c b/commit.c index 684eeaa2ccd..0ec3d22813a 100644 ---

[PATCH 14/19] commit: convert read_graft_file to handle arbitrary repositories

From: Brandon Williams Signed-off-by: Brandon Williams Signed-off-by: Stefan Beller --- commit.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/commit.c b/commit.c index 8a2ab53fc67..3fcb2fd66ce 100644 ---

Re: [PATCH 0/1] Hot fix for js/empty-config-section-fix

Johannes Schindelin writes: > In https://public-inbox.org/git/20180508134248.ga25...@sigill.intra.peff.net/ > Jeff King pointed out that an invalid config section is not an indicator > of a bug, as it is usually provided by the user. > > So we should not throw a fit

[PATCH 01/19] object-store: move object access functions to object-store.h

This should make these functions easier to find and cache.h less overwhelming to read. In particular, this moves: - read_object_file - oid_object_info - write_object_file As a result, most of the codebase needs to #include object-store.h. In this patch the #include is only added to files that

[PATCH 03/19] commit: add repository argument to commit_graft_pos

From: Jonathan Nieder Add a repository argument to allow callers of commit_graft_pos 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

[PATCH 13/19] commit: convert register_commit_graft to handle arbitrary repositories

From: Brandon Williams Signed-off-by: Brandon Williams Signed-off-by: Stefan Beller --- commit.c | 29 +++-- commit.h | 3 +-- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/commit.c

[PATCH 10/19] shallow: add repository argument to check_shallow_file_for_update

Add a repository argument to allow callers of check_shallow_file_for_update 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

Re: What's cooking in git.git (May 2018, #02; Thu, 17)

Junio C Hamano writes: > Stefan Beller writes: > >>> * sb/object-store-replace (2018-05-10) 2 commits >>> (merged to 'next' on 2018-05-16 at 41bbedcc81) >>> + replace-object.c: remove the_repository from prepare_replace_object >>> + object.c: free

[PATCH 00/19] object store: grafts and shallow.

v1: This reroll: * includes the fixup by Ramsay http://public-inbox.org/git/ae96f1c4-add2-d9d8-f08b-a765fe277...@ramsayjones.plus.com * fixes commit messages * changes the macro for the global git_path definitions such that we need fewer characters (omits the duplicates "path_" that were the

[PATCH 02/19] object: move grafts to object parser

From: Jonathan Nieder Grafts are only meaningful in the context of a single repository. Therefore they cannot be global. Signed-off-by: Stefan Beller Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

[PATCH 08/19] shallow: add repository argument to set_alternate_shallow_file

Add a repository argument to allow callers of set_alternate_shallow_file 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

[PATCH 04/19] commit: add repository argument to register_commit_graft

From: Jonathan Nieder Add a repository argument to allow callers of register_commit_graft 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

[PATCH 07/19] commit: add repository argument to lookup_commit_graft

From: Jonathan Nieder Add a repository argument to allow callers of lookup_commit_graft 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

Re: [PATCH 0/8] Reroll of sb/diff-color-move-more

On Thu, 17 May 2018 12:46:45 -0700 Stefan Beller wrote: > Stefan Beller (8): > xdiff/xdiff.h: remove unused flags > xdiff/xdiffi.c: remove unneeded function declarations > diff.c: do not pass diff options as keydata to hashmap > diff.c: adjust hash function signature

[PATCH 06/19] commit: add repository argument to prepare_commit_graft

From: Jonathan Nieder Add a repository argument to allow the caller of prepare_commit_graft 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

[PATCH 18/19] commit: allow prepare_commit_graft to handle arbitrary repositories

Move the global variable 'commit_graft_prepared' into the object pool and convert the function prepare_commit_graft to work an arbitrary repositories. Signed-off-by: Stefan Beller --- commit.c | 14 ++ object.h | 2 ++ 2 files changed, 8 insertions(+), 8

[PATCH 11/19] shallow: add repository argument to is_repository_shallow

Add a repository argument to allow callers of is_repository_shallow 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

[PATCH 17/19] shallow: migrate shallow information into the object parser

We need to convert the shallow functions all at the same time as we move the data structures they operate on into the repository. Signed-off-by: Stefan Beller --- commit.h | 9 +++-- object.c | 3 +++ object.h | 4 shallow.c | 50

[PATCH 16/19] path.c: migrate global git_path_* to take a repository argument

Migrate all git_path_* functions that are defined in path.c to take a repository argument. Unlike other patches in this series, do not use the #define trick, as we rewrite the whole function, which is rather small. This doesn't migrate all the functions, as other builtins have their own local

[PATCH 19/19] commit: allow lookup_commit_graft to handle arbitrary repositories

Signed-off-by: Stefan Beller --- commit.c | 8 commit.h | 3 +-- 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/commit.c b/commit.c index eef1675d692..b01cc0c3e0c 100644 --- a/commit.c +++ b/commit.c @@ -209,14 +209,14 @@ static void

Re: What's cooking in git.git (May 2018, #02; Thu, 17)

On Thu, May 17, 2018 at 3:36 PM, Junio C Hamano wrote: > Stefan Beller writes: > >>> * sb/object-store-replace (2018-05-10) 2 commits >>> (merged to 'next' on 2018-05-16 at 41bbedcc81) >>> + replace-object.c: remove the_repository from

Re: What's cooking in git.git (May 2018, #02; Thu, 17)

Stefan Beller writes: >> * sb/object-store-replace (2018-05-10) 2 commits >> (merged to 'next' on 2018-05-16 at 41bbedcc81) >> + replace-object.c: remove the_repository from prepare_replace_object >> + object.c: free replace map in raw_object_store_clear >> >> Hotfix. >>

Re: Troubles with picking an editor during Git update

Hi Bartosz, On Thu, 17 May 2018, Bartosz Konikiewicz wrote: > I had an issue with Git installer for Windows while trying to update > my instance of the software. My previous version was "git version > 2.15.1.windows.2", while my operating system prompted me to upgrade to > "2.17.0". The

Re: [PATCH v2 3/3] unpack_trees_options: free messages when done

Martin Ågren writes: > The strings allocated in `setup_unpack_trees_porcelain()` are never > freed. Provide a function `clear_unpack_trees_porcelain()` to do so and > call it where we use `setup_unpack_trees_porcelain()`. The only > non-trivial user is

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

Martin Ågren writes: > 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 `opts` and will help a later commit

[PATCH 0/1] Hot fix for js/empty-config-section-fix

In https://public-inbox.org/git/20180508134248.ga25...@sigill.intra.peff.net/ Jeff King pointed out that an invalid config section is not an indicator of a bug, as it is usually provided by the user. So we should not throw a fit and tell the user about a bug that they might even report. Instead,

[PATCH 1/1] config: a user-provided invalid section is not a BUG

This was pointed out by Jeff King while the empty-config-section-fix patch series was cooking, and was not addressed in time for that patch series to advance to `master`. Signed-off-by: Johannes Schindelin --- config.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH 0/2] generating ref-prefixes for configured refspecs

Brandon Williams writes: > Here's my short follow on series to the refspec refactoring. > > When v2 was introduced ref-prefixes were only generated for user > provided refspecs (given via the command line). This means that you can > only benefit from server-side ref filtering

Re: Troubles with picking an editor during Git update

Hi Bartosz, From: "Bartosz Konikiewicz" Hi there! I had an issue with Git installer for Windows while trying to update The Git for Windows package is managed, via https://gitforwindows.org/, as a separate application, based on Git. my instance of the software. My

[PATCH 8/8] diff: color-moved white space handling options imply color-moved

When giving options how move coloring should treat white spaces, the user expects that move coloring is actually active. If it is not active, we can just take the default mode. Signed-off-by: Stefan Beller --- diff.c | 18 +-

[PATCH 6/8] 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 3/8] 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/8] 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 0/8] Reroll of sb/diff-color-move-more

>> * sb/diff-color-move-more (2018-04-25) 7 commits >... >> >> Will merge to 'next'. > >I did not get around to fix it up, there are still review >comments outstanding. (The test is broken in the last commit.) This is a reroll of sb/diff-color-move-more, with the test fixed as well as another

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

This makes the follow up patch easier. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/diff.c b/diff.c index ce7bedc1b92..d1bae900cdc 100644 ---

[PATCH 2/8] 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 Signed-off-by: Junio C Hamano --- xdiff/xdiffi.c | 17 - 1 file changed, 17 deletions(-) diff --git

[PATCH 1/8] 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 Signed-off-by: Junio C Hamano --- xdiff/xdiff.h | 8 1 file changed, 8

[PATCH 5/8] 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] merge-recursive: give notice when submodule commit gets fast-forwarded

From: Leif Middelschulte Inform the user about an automatically fast-forwarded submodule. The silent merge behavior was introduced by commit 68d03e4a6e44 ("Implement automatic fast-forward merge for submodules", 2010-07-07)). Signed-off-by: Leif Middelschulte

[PATCH 2/2] replace-object.c: remove the_repository from prepare_replace_object

This was missed in 5982da9d2ce (replace-object: allow prepare_replace_object to handle arbitrary repositories, 2018-04-11) Technically the code works correctly as the replace_map is the same size in different repositories, however it is hard to read. So convert the code to the familiar pattern of

[PATCH 0/2] Reroll 2 last commits of sb/object-store-replace

>> * sb/object-store-replace (2018-05-10) 2 commits >> (merged to 'next' on 2018-05-16 at 41bbedcc81) >> + replace-object.c: remove the_repository from prepare_replace_object >> + object.c: free replace map in raw_object_store_clear >> >> Hotfix. >> >> Will merge to 'master'. > >Please do

[PATCH 1/2] object.c: free replace map in raw_object_store_clear

The replace map for objects was missed to free in the object store in the conversion of c1274495 ("replace-object: eliminate replace objects prepared flag", 2018-04-11). We also missed to free the replaced objects that are put into the replace map in that whole series. Signed-off-by: Stefan

Re: [PATCH v2 11/12] gc: automatically write commit-graph files

On 11 May 2018 at 23:15, Derrick Stolee wrote: > The commit-graph file is a very helpful feature for speeding up git > operations. In order to make it more useful, write the commit-graph file > by default during standard garbage collection operations. So does it really

Re: What's cooking in git.git (May 2018, #02; Thu, 17)

> * sb/object-store-replace (2018-05-10) 2 commits > (merged to 'next' on 2018-05-16 at 41bbedcc81) > + replace-object.c: remove the_repository from prepare_replace_object > + object.c: free replace map in raw_object_store_clear > > Hotfix. > > Will merge to 'master'. Please do not. (Or do,

Re: [PATCH v2 10/12] commit-graph: add '--reachable' option

On 11 May 2018 at 23:15, Derrick Stolee wrote: > When writing commit-graph files, it can be convenient to ask for all > reachable commits (starting at the ref set) in the resulting file. This > is particularly helpful when writing to stdin is complicated, such as a > future

Re: [PATCH v2 09/12] fsck: verify commit-graph

On 11 May 2018 at 23:15, Derrick Stolee wrote: > If core.commitGraph is true, verify the contents of the commit-graph > during 'git fsck' using the 'git commit-graph verify' subcommand. Run > this check on all alternates, as well. > diff --git a/t/t5318-commit-graph.sh

Re: [PATCH] grep: handle corrupt index files early

On Wed, May 16, 2018 at 6:36 PM, Junio C Hamano wrote: > Duy Nguyen writes: > >> With a majority of call sites dying like this though, I wonder if we >> should just add repo_read_index_or_die() with die() inside. Then the >> next person won't likely

GREETINGS BELOVED

GREETINGS BELOVED I AM BORTE ,I WAS DIAGNOSE WITH OVARIAN CANCER,WHICH DOCTORS HAVE CONFIRMED THAT I HAVE ONLY FEW WEEKS TO LIVE, SO I HAVE DECIDED TO DONATE EVERYTHING I HAVE TO THE ORPHANAGE AND THE POOR WIDOWS THROUGH YOU AND YOUR HELP .PLEASE KINDLY REPLY THROUGH MY PRIVATE BOX

Troubles with picking an editor during Git update

Hi there! I had an issue with Git installer for Windows while trying to update my instance of the software. My previous version was "git version 2.15.1.windows.2", while my operating system prompted me to upgrade to "2.17.0". The installer asked me to "choose the default editor for Git". One of

Re: Generate more revenue from Git

Michal: This is strictly a development list. If you would like to discuss any and all monetization features, please feel free to reach out to me via email. Regards, -K On Thu, May 17, 2018 at 04:45:18PM +0300, Michal Sapozhnikov wrote: Hi, I would like to schedule a quick call this week.

Re: Generate more revenue from Git

Hi, I would like to schedule a quick call this week. What's the best way to schedule a 15 minute call? Thanks, -- Michal Sapozhnikov | Business Manager, Luminati SDK | +972-50-2826778 | Skype: live:michals_43 http://luminati.io/sdk On 10-May-18 14:04, 7d (by eremind) wrote: > > Hi, > > I am

Re: jk/branch-l-0-deprecation (was Re: What's cooking in git.git (May 2018, #02; Thu, 17))

On Thu, May 17, 2018 at 11:48:33AM +0200, Ævar Arnfjörð Bjarmason wrote: > > If there are ample branches, the warning message might be > > hidden out of screen but we shouldn't rely on that, I > > suppose. > > Also if we have lots of branches, depending on your pager

Re: What's cooking in git.git (May 2018, #02; Thu, 17)

On 5/17/2018 2:01 AM, Junio C Hamano wrote: * ds/generation-numbers (2018-05-02) 11 commits - commit-graph.txt: update design document - merge: check config before loading commits - commit: use generation number in remove_redundant() - commit: add short-circuit to paint_down_to_common()

RE: Add option to git to ignore binary files unless force added

On May 16, 2018 11:18 PM, Jacob Keller > On Wed, May 16, 2018 at 5:45 PM, Anmol Sethi wrote: > > I think it’d be great to have an option to have git ignore binary files. My > repositories are always source only, committing a binary is always a mistake. > At the moment, I have to

Good day, how are you today and your family,

Re: [PATCH v2 0/3] unpack_trees_options: free messages when done

On 5/16/2018 5:54 PM, Elijah Newren wrote: Hi Martin, On Wed, May 16, 2018 at 9:30 AM, Martin Ågren wrote: On 16 May 2018 at 16:32, Elijah Newren wrote: On Sat, Apr 28, 2018 at 4:32 AM, Martin Ågren wrote: As you noted

Re: jk/branch-l-0-deprecation (was Re: What's cooking in git.git (May 2018, #02; Thu, 17))

On Thu, May 17 2018, Kaartic Sivaraam wrote: > Hi Ævar, > > On Thursday 17 May 2018 03:18 PM, Ævar Arnfjörð Bjarmason wrote: >> I've ended up with that $LESS setting via hackery over the years, so >> maybe I'm doing something retarded, minimal test case: >> >> PAGER=less LESS="--no-init

Re: jk/branch-l-0-deprecation (was Re: What's cooking in git.git (May 2018, #02; Thu, 17))

Hi Ævar, On Thursday 17 May 2018 03:18 PM, Ævar Arnfjörð Bjarmason wrote: > I've ended up with that $LESS setting via hackery over the years, so > maybe I'm doing something retarded, minimal test case: > > PAGER=less LESS="--no-init --quit-if-one-screen" git branch -l > > ... > > So I

Re: [GSoC] A blog about 'git stash' project

On Thursday 17 May 2018 02:39 PM, Johannes Schindelin wrote: > I have great empathy for the desire to see these bugs fixed. The > conversion must come first, though, and in the interest of making it > easier on me and other reviewers, I must insist on keeping the conversion > free of any changes,

Re: jk/branch-l-0-deprecation (was Re: What's cooking in git.git (May 2018, #02; Thu, 17))

On Thu, May 17 2018, Kaartic Sivaraam wrote: > On Thursday 17 May 2018 11:31 AM, Junio C Hamano wrote: >> * jk/branch-l-0-deprecation (2018-03-26) 3 commits >> >> ... >> >> The "-l" option in "git branch -l" is an unfortunate short-hand for >> "--create-reflog", but many users, both old and

Re: [GSoC] A blog about 'git stash' project

Hi Kaartic, > On Thursday 17 May 2018 12:28 PM, Kaartic Sivaraam wrote: > > > I thought of pointing you to one of the issues with the current > > implementation of 'git stash' which you could probably fix while > > porting it to C. > > > > ... > > > > Forgot to mention about another issue,

Re: [GSoC] A blog about 'git stash' project

On Thursday 17 May 2018 12:28 PM, Kaartic Sivaraam wrote: > Hi Sebi, > > I thought of pointing you to one of the issues with the current > implementation of 'git stash' which you could probably fix while porting > it to C. > > ... > Forgot to mention about another issue, which I consider to be

Re: [GSoC] A blog about 'git stash' project

Hi Sebi, I thought of pointing you to one of the issues with the current implementation of 'git stash' which you could probably fix while porting it to C. It's about stashing untracked files. You could find more information about it in the following mailing list thread:

jk/branch-l-0-deprecation (was Re: What's cooking in git.git (May 2018, #02; Thu, 17))

On Thursday 17 May 2018 11:31 AM, Junio C Hamano wrote: > * jk/branch-l-0-deprecation (2018-03-26) 3 commits > > ... > > The "-l" option in "git branch -l" is an unfortunate short-hand for > "--create-reflog", but many users, both old and new, somehow expect > it to be something else, perhaps

wir bieten 2% Kredite

Sehr geehrte Damen und Herren, Sie brauchen Geld? Sie sind auf der suche nach einem Darlehen? Seriös und unkompliziert? Dann sind Sie hier bei uns genau richtig. Durch unsere jahrelange Erfahrung und kompetente Beratung sind wir Europaweit tätig. Wir bieten jedem ein GÜNSTIGES Darlehen zu TOP

What's cooking in git.git (May 2018, #02; Thu, 17)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. You can find the changes