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

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

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

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

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

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

[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

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: 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] 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 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 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 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 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 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 Chris, On Mon, 21 May 2018, Christian Couder wrote: > From: David Turner I vaguely remember that Dave suggested using a different email address these days... *clicketyclick* ah, yes:

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

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

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

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.

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

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

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

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.

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

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

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

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

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

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

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

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

[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

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

Business Proposal

Hello, I am Mr. Alan Austin, I am currently working with Credit suisse Bank London. I saw your contact during my private search and I have a deep believe that you will be very honest, committed and capable of assisting in this business venture. I am an account officer to late Dr. Manzoor

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: [PATCHv4 1/1] git-p4: add unshelve command

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 squashed after getting an ack? t/t9832-unshelve.sh | 23

Re: [PATCH v2] travis-ci: run gcc-8 on linux-gcc jobs

Nguyễn Thái Ngọc Duy writes: > v2 switches from gcc-7 to gcc-8. I initially ignored gcc 8 because it > was too new. But it built 'pu' ok and 8.1 was already out so the > first wave of bugs should have been gone by now. I also liked the choice to ignore v8 for the same

Re: [PATCH] git-p4: add options --commit and --disable-rebase

Luke Diamand writes: > On 9 May 2018 at 16:32, Romain Merland wrote: >> On a daily work with multiple local git branches, the usual way to submit >> only a >> specified commit was to cherry-pick the commit on master then run git-p4 >> submit. >> It can be

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 >

[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

[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

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()`",

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

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

  1   2   >