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 <[EMAIL PROTECTED]> wrote:
In message <[EMAIL PROTECTED]>, "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.
_______________________________________________ unionfs mailing list: http://unionfs.filesystems.org/ [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
