Re: commit-graph: change in "best" merge-base when ambiguous

On 05/21/2018 08:10 PM, Derrick Stolee wrote: > [...] > In the Discussion section of the `git merge-base` docs [1], we have the > following: > >     When the history involves criss-cross merges, there can be more than > one best common ancestor for two commits. For example, with this topology: >

Re: [PATCH v5 0/4] unpack_trees_options: free messages when done

Junio C Hamano writes: > Martin Ågren writes: > >> I've taken the six patches that Junio has queued and rebuilt the series >> to get rid of the new and possibly bug-prone function that no-one uses >> once the series is over. > > Hmph, this

Re: why does "man git-clean" not mention files ignored by core.excludesFile?

"Robert P. J. Day" writes: > why is there no mention of files ignored via a user's > core.excludesFile configuration? IIUC, core.excludesFile is a much much later invention made long after everybody lost interest in updating "git clean", let alone its documentation.

Re: [PATCH v5 0/4] unpack_trees_options: free messages when done

Martin Ågren writes: > I've taken the six patches that Junio has queued and rebuilt the series > to get rid of the new and possibly bug-prone function that no-one uses > once the series is over. Hmph, this unfortunately depends on 'next', which means we cannot merge it

Re: [PATCH] regex: do not call `regfree()` if compilation fails

On Mon, May 21, 2018 at 2:43 PM, Stefan Beller wrote: > On Sun, May 20, 2018 at 3:50 AM, Martin Ågren wrote: >> It is apparently undefined behavior to call `regfree()` on a regex where >> `regcomp()` failed. [...] >> >> diff --git a/diffcore-pickaxe.c

Re: which files are "known to git"?

Jonathan Nieder writes: > My understanding was the same as Elijah's. > > I would be in favor of a patch that replaces the phrase "known to Git" > in Git's documentation with something less confusing. One possible twist I recall was that normally we only pay attention to the

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

Jeff King writes: >> I haven't really been following all of the discussion but from what I >> can tell the point of this command is to generate a diff based on two >> different versions of a series, so why not call it 'series-diff'? :) > > That's OK with me, though I prefer

Re: [PATCH 00/18] Add `branch-diff`, a `tbdiff` lookalike

Johannes Schindelin writes: >> In the picture, the three pre-context lines that are all indented by >> a HT are prefixed by a SP, and that is prefixed by a '+' sign of the >> outer diff. > > Yep, that's exactly it. > > The way tbdiff did it was to parse the diff and

Re: [PATCH 1/2] remote-curl: accept all encoding supported by curl

