> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
