Re: "git merge" merges too much!

From: Greg A. Woods <woods@planix.com>
Date: Nov 30, 2009, 18:12 UTC
Message-ID: <m1NFAji-000kn2C@most.weird.com>
In-Reply-To: <20091129051427.GA6104@coredump.intra.peff.net>

Thank you very much for confirming my understanding of why "git merge" was merging more changes than I had desired it to merge.

The way "git merge" works does concern me somewhat though as I try to figure out how I might use "topic" branches to develop local features and then merge them onto each supported release branch. Some guides I've read suggest this methodology, but I'm sure how well this will work, even when the remote project uses release branches to manage official releases. Perhaps I really should look at StGit, but I'm not sure about it either.

At Sun, 29 Nov 2009 00:14:27 -0500, Jeff King <peff@peff.net> wrote:
Subject: Re: "git merge" merges too much!

Show 7 quoted lines

> 
> On Sat, Nov 28, 2009 at 10:21:25PM -0500, Greg A. Woods wrote:
> > 
> > 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
> 
> Try "git log --decorate".

Excellent!  That's exactly what I was looking for.

(From a first pass through the documentation I would never have guessed that "tags" were also a form of "refs". All these different names for things in the Git vs. many other VCS's, like "ref names" _really_ confusing to anyone like me with too much experience using those other revision control systems. Part of the problem is that Git documentation seems to be two-or-more minded about several of its concepts and features. Even the gitglossary(7) is somewhat inconsistent on how it uses "ref" and "refs". Perhaps all that's needed is some firm editing and clean-up of the manuals and documentation by a good strong technical editor.)

> Yes, you must cherry-pick or use rebase (which is a more featureful
> version of the pipeline you mentioned).

"git rebase" will not work for me unless it grows a "copy" option , i.e. one which does not delete the original branch (i.e. avoids the "reset" phase of its operation). This option would likely only make sense when used with the "--onto" option, I would guess.

"git rebase -i" would certainly give me all the control I could possibly want when copying changes from branch to branch.

It likely wouldn't make sense to base this new "copy" feature directly on "git rebase" though, especially in light of all the warnings about how "git rebase" isn't friendly when applied to already published branches. I think in theory this "copy" feature won't cause problems for already-published branches.

Perhaps it should be a whole new top-level command such as "git copy", but then it's so much like "git merge" I'm not sure.... Ideally if "git merge" could be taught how to work with just the changes from the base of a branch then it would do what I'm looking for directly.

> The resulting commits will have different commit ids, but git generally
> does a good job at merging such things, because it looks only at the
> result state and not the intermediate commits.  If both sides have made
> an equivalent change, then there is no conflict.

Show 5 quoted lines

> > 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?
> 
> Try "--all" with either gitk or "git log". Or if you want a subset of
> heads, just name them.

Awsome!  Those options provide just what I wanted to see!

(git-log(1) is worse than ls(1) for having too many options, but worst of all in the release I'm still using it doesn't respond sensibly nor consistently with other commands when given the "-?" option.)

-- 
						Greg A. Woods

+1 416 218-0098                VE3TCP          RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>      Secrets of the Weird <woods@weird.com>