Opened 9 years ago

Closed 9 years ago

#8633 closed Bugs (fixed)

fatal: reference is not a tree: 6f60f83963d0433e0f2cf85e57730944b3cf590c

Reported by: markmi@… Owned by: Thorsten Ottosen
Milestone: To Be Determined Component: assign
Version: Severity: Not Applicable
Keywords: boostorg/boost.git Cc:

Description

Given the stage of git conversion this might not be surprising but I figured I'd mention it...

Just a note reporting a clone error from an attempt to get a from scratch clone of https://github.com/boostorg/boost.git and what happens for libs/assign. (The command is from the SourceTree application.)

git -c diff.mnemonicprefix=false -c core.quotepath=false clone --recursive https://github.com/boostorg/boost.git /Users/markmi/Documents/boost fatal: reference is not a tree: 6f60f83963d0433e0f2cf85e57730944b3cf590c Unable to checkout '6f60f83963d0433e0f2cf85e57730944b3cf590c' in submodule path 'libs/assign'

The libs/assign/... working copy ended up empty. The rest cloned fine and each made a working copy from what I can tell. The libs/assign "Submodule path ... checked out ..." notice ended up missing (as expected given the above):

... Cloning into 'libs/array'... Submodule path 'libs/array': checked out 'f7dc34aafe94dc3bcf4665f69e623f6073ac0b3c' Cloning into 'libs/asio'... Submodule path 'libs/asio': checked out 'cfc2182105366f6ef6233519442531d7e6e8480a' Cloning into 'libs/assign'... Cloning into 'libs/atomic'... Submodule path 'libs/atomic': checked out '578d373dcc8e615201b667828ed27808ebb99763' ...

This happened both times that I tried 2013-May-30 (rather early in the morning pacific time each time).

In looking at the log for libs/assign the history was only for 8/18/04 and before until I checked off "Follow renamed files". Then more from 8/18/04 and up to a 11/5/07 check-in showed up in the display of the log. Without the check off 6f60f83963d0433e0f2cf85e57730944b3cf590c is the next-to-last 8/18/04 one shown.

In another place SourceTree listed:

-Subproject commit 6f60f83963d0433e0f2cf85e57730944b3cf590c

+Subproject commit 109f5373b70c6aac0d599a96553f5febf7f1ac02-dirty

Might the super-project have had a push without the subproject having had its matching push?

Change History (2)

comment:1 by Mark Millard <markmi@…>, 9 years ago

My "next-to-last" wording should have just said "last". Further identification of the Changeset and Subproject commit hunks leading up to and beyond the problem is as follows (the reference is not a tree number in bold):

ff84c31 8/12/04 empty log message
-Subproject commit 59d60810a016d37a1d45f6af7effb8435910e915
+Subproject commit 11501db69883143483f9629ed10ca43f6d223470

85fefda 8/18/04 removing assign
Subproject commit 91c6e822c189962133f801e4803fb88581e7e46d

9518ed6 8/18/04 empty log message
Subproject commit 6f60f83963d0433e0f2cf85e57730944b3cf590c

137e7c3 8/18/04 empty log message
-Subproject commit 11501db69883143483f9629ed10ca43f6d223470
+Subproject commit b5b4cdf6d35c43f7f8570329910e8553148708ff

Note the "removing assign" Changeset description in the Changeset just before the bold number's Changeset.

137e7c3 and beyond is not visible without "Follow renamed files" checked off in SourceTree for Log: libs/assign. 9518ed6 is visible without the check box.

In the libs/assign master does not include 91c6e82 or anything dated before that one. Instead 91c6e82 is the last commit on backups/sandbox/truck@2273. None of those are on the master branch. 6f60f83 is missing.

comment:2 by Steven Watanabe, 9 years ago

Resolution: fixed
Status: newclosed

Whatever the problem was, it doesn't seem to be an issue with the final conversion.

Note: See TracTickets for help on using tickets.