From: "Greg A. Woods" <woods@planix.com>
To: The Git Mailing List <git@vger.kernel.org>
Subject: "git merge" merges too much!
Date: Sat, 28 Nov 2009 22:21:25 -0500 [thread overview]
Message-ID: <m1NEaLp-000kn1C@most.weird.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2828 bytes --]
I'm trying to learn to use Git to manage local changes. I'm very new to
Git (hi all!), but not new at all to version tracking tools in general.
Hope I've found the right list on which to ask potentially naive
questions! I've been doing _lots_ of reading about Git, but I can't
seem to find anything about the problems I relate below.
One task I'm working on is to try to find the best way to merge changes
made from one branch to another, eg. to propagate local fixes from one
release to another.
However in at least one simple case "git merge" merges too much.
I have something like this started from a remote-cloned repository where
BL1.2 is a branch from the remote master HEAD, which happens to
correspond to a tag "TR1.2", the release-1.2 tag, and I've made three
local commits to my local BL1.2 branch: A, B, and C:
BL1.2 - A - B - C <- BL1.2 HEAD
/
master 1 - 2 - TR1.1 - 3 - 4 - 5 - TR1.2 <- master HEAD
(there are no "release" branches in this project, just tags on the
master branch to represent release points -- is there any way to get
"git log" to show which tags are associated with a given commit and/or
branch? The real project is freedesktop.org's xinit repo, but the real
tree is too messy to diagram here -- hopefully I've extracted the
essence of the problem correctly)
I now want to create a branch "BL1.1" and merge commits A, B, and C to it
in order to back-port my local fixes to the TR1.1 release. "TR1.1" is
simply a tag on the origin/master trunk.
I do the following:
git checkout -b BL1.1 TR1.1
git merge BL1.2
However this seems to merge all of 3, 4, and 5, as well as A, B, and C.
I think I can (barely) understand why it's doing what it's doing, but
that's not what I want it to do. However it looks like Git doesn't have
the same idea of a branch "base" point as I think I do.
Running "git log TR1.2..BL1.2" does show me exactly the changes I wish
to propagate, but "git merge TR1.2..BL1.2" says "not something we can
merge". Sigh.
How can I get it to merge just the changes from the "base" of the BL1.2
branch to its head?
Is using either git-cherry-pick or "git log -p | git-am", the only way
to do this? Which way best preserves Git's ability to realize if a
change has already been included on the target branch, if any?
Is this the kind of "problem" that drove the creators of Stacked-Git to
invent their tools?
Is there any way to get "git log --graph" (and/or gitk) to show me all
the branch heads, not just the current/specified one?
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]
next reply other threads:[~2009-11-29 3:31 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-29 3:21 Greg A. Woods [this message]
2009-11-29 5:14 ` "git merge" merges too much! Jeff King
2009-11-30 18:12 ` Greg A. Woods
2009-11-30 19:22 ` Dmitry Potapov
2009-12-01 18:52 ` Greg A. Woods
2009-12-01 20:50 ` Dmitry Potapov
2009-12-01 21:58 ` Greg A. Woods
2009-12-02 0:22 ` Dmitry Potapov
2009-12-02 10:20 ` Nanako Shiraishi
2009-12-02 20:09 ` Jeff King
2009-12-03 1:21 ` Git documentation consistency (was: "git merge" merges too much!) Greg A. Woods
2009-12-03 1:34 ` Git documentation consistency Junio C Hamano
2009-12-03 7:22 ` Greg A. Woods
2009-12-03 7:45 ` Jeff King
2009-12-03 15:24 ` Uri Okrent
2009-12-03 16:22 ` Marko Kreen
2009-12-09 19:56 ` Greg A. Woods
2009-12-03 2:07 ` Git documentation consistency (was: "git merge" merges too much!) Jeff King
2009-11-29 5:15 ` "git merge" merges too much! Junio C Hamano
2009-11-30 18:40 ` Greg A. Woods
2009-11-30 20:50 ` Junio C Hamano
2009-11-30 21:17 ` Dmitry Potapov
2009-12-01 0:24 ` Greg A. Woods
2009-12-01 5:47 ` Dmitry Potapov
2009-12-01 17:59 ` multiple working directories for long-running builds (was: "git merge" merges too much!) Greg A. Woods
2009-12-01 18:51 ` Dmitry Potapov
2009-12-01 18:58 ` Greg A. Woods
2009-12-01 21:18 ` Dmitry Potapov
2009-12-01 22:25 ` Jeff Epler
2009-12-01 22:44 ` Greg A. Woods
2009-12-02 0:10 ` Dmitry Potapov
2009-12-03 5:11 ` Greg A. Woods
2009-12-02 2:09 ` multiple working directories for long-running builds Junio C Hamano
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1NEaLp-000kn1C@most.weird.com \
--to=woods@planix.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.