Derek Moore <derek.p.moore@xxxxxxxxx> writes:
>> But if you then switch to B from that state, F will not even be
>> modified (i.e. it will keep the contents you prepared for "branch
>> A's instance of F").
>
> Or: the post-commit hook used in the workaround looks up the prior
> branch via @{-1}, finds all files common between @ & @{-1} that don't
> share a latest commit, deletes those files and replaces them singly
> with the results of git-archive using the latest commits of those
> files relative to @. ("All files common between @ & @{-1}" would need
> to be either all non-locally-modified files or making use of git-stash
> {save,pop} to preserve local modifications.) All this assumes having
> reversible $Format$ strings, so the clean filter can restore the
> proper $Format$ string.
>
> Might be worth doing...
I still do not see what you are trying to record in the checked out
source files with your smudge filter, so I won't comment if it might
be "worth" doing.
Your use of reflog suggests me that whatever you are recording
depends on how you acquired your history in your specific repository
you work in, and your result is not reproducible by other people who
work with you by fetching from a repository that is different from
the repository you work in. E.g. perhaps you have a repository at
GitHub and push into there, and others fetch from there into their
repository. What is in their reflog has no relation to what you
have in your reflog.
That's the nature of distrubuted life. More generally, in a
distributred world with merges, even between two people who agree
that the tip of the 'master' branch of the project is at a certain
commit, there is no single sensible answer to the question "which
commit changed this path last?" We wouldn't mind anything you may
do to emulate RCS $Id$, but it would be futile.
--
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