Re: How to cope with patches sanely
On Sat, 02 Feb 2008, Kumar Appaiah wrote:
> On Fri, Feb 01, 2008 at 06:06:04PM +0100, Raphael Hertzog wrote:
> > No, I said "rebase" and not merge.
> > See http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
> > (Note that this means that nobody should derive from upstream-patched as
> > the branch is regularly rewritten and one can't branch and later merge
> > from it)
> Dear Raphael,
> Here is where I want some explanation. Assume that my simple branches
> upstream: Pure upstream sources right from the orig.tar.gz
> master: Debian packaging on top of upstream (mostly ONLY debian/
> directory addition in comparison to upstream).
> In this simplistic case, should I have a new upstream version, should
> I update my upstream branch and merge it into master, or rebase
> master? While rebasing ensures that all my changes apply over the new
> upstream release, what is the reason I shouldn't merge?
If you don't touch upstream sources and only add a debian directory, then
the difference between merge and rebase is not important. Both would work
equally well (since you will never have a conflict).
I was explaining how I would handle patches on top of upstream code. And
where you have to update the patches when the upstream code changes.
Rebase is exactly the process of "updating patches" while merge is really
"keep the old patch and add fixups patch to reconcile after conflicts".
Le best-seller français mis à jour pour Debian Etch :