Martin Langhoff [off-list ref] writes:
On 1/9/06, Brown, Len [off-list ref] wrote:
quoted
Perhaps the tools should try to support what "a lot of people"
expect, rather than making "a lot of people" do extra work
because of the tools?
I think it does. All the tricky stuff that David and Junio have been
discussing is actually done very transparently by
git-rebase <upstream>
Now, git-rebase uses git-format-patch <options> | git-am <options> so
it sometimes has problems merging.
Careful. I do not think rebase works across merges at all.
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 8 Jan 2006, Junio C Hamano wrote:
Careful. I do not think rebase works across merges at all.
Right. You have to do one or the other (rebase your changes to another
tree _or_ merge another tree into your changes), but not mix the two.
Linus
I'll try to update the using-topic-branches document to capture this.
Some of the problem is that it doesn't quite capture what I'm doing
with my test/release branches.
My release branch really is just used as a transfer point to Linus.
I usually[1] don't leave patches sitting in "release" for long enough
that I'll be tempted to merge in from Linus ... once I decide that
some patches are ready to go to Linus I'll update "release" from Linus
(which will be a fast-forward, so no history) merge in the topic
branches, do one final sanity build, push to kernel.org and send
the "please pull" e-mail.
The huge majority of my "automatic update from upstream" merges
go into my test branch ... which never becomes part of the real
history as I never ask Linus to pull from it.
-Tony
[1] Sometimes I goof on this because I forget that I've applied
a trivial patch directly to the release branch without going through
a topic branch. I think I'll fix my update script to check for this case.