On Wed, Aug 01, 2018 at 02:58:50AM +0200, René Scharfe wrote:
> Am 31.07.2018 um 23:06 schrieb Junio C Hamano:
> > Jeff King writes:
> >
> >> On Tue, Jul 31, 2018 at 01:23:04PM -0400, Jeff King wrote:
> >> ...
> >> So here it is fixed, and with a commit message. I'm not happy to omit a
> >> regr
On Tue, Jul 31, 2018 at 02:06:12PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Tue, Jul 31, 2018 at 01:23:04PM -0400, Jeff King wrote:
> > ...
> > So here it is fixed, and with a commit message. I'm not happy to omit a
> > regression test, but I actually couldn't come up with a min
Am 31.07.2018 um 17:50 schrieb Jeff King:
> On Tue, Jul 31, 2018 at 11:03:17AM -0400, George Shammas wrote:
>
>> Bisecting around, this might be the commit that introduced the breakage.
>>
>> https://github.com/git/git/commit/d8febde
>>
>> I really hope that it hasn't been broken for 5 years and I
Am 31.07.2018 um 23:06 schrieb Junio C Hamano:
> Jeff King writes:
>
>> On Tue, Jul 31, 2018 at 01:23:04PM -0400, Jeff King wrote:
>> ...
>> So here it is fixed, and with a commit message. I'm not happy to omit a
>> regression test, but I actually couldn't come up with a minimal one that
>> tickl
Jeff King writes:
> On Tue, Jul 31, 2018 at 01:23:04PM -0400, Jeff King wrote:
> ...
> So here it is fixed, and with a commit message. I'm not happy to omit a
> regression test, but I actually couldn't come up with a minimal one that
> tickled the problem, because we're playing around with heuris
On Tue, Jul 31, 2018 at 03:52:26PM -0400, George Shammas wrote:
> This is the fastest I ever seen an open source project respond to an issue
> I reported. Thanks for being awesome!
You're welcome. My speed is an inverse to how embarrassingly long we
carried the bug for. ;)
> > Signed-off-by: Jef
This is the fastest I ever seen an open source project respond to an issue
I reported. Thanks for being awesome!
On Tue, Jul 31, 2018 at 3:05 PM Jeff King wrote:
> On Tue, Jul 31, 2018 at 01:23:04PM -0400, Jeff King wrote:
>
> > On Tue, Jul 31, 2018 at 10:17:15AM -0700, Junio C Hamano wrote:
> >
On Tue, Jul 31, 2018 at 01:23:04PM -0400, Jeff King wrote:
> On Tue, Jul 31, 2018 at 10:17:15AM -0700, Junio C Hamano wrote:
>
> > Jeff King writes:
> >
> > > +...
> > > + } else if (cmp > 0) {
> > > /* path2 does not appear in one */
> > > + score += s
On Tue, Jul 31, 2018 at 10:17:15AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > +...
> > + } else if (cmp > 0) {
> > /* path2 does not appear in one */
> > + score += score_missing(two.entry.mode, two.entry.path);
> > +
Jeff King writes:
> +...
> + } else if (cmp > 0) {
> /* path2 does not appear in one */
> + score += score_missing(two.entry.mode, two.entry.path);
> + update_tree_entry(&two);
> + continue;
> +
On Tue, Jul 31, 2018 at 08:53:23AM -0700, Junio C Hamano wrote:
> George Shammas writes:
>
> > Bisecting around, this might be the commit that introduced the breakage.
> >
> > https://github.com/git/git/commit/d8febde
>
> Interesting. I've never used the "-s subtree" strategy without
> "-Xsubt
Jeff King writes:
> The problem introduced in that commit is that each iteration through the
> loop advances the tree pointers.
Ah, indeed.
The original used tree_entry_extract() and update_tree_entry()
separately, but the update does tree_entry() on both sides.
> So the assertion in that co
While debugging this, I did try -X subtree=src/ however the effect was the
same.
On Tue, Jul 31, 2018 at 11:53 AM Junio C Hamano wrote:
> George Shammas writes:
>
> > Bisecting around, this might be the commit that introduced the breakage.
> >
> > https://github.com/git/git/commit/d8febde
>
> I
George Shammas writes:
> Bisecting around, this might be the commit that introduced the breakage.
>
> https://github.com/git/git/commit/d8febde
Interesting. I've never used the "-s subtree" strategy without
"-Xsubtree=..." to explicitly tell where the thing should go for a
long time, so I am no
On Tue, Jul 31, 2018 at 11:03:17AM -0400, George Shammas wrote:
> Bisecting around, this might be the commit that introduced the breakage.
>
> https://github.com/git/git/commit/d8febde
>
> I really hope that it hasn't been broken for 5 years and I am just doing
> something wrong.
Unfortunately,
Bisecting around, this might be the commit that introduced the breakage.
https://github.com/git/git/commit/d8febde
I really hope that it hasn't been broken for 5 years and I am just doing
something wrong.
On Tue, Jul 31, 2018 at 10:09 AM George Shammas wrote:
> At work, we recently updated fro
At work, we recently updated from a massively old version of git (1.7.10)
to 2.18. There are a few code bases that use subtrees, and they seem to
have completely broke when trying to merge in updates.
I have confirmed that it works correctly in 1.7.10. The 2.18 behavior is
clearly incorrect.
git
17 matches
Mail list logo