On Tue, Jul 29, 2014 at 11:06:25AM +1000, Bryan Turner wrote:
On Tue, Jul 29, 2014 at 10:11 AM, Junio C Hamano gits...@pobox.com wrote:
OK, I pushed out updated 'maint' and 'master'. The former merges
a rebased version of jk/alloc-commit-id in to make the reorganize
the way we manage the
Using git diff-tree --stdin on 2.0.2 and 2.0.3 produces incorrect
commit messages.
Here's an example to reproduce the issue:
bturner@ubuntu:/tmp$ git init --bare test.git
Initialized empty Git repository in /tmp/test.git/
bturner@ubuntu:/tmp$ git clone test.git
Cloning into 'test'...
warning:
On 28/07/14 10:42, Bryan Turner wrote:
Using git diff-tree --stdin on 2.0.2 and 2.0.3 produces incorrect
commit messages.
Here's an example to reproduce the issue:
bturner@ubuntu:/tmp$ git init --bare test.git
Initialized empty Git repository in /tmp/test.git/
bturner@ubuntu:/tmp$ git
On Mon, Jul 28, 2014 at 07:42:16PM +1000, Bryan Turner wrote:
Running a git bisect between v2.0.1, which does not manifest this
issue, and v2.0.2 fingers the following commit:
bturner@ubuntu:~/Development/oss/git/git$ git bisect bad
c1b3c71f4b4571abb2b2a457122fd100dc9f7eb0 is the first bad
On Mon, Jul 28, 2014 at 06:35:04AM -0400, Jeff King wrote:
I haven't reproduced here yet, but this is almost certainly the bug
where lookup_unknown_object causes a bogus commit-index field (and
prior to the commit you found, diff-tree did not use commit-index).
The series that Junio has in
On Mon, Jul 28, 2014 at 8:44 PM, Jeff King p...@peff.net wrote:
On Mon, Jul 28, 2014 at 06:35:04AM -0400, Jeff King wrote:
I haven't reproduced here yet, but this is almost certainly the bug
where lookup_unknown_object causes a bogus commit-index field (and
prior to the commit you found,
Bryan Turner btur...@atlassian.com writes:
It looks like refs ending in a dot are now legal in 2.1.0? Is that
intentional? A quick git bisect is fingering:
bturner@ubuntu:~/Development/oss/git/git$ git bisect bad
745224e04a03e4544c58d5d38d3c54f67100f8eb is the first bad commit
commit
On Mon, Jul 28, 2014 at 08:35:52AM -0700, Junio C Hamano wrote:
I am tempted to revert that series; it already caused oops, this
needs a further fix before it hit 'master' at least once, and we do
not want any more headaches at this point in the release cycle.
Yeah, that sounds reasonable to
Jeff King p...@peff.net writes:
On Mon, Jul 28, 2014 at 07:42:16PM +1000, Bryan Turner wrote:
Running a git bisect between v2.0.1, which does not manifest this
issue, and v2.0.2 fingers the following commit:
bturner@ubuntu:~/Development/oss/git/git$ git bisect bad
On Mon, Jul 28, 2014 at 10:32:45AM -0700, Junio C Hamano wrote:
Junio, we should consider a v2.0.4 with that series, I think. This is a
pretty serious regression in diff-tree (I didn't even realize that the
buffer-slab work went into the maint series; that may have been a little
On Mon, Jul 28, 2014 at 01:37:34PM -0400, Jeff King wrote:
On Mon, Jul 28, 2014 at 10:32:45AM -0700, Junio C Hamano wrote:
Junio, we should consider a v2.0.4 with that series, I think. This is a
pretty serious regression in diff-tree (I didn't even realize that the
buffer-slab work
Jeff King p...@peff.net writes:
On Mon, Jul 28, 2014 at 01:37:34PM -0400, Jeff King wrote:
On Mon, Jul 28, 2014 at 10:32:45AM -0700, Junio C Hamano wrote:
Junio, we should consider a v2.0.4 with that series, I think. This is a
pretty serious regression in diff-tree (I didn't even
Junio C Hamano gits...@pobox.com writes:
Yeah, I'm fine with a straight revert, too (I think it is fine to keep
in master, though). I think jk/alloc-commit-id is built right on top of
the original commit-slab topic, so it should be easy to do either way.
Thanks for dealing with it.
On Tue, Jul 29, 2014 at 10:11 AM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Yeah, I'm fine with a straight revert, too (I think it is fine to keep
in master, though). I think jk/alloc-commit-id is built right on top of
the original commit-slab topic, so
14 matches
Mail list logo
