[Unionfs] problem with unionfs git tree

[Simon Sasburg]

I'm by no means a git expert myself, but i tend to be a fast learner.
Reading through the git-rebase section of the git user manual, it
seems to me the obvious solution is for unionfs to use merge instead
of rebase to keep up with kernel releases.

This line i found elsewhere in the manual supports this:
"For true distributed development that supports proper merging,
published branches should never be rewritten."
This is from the "Problems with rewriting history" section, but rebase
also rewrites the history of a branch, so i think it also applies to
rebase.

Anyway, what is the reason you use rebase instead of merge?

Simon

On 7/4/07, Erez Zadok <ezk at cs.sunysb.edu> wrote:
> In message <981e6de60707031351g3bc1ea52m8b9f8e6782ddf211 at mail.gmail.com>, "Simon Sasburg" writes:
> > Hi,
> >
> > I've been trying to use the instructions on
> > http://www.filesystems.org/unionfs-git.html
> > to easily keep up to date with the latest version of the unionfs source.
> >
> > Its not working so well, when i do a git-pull to update to the latest
> > version, it fails with merge errors.
>
> Simon,
>
> Yes, this happens to us too.  The problem is that whenever we rebase our
> main branch against a newer -rc release, it changes the base code enough
> that a simple "git pull" no longer works.  You have to re-clone your copy.
>
> Now I don't profess to understand git well enough, but if someone knows of a
> trick to git-pull a rebased repository w/o resulting in that many conflicts,
> I'd love to know.
>
> One trick I've sometimes used is instead of git-pull-ing my checked out
> branch against a source repository which had been rebased, I go and rebase
> my *own* copy against Linus's tree.  Assuming you know git and can merge the
> occasional conflict, this is how you do it:
>
> $ git-fetch  \
>         git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> $ git-rebase FETCH_HEAD
>
> Cheers,
> Erez.
>