On Mon, Nov 26, 2012 at 9:04 PM, Antoine Pelisse <apelisse@xxxxxxxxx> wrote: >> I am not sure I follow the above, but anyway, I think the patch does >> is safe because (1) future "fast-export" will not refer to these >> pruned objects in its output (we have decided that these pruned >> objects are not used anywhere in the history so nobody will refer to >> them) and (2) we still need to increment the id number so that later >> objects in the marks file get assigned the same id number as they >> were assigned originally (otherwise we will not name these objects >> consistently when we later talk about them). > > I fully agree on (1), not so much on (2) though. > > I have the following behavior using my patch and running that script > that doesn't look correct. > > echo "Working scenario" > git init test && > (cd test && > git commit --allow-empty -m "Commit mark :1" && > git commit --allow-empty -m "Commit mark :2" && > git fast-export --export-marks=MARKS master > /dev/null && > cat MARKS && > git reset HEAD~1 && > sleep 1 && > git reflog expire --all --expire=now && > git prune --expire=now && > git commit --allow-empty -m "Commit mark :3" && > git fast-export --import-marks=MARKS \ > --export-marks=MARKS master > /dev/null && > cat MARKS) && > rm -rf test > > echo "Non-working scenario" > git init test && > (cd test && > git commit --allow-empty -m "Commit mark :1" && > git commit --allow-empty -m "Commit mark :2" && > git fast-export --export-marks=MARKS master > /dev/null && > cat MARKS && > git reset HEAD~1 && > sleep 1 && > git reflog expire --all --expire=now && > git prune --expire=now && > git fast-export --import-marks=MARKS \ > --export-marks=MARKS master > /dev/null && > git commit --allow-empty -m "Commit mark :3" && > git fast-export --import-marks=MARKS \ > --export-marks=MARKS master > /dev/null && > cat MARKS) && > rm -rf test > > outputs something like this: > Working scenario > Initialized empty Git repository in /home/antoine/test/.git/ > [master (root-commit) 6cf350d] Commit mark :1 > [master 8f97f85] Commit mark :2 > :1 6cf350d7ecb3dc6573b00f839a6a51625ed28966 > :2 8f97f85e1e7badf6a3daf411cf8d1133b00d522e > [master 21cadfd] Commit mark :3 > warning: Could not read blob 8f97f85e1e7badf6a3daf411cf8d1133b00d522e > :1 6cf350d7ecb3dc6573b00f839a6a51625ed28966 > :3 21cadfd87d90c05ce8770c968e5ed3d072ead4ae > Non-working scenario > Initialized empty Git repository in /home/antoine/test/.git/ > [master (root-commit) 5b5f7ec] Commit mark :1 > [master b224390] Commit mark :2 > :2 b224390daee199644495c15503882eb84df07df5 > :1 5b5f7ec77768393aab2a0c2c11b4b8f7773f8678 > warning: Could not read blob b224390daee199644495c15503882eb84df07df5 > [master 181a774] Commit mark :3 > :1 5b5f7ec77768393aab2a0c2c11b4b8f7773f8678 > :2 181a7744c6d3428edb01a1adc9df247e9620be5f > > Both "commit mark :2" and "commit mark :3" end up being marked :2. > Any tool like git-remote-hg that is using a mapping from mark <-> hg changeset > could then fail. I don't understand. "commit mark :2" 'git fast-export' would never point to that object again, the new commit would override that mark: commit refs/heads/master mark :2 ... commit mark :3 Then 'git remote-hg' should override that mark as well. But it doesn't matter, because that would be the case only for the last object, as soon as you find another valid object, that object's mark will be considered the last one. And what Junio said is consistent with what you want: last_idnum should be updated even if the object is not valid. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html