I have a case where I would like to smudge files according to the
reflog information of the switching-to branch.
This is difficult to achieve because updating HEAD to the new
switched-to refname or commit hash is the last step performed in a
checkout prior to calling the post-checkout hook, and smudge filters
process content during the rewriting of the index and work-tree before
HEAD is updated.
I believe this weakness of checkout & filters also exposes a crash
consistency concern. Suppose power is lost during a long-running
checkout while the index/worktree is being updated but before the new
HEAD file is written.
Upon coming back up, your git status will show edits against your
switching-from branch, and possibilities of recovery would rely on
your memory of what you were doing (instead of git-status reporting
"Incomplete checkout to {branch,commit}, 'git checkout --continue' to
continue").
Maybe git could record a CHECKOUT_HEAD at the start of a checkout,
then at the end of the commit update_refs_for_switch() would move
CHECKOUT_HEAD over top HEAD instead of rewriting HEAD (but,
presumably, a lot of logic in update_refs_for_switch() would have to
be relocated to when CHECKOUT_HEAD is written, other implications
notwithstanding).
Crash consistency aside, my workaround for filtering will probably be
to use a fake smudge filter that records the file paths of all
to-be-smudged files to a file under .git/, and then use a post-commit
hook that will process those files from within the newly checked-out
branch (where I'll be using git-archive to overwrite files).
Seems git could fix these two concerns in one fell swoop.
Thanks,
Derek
--
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