"Contributors never merge" and preserving history

Hi folks,

I have a question about git philosophy. Yesterday I was on #git (thanks to those of you that were there and very helpful). This comment was made: [1]

<vmiklos> patch series are created by contributors while
          contributors never merge

Now, here's my question, posed in IRC and over at [2]:

  Say we started from a common base where line 10 of file X said "hi", I
  locally changed it to "foo", upstream changed it to "bar", and at
  merge time I decide that we were both wrong and change it to "baz". I
  don't want to lose the fact that I once had it at "foo", in case it
  turns out later that really was the right decision.

I understand that git projects that use a kernel-like development model -- which seems to be common -- do not want to know that I once had it at "foo". That is fine to me. But I want a local branch -- or a local *something* -- to store that, and make it convenient to access.

That can be done easily enough if I use git pull instead of git rebase to pull in upstream updates. I'll be committing a merge patch on every upstream update. I suppose I'm OK with that, though it's not ideal.

The canonical answer from #git seems to be "never pull", always use fetch and rebase when submitting patches upstream using git-format-patch.

I have tried various ways to somehow make rebase get along with merging, but have failed on that, mainly because merging confuses rebase's algorithm that figures out which patches have already been applied.

So, the question is: what is the best way to be able to keep a full local history, while still using format-patch to interact easily with upstream? I'm thinking the answer may involve a submission branch that uses squashing, but I'm not entirely certain.

And the corrolary: As upstream, how can I facilitate users that may wish to do this?

[1] http://colabti.org/irclogger/irclogger_log/git?date=2008-02-25,Mon&sel=66#l99 [2] http://changelog.complete.org/posts/690-Git-looks-really-nice,-until.....html