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
-
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
