Re: [PATCH] fast-export: Allow pruned-references in mark file

From: Antoine Pelisse <apelisse@gmail.com>
Date: Nov 26, 2012, 20:04 UTC
Message-ID: <CALWbr2x4aia4DcdnmfEEBsZwCYasTEp2Jc0jwJgvsUqWSDaWTQ@mail.gmail.com>
In-Reply-To: <7vhaoctg6i.fsf@alter.siamese.dyndns.org>

Show 8 quoted lines

> 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.