LKML Archive on
help / color / mirror / Atom feed
From: "Björn Steinbrink" <>
To: Andi Kleen <>
Cc: Ingo Molnar <>,,,
	"H. Peter Anvin" <>
Subject: Re: More breakage in native_rdtsc out of line in git-x86
Date: Wed, 9 Jan 2008 23:09:48 +0100	[thread overview]
Message-ID: <20080109220948.GA2218@atjola.homenet> (raw)
In-Reply-To: <>

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.


  parent reply	other threads:[~2008-01-09 22:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-09  3:55 More breakage in native_rdtsc out of line in git-x86 Andi Kleen
2008-01-09  5:21 ` More breakage in native_rdtsc out of line in git-x86 II Andi Kleen
2008-01-09  9:09 ` More breakage in native_rdtsc out of line in git-x86 Ingo Molnar
2008-01-09 14:19   ` Andi Kleen
2008-01-09 15:22     ` Ingo Molnar
2008-01-09 15:51       ` Andi Kleen
2008-01-09 16:30         ` Ingo Molnar
2008-01-09 17:48           ` Andi Kleen
2008-01-09 20:25             ` Arjan van de Ven
2008-01-09 20:40               ` Andi Kleen
2008-01-09 20:57                 ` H. Peter Anvin
2008-01-09 22:09             ` Björn Steinbrink [this message]
2008-01-09 22:28               ` Andi Kleen
2008-01-09 22:35                 ` Harvey Harrison
2008-01-09 22:41                   ` Andi Kleen
2008-01-09 23:21                     ` Björn Steinbrink
2008-01-09 23:37                     ` Paolo Ciarrocchi
2008-01-11  5:21                       ` Cyrill Gorcunov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080109220948.GA2218@atjola.homenet \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).