Hi, Stefan Beller wrote: > On Mon, May 21, 2018 at 4:40 PM, Brandon Williams wrote: >> Configure curl to accept all encoding which curl supports instead of >> only accepting gzip responses. > > This partially reverts aa90b9697f9 (Enable info/refs gzip decompression > in HTTP

[PATCH v2 4/5] merge-recursive: rename conflict_rename_*() family of functions

These functions were added because processing of these conflicts needed to be deferred until process_entry() in order to get D/F conflicts and such right. The number of these has grown over time, and now include some whose name is misleading: * conflict_rename_normal() is for handling normal

[PATCH v2 5/5] merge-recursive: add pointer about unduly complex looking code

handle_change_delete() has a block of code displaying one of four nearly identical messages. Each contains about half a dozen variable interpolations, which use nearly identical variables as well. Someone trying to parse this may be slowed down trying to parse the differences and why they are

[PATCH v2 0/5] merge-recursive code cleanups

This patch series contains several small code cleanups for merge-recursive. I have removed a couple small cleanup chunks in order to avoid conflicts with any other in-flight topics in pu (namely, nd/commit-util-to-slab and sb/submodule-merge-in-merge-recursive). I may resend those later

[PATCH v2 1/5] merge-recursive: fix miscellaneous grammar error in comment

Signed-off-by: Elijah Newren --- merge-recursive.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/merge-recursive.c b/merge-recursive.c index 35df695fa4..c430fd72bc 100644 --- a/merge-recursive.c +++ b/merge-recursive.c @@ -531,7 +531,7 @@ static void

[PATCH v2 2/5] merge-recursive: fix numerous argument alignment issues

Various refactorings throughout the code have left lots of alignment issues that were driving me crazy; fix them. Acked-by: Johannes Schindelin Signed-off-by: Elijah Newren --- merge-recursive.c | 47 ---

[PATCH v2 3/5] merge-recursive: clarify the rename_dir/RENAME_DIR meaning

We had an enum of rename types which included RENAME_DIR; this name felt misleading since it was not about an entire directory but was a status for each individual file add that occurred within a renamed directory. Since this type is for signifying that the files in question were being renamed

Re: symbol string_list_appendf() unused

On 22/05/18 00:59, Junio C Hamano wrote: > Ramsay Jones writes: > >> I strongly suspect that I haven't followed the discussion on >> the list closely enough, but your 'ma/unpack-trees-free-msgs' >> branch in 'pu', seems to define string_list_appendf() but then >>

Re: [PATCH 1/2] remote-curl: accept all encoding supported by curl

On Mon, May 21, 2018 at 4:40 PM, Brandon Williams wrote: > Configure curl to accept all encoding which curl supports instead of > only accepting gzip responses. This partially reverts aa90b9697f9 (Enable info/refs gzip decompression in HTTP client, 2012-09-19), as that

Re: [PATCH 1/2] remote-curl: accept all encoding supported by curl

Hi, Brandon Williams wrote: > Subject: remote-curl: accept all encoding supported by curl nit: s/encoding/encodings > Configure curl to accept all encoding which curl supports instead of > only accepting gzip responses. Likewise. > This is necessary to fix a bug when using an installation of

Re: symbol string_list_appendf() unused

Ramsay Jones writes: > I strongly suspect that I haven't followed the discussion on > the list closely enough, but your 'ma/unpack-trees-free-msgs' > branch in 'pu', seems to define string_list_appendf() but then > never call it. This is despite commit 40ebd6c7b0

symbol string_list_appendf() unused

Hi Martin, I strongly suspect that I haven't followed the discussion on the list closely enough, but your 'ma/unpack-trees-free-msgs' branch in 'pu', seems to define string_list_appendf() but then never call it. This is despite commit 40ebd6c7b0 ("string-list: provide `string_list_appendf()`",

[PATCH 2/2] remote-curl: accept compressed responses with protocol v2

Configure curl to accept compressed responses when using protocol v2 by setting `CURLOPT_ENCODING` to "", which indicates that curl should send an "Accept-Encoding" header with all supported compression encodings. Signed-off-by: Brandon Williams --- remote-curl.c | 1 + 1

[PATCH 1/2] remote-curl: accept all encoding supported by curl

Configure curl to accept all encoding which curl supports instead of only accepting gzip responses. This is necessary to fix a bug when using an installation of curl which doesn't support gzip. Since curl doesn't do any checking to verify that it supports the encoding set when calling

Re: [PATCH v4 00/28] Hash-independent tests

On Mon, May 21, 2018 at 09:17:39AM -0400, Ben Peart wrote: > Do you plan to update those tests that hard code the SHA of the index file > itself? For example, t1700-split-index.sh has hard coded values for the SHA > and currently only supports different hard coded values for V4 indexes vs >

Re: [RFC PATCH] fetch-pack: space out sent "haves" in negotiation

Hi Jonathan, On Mon, May 21, 2018 at 1:43 PM, Jonathan Tan wrote: > I was thinking about fetch negotiation in some non-ideal situations > (specifically, when the client repo contains two or more independent > branches that meet only somewhere far in the past) and

Re: commit-graph: change in "best" merge-base when ambiguous

On Mon, May 21, 2018 at 2:50 PM, Jeff King wrote: > On Mon, May 21, 2018 at 11:33:11AM -0700, Elijah Newren wrote: > >> > In t6024-recursive-merge.sh, we have the following commit structure: >> > >> > # 1 - A - D - F >> > # \ X / >> > # B X >> > #

Re: commit-graph: change in "best" merge-base when ambiguous

On Mon, May 21, 2018 at 2:54 PM, Jeff King wrote: > Yes, I think this is clearly a case where all of the single merge-bases > we could show are equally good. And I don't think we should promise to > show a particular one, but I _do_ think it's friendly for us to have >

Re: [PATCHv4 1/1] git-p4: add unshelve command

On Tue, May 22, 2018 at 12:09 AM, Luke Diamand wrote: > On 21 May 2018 at 22:39, SZEDER Gábor wrote: >>> diff --git a/t/t9832-unshelve.sh b/t/t9832-unshelve.sh > > ... > ... > >>> +' >> >> This test fails on my box and on Travis CI (in all four standard

Proposal

Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey

Re: [PATCHv4 1/1] git-p4: add unshelve command

On 21 May 2018 at 23:09, Luke Diamand wrote: > On 21 May 2018 at 22:39, SZEDER Gábor wrote: >>> diff --git a/t/t9832-unshelve.sh b/t/t9832-unshelve.sh > > ... > ... > >>> +' >> >> This test fails on my box and on Travis CI (in all four standard Linux >>

Re: [PATCHv4 1/1] git-p4: add unshelve command

On 21 May 2018 at 22:39, SZEDER Gábor wrote: >> diff --git a/t/t9832-unshelve.sh b/t/t9832-unshelve.sh ... ... >> +' > > This test fails on my box and on Travis CI (in all four standard Linux > and OSX build jobs) with: > > + cd /home/szeder/src/git/t/trash

Re: commit-graph: change in "best" merge-base when ambiguous

On Mon, May 21, 2018 at 02:10:54PM -0400, Derrick Stolee wrote: > In the Discussion section of the `git merge-base` docs [1], we have the > following: > >     When the history involves criss-cross merges, there can be more than one > best common ancestor for two commits. For example, with this

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

On Mon, May 21, 2018 at 02:40:57PM -0700, Brandon Williams wrote: > > > > Most fellow German software engineers (who seem to have a knack for > > > > idiotically long variable/function names) would now probably suggest: > > > > > > > > git compare-patch-series-with-revised-patch-series >

Re: commit-graph: change in "best" merge-base when ambiguous

On Mon, May 21, 2018 at 11:33:11AM -0700, Elijah Newren wrote: > > In t6024-recursive-merge.sh, we have the following commit structure: > > > > # 1 - A - D - F > > # \ X / > > # B X > > # X \ > > # 2 - C - E - G > > > > When merging F to G, there are two

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

On Mon, May 21, 2018 at 2:40 PM, Brandon Williams wrote: revised-compare >> > >> > diff-revise > > I haven't really been following all of the discussion but from what I > can tell the point of this command is to generate a diff based on two > different versions of a series,

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

On 05/21, Jeff King wrote: > On Mon, May 21, 2018 at 10:56:47AM -0700, Stefan Beller wrote: > > > > It is very much about > > > comparing two *ranges of* revisions, and not just any ranges, no. Those > > > ranges need to be so related as to contain mostly identical changes. > > > > range-diff,

Re: [PATCHv4 1/1] git-p4: add unshelve command

> diff --git a/t/t9832-unshelve.sh b/t/t9832-unshelve.sh > new file mode 100755 > index 00..cca2dec536 > --- /dev/null > +++ b/t/t9832-unshelve.sh > @@ -0,0 +1,153 @@ > +#!/bin/sh > + > +last_shelved_change() { > + p4 changes -s shelved -m1 | cut -d " " -f 2 > +} > + >

Re: [PATCH v5 0/4] unpack_trees_options: free messages when done

On Mon, May 21, 2018 at 04:54:24PM +0200, Martin Ågren wrote: > That is, I've replaced the `string_list_appendf()`-patch with Junio's > `argv_push*()`-patch, then squashed Junio's "redoing the 4/4"-patch into > patch 4/4 -- with the exception of keeping the `memset(opts->msgs, ...)` > which I

Re: [PATCH 1/5] http: use strbufs instead of fixed buffers

On Mon, May 21, 2018 at 12:41 PM, Jeff King wrote: > On Mon, May 21, 2018 at 11:11:51AM -0700, Stefan Beller wrote: > >> Hi Jeff, >> >> On Fri, May 18, 2018 at 6:56 PM, Jeff King wrote: >> >> > @@ -2421,4 +2426,5 @@ void release_http_object_request(struct >> >

[RFC PATCH] fetch-pack: space out sent "haves" in negotiation

I was thinking about fetch negotiation in some non-ideal situations (specifically, when the client repo contains two or more independent branches that meet only somewhere far in the past) and thought about skipping over intermediate commits, using exponentially larger skips as we proceed, when

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

On Mon, May 21, 2018 at 10:56:47AM -0700, Stefan Beller wrote: > > It is very much about > > comparing two *ranges of* revisions, and not just any ranges, no. Those > > ranges need to be so related as to contain mostly identical changes. > > range-diff, eh? > > > Most fellow German software

Re: [PATCH 1/5] http: use strbufs instead of fixed buffers

On Mon, May 21, 2018 at 11:11:51AM -0700, Stefan Beller wrote: > Hi Jeff, > > On Fri, May 18, 2018 at 6:56 PM, Jeff King wrote: > > > @@ -2421,4 +2426,5 @@ void release_http_object_request(struct > > http_object_request *freq) > .. > > + strbuf_release(>tmpfile); > > Do

Re: [PATCH] t: make many tests depend less on the refs being files

On Sun, May 20, 2018 at 10:51 PM, Christian Couder wrote: > From: David Turner > > So that they work under alternate ref storage backends. Sometimes I have a disconnect between the subject and the commit message, (e.g. in an email reader the

Re: [PATCH 02/11] repository: introduce repo_read_index_or_die

Hi Brandon, >> One of the reviewers of the series questioned the overall goal of the >> series as we want to move away from _die() in top level code but this >> series moves more towards it. > > I've heard every once in a while that we want to move toward this but I > don't believe there is an

Re: [RFC/PATCH 1/7] rerere: unify error message when read_cache fails

On Sun, May 20, 2018 at 2:12 PM, Thomas Gummerer wrote: > We have multiple different variants of the error message we show to > the user if 'read_cache' fails. The "Could not read index" variant we > are using in 'rerere.c' is currently not used anywhere in translated >

Re: [PATCH v2 03/12] commit-graph: test that 'verify' finds corruption

Derrick Stolee writes: > Add test cases to t5318-commit-graph.sh that corrupt the commit-graph > file and check that the 'git commit-graph verify' command fails. These > tests verify the header and chunk information is checked carefully. > > Helped-by: Martin Ågren

Re: [PATCH 02/11] repository: introduce repo_read_index_or_die

On 05/21, Stefan Beller wrote: > On Fri, May 18, 2018 at 11:37 PM, Duy Nguyen wrote: > > On Wed, May 16, 2018 at 03:21:09PM -0700, Stefan Beller wrote: > >> A common pattern with the repo_read_index function is to die if the return > >> of repo_read_index is negative. Move

Re: [PATCH 07/11] rerere: use repo_read_index_or_die

Hi Thomas, On Sun, May 20, 2018 at 10:45 AM, Thomas Gummerer wrote: > On 05/16, Stefan Beller wrote: >> By switching to repo_read_index_or_die, we'll get a slightly different >> error message ("index file corrupt") as well as localization of it. > > Apart from the slightly

Re: [PATCH] regex: do not call `regfree()` if compilation fails

On Sun, May 20, 2018 at 3:50 AM, Martin Ågren wrote: > It is apparently undefined behavior to call `regfree()` on a regex where > `regcomp()` failed. The language in [1] is a bit muddy, at least to me, > but the clearest hint is this (`preg` is the `regex_t *`): > >

Re: [PATCH 02/11] repository: introduce repo_read_index_or_die

On Fri, May 18, 2018 at 11:37 PM, Duy Nguyen wrote: > On Wed, May 16, 2018 at 03:21:09PM -0700, Stefan Beller wrote: >> A common pattern with the repo_read_index function is to die if the return >> of repo_read_index is negative. Move this pattern into a function. >> >> This

Re: commit-graph: change in "best" merge-base when ambiguous

Hi, On Mon, May 21, 2018 at 11:10 AM, Derrick Stolee wrote: > Hello all, > > While working on the commit-graph feature, I made a test commit that sets > core.commitGraph and gc.commitGraph to true by default AND runs 'git > commit-graph write --reachable' after each 'git

Re: which files are "known to git"?

On Mon, 21 May 2018, Elijah Newren wrote: > > can anyone refresh my memory if that happened here, and whether > > that was the consensus after the discussion was over? > > Perhaps this: > https://public-inbox.org/git/EEC5BA1D5F274F02AE20FC269868FDEF@PhilipOakley/ > ? yup, that's it, thanks.

Re: which files are "known to git"?

On Mon, May 21, 2018 at 10:40 AM, Robert P. J. Day wrote: > On Mon, 21 May 2018, Elijah Newren wrote: > >> Hi Robert, >> >> I had always assumed prior to your email that 'known to Git' meant >> 'tracked' or 'recorded in the index'... > > i *know* i've been in this

Re: which files are "known to git"?

Hi, Robert P. J. Day wrote: > i did a quick search for that phrase in the current code base and > came up with: > > builtin/difftool.c: /* The symlink is unknown to Git so read from > the filesystem */ > dir.c:error("pathspec '%s' did not match any file(s) known to

Re: which files are "known to git"?

On Mon, May 21, 2018 at 10:40 AM, Robert P. J. Day wrote: > On Mon, 21 May 2018, Elijah Newren wrote: > >> I had always assumed prior to your email that 'known to Git' meant >> 'tracked' or 'recorded in the index'... > > i *know* i've been in this discussion before, but i

Re: [PATCH 1/5] http: use strbufs instead of fixed buffers

Hi Jeff, On Fri, May 18, 2018 at 6:56 PM, Jeff King wrote: > @@ -2421,4 +2426,5 @@ void release_http_object_request(struct > http_object_request *freq) .. > + strbuf_release(>tmpfile); Do we need an equivalent in release_http_pack_request as well?

commit-graph: change in "best" merge-base when ambiguous

Hello all, While working on the commit-graph feature, I made a test commit that sets core.commitGraph and gc.commitGraph to true by default AND runs 'git commit-graph write --reachable' after each 'git commit' command. This helped me find instances in the test suite where the commit-graph

Re: which files are "known to git"?

On Mon, 21 May 2018, Jonathan Nieder wrote: > Robert P. J. Day wrote: > > On Mon, 21 May 2018, Elijah Newren wrote: > > >> Hi Robert, > >> > >> I had always assumed prior to your email that 'known to Git' > >> meant 'tracked' or 'recorded in the index'... > > > > i *know* i've been in this

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

Hi Johannes, >> (2) git diff --branch topic-v1...topic-v2 > > From my point of view, `git diff --branch` indicates that I diff > *branches*. Which is not really something that makes sense, and definitely > not what this command is about. > > We are not comparing branches. > > We are comparing

Re: which files are "known to git"?

Robert P. J. Day wrote: > On Mon, 21 May 2018, Elijah Newren wrote: >> Hi Robert, >> >> I had always assumed prior to your email that 'known to Git' meant >> 'tracked' or 'recorded in the index'... > > i *know* i've been in this discussion before, but i don't remember > where, i *assume* it was

Re: which files are "known to git"?

On Mon, 21 May 2018, Elijah Newren wrote: > Hi Robert, > > I had always assumed prior to your email that 'known to Git' meant > 'tracked' or 'recorded in the index'... i *know* i've been in this discussion before, but i don't remember where, i *assume* it was on this list, and i recall someone

Bug in update-index man page

I've noticed the following text in the documentation pages for the `update-index` command: Files to act on. Note that files beginning with . are discarded. This includes ./file and dir/./file. If you don't want this, then use cleaner names. The same applies to

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

>> Many tests hardcode the raw object names, which would change once >> we migrate away from SHA-1. While some of them must test against >> exact object names, most of them do not have to use hardcoded >> constants in the test. The latter kind of tests have been updated >> to test the moral

Re: [PATCH 5/5] merge-recursive: simplify handle_change_delete

Hi Dscho, On Mon, May 21, 2018 at 6:41 AM, Johannes Schindelin wrote: > On Sat, 19 May 2018, Elijah Newren wrote: >> On Sat, May 19, 2018 at 12:32 AM, Johannes Sixt wrote: >> > >> > Oh, there is a reason for the repeated message text: translations!

Re: issues(?) installing git-lfs via fedora "dnf" command

On Mon, 21 May 2018, Jonathan Nieder wrote: > Hi, > > Robert P. J. Day wrote: > > On Mon, 21 May 2018, Jonathan Nieder wrote: > > >> The packager should be able to find out whether it's an issue in > >> git-lfs upstream and report it to that project if it is. Git-lfs is > >> not part of git.git;

Re: issues(?) installing git-lfs via fedora "dnf" command

Hi, Robert P. J. Day wrote: > On Mon, 21 May 2018, Jonathan Nieder wrote: >> The packager should be able to find out whether it's an issue in >> git-lfs upstream and report it to that project if it is. Git-lfs is >> not part of git.git; it's a separate project: >>

Re: issues(?) installing git-lfs via fedora "dnf" command

On Mon, 21 May 2018, Jonathan Nieder wrote: > Robert P. J. Day wrote: > > > $ sudo dnf install git-lfs > [...] > > Running transaction > > Preparing: > > Installing : git-lfs-2.4.0-1.fc28.x86_64 > > Running scriptlet: git-lfs-2.4.0-1.fc28.x86_64 > > Error: Failed

Re: issues(?) installing git-lfs via fedora "dnf" command

Robert P. J. Day wrote: > $ sudo dnf install git-lfs [...] > Running transaction > Preparing: > Installing : git-lfs-2.4.0-1.fc28.x86_64 > Running scriptlet: git-lfs-2.4.0-1.fc28.x86_64 > Error: Failed to call git rev-parse --git-dir --show-toplevel: "fatal: >

Re: [PATCH 2/5] merge-recursive: fix numerous argument alignment issues

Hi Dscho, On Mon, May 21, 2018 at 6:42 AM, Johannes Schindelin wrote: > Hi Elijah, > > On Fri, 18 May 2018, Elijah Newren wrote: > >> Various refactorings throughout the code have left lots of alignment >> issues that were driving me crazy; fix them. > > I hope you

why does "man git-clean" not mention files ignored by core.excludesFile?

sort of related to my previous post, but in "man git-clean", one reads: -e , --exclude= In addition to those found in .gitignore (per directory) and $GIT_DIR/info/exclude, also consider these patterns to be in the set of the ignore rules in effect. -x Don’t use the

Re: which files are "known to git"?

On Tue, May 22, 2018 at 12:09 AM, Elijah Newren wrote: > > I had always assumed prior to your email that 'known to Git' meant > 'tracked' or 'recorded in the index'. That's been my intention as well ;-) > From Documentation/git-clean.txt: > > Normally, only files unknown

Re: which files are "known to git"?

On Mon, 21 May 2018, Elijah Newren wrote: > Hi Robert, > I had always assumed prior to your email that 'known to Git' meant > 'tracked' or 'recorded in the index'. However, a quick `git grep -i > known.to.git` shows that we're actually not consistent by what we > mean with this phrase. A

Re: which files are "known to git"?

On Mon, 21 May 2018, Elijah Newren wrote: > Hi Robert, > > On Mon, May 21, 2018 at 4:18 AM, Robert P. J. Day > wrote: > > > > updating my git courseware and, since some man pages refer to files > > "known to git", i just want to make sure i understand precisely which >

Re: which files are "known to git"?

On Mon, May 21, 2018 at 5:09 PM, Elijah Newren wrote: > Robert, since you're working on documentation of sorts anyway, would > you like to propose some patches to fix things here? I'm not entirely > sure what to suggest, and we might need a random suggestion to get the >

Re: which files are "known to git"?

Hi Robert, On Mon, May 21, 2018 at 4:18 AM, Robert P. J. Day wrote: > > updating my git courseware and, since some man pages refer to files > "known to git", i just want to make sure i understand precisely which > files those are. AIUI, they would include: > > *

Re: [PATCHv4 1/1] git-p4: add unshelve command

On 21 May 2018 at 08:07, Junio C Hamano wrote: > SZEDER Gábor writes: > >>> diff --git a/t/t9832-unshelve.sh b/t/t9832-unshelve.sh >>> new file mode 100755 >>> index 00..cca2dec536 > > ... in short, I'd queue a fix-up on top like this to be later

[PATCH v5 3/4] argv-array: return the pushed string from argv_push*()

From: Junio C Hamano Such an API change allows us to use an argv_array this way: struct argv_array to_free = ARGV_ARRAY_INIT; const char *msg; if (some condition) { msg = "constant string message"; ... other logic ...

[PATCH v5 2/4] merge-recursive: provide pair of `unpack_trees_{start,finish}()`

From: Elijah Newren Rename `git_merge_trees()` to `unpack_trees_start()` and extract the call to `discard_index()` into a new function `unpack_trees_finish()`. As a result, these are called early resp. late in `merge_trees()`, making the resource handling clearer. A later

[PATCH v5 4/4] unpack_trees_options: free messages when done

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 `unpack_trees_start()`, where we should place the new call in

[PATCH v5 1/4] merge: setup `opts` later in `checkout_fast_forward()`

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 fix a memory leak without having to worry about those

[PATCH v5 0/4] unpack_trees_options: free messages when done

On 21 May 2018 at 02:25, Junio C Hamano wrote: > Junio C Hamano writes: > >> I have a feeling that argv_array might be a better fit for the >> purpose of keeping track of to_free[] strings in the context of this >> series. Moving away from string_list would

Re: [PATCH 4/5] merge-recursive: rename conflict_rename_*() family of functions

Hi Elijah, On Fri, 18 May 2018, Elijah Newren wrote: > These functions were added because processing of these conflicts needed > to be deferred until process_entry() in order to get D/F conflicts and > such right. The number of these has grown over time, and now include > some whose name is

Re: [PATCH 3/5] merge-recursive: clarify the rename_dir/RENAME_DIR meaning

Hi Elijah, On Fri, 18 May 2018, Elijah Newren wrote: > We had an enum of rename types which included RENAME_DIR; this name felt > misleading since it was not about an entire directory but was a status for > each individual file add that occurred within a renamed directory. Since > this type is

RE: which files are "known to git"?

On May 21, 2018 7:19 AM, Robert P. J. Day: > updating my git courseware and, since some man pages refer to files > "known to git", i just want to make sure i understand precisely which files > those are. AIUI, they would include: > > * tracked files > * ignored files > * new files which

Re: [PATCH 2/5] merge-recursive: fix numerous argument alignment issues

Hi Elijah, On Fri, 18 May 2018, Elijah Newren wrote: > Various refactorings throughout the code have left lots of alignment > issues that were driving me crazy; fix them. I hope you did not do that manually. What is your code formatting tool of choice? The patch looks obviously good to me.

Re: [PATCH 5/5] merge-recursive: simplify handle_change_delete

Hi Elijah, On Sat, 19 May 2018, Elijah Newren wrote: > On Sat, May 19, 2018 at 12:32 AM, Johannes Sixt wrote: > > Am 19.05.2018 um 04:07 schrieb Elijah Newren: > >> > >> There is really no need for four branches of nearly identical messages > >> when we can store the differences

Re: [PATCH v4 00/28] Hash-independent tests

On 5/20/2018 10:01 PM, brian m. carlson wrote: This is part 2 in the series to make tests hash independent. Do you plan to update those tests that hard code the SHA of the index file itself? For example, t1700-split-index.sh has hard coded values for the SHA and currently only supports

Re: [PATCH] t: make many tests depend less on the refs being files

Hi, of course I messed up and did not fix the Cc: list... now fixed ;-) On Mon, 21 May 2018, Johannes Schindelin wrote: > Hi Chris, > > On Mon, 21 May 2018, Christian Couder wrote: > > > From: David Turner > > I vaguely remember that Dave suggested using a

Re: [PATCH 3/5] query_fsmonitor: use xsnprintf for formatting integers

On 5/19/2018 4:27 AM, René Scharfe wrote: Am 19.05.2018 um 03:57 schrieb Jeff King: These formatted integers should always fit into their 64-byte buffers. Let's use xsnprintf() to add an assertion that this is the case, which makes auditing for other unchecked snprintfs() easier. How about

Re: [PATCH] t: make many tests depend less on the refs being files

Hi Dscho, On Mon, May 21, 2018 at 11:41 AM, Johannes Schindelin wrote: > > On Mon, 21 May 2018, Christian Couder wrote: > >> From: David Turner > > I vaguely remember that Dave suggested using a different email address > these days... > >

Re: [PATCH 0/2] Test improvements for 'sg/complete-paths'

Hi Junio, On Mon, 21 May 2018, Johannes Schindelin wrote: > On Fri, 18 May 2018, SZEDER Gábor wrote: > > > > > So, I think for v2 I will rewrite these tests to call > > > > __git_complete_index_file() directly instead of using > > > > 'test_completion', and will include a test with spaces in

Re: [PATCH 2/2] t9902-completion: exercise __git_complete_index_file() directly

Hi Gábor, On Fri, 18 May 2018, SZEDER Gábor wrote: > The tests added in 2f271cd9cf (t9902-completion: add tests > demonstrating issues with quoted pathnames, 2018-05-08) and in > 2ab6eab4fe (completion: improve handling quoted paths in 'git > ls-files's output, 2018-03-28) have a few

Re: [PATCH] t: make many tests depend less on the refs being files

> > diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh > > index 8f5c811dd7..c3b89ae783 100755 > > --- a/t/t9903-bash-prompt.sh > > +++ b/t/t9903-bash-prompt.sh > > @@ -148,7 +148,7 @@ test_expect_success 'prompt - inside .git directory' ' > > test_expect_success 'prompt - deep inside

Re: [PATCH 0/2] Test improvements for 'sg/complete-paths'

Hi Gábor, On Fri, 18 May 2018, SZEDER Gábor wrote: > > > So, I think for v2 I will rewrite these tests to call > > > __git_complete_index_file() directly instead of using > > > 'test_completion', and will include a test with spaces in path > > > names. > > > > Quite well thought-out reasoning.

which files are "known to git"?

updating my git courseware and, since some man pages refer to files "known to git", i just want to make sure i understand precisely which files those are. AIUI, they would include: * tracked files * ignored files * new files which have been staged but not yet committed is that it? are

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

Hi Junio, On Tue, 8 May 2018, Junio C Hamano wrote: > Johannes Schindelin writes: > > > It would be easy to introduce, but I am wary about its usefulness. > > Unless you re-generate the branch from patches (which I guess you do a > > lot, but I don't), you are

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

Hi Buga, On Mon, 7 May 2018, Igor Djordjevic wrote: > On 07/05/2018 09:48, Jeff King wrote: > > > > > > Let's, please, not fall into the trap of polluting git-branch with > > > > utterly unrelated functionality, as has happened a few times with > > > > other Git commands. Let's especially not

issues(?) installing git-lfs via fedora "dnf" command

first, i realize this is almost entirely a fedora packaging issue and i'm planning on reporting it there, but i just want to make sure i'm not doing something stupid. knowing nothing about the git-lfs package, i thought i would install it and just poke around out of sheer curiosity, so on my

Opt-in MSPs Contact List

"Hi there, Hope this mail finds you well. I am writing this email to inform you that we have fresh updated Managed Service Providers-(MSPs) contacts to increase your 2018 sales. You can use these database for direct mailing campaigns, email campaigns, cold calling, and to share

Re: [PATCH 01/18] Add a function to solve least-cost assignment problems

Hi Duy, On Sun, 13 May 2018, Duy Nguyen wrote: > On Thu, May 3, 2018 at 5:30 PM, Johannes Schindelin > wrote: > > + /* reduction transfer */ > > + free_row = xmalloc(sizeof(int) * row_count); > > + for (int i = 0; i < row_count; i++) { > > travis

Re: [PATCH 00/18] Add `branch-diff`, a `tbdiff` lookalike

Hi Junio, On Mon, 21 May 2018, Junio C Hamano wrote: > I've been using both branch-diff and tbdiff while comparing rerolled > topics before accepting them. One obvious difference between the two is > that the speed to compute pairing is quite different but that is > expected ;-) Yep. It is

  1   2   >