On Fri, Dec 07, 2018 at 01:50:57PM -0800, biswaranjan panda wrote:
> Thanks Jeff and Bryan! However, I am curious that if there were a way
> to tell git blame to skip a commit (the one which added the file again
> and maybe the one which deleted it originally) while it walks back
> through
On Fri, Dec 07, 2018 at 07:09:58PM -0500, George King wrote:
> My goal is to detect SGR color sequences, e.g. '\x1b[32m', that exist
> in the source text, and have my highlighter print escaped
> representations of those. For example, I have checked in files that
> are expected test outputs for
On Thu, Dec 06, 2018 at 12:20:54PM -0800, Josh Steadmon wrote:
> diff --git a/commit-graph.c b/commit-graph.c
> index 07dd410f3c..224a5f161e 100644
> --- a/commit-graph.c
> +++ b/commit-graph.c
> @@ -165,10 +165,20 @@ struct commit_graph *parse_commit_graph(void
> *graph_map, int fd,
>
On Thu, Dec 06, 2018 at 03:54:46PM -0800, Jonathan Tan wrote:
> This makes sense - I thought I shouldn't mention the commit graph in the
> code since it seems like a layering violation, but I felt the need to
> mention commit graph in a comment, so maybe the need to mention commit
> graph in the
On Thu, Dec 06, 2018 at 11:07:00PM -0800, biswaranjan panda wrote:
> Thanks! Strangely git log --follow does work.
I suspect it would work even without --follow. When you limit a log
traversal with a pathspec, like:
git log foo
that is not about following some continuous stream of content,
On Fri, Dec 07, 2018 at 12:10:05AM +0100, SZEDER Gábor wrote:
> On Wed, Dec 05, 2018 at 04:56:21PM -0500, Jeff King wrote:
> > Could we just kill them all?
> >
> > I guess it's a little tricky, because $! is going to give us the pid of
> > each subshell. We actuall
On Thu, Dec 06, 2018 at 11:56:01PM +0100, SZEDER Gábor wrote:
> > +test_expect_success 'roll those dice' '
> > + case "$(openssl rand -base64 1)" in
> > + z*)
> > + return 1
> > + esac
> > +'
>
> Wasteful :)
>
> test $(($$ % 42)) -ne 0
Oh, indeed, that is much more clever. :)
Registration is now open for the Contributor Summit at Git Merge. To
recap from my earlier announcement[1]:
When: Thursday, January 31, 2019. 10am-5pm.
Where: The Egg[2], Brussels, Belgium
What: Round-table discussion about Git
Who: All contributors to Git or related projects in the Git
On Thu, Dec 06, 2018 at 10:17:24AM +0100, Ævar Arnfjörð Bjarmason wrote:
> > The other major user of that feature I can think of is LFS. There Git
> > ends up diffing the LFS pointers, not the big files. Which arguably is
> > the wrong thing (you'd prefer to see the actual file contents diffed),
On Wed, Dec 05, 2018 at 11:42:09PM +, Coiner, John wrote:
> > For instance, Git is very eager to try to find delta-compression
> > opportunities between objects, even if they don't have any relationship
> > within the tree structure. So imagine I want to know the contents of
> > tree X. I
On Thu, Dec 06, 2018 at 10:08:57AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > In my opinion this feature is so contrary to Git's general assumptions
> > that it's likely to create a ton of information leaks of the supposedly
> > protected data.
> > ..
On Thu, Dec 06, 2018 at 09:22:23AM +0900, Junio C Hamano wrote:
> > So the right number of waits is either "1" or "2". Looping means we do
> > too many (which is mostly a harmless noop) or too few (in the off chance
> > that you have only a single job ;) ). So it works out in practice.
>
> Well,
On Wed, Dec 05, 2018 at 01:20:35PM +0100, SZEDER Gábor wrote:
> On Wed, Dec 05, 2018 at 12:17:09AM -0500, Jeff King wrote:
> > On Tue, Dec 04, 2018 at 05:34:56PM +0100, SZEDER Gábor wrote:
> >
> > > Several test scripts run daemons like 'git-daemon' or Apache, and
>
On Wed, Dec 05, 2018 at 03:01:06PM +0100, SZEDER Gábor wrote:
> > > - Make '--stress' imply '--verbose-log' and discard the test's
> > > standard ouput and error; dumping the output of several parallel
> > > tests to the terminal would create a big ugly mess.
> >
> > Makes sense. My
On Wed, Dec 05, 2018 at 11:34:54AM +0100, SZEDER Gábor wrote:
>
> Just a quick reply to this one point for now:
>
> On Wed, Dec 05, 2018 at 12:44:09AM -0500, Jeff King wrote:
> > On Tue, Dec 04, 2018 at 05:34:57PM +0100, SZEDER Gábor wrote:
> > > + job_nr=0
>
On Wed, Dec 05, 2018 at 08:13:16PM +, Coiner, John wrote:
> One obstacle to moving AMD to git/VFSForGit is the lack of access
> control support in git. AMD has a lot of data whose distribution must be
> limited. Sometimes it's a legal requirement, eg. CPU core designs are
> covered by US
On Wed, Dec 05, 2018 at 07:41:44PM +0100, René Scharfe wrote:
> > If we start to convert those, there's a
> > little bit of a rabbit hole, but it's actually not too bad.
>
> You don't need to crawl in just for quick_has_loose(), but eventually
> everything has to be converted. It seems a bit
On Wed, Dec 05, 2018 at 01:51:36AM -0500, Jeff King wrote:
> > This
> > function is easily converted to struct object_id, though, as its single
> > caller can pass one on -- this makes the copy unnecessary.
>
> If you mean modifying sha1_loose_object_info() to take an o
On Wed, Dec 05, 2018 at 07:02:17AM +0100, René Scharfe wrote:
> > I actually wrote it that way initially, but doing the hashcpy() in the
> > caller is a bit more awkward. My thought was to punt on that until the
> > rest of the surrounding code starts handling oids.
>
> The level of awkwardness
On Wed, Dec 05, 2018 at 12:35:08PM +0900, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > Since 26125f6b9b ("detect broken alternates.", 2006-02-22) we've
> > emitted an error if the alternates directory doesn't exist, but not
> > for the common misstep of adding a path to
On Wed, Dec 05, 2018 at 12:37:58PM +0900, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > Change the "error" message emitted by alt_odb_usable() to be a
> > "warning" instead. As noted in commits leading up to this one this has
> > never impacted the exit code ever since the
On Tue, Dec 04, 2018 at 07:11:08PM +0100, Ævar Arnfjörð Bjarmason wrote:
> It's a frequent annoyance of mine in the test suite that I'm
> e.g. running t*.sh with some parallel "prove" in one screen, and then I
> run tABCD*.sh manually, and get unlucky because they use the same trash
> dir, and
On Tue, Dec 04, 2018 at 06:04:14PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Tue, Dec 04 2018, SZEDER Gábor wrote:
>
> > The number of parallel invocations is determined by, in order of
> > precedence: the number specified as '--stress=', or the value of
> > the GIT_TEST_STRESS_LOAD
On Tue, Dec 04, 2018 at 05:34:57PM +0100, SZEDER Gábor wrote:
> To prevent the several parallel invocations of the same test from
> interfering with each other:
>
> - Include the parallel job's number in the name of the trash
> directory and the various output files under 't/test-results/'
On Tue, Dec 04, 2018 at 05:34:56PM +0100, SZEDER Gábor wrote:
> Several test scripts run daemons like 'git-daemon' or Apache, and
> communicate with them through TCP sockets. To have unique ports where
> these daemons are accessible, the ports are usually the number of the
> corresponding test
On Tue, Dec 04, 2018 at 05:34:55PM +0100, SZEDER Gábor wrote:
> There are two places where we strip off any leading path components
> and the '.sh' suffix from the test script's pathname, and there are
> two places where we construct the filename of test output files in
> 't/test-results/'. The
On Tue, Dec 04, 2018 at 02:42:38PM -0800, Jonathan Tan wrote:
> diff --git a/revision.c b/revision.c
> index b5108b75ab..e7da2c57ab 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -212,7 +212,20 @@ static struct object *get_reference(struct rev_info
> *revs, const char *name,
> {
>
On Tue, Dec 04, 2018 at 10:45:13PM +0100, René Scharfe wrote:
> > The comment in the context there is warning callers to remember to load
> > the cache first. Now that we have individual caches, might it make sense
> > to change the interface a bit, and make these members private. I.e.,
> >
On Tue, Dec 04, 2018 at 06:48:22PM -0800, Stefan Beller wrote:
> > Perhaps we should note this more prominently, and since Brandon isn't at
> > Google anymore can some of you working there edit this post? It's the
> > first Google result for "git protocol v2", so it's going to be quite
> >
On Mon, Nov 26, 2018 at 09:03:37PM +0100, SZEDER Gábor wrote:
> Test scripts checking 'git daemon' stop the daemon with a TERM signal,
> and the 'stop_git_daemon' helper checks the daemon's exit status to
> make sure that it indeed died because of that signal.
>
> This check is bogus since
On Mon, Dec 03, 2018 at 08:19:12PM -0800, Jamie Zawinski wrote:
> On Dec 3, 2018, at 8:09 PM, Jeff King wrote:
> >
> > but it works fine. Might there be some effective-uid trickiness with the
> > way the server side of git is invoked? Or is this a network mount where
&
On Mon, Dec 03, 2018 at 07:27:13PM -0800, Jamie Zawinski wrote:
> I think sharedrepository=group stopped working some time between
> 2.10.5 (works) and 2.12.4 (does not). 2.19.2 also does not.
Hmm. Given the time-frame and the fact that your strace shows problems
writing into the
On Mon, Dec 03, 2018 at 02:30:44PM -0800, Matthew DeVore wrote:
> Here is a one-liner to do it. It is Perl line noise, so it's not very cute,
> thought that is subjective. The output shown below is for the Git project
> (not Linux) repository as I've currently synced it:
>
> $ git rev-list
On Mon, Dec 03, 2018 at 02:10:19PM -0800, Matthew DeVore wrote:
> Put the allow_exclude_promisor_objects flag in setup_revision_opt. When
> it was in rev_info, it was unclear when it was used, since rev_info is
> passed to functions that don't use the flag. This resulted in
> unnecessary setting
On Sun, Dec 02, 2018 at 09:07:47PM +1100, Robert White wrote:
> `git log --pretty short` gives the error message "ambiguous argument
> 'short'". To get the expected result, you need to use `git log
> --pretty=short`. However, `git log --since yesterday` and `git log
> --since=yesterday` both work
On Sun, Dec 02, 2018 at 11:52:50AM +0100, René Scharfe wrote:
> > And for mu.git, a ~20k object repo:
> >
> > Test origin/master
> > peff/jk/loose-cache avar/check-collisions-config
> >
> >
On Mon, Dec 03, 2018 at 06:53:22PM +0100, Duy Nguyen wrote:
> On Sat, Dec 01, 2018 at 03:02:09PM -0500, Jeff King wrote:
> > I sometimes add "x false" to the top of the todo list to stop and create
> > new commits before the first one.
>
> And here I've been doi
On Mon, Dec 03, 2018 at 08:01:44PM +0100, Johannes Schindelin wrote:
> > In this sort of situation, I often whish to be able to do nested rebases.
> > Even more because it happen relatively often that I forget that I'm
> > working in a rebase and not on the head, and then it's quite natural
> >
On Mon, Dec 03, 2018 at 02:31:37PM +, Phillip Wood wrote:
> > How would I move past the test that fails to continue? I guess "git
> > rebase --edit-todo" and then manually remove it (and any other remaining
> > test lines)?
>
> Perhaps we could teach git rebase --skip to skip a rescheduled
On Mon, Dec 03, 2018 at 11:23:56AM -0800, Matthew DeVore wrote:
> Put the allow_exclude_promisor_objects flag in setup_revision_opt. When
> it was in rev_info, it was unclear when it was used, since rev_info is
> passed to functions that don't use the flag. This resulted in
> unnecessary setting
On Mon, Dec 03, 2018 at 11:10:49AM -0800, Matthew DeVore wrote:
> > > + memset(_r_opt, 0, sizeof(s_r_opt));
> > > + s_r_opt.allow_exclude_promisor_objects = 1;
> > > + setup_revisions(ac, av, , _r_opt);
> >
> > I wonder if a static initializer for setup_revision_opt is worth it. It
> > would
On Sat, Dec 01, 2018 at 09:28:47PM -0500, Eric Sunshine wrote:
> On Sat, Dec 1, 2018 at 3:02 PM Jeff King wrote:
> > On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote:
> > > In reality, I think that it would even make sense to change the default to
> > &
On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote:
> > > Would it not make more sense to add a command-line option (and a config
> > > setting) to re-schedule failed `exec` commands? Like so:
> >
> > Your proposition would do in most cases, however it is not possible to
> >
On Wed, Nov 28, 2018 at 03:56:29PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Thu, Nov 22 2018, Jeff King wrote:
>
> > On Thu, Nov 22, 2018 at 02:17:01AM -0800, Carlo Arenas wrote:
> >> PS. upstreaming the PERL_PATH fix is likely to be good to do soonish
> >&
On Wed, Nov 28, 2018 at 02:27:08PM +0100, SZEDER Gábor wrote:
> > Curiously, the act.err file also has 54 NUL bytes before the "fatal:"
> > message.
>
> I think those NUL bytes come from the file system.
>
> The contents of 'act.err' from the previous test ('fetch gzipped
> empty') is usually:
On Tue, Nov 27, 2018 at 09:48:57PM +0100, René Scharfe wrote:
> > +static int quick_has_loose(struct repository *r,
> > + const unsigned char *sha1)
> > +{
> > + int subdir_nr = sha1[0];
> > + struct object_id oid;
> > + struct object_directory *odb;
> > +
> > +
On Fri, Nov 30, 2018 at 05:32:47PM -0800, Matthew DeVore wrote:
> > Speaking of which, would this flag work better as a field in
> > setup_revision_opt, which is passed to setup_revisions()? The intent
> > seem to be to influence how we parse command-line arguments, and that's
> > where other
On Sat, Dec 01, 2018 at 06:07:57PM +0100, H.Merijn Brand wrote:
> When $PATH contains the current directory as .:PATH, PATH:., PATH:.:PATH,
> or (maybe worse) as :PATH, PATH:, or PATH::PATH - as an empty entry is
> identical to having dot in $PATH - this test used to fail
Good catch. The test
On Sun, Nov 25, 2018 at 11:02:05AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I do also think in the long run we should be fixing the "unreachable
> > always become loose" issues.
>
> I think I've seen an idea of collecting them into a garbage
On Sun, Nov 25, 2018 at 11:22:47PM +0100, SZEDER Gábor wrote:
> > The following fixes it, but I am not sure if this is the ideal
> > solution.
>
> Currently this is the only test that looks at 'daemon.log', but if we
> ever going to add another one, then that will be prone to the same
> issue.
>
On Sun, Nov 25, 2018 at 10:01:38PM +, Thomas Gummerer wrote:
> On 11/25, Torsten Bögershausen wrote:
> > After running the "Git 2.20-rc1" testsuite here on a raspi,
> > the only TC that failed was t5570.
> > When the "grep" was run on daemon.log, the file was empty (?).
> > When inspecting
On Sat, Nov 24, 2018 at 04:47:19PM +0900, Junio C Hamano wrote:
> I do agree that forcing the parent to wait, like you described in
> the comment, would be far more preferrable, [...]
Stray processes can sometimes have funny effects on an outer test
harness, too. E.g., I think I've seen hangs
On Fri, Nov 23, 2018 at 01:38:21AM +0200, Max Kirillov wrote:
> From: Jeff King
>
> Some systems do not have perl installed to /usr/bin. Use the variable
> from the build settiings, and call perl directly than via shebang.
>
> Signed-off-by: Max Kirillov
> ---
> Submit
On Thu, Nov 22, 2018 at 07:36:54PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > Yeah, my intent had been to circle back around to this, but I just
> > hadn't gotten to it. I'm still pondering a config option or similar,
> > though I remain unconvinced that the cases in which you've showed it
> >
On Sat, Nov 24, 2018 at 11:11:36AM +0900, Junio C Hamano wrote:
> > However, note that the cache-load for finding abbreviations _must_ have
> > the complete list. And has been loading it for some time. So if you run
> > "git-fetch", for example, you've already been running this code for
> >
ide helpers for
loose_objects_cache, 2018-11-12) moved the cache-loading code from
find_short_object_filename(), but forgot the line that releases the path
strbuf.
Reported-by: René Scharfe
Signed-off-by: Jeff King
---
sha1-file.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sha1-file.c b/sha1
On Mon, Nov 12, 2018 at 11:04:52AM -0800, Stefan Beller wrote:
> > for (odb = the_repository->objects->odb; odb; odb = odb->next) {
> > if (odb->local)
> > return odb->path;
> > }
> > return NULL; /* yikes? */
> >
> > ? That feels like it's making things more
On Thu, Nov 08, 2018 at 01:57:52PM -0500, Jeff Hostetler wrote:
> > Should we simply be disallowing sparse:path filters over upload-pack?
>
> The option to allow an absolute path over the wire probably needs more
> thought as you suggest.
>
> Having it in the traverse code was useful for local
On Sat, Nov 17, 2018 at 11:07:32PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I suspect it would be less confusing if the rewrite were inverted, like:
> >
> > [url "gh:"]
> > rewriteTo = https://github.com
> > rewritePrivate
>
On Tue, Nov 20, 2018 at 05:37:18PM +0100, Duy Nguyen wrote:
> > But in (b), we use the number of stored objects, _not_ the allocated
> > size of the objects array. So we can run into a situation like this:
> >
> > 1. packlist_alloc() needs to store the Nth object, so it grows the
> >
On Tue, Nov 20, 2018 at 10:06:57AM -0500, Derrick Stolee wrote:
> On 11/20/2018 4:44 AM, Jeff King wrote:
> > In cases like this I think it's often a good idea to have a perf test.
> > Those are expensive anyway, and we'd have the double benefit of
> > exercising the
On Wed, Nov 21, 2018 at 11:28:28AM -0800, Bryan Turner wrote:
> But that test code exists because Bitbucket Server provides a Java API
> [1][2] which allows third-party developers to easily build arbitrary
> Git commands to invoke for their own functionality. Setting
>
On Thu, Nov 22, 2018 at 11:16:38AM +0100, Ævar Arnfjörð Bjarmason wrote:
> > +test_expect_success 'log -G looks into binary files with textconv filter' '
> > + rm -rf .git &&
> > + git init &&
> > + echo "* diff=bin" > .gitattributes &&
> > + printf "a\0b" >data.bin &&
> > + git add
On Wed, Nov 21, 2018 at 09:52:27PM +0100, Thomas Braun wrote:
> diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
> index 69fc55ea1e..8c2558b07d 100644
> --- a/diffcore-pickaxe.c
> +++ b/diffcore-pickaxe.c
> @@ -144,6 +144,11 @@ static int pickaxe_match(struct diff_filepair *p, struct
>
On Thu, Nov 22, 2018 at 02:17:01AM -0800, Carlo Arenas wrote:
> Peff, could you elaborate on your "load testing" setup? which could
> give us any hints
> on what to look for?, FWIW I hadn't been able to reproduce the problem
> anywhere
> else (and not for a lack of trying)
The script I use is
On Thu, Nov 22, 2018 at 01:48:53PM +0100, Johannes Schindelin wrote:
> > So it's maybe do-able, but not quite as trivial as one might hope.
>
> A trivial alternative would be to recommend adding a man page for
> 3rd-party git-s.
>
> In other words, as soon as `git-sizer` is accompanied by
On Thu, Nov 22, 2018 at 11:58:36AM +0100, Greg Hurrell wrote:
> I was troubleshooting some breakage in some code that consumes the
> output of `git log --raw` and looking on two machines with different
> versions of Git just now I discovered the output format has changed
> somewhere between
On Tue, Nov 20, 2018 at 02:21:51PM +0100, SZEDER Gábor wrote:
> On Tue, Nov 20, 2018 at 08:06:16AM -0500, Ben Peart wrote:
> > >diff --git a/read-cache.c b/read-cache.c
> > >index 4ca81286c0..1e9c772603 100644
> > >--- a/read-cache.c
> > >+++ b/read-cache.c
> > >@@ -2689,6 +2689,15 @@ void
On Mon, Oct 22, 2018 at 06:13:42PM -0700, Matthew DeVore wrote:
> diff --git a/builtin/prune.c b/builtin/prune.c
> index 41230f8215..11284d0bf3 100644
> --- a/builtin/prune.c
> +++ b/builtin/prune.c
> @@ -120,6 +120,7 @@ int cmd_prune(int argc, const char **argv, const char
> *prefix)
>
On Tue, Nov 20, 2018 at 03:17:07PM -0800, Bryan Turner wrote:
> I've run 2.20.0-rc0 through the test matrix for Bitbucket Server on
> both Linux and Windows, and the only failures were related to this
> change:
>
> * "git branch -l " used to be a way to ask a reflog to be
>created while
On Wed, Nov 21, 2018 at 03:05:04PM +0100, Nickolai Belakovski wrote:
> I think if we move to making this atom just store worktree path, that
> needs to be implemented as a hashmap of refname->wtpath, which would
> also solve this string_list issue, correct? Just making sure I'm not
> missing
On Wed, Nov 21, 2018 at 02:54:34PM +0100, Marc Gonzalez wrote:
> If I specify the branch to explore, git grep prints a colon instead of
> a slash in the path:
>
> $ git grep arm,coresight-tmc master:Documentation/devicetree
> master:Documentation/devicetree:bindings/arm/coresight.txt:
On Wed, Nov 21, 2018 at 10:23:34AM +0100, Marc Strapetz wrote:
> From our GUI client we are invoking git operations on a possibly large set
> of files. This may result in pathspecs which are exceeding the maximum
> command line length, especially on Windows [1] and OSX [2]. To workaround
> this
On Tue, Nov 20, 2018 at 07:17:46AM -0500, Derrick Stolee wrote:
> > And I think that's a pattern with the delta-island code. What we really
> > care about most is that if we throw a real fork-network repository at
> > it, it produces faster clones with fewer un-reusable deltas. So I think
> > a
On Tue, Nov 20, 2018 at 12:25:38PM +0100, SZEDER Gábor wrote:
> > but we do not
> > usually bother to do so for our helper functions (like test_cmp).
>
> test_i18ngrep() does since your 03aa3783f2 (t: send verbose
> test-helper output to fd 4, 2018-02-22).
Oh, indeed. Usually I find myself
On Mon, Nov 19, 2018 at 10:40:53AM -0500, Derrick Stolee wrote:
> > 28b8a73080 builtin/pack-objects.c 2793) depth++;
> > 108f530385 builtin/pack-objects.c 2797) oe_set_tree_depth(_pack, ent,
> > depth);
>
> This 'depth' variable is incremented as part of a for loop in this patch:
>
> static
On Tue, Nov 20, 2018 at 05:45:28AM -0500, Jeff King wrote:
> On Tue, Nov 20, 2018 at 12:34:04AM +0100, SZEDER Gábor wrote:
>
> > > I do notice that many of the existing "FATAL:" errors use descriptor 5,
> > > which goes to stdout. I'm not sure if those should
On Tue, Nov 20, 2018 at 12:34:04AM +0100, SZEDER Gábor wrote:
> > I do notice that many of the existing "FATAL:" errors use descriptor 5,
> > which goes to stdout. I'm not sure if those should actually be going to
> > stderr (or if there's some TAP significance to those lines).
>
> I chose to
small effect. Some
experiments on the real-world git/git fork network at GitHub showed an
improvement of only 0.14% in the resulting clone size.
Signed-off-by: Jeff King
---
builtin/pack-objects.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/builtin/pack-objects.c b/b
but they'll be initialized by packlist_alloc() when it initializes
the entry in the "objects" array).
So it works, but only by chance. To be defensive, let's zero the array,
which matches the "unset" values which would be handed out by
oe_tree_depth() already.
Signed-off-by:
array to match pack->nr_alloc, not
pack->nr_objects. Likewise for the "layer" array from fe0ac2fb7f
(pack-objects: move 'layer' into 'struct packing_data', 2018-08-16),
which has the same bug.
Signed-off-by: Jeff King
---
pack-objects.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletion
This fixes a few bugs in the cc/delta-islands topic: one major, and two
minor.
Sadly, the major one was not caught by our test suite, and I'm not sure
how to remedy that. The problem is a memory management one, and happens
only when you have a reasonably large number of objects. So it triggers
On Mon, Nov 19, 2018 at 11:36:08AM -0800, Carlo Arenas wrote:
> tests 3-8 seem to fail because perl is hardcoded to /urs/bin/perl in
> t5562/invoke-with-content-length.pl, while I seem to be getting some
> sporadic errors in 9 with the following output :
>
> ++ env
On Mon, Nov 19, 2018 at 11:26:03PM +0200, Max Kirillov wrote:
> On Mon, Nov 19, 2018 at 11:36:08AM -0800, Carlo Arenas wrote:
> > NO_CURL reflects the build setting (for http support); CURL checks for
> > the curl binary, but as Ævar points out the requirements must be from
> > somewhere else
On Mon, Nov 19, 2018 at 02:28:18PM +0100, SZEDER Gábor wrote:
> The 'test_cmp_rev' helper is merely a wrapper around 'test_cmp'
> checking the output of two 'git rev-parse' commands, which means that
> its output on failure is not particularly informative, as it's
> basically two OIDs with a bit
On Mon, Nov 19, 2018 at 02:13:26PM +0100, SZEDER Gábor wrote:
> Send these "bug in the test script" error messages directly to the
> test scripts standard error and thus to the terminal, so those bugs
> will be much harder to overlook. Instead of updating all ~20 such
> 'error' calls with a
On Mon, Nov 19, 2018 at 11:21:38AM -0500, Jeff King wrote:
> > + if (use_delta_islands) {
> > + const char *p;
> > + unsigned depth = 0;
> > + struct object_entry *ent;
> > +
> > + for (p = st
On Mon, Nov 19, 2018 at 10:40:53AM -0500, Derrick Stolee wrote:
> > 2fa233a554 builtin/pack-objects.c 1512) hashcpy(base_oid.hash,
> > base_sha1);
> > 2fa233a554 builtin/pack-objects.c 1513) if
> > (!in_same_island(>idx.oid, _oid))
> > 2fa233a554 builtin/pack-objects.c 1514) return 0;
>
> These
On Sun, Nov 18, 2018 at 08:51:52PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > But this also reveals an interesting thing: even though we walk on a
> > tree, we check attributes from _worktree_ (and optionally fall back to
> > the index). This is how attributes are implemented since forever. I
> >
On Tue, Nov 13, 2018 at 06:04:15PM -0500, _g e r r y _ _l o w r y _ wrote:
> Examples:
>
> {me, extreme often, Windows} very granular, with a brief yet appropriate
> comment [like narrating a story] per commit-i change a few
> lines of code,
> Alt+Tab to Git Bash, Git Add/Commit,
> Alt+Tab
On Sun, Nov 18, 2018 at 10:02:02PM +0100, Sven Strickroth wrote:
> This also removes an implicit conversion from size_t (unsigned) to int
> (signed).
>
> _stricmp as well as _strnicmp are both available since VS2012.
Once upon a time we had problems with taking a function pointer of
strcasecmp
On Sat, Nov 17, 2018 at 04:46:22PM +0900, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> >> $ git request-pull HEAD^ git://foo.example.com/example | grep example
> >> ssh://bar.example.com/example
> >>
> >> I think that if we use the "principle of least surprise," insteadOf
> >>
On Fri, Nov 16, 2018 at 08:22:11PM +0100, Ævar Arnfjörð Bjarmason wrote:
> So maybe we should just document this interface better. It seems one
> implicit dependency is that we expect a manpage for the tool to exist
> for --help.
Yeah, I think this really the only problematic assumption. The
trigger (the other likely
errors are write() problems like ENOSPC). Note that it would already
pass on non-Windows systems (because they are happy to unlink an
already-open file).
Based-on-a-patch-by: Gaël Lhez
Signed-off-by: Jeff King
---
bundle.c| 39 ++
On Fri, Nov 16, 2018 at 02:09:07PM +0900, Junio C Hamano wrote:
> >> I see problems in both directions:
> >>
> >> - sorting by "objectname" works now, but it's marked with SOURCE_OBJ,
> >>and would be forbidden with your patch. I'm actually not sure if
> >>SOURCE_OBJ is accurate; we
for this issue.
Signed-off-by: Josh Steadmon
Signed-off-by: Jeff King
---
remote-curl.c | 3 +++
t/lib-httpd.sh | 1 +
t/lib-httpd/apache.conf | 4
t/lib-httpd/error-smart-http.sh | 3 +++
t/t5551-http-fetch-smart.sh | 5 +
5 files changed
On Thu, Nov 15, 2018 at 11:59:45PM -0800, Elijah Newren wrote:
> This is a series of small fixes and features for fast-export and
> fast-import, mostly on the fast-export side.
>
> Changes since v2 (full range-diff below):
> * Dropped the final patch; going to try to use Peff's suggestion of
>
20", for example).
Let's tighten this check to use strcmp(). Note that we don't need to
worry about a trailing newline here, because the ptk-line code will have
chomped it for us already.
Signed-off-by: Jeff King
---
remote-curl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
http-protocol.txt, l. 247
Helped-by: Josh Steadmon
Signed-off-by: Jeff King
---
remote-curl.c | 93 ---
1 file changed, 59 insertions(+), 34 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index 762a55a75f..dd9bc41aa1 100644
--- a/remote
On Thu, Nov 15, 2018 at 01:51:52PM -0800, Josh Steadmon wrote:
> > This patch tightens both of those (I also made a few stylistic tweaks,
> > and added the ERR condition to show where it would go). I dunno. Part of
> > me sees this as a nice cleanup, but maybe it is better to just leave it
> >
1 - 100 of 13736 matches
Mail list logo
