idea: git "came from" tags

Actors:
- public "upstream" repository
- public "local" repository
- end users tracking both

Situation:
- local starts by tracking upstream
- local makes changes, commits, and sends upstream
- users now tracking local ahead of upstream
- upstream makes modified commits
- local satisfied, wants to reset master to upstream/master

Problem:
- A merge will perpetually leave two parallel branches.  Even though
there are no longer any diffs, local/master cannot use the same
objects as upstream/master.
- A hard reset lets local/master return to sharing objects with
upstream/master; but this may break pulls or cause other problems for
users.

Proposed solution:
- Local adds a "came from" tag to upstream/master, leaves a tag on the
head of local/master, and does a hard reset from local/master to
upstream/master.  When a user tracking local/master does a pull, their
client detects a non-fast-forward, finds the came-from tag, and treats
it as a fast-forward.

Basically, this is a protocol to glue a "strategy ours" merge onto an existing tree. This way local can cleanly track upstream, with no added complexity in the nominal (no local changes) case.

Example:
Without this addition, local/master looks something like
u1 - u2 - u3 - u4 - u5 - u6 ...
   \- l1 - l2\+ m1 -   \+ m2\+ m3 ...

With this addition, local/master looks like
u1 - u2 - u3(tcf) - u4 - u5 - u6 ...
   \- l1 - l2 - t0
where
* u# = upstream changes
* l# = local changes
* m# = local merges (m1=u3, m2=u5, m3=u6, ...)
* the tcf tag points to t0, and t0 tags the end of the local mods

Pseudo-shell-code addition to git-pull:
fetch local/master
fast_forward=usual test whether local/master contains user/master
if test $fast_forward = no
then
   for tag in $fetched_tags # something like this or git-describe
   do
     if is_came_from($tag) && (came_from($tag) contains user/master)
     then
       fast_forward=yes
       break
     fi
   done
fi

Comments? I think this is completely implementable (though I'm not well-versed in git internals). Since it only triggers during non-fast-forward operations, it should have negligible performance impact.

Of course, it would be even better if somebody shows me how to do this with the current tools. Maybe I'm just doing it all wrong.

Thanks, Daniel