Here's a solution that depends only/mostly on blob contents: 1) construct the ident of the blob via an `(echo -e -n "blob <size>\0" ; cat file) | sha1sum` equivalent if an $Id$ string is not found in its contents, 2) look up the earliest commit with that blob hash at that path, and 3) use the reflog metadata from that earliest commit. Then when switching from C-to-A or C-to-B, F will have the same contents as a noop switch when switching A-to-B from C-to-A (although, conceivably, you may get a commit that is in neither A nor B, but you will have the earliest introduction of that file at that state). In other words, always use the earliest occurrence of a specific content at a given path, earliest commit wins irrespective of branches. Not the most elegant solution. I may have to go back and let these people know that outside of build scripts they can't get what they think they want. Thanks! :D On Wed, Nov 12, 2014 at 12:30 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Derek Moore <derek.p.moore@xxxxxxxxx> writes: > >> I have a case where I would like to smudge files according to the >> reflog information of the switching-to branch. > > Don't do that. > > When you have branches A, B and C, and a path F is the same between > branches A and B but different in branch C, if you start from branch > C and switch to branch A, F will be updated and obtain your smudge > tailored for "branch A's instance of F". > > 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"). > > In short, do not make clean/smudge depend on anything but blob > contents. -- 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