Hi Valdis,
"git mv" has you covered.
OK.
"foo_del.c has merged with foo.c in the next."
Best practice here is to generate a commit that *only* does
the merge (plus any #include surgery, etc to make a clean compile),
and explain it was a code migration in the commit comment.
Right.
I wonder if git-mv(1) adds meta-data to the pending commit, and if so
does that survive a merge of another commit that also moves to the same
destination file. I'm guessing not as it would otherwise multi-parent
graph of the destination file that I'm after.
On a related note, I'm planning on pushing my current
one-commit-per-new-foo.h as that way any dead ends in following `git
blame', etc., will end with a small commit that makes clear where to
pick up the trail. The alternative is to rebase and squash them all
into one honking "empty h/prototypes.h". If anyone has good reasons why
that's preferable, let me know.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers