]> git.ipfire.org Git - thirdparty/git.git/commit - Documentation/git-fast-export.txt
fast-export: add --reference-excluded-parents option
authorElijah Newren <newren@gmail.com>
Fri, 16 Nov 2018 07:59:54 +0000 (23:59 -0800)
committerJunio C Hamano <gitster@pobox.com>
Sat, 17 Nov 2018 09:43:52 +0000 (18:43 +0900)
commit530ca19c02b1fa1d13195d24fc76c2926ceecdc2
treeeb088bd25a5e026e1d28c0b7d84a692595e507c5
parentfdf31b6369a4c66a2db743ee480f97daa239fc81
fast-export: add --reference-excluded-parents option

git filter-branch has a nifty feature allowing you to rewrite, e.g. just
the last 8 commits of a linear history
  git filter-branch $OPTIONS HEAD~8..HEAD

If you try the same with git fast-export, you instead get a history of
only 8 commits, with HEAD~7 being rewritten into a root commit.  There
are two alternatives:

  1) Don't use the negative revision specification, and when you're
     filtering the output to make modifications to the last 8 commits,
     just be careful to not modify any earlier commits somehow.

  2) First run 'git fast-export --export-marks=somefile HEAD~8', then
     run 'git fast-export --import-marks=somefile HEAD~8..HEAD'.

Both are more error prone than I'd like (the first for obvious reasons;
with the second option I have sometimes accidentally included too many
revisions in the first command and then found that the corresponding
extra revisions were not exported by the second command and thus were
not modified as I expected).  Also, both are poor from a performance
perspective.

Add a new --reference-excluded-parents option which will cause
fast-export to refer to commits outside the specified rev-list-args
range by their sha1sum.  Such a stream will only be useful in a
repository which already contains the necessary commits (much like the
restriction imposed when using --no-data).

Note from Peff:
  I think we might be able to do a little more optimization here. If
  we're exporting HEAD^..HEAD and there's an object in HEAD^ which is
  unchanged in HEAD, I think we'd still print it (because it would not
  be marked SHOWN), but we could omit it (by walking the tree of the
  boundary commits and marking them shown).  I don't think it's a
  blocker for what you're doing here, but just a possible future
  optimization.

Signed-off-by: Elijah Newren <newren@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/git-fast-export.txt
builtin/fast-export.c
t/t9350-fast-export.sh