On 2008.01.09 18:48:00 +0100, Andi Kleen wrote: > On Wed, Jan 09, 2008 at 05:30:18PM +0100, Ingo Molnar wrote: > > then you have a truly ancient x86.git repository ;-) > > I update only infrequently because frankly git's remote branch tracking > is a mess. At least it doesn't really work for x86#mm here. > > I usually have to blow away the repository and reclone > to get back to a sane state.
Someone in #git had a similar problem today. Conclusion was that x86/mm is not "stable" in the sense that commits are only added, instead history gets rewritten. That breaks pull/merge/"basic rebase". Basically, you'll want to "rebase --onto", taking your local commits from the old branch history to the new branch history. One way to make that bearable is to have two branches (or a branch and a tag). One branch is used to keep your work, the other branch (or tag) is used to "mark" where the old upstream ended and your work started. Assuming that your remote is called "x86", this could look like this: git branch myStuff x86/mm git branch myStuff_start x86/mm work work work commit commit commit git fetch x86 mm git rebase --onto x86/mm myStuff_start myStuff git branch -f myStuff_start x86/mm The rebase will take all of the commits that you added to myStuff, on top of the old x86/mm (referred to by myStuff_start) and try to apply them on top of the new x86/mm, updating myStuff to point to the rebased commits afterwards. Then myStuff_start is updated to point to the now current start of your stuff, so that you can do the rebase again later. That's not actually a problem of git's tracking branches, because they're not made for that style of work at all. For such stuff, rebase is the only useful option AFAIK. HTH, Björn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
